LOPA: o que é Layer of Protection Analysis, camadas independentes e redução de risco

Entenda o que é LOPA, eventos iniciadores, IPLs, PFD, independência, condições habilitadoras, cálculo de risco e relação com SIL e IEC 61511.

Confira!

Layer of Protection Analysis (LOPA) é uma metodologia semiquantitativa de análise de risco usada para avaliar cenários de acidente específicos, estimar a frequência mitigada de uma consequência e verificar se as camadas independentes de proteção existentes são suficientes para atingir o critério de risco adotado. A LOPA ocupa uma posição intermediária entre análises qualitativas, como HAZID e HAZOP, e estudos quantitativos mais complexos. Seu valor não está em produzir números com muitas casas decimais, mas em disciplinar as premissas: um cenário por vez, uma frequência de evento iniciador coerente, crédito apenas para camadas realmente independentes e rastreabilidade sobre a necessidade de redução adicional de risco.

O que é LOPA

LOPA significa Layer of Protection Analysis, ou Análise de Camadas de Proteção. O Center for Chemical Process Safety (CCPS) descreve a técnica como uma metodologia semiquantitativa que trabalha com um único par causa-consequência por cenário e utiliza critérios específicos para avaliar quais salvaguardas podem receber crédito como Independent Protection Layers (IPLs).

A lógica básica é simples: parte-se de um cenário já identificado, estima-se a frequência do evento iniciador e verifica-se quanto cada camada independente reduz a probabilidade de o cenário evoluir até a consequência de interesse. O resultado é comparado com o critério de risco da organização. Se a redução existente for insuficiente, novas medidas precisam ser avaliadas.

Essa simplicidade aparente exige disciplina. Uma LOPA tecnicamente fraca pode parecer quantitativa, mas esconder dependências, frequências sem base, créditos duplicados e barreiras que não possuem confiabilidade demonstrável.

Onde a LOPA se posiciona entre HAZID, HAZOP e QRA

HAZID identifica perigos de forma ampla. HAZOP investiga desvios de processo de maneira estruturada. LOPA seleciona cenários relevantes e quantifica o efeito de camadas independentes em ordens de grandeza. Uma Quantitative Risk Assessment (QRA) pode modelar frequências, consequências e risco de maneira ainda mais detalhada, incluindo distribuição espacial, vulnerabilidade e múltiplos cenários.

Método	Foco principal	Natureza
HAZID	Identificação ampla de perigos	Qualitativa/estruturada
HAZOP	Desvios, causas, consequências e salvaguardas	Qualitativa/estruturada
LOPA	Frequência de cenário e crédito de IPLs	Semiquantitativa
QRA	Modelagem quantitativa de risco	Quantitativa

A escolha depende da decisão. A LOPA não deve ser usada apenas porque existe uma planilha disponível; deve ser usada quando o nível de detalhamento é compatível com a incerteza dos dados e com a relevância da decisão.

A anatomia de um cenário LOPA

Uma LOPA analisa uma cadeia definida. Em termos conceituais, ela possui:

• consequência de interesse;
• cenário ou sequência acidental;
• evento iniciador;
• condições habilitadoras, quando aplicáveis;
• camadas independentes de proteção;
• modificadores condicionais, quando aplicáveis;
• frequência mitigada estimada;
• critério de risco ou frequência tolerável;
• necessidade de redução adicional.

Nem todo cenário terá condição habilitadora, modificador condicional ou três IPLs. O diagrama representa a lógica, não uma quantidade obrigatória de barreiras.

O cenário deve ser específico

LOPA não trabalha bem com descrições vagas como “risco de explosão da unidade”. A análise precisa definir uma relação clara entre causa e consequência.

Um cenário útil deve responder:

• qual evento inicia a sequência?
• em qual condição operacional?
• qual perda de controle ocorre?
• qual consequência está sendo avaliada?
• quais proteções atuam entre o evento iniciador e a consequência?

Quando múltiplas causas possuem frequências ou dependências diferentes, pode ser necessário separá-las em cenários distintos em vez de agregá-las de forma arbitrária.

Evento iniciador

O initiating event é a falha, erro ou condição que inicia a propagação do cenário. A frequência utilizada deve representar a ocorrência do evento no contexto analisado, e não um número escolhido apenas para facilitar o cálculo.

Eventos iniciadores podem envolver:

