Entienda qué es LOPA, eventos iniciadores, IPLs, PFD, independencia, condiciones habilitantes, cálculo de riesgo y relación con SIL e IEC 61511.
¡Descúbrelo!
Layer of Protection Analysis (LOPA) es una metodología semicuantitativa de análisis de riesgos utilizada para evaluar escenarios de accidente específicos, estimar la frecuencia mitigada de una consecuencia y verificar si las capas independientes de protección existentes son suficientes para alcanzar el criterio de riesgo adoptado. LOPA ocupa una posición intermedia entre análisis cualitativos, como HAZID y HAZOP, y estudios cuantitativos más complejos. Su valor no reside en producir números con muchas cifras decimales, sino en disciplinar las premisas: un escenario a la vez, una frecuencia coherente del evento iniciador, crédito solo para capas realmente independientes y trazabilidad sobre la necesidad de reducción adicional del riesgo.
Qué es LOPA
LOPA significa Layer of Protection Analysis, o Análisis de Capas de Protección. El Center for Chemical Process Safety (CCPS) describe la técnica como una metodología semicuantitativa que trabaja con un único par causa-consecuencia por escenario y utiliza criterios específicos para evaluar qué salvaguardas pueden recibir crédito como Independent Protection Layers (IPLs).
La lógica básica es simple: se parte de un escenario ya identificado, se estima la frecuencia del evento iniciador y se verifica cuánto reduce cada capa independiente la probabilidad de que el escenario evolucione hasta la consecuencia de interés. El resultado se compara con el criterio de riesgo de la organización. Si la reducción existente es insuficiente, deben evaluarse nuevas medidas.
Esta aparente simplicidad exige disciplina. Una LOPA técnicamente débil puede parecer cuantitativa y, sin embargo, ocultar dependencias, frecuencias sin fundamento, créditos duplicados y barreras cuya confiabilidad no ha sido demostrada.
Dónde se sitúa LOPA entre HAZID, HAZOP y QRA
HAZID identifica peligros de forma amplia. HAZOP investiga desviaciones de proceso de manera estructurada. LOPA selecciona escenarios relevantes y cuantifica el efecto de capas independientes en órdenes de magnitud. Una Quantitative Risk Assessment (QRA) puede modelar frecuencias, consecuencias y riesgo con todavía más detalle, incluyendo distribución espacial, vulnerabilidad y múltiples escenarios.
| Método | Enfoque principal | Naturaleza |
| HAZID | Identificación amplia de peligros | Cualitativa/estructurada |
| HAZOP | Desviaciones, causas, consecuencias y salvaguardas | Cualitativa/estructurada |
| LOPA | Frecuencia del escenario y crédito de IPLs | Semicuantitativa |
| QRA | Modelado cuantitativo del riesgo | Cuantitativa |
La elección depende de la decisión. LOPA no debe utilizarse solo porque exista una hoja de cálculo disponible; debe utilizarse cuando el nivel de detalle sea compatible con la incertidumbre de los datos y con la relevancia de la decisión.
Anatomía de un escenario LOPA
Una LOPA analiza una cadena definida. En términos conceptuales, incluye:
- la consecuencia de interés;
- el escenario o secuencia accidental;
- el evento iniciador;
- condiciones habilitantes, cuando sean aplicables;
- capas independientes de protección;
- modificadores condicionales, cuando sean aplicables;
- frecuencia mitigada estimada;
- criterio de riesgo o frecuencia tolerable;
- necesidad de reducción adicional.
No todos los escenarios tendrán una condición habilitante, un modificador condicional o tres IPLs. El diagrama representa la lógica, no una cantidad obligatoria de barreras.
El escenario debe ser específico
LOPA no comienza por el cálculo. Antes de multiplicar frecuencias y PFDs, el escenario debe estar correctamente delimitado y las fuentes de las premisas deben ser trazables. Un análisis de riesgo mal definido no mejora simplemente porque se haya colocado en una hoja de cálculo.
LOPA no funciona bien con descripciones vagas como “riesgo de explosión de la unidad”. El análisis debe definir una relación clara entre causa y consecuencia.
Un escenario útil debe responder:
- ¿qué evento inicia la secuencia?
- ¿bajo qué condición operativa?
- ¿qué pérdida de control ocurre?
- ¿qué consecuencia se está evaluando?
- ¿qué protecciones actúan entre el evento iniciador y la consecuencia?
Cuando múltiples causas tienen frecuencias o dependencias diferentes, puede ser necesario separarlas en escenarios distintos en vez de agregarlas arbitrariamente.
Evento iniciador
El initiating event es el fallo, error o condición que inicia la propagación del escenario. La frecuencia utilizada debe representar la ocurrencia del evento en el contexto analizado y no un número elegido únicamente para facilitar el cálculo.
Los eventos iniciadores pueden involucrar:
- fallo del control básico;
- fallo de equipo;
- error humano;
- pérdida de una utilidad;
- apertura o cierre indebidos;
- fallo de válvula;
- sobrepresión causada por una condición de proceso;
- pérdida de refrigeración;
- pérdida de energía;
- intervención de mantenimiento inadecuada.
La fuente de la frecuencia debe documentarse: base corporativa, datos históricos, literatura reconocida, análisis específico o criterio técnico validado.
La frecuencia del evento iniciador no es la probabilidad de la consecuencia
Una causa puede ocurrir sin producir la consecuencia final porque existen condiciones intermedias y capas de protección. Confundir la frecuencia del iniciador con la frecuencia de la consecuencia sobreestima o subestima el riesgo.
La estructura matemática de LOPA representa precisamente esta secuencia. De forma simplificada:
Frecuencia mitigada ≈ frecuencia del evento iniciador × factores aplicables × PFD de las IPLs acreditadas.
Esta expresión no debe utilizarse mecánicamente. Antes de multiplicar factores, es necesario verificar que pertenezcan al escenario, que no exista doble conteo y que las capas sean realmente independientes.
Qué es una IPL
Una Independent Protection Layer (IPL) es una protección capaz de impedir que el escenario progrese hasta la consecuencia de interés de forma independiente del evento iniciador y de las demás capas acreditadas.
CCPS destaca atributos como independencia, funcionalidad, integridad, confiabilidad, auditabilidad, control de acceso y gestión de cambios. Esto significa que disponer de un dispositivo o alarma en el P&ID no basta para convertirlo en una IPL.
Una IPL debe tener una función definida y un desempeño sostenido durante todo el ciclo de vida.
Salvaguarda vs. IPL
Toda IPL es una salvaguarda, pero no toda salvaguarda merece crédito como IPL.
| Situación | ¿Puede ser salvaguarda? | ¿Puede ser IPL automáticamente? |
| Alarma de proceso | Sí | No |
| Interlock en el mismo BPCS que causa el evento | Sí | Generalmente no, sin análisis de independencia |
| Válvula de alivio correctamente diseñada | Sí | Puede serlo, según el escenario y los criterios |
| Procedimiento operativo | Sí | No automáticamente |
| SIF independiente | Sí | Puede serlo, con desempeño e independencia demostrados |
| Muro de contención | Sí | Depende de la consecuencia analizada y de los criterios |
Esta distinción es central. Atribuir crédito a cualquier salvaguarda genera una sensación artificial de seguridad.
Independencia entre capas
El crédito de una IPL debe superar la prueba de independencia. Si dos protecciones comparten sensor, energía, lógica, elemento final o un modo común de fallo, tratarlas como independientes puede sobreestimar la reducción del riesgo.
Dos protecciones no son independientes solo porque tengan nombres diferentes. Pueden existir dependencias en sensores, lógica, alimentación, utilidades, comunicación, elemento final, mantenimiento, pruebas, configuración o acción humana.
Ejemplo: una alarma y un trip que utilizan el mismo transmisor pueden perder simultáneamente su capacidad de protección si ese transmisor falla peligrosamente. Del mismo modo, dos sistemas alimentados por el mismo circuito o dependientes de la misma red pueden compartir un modo común de fallo.
El análisis debe preguntar ¿qué puede dejar fuera de servicio ambas capas al mismo tiempo?
Common cause y common mode
Los fallos de causa común son especialmente peligrosos porque invalidan la suposición de multiplicación simple entre probabilidades independientes.
Las fuentes de dependencia pueden incluir:
- la misma alimentación eléctrica;
- el mismo aire de instrumentos;
- el mismo transmisor;
- la misma lógica de control;
- el mismo elemento final;
- la misma ruta física de cables;
- la misma condición ambiental;
- el mismo equipo o procedimiento de mantenimiento;
- un error de configuración replicado;
- un bypass común;
- una vulnerabilidad de ciberseguridad compartida.
La gobernanza de LOPA debe registrar estas dependencias antes de conceder crédito.
Probability of Failure on Demand — PFD
PFD representa la probabilidad de que una capa falle cuando su función sea demandada, dentro de las hipótesis del método utilizado. En LOPA, los valores de PFD se emplean para estimar la reducción de frecuencia asociada a las IPLs.
No deben copiarse valores genéricos sin verificar las condiciones necesarias para sustentarlos. Frecuencia de pruebas, cobertura diagnóstica, reparación, mantenimiento, bypass, arquitectura, competencia y gestión de cambios pueden afectar el desempeño real.
Para una Safety Instrumented Function (SIF), la verificación de SIL es un problema de ingeniería propio y no debe sustituirse por una celda fija en una hoja LOPA.
Condiciones habilitantes
Una enabling condition es una condición que debe estar presente para que el evento iniciador pueda evolucionar en el escenario analizado, pero que no constituye por sí misma la causa iniciadora.
Los ejemplos pueden incluir una etapa operativa específica, presencia de material, modo de campaña o equipo en un determinado estado.
El uso inadecuado de condiciones habilitantes puede reducir artificialmente la frecuencia del escenario. Solo deben aplicarse cuando exista una justificación clara y sin solapamiento con la propia frecuencia del evento iniciador.
Modificadores condicionales
Los conditional modifiers representan probabilidades asociadas a condiciones posteriores o complementarias del escenario, como presencia de personas, probabilidad de ignición u otros factores cuando sean técnicamente aplicables.
Al igual que las condiciones habilitantes, los modificadores condicionales exigen disciplina para evitar doble conteo. CCPS publicó orientación específica para estos elementos precisamente porque su uso inconsistente puede alterar significativamente el resultado.
Cómo ejecutar una LOPA
El proceso debe ser reproducible y auditable.
Seleccionar la consecuencia
La consecuencia debe estar técnicamente definida. Una misma causa puede conducir a consecuencias distintas y requerir escenarios separados.
Definir el evento iniciador
La causa iniciadora debe ser coherente con el mecanismo analizado. Frecuencias duplicadas o agregaciones arbitrarias comprometen el análisis.
Identificar salvaguardas
Primero registre las protecciones existentes. Después evalúe cuáles cumplen los criterios de una IPL. Este orden reduce la tendencia a “forzar” una salvaguarda dentro del cálculo porque ya fue mencionada en HAZOP.
Comparar con el criterio de riesgo
La organización debe disponer de un criterio documentado. La hoja LOPA no define por sí sola qué es un riesgo tolerable.
Ejemplo conceptual de cálculo
Considere, únicamente como ejemplo didáctico, un evento iniciador con una frecuencia hipotética de 10⁻¹ por año. Suponga que existen dos IPLs independientes, cada una con una PFD hipotética de 10⁻¹. Despreciando otros factores en el ejemplo, la frecuencia mitigada sería del orden de:
10⁻¹ × 10⁻¹ × 10⁻¹ = 10⁻³ por año.
Este ejemplo muestra la lógica de órdenes de magnitud; no proporciona valores estandarizados para uso en proyecto. En un estudio real, cada frecuencia, PFD, dependencia y condición debe justificarse técnicamente.
Criterio de tolerabilidad y brecha de riesgo
El resultado de LOPA solo es útil cuando se compara con un criterio de riesgo definido. Si la frecuencia mitigada estimada permanece por encima del criterio para la consecuencia, existe una brecha de reducción de riesgo.
Esta brecha puede tratarse mediante diferentes estrategias:
- eliminar o reducir el peligro mediante un diseño inherentemente más seguro;
- reducir la frecuencia del iniciador;
- añadir o mejorar una capa de protección;
- modificar el proceso o inventario;
- mejorar segregación o contención;
- implementar una SIF con el SIL requerido cuando sea apropiado;
- revisar operación o mantenimiento.
La decisión no debe saltar automáticamente a “instalar un SIS”. La jerarquía de reducción del riesgo y la viabilidad de soluciones inherentes o pasivas deben considerarse primero.
Relación entre LOPA y SIL
Cuando LOPA genera un requisito para una SIF, ese requisito debe atravesar proyecto, Procurement, FAT, SAT, validación y operación sin perder trazabilidad. Es precisamente en este tramo donde Owner’s Engineering y la puesta en marcha agregan valor.
Una de las aplicaciones importantes de LOPA es ayudar a determinar la reducción de riesgo que debe proporcionar una función instrumentada de seguridad. CCPS reconoce el uso de LOPA para este propósito, y la IEC 61511 incluye orientación para determinar los niveles requeridos de integridad de seguridad.
Cuando se requiere una SIF, el requisito resultante debe migrar al ciclo de Seguridad Funcional: definición de la función, estado seguro, condiciones de disparo, tiempo de respuesta, SIL requerido, independencia, arquitectura, pruebas, operación y gestión de cambios.
LOPA ayuda a determinar el requisito; no sustituye la verificación de que la SIF diseñada cumpla realmente ese requisito.
SIL requerido vs. SIL verificado
El SIL requerido deriva de la necesidad de reducción de riesgo para una SIF. La verificación de SIL evalúa si la arquitectura y los componentes diseñados pueden alcanzar el desempeño exigido, considerando fallos aleatorios y sistemáticos de acuerdo con el método aplicable.
Mezclar estas dos etapas es un error grave: determinar “SIL 2” en una LOPA no demuestra que el sistema implementado sea SIL 2.
BPCS e independencia
El Basic Process Control System (BPCS) ejecuta el control normal del proceso. Dependiendo del escenario, una función de control o alarma en el BPCS puede ser una salvaguarda útil. Sin embargo, conceder crédito como IPL exige evaluar la independencia respecto del evento iniciador y de las demás capas.
Si el fallo del BPCS es el propio iniciador, utilizar otra función dependiente de la misma infraestructura para reducir el escenario puede generar un crédito indebido.
Alarmas y acción del operador
Una alarma seguida de respuesta humana no recibe crédito automáticamente. Es necesario evaluar si:
- la condición se detecta de forma confiable;
- la alarma es distinguible;
- existe tiempo suficiente para diagnóstico y acción;
- el operador dispone de procedimiento y capacitación;
- la acción es físicamente ejecutable;
- no existe sobrecarga de alarmas;
- la función es independiente de las demás capas acreditadas;
- se mantienen el desempeño y las pruebas.
En escenarios rápidos, una respuesta humana puede simplemente no ser compatible con el tiempo disponible.
Dispositivos de alivio y protección mecánica
PSVs, discos de ruptura, contenciones y otras barreras pueden ser extremadamente importantes, pero el crédito depende de la consecuencia analizada, capacidad, independencia, diseño, inspección, mantenimiento y condiciones reales de operación.
Una válvula de alivio puede prevenir la sobrepresión del equipo y aun así no impedir otra consecuencia, como una descarga peligrosa en un lugar inadecuado. La IPL debe evaluarse frente al escenario específico.
Sistemas instrumentados de seguridad
Una SIF puede actuar como IPL cuando posee independencia y desempeño adecuados al escenario. La función completa normalmente incluye sensor, logic solver y elemento final. Confiar únicamente en la certificación individual de componentes no demuestra el desempeño de la función completa.
Además del cálculo de PFD, deben gobernarse:
- requisitos funcionales;
- arquitectura;
- intervalos de proof test;
- bypasses;
- fallos detectados y no detectados;
- competencia;
- configuración;
- validación;
- mantenimiento;
- Management of Change.
LOPA y factores humanos
El error humano puede aparecer como iniciador, condición o elemento de protección según el escenario. Esto exige cuidado para no atribuir independencia artificial a acciones realizadas por la misma persona, bajo la misma presión operativa y a partir de la misma información.
El estudio debe representar el trabajo real y no un procedimiento idealizado.
LOPA en instalaciones brownfield
En plantas existentes, una dificultad común consiste en utilizar IPLs “de diseño” que ya no existen de la forma documentada. Cambios de lógica, bypasses, cambios de instrumentos, válvulas trabadas, pruebas atrasadas y fallos de documentación afectan la validez de las premisas.
Antes de acreditar una capa, puede ser necesario verificar físicamente:
- arquitectura instalada;
- sensor y elemento final;
- alimentación y utilidades;
- lógica y setpoints;
- independencia física y funcional;
- historial de pruebas;
- condición de bypass;
- documentación As-Built.
Esto conecta LOPA con Site Survey, Ingeniería Diagnóstica y recommissioning.
Gestión de cambios
Una LOPA contiene premisas que pueden perder validez después de modificaciones. Un aumento de capacidad, cambio de producto, nuevo modo operativo, modificación de setpoint, sustitución de válvula, actualización de software o cambio del intervalo de prueba pueden alterar frecuencia, consecuencia o desempeño de una IPL.
El Management of Change debe identificar qué estudios de riesgo necesitan revisarse.
Documentación y trazabilidad
El registro de LOPA debe permitir reconstruir el razonamiento. Para cada escenario, conviene registrar:
- origen del escenario;
- consecuencia analizada;
- evento iniciador y fuente de la frecuencia;
- condiciones habilitantes;
- modificadores condicionales;
- salvaguardas identificadas;
- justificación de las IPLs acreditadas;
- PFD y fuente adoptada;
- dependencias evaluadas;
- resultado del cálculo;
- criterio de riesgo;
- brecha de reducción;
- recomendaciones;
- responsables y estado.
Sin esta trazabilidad, las revisiones futuras se convierten en ejercicios de reconstrucción de premisas.
Calidad de los datos
LOPA trabaja con órdenes de magnitud, pero eso no significa aceptar cualquier dato. La incertidumbre debe reconocerse y tratarse conservadoramente cuando sea necesario.
Una gobernanza madura define fuentes autorizadas, criterios para datos propios, reglas de actualización, tratamiento de ausencia de información y responsables de aprobar premisas.
Facilitación y competencia
El workshop debe reunir conocimientos de proceso, operación, instrumentación, automatización, mantenimiento y seguridad compatibles con los escenarios. El facilitador debe controlar el método y cuestionar créditos indebidos.
En decisiones que conducen a la especificación de SIL o SIS, aumenta la competencia requerida. La organización debe definir claramente quién determina el requisito, quién verifica el cálculo, quién lo aprueba y quién valida la implementación.
Owner’s Engineering y revisión independiente
Owner’s Engineering puede actuar como capa de gobernanza entre el estudio de riesgos, el proyecto y el proveedor. Esto incluye revisar premisas, garantizar consistencia entre HAZOP y LOPA, verificar que los requisitos hayan migrado a las especificaciones, acompañar TBE y FAT/SAT y controlar cambios.
Este papel es diferente de suministrar el Safety PLC o desarrollar toda la lógica de aplicación. El foco es preservar los requisitos de riesgo del propietario durante la contratación y la implantación.
LOPA en Procurement
Cuando una recomendación resulta en un nuevo sistema o modificación, el proceso de compra debe preservar los requisitos técnicos. Una RFP genérica que solicite un “sistema SIL 2” sin definir SIFs, interfaces, condiciones de proceso, proof tests y responsabilidades transfiere ambigüedades al proveedor.
Los requisitos provenientes de LOPA deben convertirse en documentación de ingeniería y criterios de aceptación.
FAT, SAT y validación
La existencia de hardware compatible con un determinado SIL no cierra el ciclo. Las pruebas deben demostrar que las funciones implementadas corresponden a los requisitos.
FAT y SAT pueden verificar lógica, secuencias, diagnósticos, fallos, interfaces y documentación. La validación de Seguridad Funcional posee requisitos propios y debe planificarse conforme al alcance, independencia y responsabilidades aplicables.
Auditoría de las IPLs durante la operación
Una IPL solo mantiene el crédito si su desempeño se sostiene. La gobernanza operativa debe controlar:
- proof tests e inspecciones;
- fallos bajo demanda;
- bypasses;
- reparaciones pendientes;
- cambios de configuración;
- desempeño de alarmas;
- fallos espurios;
- cambios de proceso;
- competencia de mantenimiento;
- evidencias de prueba.
Este seguimiento cierra la distancia entre la LOPA “de proyecto” y el riesgo real de la instalación.
Errores recurrentes en LOPA
Los principales problemas son metodológicos, no aritméticos:
- escenarios demasiado amplios;
- frecuencia iniciadora sin fuente;
- doble conteo de condiciones;
- atribución de crédito a salvaguardas no independientes;
- ignorar fallos de causa común;
- usar PFD genérica sin premisas;
- considerar acción humana sin tiempo y confiabilidad;
- tratar SIL requerido como SIL verificado;
- no actualizar el estudio después de un cambio;
- cerrar recomendaciones sin comprobar la implementación.
Una hoja de cálculo puede multiplicar números correctamente y aun así producir una conclusión errónea si estas premisas son inadecuadas.
Cómo puede actuar la Ingeniería Consultiva en LOPA
La actuación consultiva puede concentrarse en método, facilitación, gobernanza y revisión independiente. Esto incluye preparar escenarios, organizar información, moderar workshops, verificar criterios de IPL, registrar premisas, integrar especialistas, acompañar recomendaciones y asegurar que los requisitos resultantes lleguen al proyecto y a la contratación.
Para A3A, este enfoque se conecta directamente con Gestión de Riesgos de Ingeniería, Consultoría Técnica, Proyecto de Automatización Industrial, Owner’s Engineering y Puesta en Marcha, sin confundir consultoría con certificación de SIL o suministro de SIS.
Entregables de una LOPA consultiva
Un paquete puede incluir:
- plan y criterios del estudio;
- lista de escenarios seleccionados;
- hojas LOPA controladas;
- fuentes de frecuencias y PFDs;
- justificaciones de IPL;
- registro de dependencias;
- cálculo del riesgo mitigado;
- brechas de reducción;
- recomendaciones;
- requisitos para estudios posteriores;
- matriz de acciones;
- informe ejecutivo y registro de aprobación.
Consideraciones finales
LOPA es una herramienta poderosa porque obliga a la ingeniería a explicitar por qué una protección merece crédito y cuánto riesgo permanece después de su actuación. Su rigor reside menos en la sofisticación matemática y más en la calidad de las premisas, la independencia de las capas y la gobernanza del ciclo de vida.
Cuando se integra con HAZID, HAZOP, SIL, proyecto de automatización, Procurement y puesta en marcha, LOPA transforma escenarios de riesgo en requisitos trazables. Este encadenamiento es esencial para que la reducción de riesgo definida en el estudio siga existiendo después de que el proyecto pase por proveedores, montaje, pruebas, operación y cambios.
Referencias técnicas
[1] CENTER FOR CHEMICAL PROCESS SAFETY (CCPS). LOPA Data — What is LOPA. New York: AIChE. Disponible en: 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. Disponible en: 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. Disponible en: 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. Disponible en: 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. Disponible en: https://webstore.iec.ch/en/publication/60766
[6] INTERNATIONAL SOCIETY OF AUTOMATION. ISA-84 Series of Standards. Research Triangle Park: ISA. Disponible en: https://www.isa.org/standards-and-publications/isa-standards/isa-84-standards
Preguntas frecuentes
LOPA es Layer of Protection Analysis, una metodología semicuantitativa que evalúa un escenario específico, su frecuencia iniciadora y las capas independientes de protección para estimar la frecuencia mitigada de la consecuencia.
Una salvaguarda es cualquier medida que contribuye a reducir el riesgo. Una IPL es una salvaguarda que cumple criterios adicionales de independencia, funcionalidad, integridad, confiabilidad y auditabilidad y que puede recibir crédito cuantitativo en LOPA.
Normalmente se clasifica como semicuantitativa. Trabaja con frecuencias y probabilidades en órdenes de magnitud, con reglas simplificadas, situándose entre análisis cualitativos y una QRA detallada.
Puede utilizarse para determinar la reducción de riesgo adicional necesaria y, cuando esa reducción será proporcionada por una SIF, apoyar la determinación del SIL requerido. Esto no sustituye la verificación posterior de SIL de la función diseñada.
Puede formar parte de una capa acreditable bajo condiciones específicas, pero no automáticamente. Deben evaluarse independencia, detección, tiempo de respuesta, acción del operador, capacitación, auditabilidad y demás criterios aplicables.
Debe reevaluarse cuando cambios de proceso, capacidad, setpoints, instrumentos, lógica, pruebas, equipos o condiciones operativas puedan alterar las premisas del escenario o el desempeño de las capas.
Materiales técnicos complementarios
Soluciones relacionadas
Servicios relacionados
- Consultoría Técnica de Ingeniería: diagnóstico, estrategia y apoyo a la decisión
- Gestión de Riesgos de Ingeniería: identificación, análisis, mitigación y contingencia
- Proyecto de Automatización Industrial: control, supervisión, redes OT e integración
- Puesta en Marcha de Ingeniería: planificación, pruebas, preparación y handover
Contenidos principales sobre el tema
- HAZID en Ingeniería: qué es Hazard Identification, metodología y aplicación en proyectos industriales
- HAZOP en Ingeniería: metodología, palabras guía y análisis de desviaciones de proceso
