Quando 11 controles falham: o que a explosão da Shell Monaca ensina sobre barreiras de engenharia e HMI

Em resumo: onze controles não significavam onze barreiras independentes

A explosão de 4 de junho de 2025 na Furnace 5 da Shell Polymers Monaca ocorreu depois que gás craqueado inflamável retornou do sistema a jusante para a caixa de fogo do forno e encontrou pilotos acesos. A U.S. Chemical Safety Board (CSB) determinou que a abertura inadvertida simultânea de duas válvulas motorizadas de isolamento criou esse caminho de fluxo reverso.

O número que chama atenção no relatório final é onze: a CSB catalogou onze controles administrativos que deveriam prevenir ou mitigar o cenário. No contexto real do evento, eles falharam, estavam indisponíveis, não se aplicavam à configuração ou não foram executados e interpretados como necessário.

Isso não equivale a dizer que a instalação possuía onze barreiras independentes e confiáveis. Várias medidas dependiam das mesmas pessoas reconhecerem sinais, entenderem o modo operacional, consultarem interfaces semelhantes e corrigirem a trajetória a tempo. Contar controles é simples; demonstrar independência, disponibilidade e capacidade de interromper a progressão é engenharia.

O que aconteceu em Monaca

A unidade de craqueamento de etano havia iniciado operações em novembro de 2022. Durante uma parada em 2025, a Shell decidiu limpar pela primeira vez os coke traps dos sete fornos. Esses equipamentos recebem resíduos sólidos de coque para evitar que sigam pelo processo. Para limpar o coke trap da Furnace 5, duas válvulas motorizadas de 36 polegadas — motor-operated valves, ou MOVs — foram fechadas em série entre o forno e a quench tower.

No retorno da Furnace 5 ao serviço, um engenheiro de processo, automação, controle e otimização — função que o relatório chama de PACO — comandou as válvulas a partir de uma estação de engenharia. Era a primeira vez que ele executava aquela tarefa. A sequência exigia remover uma condição de dupla isolação enquanto outros fornos já produziam gás craqueado e alimentavam o sistema comum a jusante.

A tela de lógica exibia três válvulas visualmente semelhantes, com tags diferentes principalmente no último dígito. O job aid usado na tarefa possuía passos fora da sequência operacional. Depois de uma mudança de modo, a tela se atualizou e voltou a uma posição que favoreceu a seleção da MOV errada. As duas válvulas de isolamento ficaram abertas ao mesmo tempo.

O header e a quench tower operavam pressurizados, enquanto o forno estava em configuração de menor pressão. O gás retornou para a firebox. Aproximadamente seis minutos depois do comando inadvertido, cerca de 641 libras de gás craqueado haviam se acumulado, segundo a estimativa apresentada pela CSB. O gás encontrou os pilotos acesos, explodiu, rompeu uma parede da caixa de fogo e gerou incêndio.

Consequências graves, embora sem vítimas

Quinze empregados evacuaram a área e não houve feridos reportados. Um contratado ficou preso em um elevador próximo à Furnace 5 e precisou ser resgatado. A ausência de mortes ou lesões não reduz a gravidade do mecanismo: o relatório registra um cenário com potencial reconhecido para múltiplas fatalidades.

A Shell estimou US$ 95 milhões em danos materiais. O relatório também registra aproximadamente 5.100 libras de etileno e produtos de combustão liberados. A Furnace 5 foi reconstruída e voltou ao serviço em 22 de janeiro de 2026, cerca de sete meses após o evento.

Esses números ajudam a dimensionar a consequência, mas o aprendizado não depende de dramatização. O caso interessa porque mostra como uma sequência tecnicamente plausível atravessou procedimentos, alarmes, interface e decisões sem encontrar uma barreira de engenharia válida naquele modo.

Não foi apenas ‘clicar na válvula errada’

A CSB atribuiu a causa à abertura inadvertida simultânea das duas MOVs usadas para isolar o forno. Também identificou fatores contribuintes: designação de um profissional com experiência limitada naquela tarefa e conhecimento limitado do processo; controles administrativos ineficazes; e deficiências na interface homem-máquina do sistema instrumentado de segurança.