• falha de controle básico;
• falha de equipamento;
• erro humano;
• perda de utilidade;
• abertura ou fechamento indevido;
• falha de válvula;
• sobrepressão causada por condição de processo;
• perda de resfriamento;
• perda de energia;
• intervenção de manutenção inadequada.

A fonte da frequência precisa ser documentada: base corporativa, dados históricos, literatura reconhecida, análise específica ou critério técnico validado.

Frequência do evento iniciador não é probabilidade de consequência

Uma causa pode ocorrer sem produzir a consequência final porque existem condições intermediárias e camadas de proteção. Confundir frequência de iniciador com frequência de consequência superestima ou subestima o risco.

A estrutura matemática da LOPA representa justamente essa sequência. Em uma forma simplificada:

Frequência mitigada ≈ frequência do evento iniciador × fatores aplicáveis × PFD das IPLs creditadas.

Essa expressão não deve ser usada mecanicamente. Antes de multiplicar fatores, é necessário verificar se eles pertencem ao cenário, se não existe dupla contagem e se as camadas são realmente independentes.

O que é uma IPL

Independent Protection Layer (IPL) é uma proteção capaz de impedir que o cenário progrida até a consequência de interesse de forma independente do evento iniciador e das demais camadas creditadas.

O CCPS destaca atributos como independência, funcionalidade, integridade, confiabilidade, auditabilidade, controle de acesso e gestão de mudanças. Isso significa que possuir um dispositivo ou alarme no P&ID não é suficiente para transformá-lo em IPL.

Uma IPL precisa ter função definida e desempenho sustentado ao longo do ciclo de vida.

Salvaguarda x IPL

Toda IPL é uma salvaguarda, mas nem toda salvaguarda merece crédito como IPL.

Situação	Pode ser salvaguarda?	Pode ser IPL automaticamente?
Alarme de processo	Sim	Não
Intertravamento no mesmo BPCS que causa o evento	Sim	Geralmente não sem análise de independência
Válvula de alívio adequadamente projetada	Sim	Pode ser, conforme cenário e critérios
Procedimento operacional	Sim	Não automaticamente
SIF independente	Sim	Pode ser, com desempenho e independência demonstrados
Muro de contenção	Sim	Depende da consequência analisada e critérios

Essa distinção é central. Atribuir crédito a qualquer salvaguarda produz uma sensação artificial de segurança.

Independência entre camadas

Duas proteções não são independentes apenas porque possuem nomes diferentes. Dependências podem existir em sensores, lógica, fonte de energia, utilidades, comunicação, elemento final, manutenção, teste, configuração ou ação humana.

Exemplo: um alarme e um trip que usam o mesmo transmissor podem perder simultaneamente sua capacidade de proteção se esse transmissor falhar perigosamente. Da mesma forma, dois sistemas alimentados pelo mesmo circuito ou dependentes da mesma rede podem compartilhar modo comum de falha.

A análise precisa perguntar o que pode derrubar as duas camadas ao mesmo tempo?

Common cause e common mode

Falhas de causa comum são particularmente perigosas porque invalidam a suposição de multiplicação simples entre probabilidades independentes.

Fontes de dependência podem incluir:

• mesma alimentação elétrica;
• mesmo ar de instrumento;
• mesmo transmissor;
• mesma lógica de controle;
• mesmo elemento final;
• mesma rota física de cabo;
• mesma condição ambiental;
• mesma equipe ou procedimento de manutenção;
• erro de configuração replicado;
• bypass comum;
• vulnerabilidade cibernética compartilhada.

A governança da LOPA precisa registrar essas dependências antes de conceder crédito.

Probability of Failure on Demand — PFD

PFD representa a probabilidade de uma camada falhar quando sua função é demandada, dentro das hipóteses do método utilizado. Em LOPA, valores de PFD são empregados para estimar a redução de frequência associada às IPLs.

Não se deve copiar valores genéricos sem verificar as condições necessárias para sustentá-los. Frequência de teste, cobertura de diagnóstico, reparo, manutenção, bypass, arquitetura, competência e gestão de mudanças podem afetar o desempenho real.

Para uma Safety Instrumented Function (SIF), a verificação de SIL é um problema de engenharia próprio e não deve ser substituída por uma célula fixa em planilha LOPA.

Enabling conditions