A ação na interface foi a etapa proximal — o movimento imediatamente anterior à criação do caminho perigoso. Mas ela não explica sozinha por que o comando era plausível, por que a tela favorecia confusão, por que alarmes relevantes estavam suprimidos, por que o procedimento não correspondia à configuração e por que não existia uma barreira automática capaz de manter uma das válvulas fechada.

Reduzir o evento a erro humano encerra a investigação no ponto em que ela deveria começar. A pergunta útil não é apenas quem abriu a válvula, mas quais condições permitiram que uma seleção equivocada se convertesse em fluxo reverso para um forno com fonte de ignição sem interrupção independente.

Onze controles — mas quão independentes eram?

O relatório descreve políticas, procedimentos, alarmes, execução em campo, job aid, regra de bypass, parada de emergência e controle de área. Cada medida pode ter valor. O problema é considerar o conjunto robusto apenas porque a lista é longa.

Uma barreira independente precisa ter função clara, ser capaz de atuar no cenário, estar disponível no modo real e não compartilhar de forma excessiva o mesmo mecanismo de falha. Procedimento, treinamento, alarme e resposta do operador podem depender da mesma pessoa, da mesma tela e da mesma interpretação. Se o contexto torna o sinal ambíguo, várias linhas no inventário podem desaparecer juntas.

Controle não é sinônimo de barreira independente

No uso cotidiano, qualquer regra ou recurso pode ser chamado de controle. Em análise de riscos, porém, a palavra barreira precisa vir acompanhada de perguntas mais exigentes: qual evento ela detecta ou impede, qual ação executa, quanto tempo possui, de que energia depende, como sua disponibilidade é conhecida e o que acontece quando falha?

A independência também importa. Duas instruções no mesmo procedimento não são necessariamente duas barreiras. Dois alarmes na mesma tela, suprimidos pelo mesmo modo, podem compartilhar causa comum. Treinamento e supervisão podem falhar juntos quando a organização classifica incorretamente a tarefa e não reconhece a transição como condição anormal.

Por isso, este artigo não atribui SIL, probabilidade de falha ou crédito quantitativo aos onze controles. O relatório sustenta a discussão qualitativa: para uma consequência potencialmente fatal, a instalação dependia exclusivamente de medidas administrativas e não tinha o controle engenheirado disponível naquela configuração.

Dependência comum: quando várias linhas falham pelo mesmo motivo

Um inventário de salvaguardas pode parecer diversificado e ainda concentrar sua confiabilidade em um único ponto. Se procedimento, job aid, alarme e supervisão dependem da mesma interpretação do estado do forno, uma premissa errada enfraquece todos ao mesmo tempo. Se diferentes alarmes aparecem na mesma HMI com nomenclatura semelhante, a interface vira causa comum de dificuldade de reconhecimento.

Dependência comum também pode ser organizacional. A classificação da tarefa define quais documentos serão usados, quem participa, quais alarmes permanecem ativos, qual autorização é exigida e se uma mudança temporária será registrada. Quando a configuração de remoção da dupla isolação não é reconhecida como condição distinta, várias medidas podem deixar de ser convocadas pela mesma decisão inicial.

Na prática, a equipe de PHA deve procurar relações, não somente somar linhas. Pergunte quais salvaguardas compartilham pessoa, sensor, lógica, energia, tela, procedimento, rede, premissa ou prazo de resposta. Depois, teste o cenário de perda comum: se esse elemento falhar ou for interpretado incorretamente, quantas camadas continuam realmente capazes de atuar?

Essa análise evita uma falsa sensação de redundância. Três ações manuais sucessivas podem ser úteis, porém não equivalem automaticamente a três camadas independentes. Uma proteção engenheirada com sensor e lógica próprios também não é independente por definição: alimentação, arquitetura, bypass, teste e causa comum precisam ser avaliados.

Análise de tarefas: projetar para o trabalho que realmente acontece

Task analysis decompõe a atividade real em objetivos, decisões, passos, informações, comandos, verificações, comunicações e possíveis desvios. Para uma transição crítica, não basta copiar a sequência nominal do procedimento. É preciso observar quais telas são abertas, onde ocorre rolagem, como o sistema reage a uma mudança de modo e como a pessoa distingue equipamentos parecidos.

A análise deve incluir tarefas raras. Startup após manutenção, recuperação de bypass, remoção de isolamento, resposta a alarme e retorno de equipamento são executados com menor frequência e, justamente por isso, oferecem menos oportunidade de desenvolver familiaridade. A raridade não reduz a consequência; pode aumentar a necessidade de apoio claro, simulação e supervisão competente.

Competência também precisa ser específica. Um engenheiro qualificado em automação pode conhecer profundamente a lógica e ainda não possuir experiência suficiente com a configuração de processo daquela tarefa. Da mesma forma, um operador experiente pode conhecer o forno e não dominar as consequências de determinada alteração no SIS. Designação deve considerar o conjunto necessário de conhecimento, experiência e autoridade.

O objetivo não é procurar uma pessoa infalível. É desenhar a tarefa para que alguém competente encontre identificação clara, sequência aplicável, confirmação independente, critérios de parada e suporte quando a situação divergir do esperado. Treinamento prepara a pessoa; task analysis também melhora a tecnologia e o método que ela receberá.

Tempo de detecção e possibilidade de recuperação

Entre o comando inadvertido e a ignição decorreram aproximadamente seis minutos. Esse intervalo não deve ser interpretado como uma janela confortável. O gás precisava ser detectado, o sinal reconhecido, a causa identificada, a ação correta decidida e o fluxo interrompido antes que a concentração alcançasse condição inflamável junto aos pilotos.

Barreiras que dependem de resposta humana precisam ser avaliadas contra o tempo real do processo. Um alarme pode funcionar tecnicamente e ainda chegar tarde para a cadeia de percepção, diagnóstico, decisão e execução. Uma parada de emergência pode estar disponível e ainda depender de alguém reconhecer qual condição exige acionamento.

Comandos de alta consequência merecem prevenção de erro e recuperação. Confirmação contextual, indicação clara do equipamento, visualização da consequência operacional, bloqueio de combinações incompatíveis e possibilidade de abortar o movimento podem reduzir a chance de uma ação produzir estado perigoso. A solução exata depende da análise; caixas de confirmação genéricas e repetitivas podem apenas ensinar o usuário a clicar automaticamente.

A pergunta temporal complementa a pergunta de independência: depois do desvio, existe tempo demonstrado para detectar e recuperar antes da consequência? Se a resposta depende de vigilância perfeita em poucos minutos, o controle provavelmente precisa ser fortalecido mais perto da fonte do perigo.

SIS e intertravamentos também exigem ciclo de vida

SIS é o sistema instrumentado de segurança que executa funções específicas para levar o processo a um estado definido diante de condições perigosas. Um intertravamento pode impedir comandos incompatíveis, manter uma válvula em posição ou iniciar uma ação protetiva. Mas a sigla não garante proteção por si mesma.

A função precisa nascer de um cenário bem definido: qual desvio deve detectar, quais entradas utiliza, qual ação executa, em quanto tempo e para quais modos. Depois vêm especificação, projeto, verificação, validação, teste periódico, gestão de falhas, controle de bypass e revisão após modificações. Uma lógica que não cobre a configuração da tarefa não pode receber crédito apenas porque o equipamento participa de um SIS.

A correção implantada na Furnace 5 ilustra o princípio: nova lógica mantém fechada a MOV do lado da torre se a MOV do lado do forno for aberta por engano. Ela atua na combinação perigosa sem aguardar que uma segunda pessoa diagnostique o fluxo reverso. O relatório não oferece base para transportar essa lógica literalmente a outra instalação; oferece base para exigir uma função que responda ao cenário específico.

Também é necessário administrar indisponibilidades. Uma função sob manutenção, bypass ou teste pode desaparecer justamente durante uma transição. Procedimentos compensatórios devem ser explícitos, temporários, autorizados e encerrados; a equipe precisa saber que a proteção automática não está presente.

HMI não é estética