Uma enabling condition é uma condição que precisa estar presente para que o evento iniciador possa evoluir no cenário analisado, mas que não é a causa iniciadora propriamente dita.

Exemplos podem envolver uma etapa operacional específica, presença de material, modo de campanha ou equipamento em determinado estado.

O uso inadequado de condições habilitadoras pode reduzir artificialmente a frequência do cenário. Elas só devem ser aplicadas quando existe justificativa clara e sem sobreposição com a própria frequência do evento iniciador.

Conditional modifiers

Conditional modifiers representam probabilidades associadas a condições posteriores ou complementares ao cenário, como presença de pessoas, probabilidade de ignição ou outros fatores quando tecnicamente aplicáveis.

Assim como enabling conditions, modificadores condicionais exigem disciplina para evitar dupla contagem. O CCPS publicou orientação específica para esses elementos justamente porque seu uso inconsistente pode alterar significativamente o resultado.

Como executar uma LOPA

O processo precisa ser reproduzível e auditável.

Selecionar a consequência

A consequência deve ser tecnicamente definida. Uma mesma causa pode levar a consequências distintas e exigir cenários separados.

Definir o evento iniciador

A causa iniciadora precisa ser coerente com o mecanismo analisado. Frequências duplicadas ou agregações arbitrárias comprometem a análise.

Identificar salvaguardas

Primeiro registre as proteções existentes. Depois avalie quais atendem aos critérios para IPL. Essa ordem reduz a tendência de “forçar” uma salvaguarda a entrar no cálculo porque ela já foi mencionada em HAZOP.

Comparar com o critério de risco

A organização precisa possuir critério documentado. A planilha LOPA não define sozinha o que é risco tolerável.

Exemplo conceitual de cálculo

Considere, apenas como exemplo didático, um evento iniciador com frequência hipotética de 10⁻¹ por ano. Suponha que existam duas IPLs independentes, cada uma com PFD hipotética de 10⁻¹. Desconsiderando outros fatores no exemplo, a frequência mitigada seria da ordem de:

10⁻¹ × 10⁻¹ × 10⁻¹ = 10⁻³ por ano.

Esse exemplo mostra a lógica de ordens de grandeza, não fornece valores padronizados para uso em projeto. Em um estudo real, cada frequência, PFD, dependência e condição precisa ser tecnicamente justificada.

Critério de tolerabilidade e gap de risco

O resultado da LOPA só é útil quando comparado a um critério de risco definido. Se a frequência mitigada estimada permanecer acima do critério para a consequência, existe um gap de redução de risco.

Esse gap pode ser tratado por diferentes estratégias:

• eliminar ou reduzir o perigo por projeto inerentemente mais seguro;
• reduzir a frequência do iniciador;
• adicionar ou melhorar camada de proteção;
• modificar processo ou inventário;
• melhorar segregação ou contenção;
• implementar SIF com SIL requerido quando apropriado;
• rever operação ou manutenção.

A decisão não deve saltar automaticamente para “instalar um SIS”. A hierarquia de redução de risco e a viabilidade de soluções inerentes ou passivas devem ser consideradas antes.

Relação entre LOPA e SIL

Uma das aplicações importantes da LOPA é auxiliar na determinação da redução de risco que precisa ser fornecida por uma função instrumentada de segurança. O CCPS reconhece o uso da LOPA para esse propósito, e a IEC 61511 inclui orientação para determinação dos níveis requeridos de integridade de segurança.

Quando uma SIF é necessária, o requisito resultante deve migrar para o ciclo de Segurança Funcional: definição da função, estado seguro, condições de disparo, tempo de resposta, SIL requerido, independência, arquitetura, teste, operação e gestão de mudanças.

LOPA ajuda a determinar requisito; não substitui a verificação de que a SIF projetada realmente atende esse requisito.

SIL requerido x SIL verificado

O SIL requerido decorre da necessidade de redução de risco para uma SIF. A verificação de SIL avalia se a arquitetura e os componentes projetados conseguem atingir o desempenho exigido, considerando falhas aleatórias e sistemáticas conforme o método aplicável.

Misturar essas duas etapas é um erro sério: determinar “SIL 2” em uma LOPA não comprova que o sistema implementado é SIL 2.

BPCS e independência