HMI é a interface homem-máquina: o conjunto de telas, símbolos, tags, comandos, alarmes, tendências, estados e feedbacks pelos quais uma pessoa percebe e modifica o processo. Em segurança de processos, ela não é acabamento gráfico. É parte do caminho entre intenção operacional e movimento físico de equipamentos.

A CSB encontrou três MOVs quase idênticas na mesma tela de lógica. As identificações diferiam principalmente no último dígito, havia necessidade de navegação e rolagem, e a tela retornou a uma posição após mudança de modo. O sistema também não oferecia salvaguardas de confirmação suficientes para o comando crítico.

Uma interface de alto desempenho precisa apoiar a tarefa. Isso inclui hierarquia visual, contexto de processo, distinção funcional, nomenclatura legível, estado inequívoco, confirmação proporcional à consequência, feedback sobre o comando e caminhos de recuperação. Colocar mais cores ou ampliar o desenho sem analisar a tarefa real pode apenas tornar a mesma ambiguidade mais bonita.

A série ISA-101 é mencionada pela CSB e sua página pública descreve um ciclo de vida para interfaces orientadas a segurança, usabilidade e desempenho. Essa referência técnica não é reproduzida aqui nem apresentada como obrigação automática no Brasil.

Alarmes precisam informar — e existir no modo certo

Alarmes de pressão e detecção de gases que poderiam fornecer informação estavam suprimidos no modo pilot-only. Um alarme crítico de estado inesperado da MOV apareceu, mas sua descrição era quase idêntica à de outra válvula e foi reconhecida sem correção da condição.

Suprimir um alarme não é necessariamente errado. Alarmes sem significado em determinado estado podem produzir nuisance alarms, saturar a atenção e degradar resposta. O problema surge quando a lógica de supressão considera apenas o modo nominal e não testa configurações transitórias, manutenção, recuperação de isolamento ou combinações não previstas.

A pergunta de projeto não é ‘o alarme deve estar sempre ativo?’. É: quando o perigo pode existir, qual informação continuará disponível, quem deverá interpretá-la e qual proteção não dependerá dessa interpretação?

A armadilha dos modos operacionais

Um forno de craqueamento não possui apenas estados ‘ligado’ e ‘desligado’. O relatório descreve craqueamento de etano, decoking, hot steam standby (HSSB), pilot-only, startup, shutdown e condições de manutenção. Pressões, fontes de ignição, permissivos, alarmes e rotas de fluxo mudam entre esses estados.

Uma salvaguarda válida em operação normal pode estar inibida, semanticamente inadequada ou indisponível durante uma transição. Em Monaca, controles locais fornecidos pelo licenciador podiam evitar backflow, mas não estavam configurados para a remoção da dupla isolação. A proteção existia tecnicamente e ainda assim não cobria o momento em que o perigo se materializou.

Análises de risco precisam tratar modo operacional como variável de segurança. Não basta perguntar se há intertravamento; é preciso verificar se ele está habilitado e funcional durante startup, shutdown, pilot-only, manutenção, bypass, recuperação e emergência.

Quando a análise de perigos conhece o cenário

A revalidação da análise de perigos de processo — process hazard analysis, ou PHA — realizada em 2023 identificou fluxo reverso ou direcionado incorretamente para um forno offline como cenário de explosão com potencial para múltiplas fatalidades. Isso torna a discussão de governança especialmente relevante: o perigo não era inimaginável.

Dois controles administrativos considerados na análise não estavam ativos no dia do evento. Mais amplamente, a CSB concluiu que o cenário dependia de medidas administrativas em vez de uma salvaguarda de engenharia capaz de impedir o backflow na dupla isolação.

Uma PHA não termina quando a equipe preenche a planilha. Ela precisa testar se as salvaguardas são aplicáveis à configuração, se continuam válidas após mudanças, se possuem dependências comuns e se o crédito dado a procedimentos, alarmes e treinamento é compatível com a consequência.

É por isso que a primeira recomendação da CSB pede revisão da PHA para localizar desvios tratados somente com controles administrativos e adoção de projeto inerentemente mais seguro ou controle de engenharia quando o cenário puder causar morte, lesão grave ou dano material substancial.

O que havia de engenharia e não estava disponível naquele modo

O licenciador da tecnologia havia fornecido controles no painel local capazes de impedir o retorno de gás. Entretanto, a configuração da Shell não permitia utilizar essa proteção quando a dupla isolação era removida. A tarefa foi deslocada para atuação remota do PACO, por uma interface com as deficiências descritas.

A segunda recomendação da CSB pede um controle engenheirado mantido para impedir backflow de gás craqueado em todos os modos de operação do forno, com contribuição do licenciador e de boas práticas reconhecidas. A recomendação cita a família IEC/ISA 61511 como referência de segurança funcional.

Isso não significa que toda válvula crítica exige a mesma arquitetura ou SIL. Significa que a função necessária deve ser definida para o cenário e permanecer válida onde o risco existe. A solução deve nascer de análise específica, requisitos funcionais, verificação, validação, gestão de bypass e manutenção.

O que mudou depois

Após o evento, a Shell modificou o controle local para que operadores pudessem abrir e fechar as MOVs do lado do forno, de decoking e do lado da torre a partir do painel de campo, eliminando a necessidade de o PACO manipular essas válvulas naquela tarefa.

Também implementou nova lógica no sistema instrumentado de segurança — safety instrumented system, ou SIS — para manter fechada a MOV do lado da torre caso o operador de campo abra por engano a MOV do lado do forno. Além disso, emitiu um procedimento passo a passo e treinou as pessoas envolvidas.

A combinação é importante. Engenharia reduz a possibilidade de o processo evoluir; procedimento e treinamento estruturam a execução e a compreensão. Não é preciso escolher entre tecnologia e competência. O ponto é não exigir que competência humana seja a única defesa diante de uma consequência catastrófica.

Hierarquia de controles: duas referências que não devem ser fundidas

A hierarquia publicada pelo NIOSH organiza, em ordem preferencial geral, eliminação, substituição, controles de engenharia, controles administrativos e EPI. Eliminação, substituição e engenharia tendem a exigir menos interação humana contínua para funcionar. Isso não torna controles administrativos dispensáveis; mostra por que sua confiabilidade depende de esforço constante.

A NR-1 brasileira possui ordem jurídica própria: evitar/eliminar perigos; quando isso não for possível, minimizar e controlar com medidas de proteção coletiva; depois medidas administrativas ou de organização do trabalho; e, por fim, proteção individual. As listas convergem na preferência por atuar na fonte e reduzir dependência humana, mas não são textos equivalentes.

Projeto inerentemente mais seguro é outra lente: eliminar, substituir, minimizar, moderar ou simplificar o perigo no desenho do processo quando aplicável. A CSB usa esse conceito na recomendação. Não se deve afirmar que a NR-1 emprega exatamente a mesma terminologia.

O contexto OSHA nos Estados Unidos

Nos Estados Unidos, o padrão Process Safety Management da OSHA conecta informação de segurança de processo, PHA, procedimentos por fase, treinamento, integridade mecânica, gestão de mudanças, revisão de segurança pré-partida, investigação e auditoria.

A ficha pública da inspeção 1829624.015 registra encerramento em 2 de janeiro de 2026, duas violações sérias e penalidade corrente total de US$ 26.480. O artigo limita-se ao estado público do registro; não transforma citações administrativas em julgamento amplo sobre intenção, cultura ou responsabilidade civil.

Também é essencial separar funções institucionais. A OSHA fiscaliza e pode emitir citações. A CSB é agência federal independente, investigativa e não regulatória: determina fatos e causas e emite recomendações, mas não aplica multas.

E em uma petroquímica no Brasil?

NR-1 e NR-20 não regiam o evento da Pensilvânia. Em instalação equivalente no Brasil, depois de verificar o campo de aplicação, elas oferecem perguntas úteis de gestão e projeto.

A NR-1 exige evitar perigos, identificar e avaliar riscos, implementar prevenção conforme a classificação e revisar a avaliação após mudanças, ineficácia, acidentes ou evolução do conhecimento. A análise de eventos deve considerar atividades efetivamente realizadas, processo, materiais, ambiente e organização do trabalho — não somente o procedimento imaginado.