O Basic Process Control System (BPCS) executa controle normal do processo. Dependendo do cenário, uma função de controle ou alarme no BPCS pode ser uma salvaguarda útil. Entretanto, conceder crédito como IPL exige avaliação de independência em relação ao evento iniciador e às demais camadas.

Se a falha do BPCS é o próprio iniciador, utilizar outra função dependente da mesma infraestrutura para reduzir o cenário pode criar crédito indevido.

Alarmes e ação do operador

Um alarme seguido de resposta humana não recebe crédito automaticamente. É necessário avaliar se:

• a condição é detectada de forma confiável;
• o alarme é distinguível;
• existe tempo suficiente para diagnóstico e ação;
• o operador possui procedimento e treinamento;
• a ação é fisicamente executável;
• não existe sobrecarga de alarmes;
• a função é independente das demais camadas creditadas;
• desempenho e testes são mantidos.

Em cenários rápidos, uma resposta humana pode simplesmente não ser compatível com o tempo disponível.

Dispositivos de alívio e proteção mecânica

PSVs, discos de ruptura, contenções e outras barreiras podem ser extremamente importantes, mas o crédito depende da consequência analisada, da capacidade, independência, projeto, inspeção, manutenção e condições reais de operação.

Uma válvula de alívio pode prevenir sobrepressão do equipamento e ainda assim não impedir outra consequência, como descarga perigosa em local inadequado. A IPL deve ser avaliada contra o cenário específico.

Sistemas instrumentados de segurança

Uma SIF pode atuar como IPL quando possui independência e desempenho adequados ao cenário. A função completa normalmente envolve sensor, logic solver e elemento final. Confiar apenas na certificação individual de componentes não demonstra o desempenho da função completa.

Além do cálculo de PFD, precisam ser governados:

• requisitos funcionais;
• arquitetura;
• intervalos de proof test;
• bypasses;
• falhas detectadas e não detectadas;
• competência;
• configuração;
• validação;
• manutenção;
• Management of Change.

LOPA e fatores humanos

Erro humano pode aparecer como iniciador, condição ou elemento de proteção dependendo do cenário. Isso exige cuidado para não atribuir independência artificial a ações executadas pela mesma pessoa, sob a mesma pressão operacional e a partir da mesma informação.

O estudo deve representar o trabalho real e não um procedimento idealizado.

LOPA em instalações brownfield

Em plantas existentes, uma dificuldade comum é utilizar IPLs “de projeto” que já não existem da forma documentada. Alterações de lógica, bypasses, mudanças de instrumentos, válvulas travadas, testes atrasados e falhas de documentação afetam a validade das premissas.

Antes de creditar uma camada, pode ser necessário verificar fisicamente:

• arquitetura instalada;
• sensor e elemento final;
• alimentação e utilidades;
• lógica e setpoints;
• independência física e funcional;
• histórico de testes;
• condição de bypass;
• documentação As Built.

Isso conecta LOPA a Site Survey, Engenharia Diagnóstica e recomissionamento.

Gestão de mudanças

Uma LOPA possui premissas que podem perder validade após modificações. Aumento de capacidade, alteração de produto, novo modo operacional, mudança de setpoint, substituição de válvula, atualização de software ou modificação de intervalo de teste podem alterar frequência, consequência ou desempenho de IPL.

O Management of Change deve identificar quais estudos de risco precisam ser revisitados.

Documentação e rastreabilidade

O registro da LOPA deve permitir reconstruir o raciocínio. Para cada cenário, convém registrar:

• origem do cenário;
• consequência analisada;
• evento iniciador e fonte da frequência;
• condições habilitadoras;
• modificadores condicionais;
• salvaguardas identificadas;
• justificativa das IPLs creditadas;
• PFD e fonte adotada;
• dependências avaliadas;
• resultado do cálculo;
• critério de risco;
• gap de redução;
• recomendações;
• responsáveis e status.

Sem essa rastreabilidade, revisões futuras se tornam exercícios de reconstrução de premissas.

Qualidade dos dados

LOPA trabalha com ordens de grandeza, mas isso não significa aceitar qualquer dado. A incerteza precisa ser reconhecida e tratada conservadoramente quando necessário.

Uma governança madura define fontes autorizadas, critérios para dados próprios, regras de atualização, tratamento de ausência de informação e responsáveis pela aprovação de premissas.

Facilitação e competência