A NR-20 inclui instalações petroquímicas na Classe III por atividade, observadas suas regras e exceções. Ela conecta projeto, mecanismos para interromper ou reduzir cadeias de vazamento, incêndio e explosão, análises de risco documentadas, modificações, procedimentos alinhados ao projeto e à análise, inspeção, manutenção e atividades não rotineiras.

Para unidades de processo abrangidas, procedimentos precisam tratar fases como pré-operação, operação normal, operação temporária, emergência, parada e pós-emergência. Essa exigência dialoga diretamente com a lição de Monaca: uma barreira só existe se continuar válida no modo em que o risco aparece.

GRO/PGR da NR-1 não é equivalente jurídico de PHA/PSM norte-americano. ISA-101 e IEC 61511 também não se tornam automaticamente obrigatórias no Brasil por serem referências técnicas. Aplicabilidade depende de requisito legal, projeto, contrato, análise de risco e normas adotadas.

Teste suas barreiras antes do próximo startup

Use as perguntas como roteiro de revisão técnica. Elas não substituem PHA, projeto, procedimento, validação ou julgamento de profissionais competentes.

• Qual consequência ocorre se a ação crítica for executada na ordem errada?
• Existe barreira automática ou engenheirada que impeça o caminho perigoso?
• Essa barreira está disponível em operação normal, startup, shutdown, manutenção, bypass e emergência?
• Algum alarme importante fica suprimido no modo da tarefa? Qual compensação permanece?
• Controles chamados de independentes dependem da mesma pessoa, tela, procedimento, sinal ou fonte de energia?
• A HMI distingue equipamentos semelhantes por função, posição, contexto e consequência?
• Comandos perigosos possuem confirmação, feedback e recuperação compatíveis com o risco?
• A análise de tarefas inclui manutenção, retorno, recuperação de isolamento e outras atividades não rotineiras?
• O procedimento corresponde exatamente à configuração operacional real?
• A análise de riscos concede crédito excessivo a treinamento, alarme ou procedimento para cenário catastrófico?
• Recomendações de engenharia adiadas têm justificativa, responsável e data de revisão?
• A equipe sabe qual condição exige abortar a transição e levar o processo a estado seguro?

O que este caso não prova

O relatório não prova que treinamento é inútil, que procedimentos não funcionam ou que operadores são a causa suficiente de acidentes. Treinamento, procedimento e competência continuam essenciais; precisam estar inseridos em um sistema que torne o erro menos provável, forneça feedback claro e limite suas consequências.

O caso não autoriza diagnóstico genérico de cultura, intenção ou culpa. Também não prova que qualquer HMI semelhante produzirá acidente nem que uma solução universal sirva para todos os fornos.

Por fim, a menção a ISA-101, IEC 61511, CCPS, NIOSH ou OSHA não cria obrigação legal automática no Brasil. Referência técnica ajuda a pensar; enquadramento normativo exige análise própria.

Conclusão: a pergunta que deve sobreviver ao caso

A Shell Polymers Monaca possuía políticas, alarmes, procedimentos, regras, treinamento e resposta. Ainda assim, o cenário conhecido atravessou essas camadas porque o conjunto compartilhava dependências humanas e porque a proteção de engenharia não estava configurada para o modo real da tarefa.

A lição não é substituir pessoas por automação nem desprezar procedimentos. É projetar um sistema em que informação, competência, interface e engenharia se reforcem, sem depositar todo o sucesso em uma cadeia de acertos humanos sob transição operacional.

Isso exige governança depois da análise: recomendações com responsáveis e prazos, justificativas técnicas para decisões, verificação da implantação e retorno das mudanças para a PHA. Uma barreira aprovada em reunião, mas não configurada, testada e mantida no campo, permanece apenas uma intenção. O mesmo vale para o aprendizado: ele só se consolida quando altera projeto, interface, procedimento, competência e critérios de decisão.

A pergunta transferível é direta: se esta ação for executada errada, qual barreira independente impede que o processo evolua para uma consequência grave sem exigir que outra pessoa perceba e corrija a tempo? Se a resposta for apenas ‘o procedimento manda fazer certo’, a análise ainda não terminou.