O workshop deve reunir conhecimento de processo, operação, instrumentação, automação, manutenção e segurança compatível com os cenários. O facilitador precisa controlar o método e desafiar créditos indevidos.

Em decisões que conduzem à especificação de SIL ou SIS, a competência requerida aumenta. A organização deve definir claramente quem determina requisito, quem verifica cálculo, quem aprova e quem valida a implementação.

Owner’s Engineering e revisão independente

A Engenharia do Proprietário pode atuar como camada de governança entre estudo de risco, projeto e fornecedor. Isso inclui revisar premissas, assegurar consistência entre HAZOP e LOPA, verificar se requisitos migraram para especificações, acompanhar TBE, FAT/SAT e controlar mudanças.

Esse papel é diferente de fornecer o Safety PLC ou desenvolver toda a lógica de aplicação. O foco é preservar os requisitos de risco do proprietário ao longo da contratação e implantação.

LOPA em Procurement

Quando uma recomendação resulta em novo sistema ou modificação, o processo de compra deve preservar os requisitos técnicos. Uma RFP genérica que solicita “sistema SIL 2” sem definir SIFs, interfaces, condições de processo, proof tests e responsabilidades transfere ambiguidades para o fornecedor.

Requisitos provenientes da LOPA precisam ser convertidos em documentação de engenharia e critérios de aceite.

FAT, SAT e validação

A existência de hardware compatível com um determinado SIL não encerra o ciclo. Testes precisam demonstrar que as funções implementadas correspondem aos requisitos.

FAT e SAT podem verificar lógica, sequências, diagnósticos, falhas, interfaces e documentação. A validação de Segurança Funcional possui requisitos próprios e deve ser planejada conforme escopo, independência e responsabilidade aplicáveis.

Auditoria das IPLs ao longo da operação

Uma IPL só mantém o crédito se seu desempenho for sustentado. Governança operacional deve controlar:

• proof tests e inspeções;
• falhas em demanda;
• bypasses;
• reparos pendentes;
• alterações de configuração;
• desempenho de alarmes;
• falhas espúrias;
• mudanças de processo;
• competência de manutenção;
• evidências de teste.

Esse acompanhamento fecha a distância entre a LOPA “de projeto” e o risco real da instalação.

Erros recorrentes em LOPA

Os principais problemas são metodológicos, não aritméticos:

• cenários amplos demais;
• frequência iniciadora sem fonte;
• dupla contagem de condições;
• atribuição de crédito a salvaguardas não independentes;
• ignorar falha comum;
• usar PFD genérica sem premissas;
• considerar ação humana sem tempo e confiabilidade;
• tratar SIL requerido como SIL verificado;
• não atualizar o estudo após mudança;
• fechar recomendações sem comprovação de implementação.

Uma planilha pode multiplicar números corretamente e ainda produzir uma conclusão errada se essas premissas estiverem inadequadas.

Como a Engenharia Consultiva pode atuar em LOPA

A atuação consultiva pode concentrar-se em método, facilitação, governança e revisão independente. Isso inclui preparar cenários, organizar informações, moderar workshops, verificar critérios de IPL, registrar premissas, integrar especialistas, acompanhar recomendações e assegurar que requisitos resultantes cheguem ao projeto e à contratação.

Para a A3A, essa abordagem se conecta diretamente a Gerenciamento de Riscos de Engenharia, Consultoria Técnica, Projeto de Automação Industrial, Owner’s Engineering e Comissionamento, sem confundir consultoria com certificação de SIL ou fornecimento de SIS.

Entregáveis de uma LOPA consultiva

Um pacote pode incluir:

• plano e critérios do estudo;
• lista de cenários selecionados;
• planilhas LOPA controladas;
• fontes de frequências e PFDs;
• justificativas de IPL;
• registro de dependências;
• cálculo do risco mitigado;
• gaps de redução;
• recomendações;
• requisitos para estudos posteriores;
• matriz de ações;
• relatório executivo e registro de aprovação.

Considerações finais

LOPA é uma ferramenta poderosa porque força a engenharia a explicitar por que uma proteção merece crédito e quanto risco ainda permanece após sua atuação. Seu rigor está menos na sofisticação matemática e mais na qualidade das premissas, na independência das camadas e na governança do ciclo de vida.

Quando integrada a HAZID, HAZOP, SIL, projeto de automação, Procurement e comissionamento, a LOPA transforma cenários de risco em requisitos rastreáveis. Esse encadeamento é essencial para que a redução de risco definida no estudo continue existindo depois que o projeto passa por fornecedores, montagem, testes, operação e mudanças.

Referências técnicas

[1] CENTER FOR CHEMICAL PROCESS SAFETY (CCPS). LOPA Data — What is LOPA. New York: AIChE. Disponível em: https://ccps.aiche.org/resources/tools/lopa

[2] CENTER FOR CHEMICAL PROCESS SAFETY (CCPS). Layer of Protection Analysis: Simplified Process Risk Assessment. New York: AIChE, 2001. Disponível em: https://ccps.aiche.org/publications/books/layer-protection-analysis-simplified-process-risk-assessment

[3] CENTER FOR CHEMICAL PROCESS SAFETY (CCPS). Guidelines for Enabling Conditions and Conditional Modifiers in Layers of Protection Analysis. New York: AIChE, 2013. Disponível em: https://ccps.aiche.org/publications/books/guidelines-enabling-conditions-and-conditional-modifiers-layers-protection-analysis

[4] INTERNATIONAL ELECTROTECHNICAL COMMISSION. IEC 61511-1:2016+AMD1:2017 CSV — Functional safety — Safety instrumented systems for the process industry sector — Part 1. Geneva: IEC. Disponível em: https://webstore.iec.ch/en/publication/61289

[5] INTERNATIONAL ELECTROTECHNICAL COMMISSION. IEC TR 61511-0:2018 — Functional safety for the process industry and IEC 61511. Geneva: IEC. Disponível em: https://webstore.iec.ch/en/publication/60766

[6] INTERNATIONAL SOCIETY OF AUTOMATION. ISA-84 Series of Standards. Research Triangle Park: ISA. Disponível em: https://www.isa.org/standards-and-publications/isa-standards/isa-84-standards

Perguntas frequentes

O que é LOPA?

LOPA é Layer of Protection Analysis, uma metodologia semiquantitativa que avalia um cenário específico, sua frequência iniciadora e as camadas independentes de proteção para estimar a frequência mitigada da consequência.

Qual é a diferença entre salvaguarda e IPL?

Salvaguarda é qualquer medida que contribui para reduzir risco. IPL é uma salvaguarda que atende critérios adicionais de independência, funcionalidade, integridade, confiabilidade e auditabilidade e que pode receber crédito quantitativo na LOPA.

LOPA é uma análise quantitativa?

Ela é normalmente classificada como semiquantitativa. Trabalha com frequências e probabilidades em ordens de grandeza, com regras simplificadas, ficando entre análises qualitativas e uma QRA detalhada.

LOPA serve para definir SIL?

Pode ser usada para determinar a redução de risco adicional necessária e, quando essa redução será fornecida por uma SIF, apoiar a determinação do SIL requerido. Isso não substitui a verificação posterior de SIL da função projetada.

Um alarme pode ser IPL?

Pode ser parte de uma camada creditável em condições específicas, mas não automaticamente. É necessário avaliar independência, detecção, tempo de resposta, ação do operador, treinamento, auditabilidade e demais critérios aplicáveis.

Quando a LOPA deve ser revisada?

Deve ser reavaliada quando mudanças de processo, capacidade, setpoints, instrumentos, lógica, testes, equipamentos ou condições operacionais puderem alterar as premissas do cenário ou o desempenho das camadas.

Materiais técnicos complementares

Soluções relacionadas

• Sistemas Digitais de Supervisão e Controle (SDSC): automação e operação integrada

Serviços relacionados

• Consultoria Técnica de Engenharia: diagnóstico, estratégia e suporte à decisão
• Gerenciamento de Riscos de Engenharia: identificação, análise, mitigação e contingência
• Projeto de Automação Industrial: controle, supervisão, redes OT e integração
• Comissionamento de Engenharia: planejamento, testes, prontidão e handover

Conteúdos principais sobre o tema

• HAZID na Engenharia: o que é Hazard Identification, metodologia e aplicação em projetos industriais
• HAZOP na Engenharia: metodologia, palavras-guia e análise de desvios de processo

Conteúdos técnicos correlatos

• Bow Tie na Engenharia: causas, evento crítico, consequências e barreiras de controle
• Análise de Riscos em Projetos de Engenharia: métodos, critérios e priorização