Entienda qué es SIL, PFDavg, RRF, SIF, determinación y verificación, proof test, arquitectura, SRS, validación y gobernanza según IEC 61511.
¡Descúbrelo!
Safety Integrity Level (SIL) es una medida discreta del nivel de integridad requerido o alcanzado por una función instrumentada de seguridad, utilizada para relacionar la reducción de riesgo necesaria con el desempeño que esa función debe demostrar durante todo su ciclo de vida. En aplicaciones de proceso, SIL debe entenderse en el contexto de la Seguridad Funcional y de la IEC 61511: primero se identifica el riesgo y se determina cuánta reducción adicional es necesaria; después esa necesidad se transforma en requisitos de una Safety Instrumented Function (SIF); por último, el diseño debe verificarse y validarse para demostrar que la función implementada cumple el nivel requerido. Por ello, “tener un PLC SIL 3” no significa que una función completa sea SIL 3.
Qué es SIL
SIL significa Safety Integrity Level, o Nivel de Integridad de Seguridad. El concepto se utiliza en normas de Seguridad Funcional para clasificar requisitos de desempeño asociados a funciones de seguridad.
En la industria de procesos, la IEC 61511 establece requisitos para la especificación, diseño, instalación, operación y mantenimiento de Safety Instrumented Systems (SIS), con base en la IEC 61508. El SIL aparece dentro de este ciclo como una forma de expresar la integridad requerida para determinadas Safety Instrumented Functions.
La palabra clave es función. SIL no debe tratarse como una etiqueta genérica de la planta, del panel o de un equipo aislado.
SIL es propiedad de la SIF, no del equipo aislado
Una Safety Instrumented Function normalmente comprende toda la cadena necesaria para detectar una condición peligrosa y llevar el proceso a un estado seguro:
- sensor o conjunto de sensores;
- lógica o logic solver;
- elemento final, como válvula, contactor, actuador o sistema de parada;
- alimentación y utilidades asociadas;
- lógica de aplicación;
- diagnósticos;
- procedimientos de prueba y mantenimiento.
Un transmisor certificado para determinado nivel o un Safety PLC con capacidad declarada es solo una parte de la evidencia. La función completa debe cumplir los requisitos de integridad, arquitectura, independencia, aplicación, pruebas y gestión definidos para el escenario.
Seguridad Funcional y Seguridad de Procesos
La Seguridad Funcional es la parte de la seguridad que depende del funcionamiento correcto de sistemas y funciones de protección. En procesos industriales, se integra en una estrategia más amplia que puede incluir diseño inherentemente seguro, contención, alivio, procedimientos, protección pasiva, alarmas, SIS y respuesta a emergencias.
La IEC TR 61511-0 destaca que la seguridad de procesos debe priorizar procesos inherentemente seguros cuando sea posible y utilizar sistemas de protección cuando la eliminación del peligro no sea práctica o suficiente.
Por tanto, SIL no debe ser la primera respuesta a cualquier riesgo. Aparece cuando el análisis demuestra la necesidad de una función instrumentada con una reducción de riesgo específica.
Cómo se establece un requisito SIL
El requisito SIL debe originarse en el análisis de riesgos. Especificar previamente “SIL 2” o “SIL 3” sin escenario, criterio de tolerabilidad y reducción requerida convierte una decisión de seguridad en un requisito de compra sin trazabilidad.
Conecte el análisis de riesgos con los requisitos de ingeniería
El requisito no debería comenzar con la selección del hardware. Nace del análisis del escenario.
Un camino típico comprende:
- identificar peligros;
- desarrollar escenarios de riesgo;
- evaluar consecuencias y frecuencia;
- considerar las capas de protección existentes;
- determinar el riesgo residual o la brecha de reducción;
- decidir qué medidas adicionales son apropiadas;
- cuando sea necesaria una SIF, asignar el SIL requerido.
Métodos como LOPA pueden utilizarse para apoyar esta determinación en aplicaciones de proceso.
SIL requerido no es SIL verificado
Esta distinción es esencial.
SIL requerido representa el desempeño que la SIF debe alcanzar para proporcionar la reducción de riesgo definida por el análisis.
SIL verificado representa la conclusión de que el diseño propuesto, dentro de las hipótesis de arquitectura, tasas de fallo, intervalos de prueba, cobertura de diagnóstico, reparación y demás factores, es capaz de cumplir el requisito.
Después existe todavía la validación, que verifica si la función instalada e implementada cumple los requisitos funcionales y de integridad en el contexto real de aplicación.
Mezclar estas etapas lleva a conclusiones como “LOPA dio SIL 2, por tanto el sistema es SIL 2”, lo que no es técnicamente correcto.
Relación entre SIL y reducción de riesgo
SIL está relacionado con la probabilidad de fallo peligroso de la función y, por tanto, con el factor de reducción de riesgo que puede proporcionar dentro de las condiciones de aplicación.
En modo de baja demanda, normalmente se utiliza Probability of Failure on Demand average (PFDavg). En aplicaciones de alta demanda o continuas, el tratamiento se asocia a la frecuencia o probabilidad de fallo peligroso por unidad de tiempo conforme a la estructura normativa aplicable.
Lo importante para la ingeniería es comprender que un SIL más alto exige un desempeño más riguroso, pero no debe seleccionarse como un “margen de seguridad” arbitrario. Los requisitos excesivos pueden aumentar complejidad, coste, mantenimiento y dificultad de validación sin necesariamente mejorar la arquitectura global de riesgo.
Rangos de PFDavg en baja demanda
Para funciones que operan en modo de baja demanda, los rangos tradicionalmente asociados a los niveles de integridad se expresan mediante órdenes de magnitud de PFDavg.
| SIL | Rango de PFDavg | Reducción de riesgo aproximada asociada |
| SIL 1 | ≥ 10⁻² y < 10⁻¹ | > 10 a ≤ 100 |
| SIL 2 | ≥ 10⁻³ y < 10⁻² | > 100 a ≤ 1.000 |
| SIL 3 | ≥ 10⁻⁴ y < 10⁻³ | > 1.000 a ≤ 10.000 |
Estos intervalos ayudan a interpretar el requisito, pero no sustituyen la verificación de la función. La reducción real depende de la arquitectura y de las hipótesis del ciclo de vida.
En la industria de procesos, los requisitos muy elevados deben plantear una pregunta de ingeniería: ¿es posible reducir el riesgo mediante otras capas, modificar el proceso o eliminar dependencias antes de concentrar toda la reducción en una única SIF?
PFDavg
PFDavg representa la probabilidad media de que una función falle peligrosamente cuando sea demandada. Para una SIF de baja demanda, es una de las métricas centrales de la verificación de SIL.
El valor no depende únicamente del “SIL del equipo”. Entre los factores relevantes se encuentran:
- tasas de fallo peligroso;
- fracción de fallos detectados y no detectados;
- arquitectura 1oo1, 1oo2, 2oo3 u otra aplicable;
- intervalos de proof test;
- cobertura del proof test;
- tiempo de reparación;
- diagnósticos;
- fallos de causa común;
- bypasses;
- comportamiento del elemento final;
- hipótesis de mantenimiento.
Risk Reduction Factor — RRF
El Risk Reduction Factor es una forma intuitiva de interpretar la reducción asociada a una capa o función. En un tratamiento simplificado de baja demanda, RRF se relaciona con el inverso de PFDavg.
Por ejemplo, una PFDavg de 10⁻² corresponde conceptualmente a una reducción de riesgo del orden de 100. Esto no significa que cualquier dispositivo con esta característica pueda insertarse en la arquitectura y producir automáticamente ese RRF. La función debe mantener independencia y desempeño como sistema completo.
Sensor, logic solver y elemento final contribuyen al resultado
La función de seguridad es una cadena. Sensor, lógica, elemento final, alimentación, pruebas y mantenimiento deben analizarse como un sistema; concentrar la especificación en el Safety PLC deja dependencias críticas fuera de la decisión.
Estructure la arquitectura de automatización a partir de requisitos
La PFD de la SIF resulta de la contribución de las partes de la cadena y de las dependencias entre ellas. En muchas aplicaciones, los elementos finales pueden representar una parte relevante de la indisponibilidad peligrosa, porque están sujetos a mecanismos mecánicos, condiciones de proceso, atascamiento, desgaste y pruebas imperfectas.
Concentrarse únicamente en el Safety PLC puede llevar a una arquitectura electrónicamente sofisticada y mecánicamente vulnerable.
Arquitecturas 1oo1, 1oo2 y 2oo3
La notación MooN describe cuántos canales deben votar para que la función actúe.
- 1oo1: uno de un canal es suficiente;
- 1oo2: uno de dos canales puede provocar la acción;
- 2oo3: dos de tres canales son necesarios para la votación.
La redundancia puede reducir determinadas probabilidades de fallo peligroso, pero también introduce complejidad, fallos comunes, mantenimiento adicional y posibilidad de trips espurios. La arquitectura correcta depende del requisito funcional, de las restricciones normativas, de la disponibilidad deseada y de la calidad de los datos utilizados.
Hardware Fault Tolerance y restricciones arquitectónicas
Alcanzar una PFD calculada no es la única condición relevante. Las normas de Seguridad Funcional también abordan restricciones arquitectónicas, tolerancia a fallos, capacidades de los dispositivos y mecanismos sistemáticos.
Por tanto, un cálculo numérico favorable no debe utilizarse para eludir requisitos de arquitectura o competencia.
Fallos aleatorios frente a fallos sistemáticos
Los fallos aleatorios de hardware pueden tratarse mediante modelos probabilísticos. Los fallos sistemáticos surgen de la especificación, diseño, software, configuración, integración, procedimientos u otras causas que no están adecuadamente representadas únicamente por tasas aleatorias.
Ejemplos:
- requisito incorrecto;
- lógica implementada incorrectamente;
- unidad de ingeniería equivocada;
- setpoint incorrecto;
- error de programación replicado;
- prueba de validación incompleta;
- mantenimiento con un procedimiento inadecuado.
Por eso la Seguridad Funcional es un problema de ciclo de vida y gestión, no solo de confiabilidad de componentes.
La certificación de un componente no certifica la SIF
Los certificados de productos ayudan a demostrar capacidades y límites de uso, pero la responsabilidad de la aplicación permanece.
Un sensor, logic solver o elemento final puede contar con certificación o datos apropiados para una determinada aplicación y aun así utilizarse de forma incompatible con el requisito de la SIF.
Cuestiones como el intervalo de proof test, condiciones ambientales, arquitectura, diagnóstico, versión de firmware, configuración, restricciones de uso e independencia siguen siendo relevantes.
Prior use y datos de campo
En algunos contextos, la experiencia operacional demostrada puede apoyar justificaciones de uso de equipos. Sin embargo, “siempre usamos este modelo” no equivale a evidencia estructurada.
Los datos deben considerar población, horas de operación, modos de fallo, condiciones de uso, calidad del registro y similitud de la aplicación.
Proof test
Proof test es una prueba periódica destinada a revelar fallos peligrosos no detectados que podrían impedir que la función actúe cuando sea demandada.
El intervalo entre pruebas influye directamente en PFDavg en muchas arquitecturas. Aumentar el intervalo puede degradar el desempeño; reducirlo puede aumentar el esfuerzo de mantenimiento y la exposición operacional.
El intervalo debe ser una decisión de ingeniería conectada al cálculo y a la capacidad real de la organización para ejecutar el procedimiento.
Proof Test Coverage — PTC
Ninguna prueba debe suponerse capaz de revelar todos los fallos peligrosos únicamente porque exista una hoja de inspección. Proof Test Coverage representa qué parte del universo relevante de fallos es efectivamente detectada por el procedimiento.
Una prueba superficial puede cumplir el calendario sin restaurar la confiabilidad esperada.
La especificación debe definir método, instrumentos necesarios, condiciones de proceso, secuencia, criterios de aceptación, restauración y evidencias.
Diagnósticos y cobertura diagnóstica
Los diagnósticos automáticos pueden reducir el tiempo durante el cual determinados fallos permanecen ocultos, pero deben evaluarse en cuanto a cobertura, respuesta, alarmas, reparación e independencia.
Un fallo detectado que permanece meses sin corregirse no ofrece el mismo beneficio que un diagnóstico asociado a una política efectiva de mantenimiento.
Fallo de causa común
La redundancia no elimina fallos que afectan varios canales simultáneamente.
Las posibles causas comunes incluyen:
- la misma toma de proceso;
- la misma línea de impulso o manifold;
- la misma alimentación;
- el mismo ambiente;
- la misma ruta de cable;
- la misma tecnología sujeta al mismo mecanismo;
- la misma configuración incorrecta;
- el mismo equipo ejecutando mantenimiento inadecuado;
- la misma vulnerabilidad de ciberseguridad.
Los modelos de verificación deben considerar las dependencias de causa común de forma compatible con la arquitectura.
Independencia entre BPCS y SIS
Una SIF utilizada para reducir riesgo necesita independencia suficiente respecto del evento iniciador y de las capas a las que se atribuyó crédito.
Si el BPCS causa el evento y la SIF comparte sensor, lógica, comunicación o elemento final de forma incompatible con la independencia requerida, el beneficio calculado puede no existir en la práctica.
La independencia debe definirse en la arquitectura, no solo declararse en el memorial descriptivo.
Safety Requirements Specification — SRS
La Safety Requirements Specification transforma el análisis de riesgos en requisitos de ingeniería para el SIS y sus SIF.
Una SRS robusta debe definir, según corresponda:
- identificación de la SIF;
- peligro y escenario asociado;
- SIL requerido;
- variables monitorizadas;
- setpoints y tolerancias;
- estado seguro;
- acción de los elementos finales;
- tiempo de respuesta;
- condiciones de reset;
- bypasses y permisivos;
- interfaces con BPCS y otros sistemas;
- requisitos de diagnóstico;
- intervalo y método de proof test;
- requisitos de operación y mantenimiento;
- criterios de validación.
La SRS es uno de los principales puentes entre LOPA y el proyecto de automatización.
La matriz de causa y efecto no sustituye a la SRS
Una Cause & Effect Matrix es excelente para representar relaciones entre causas y acciones, pero normalmente no contiene todo el conjunto de requisitos necesarios para gobernar la Seguridad Funcional.
Puede formar parte de la SRS o ser un documento relacionado. El error es reducir la función de seguridad a una matriz de bits sin registrar las hipótesis de desempeño y ciclo de vida.
Del SIL requerido a la arquitectura
El desarrollo debe traducir los requisitos en una solución que satisfaga el desempeño y las restricciones.
Esta visión evita tratar la verificación como una simple consulta a un certificado del fabricante.
Verificación de SIL
La verificación demuestra, mediante método y datos documentados, que la SIF diseñada cumple los requisitos de integridad aplicables.
Puede incluir cálculos de PFDavg o métricas correspondientes, evaluación de arquitectura, fallos sistemáticos, restricciones de los dispositivos y condiciones de uso.
ISA mantiene el informe técnico ISA-TR84.00.02-2022, dedicado específicamente a la verificación de SIL de SIF, que aborda fallos aleatorios y sistemáticos, probabilidades de fallo y otros aspectos de desempeño.
Validación de Seguridad Funcional
FAT, SAT y validación deben nacer de la SRS y de los criterios de aceptación. El seguimiento independiente ayuda a impedir que los requisitos de Seguridad Funcional se reduzcan a pruebas genéricas de I/O y secuencia.
La verificación responde si el diseño cumple los requisitos definidos. La validación responde si la función implementada, instalada y configurada cumple los requisitos de Seguridad Funcional en el contexto de aplicación.
La validación debe planificarse antes de las pruebas y contar con criterios de aceptación claros.
Puede incluir:
- simulación de condiciones de disparo;
- verificación de setpoints;
- lógica y secuencias;
- acción de elementos finales;
- tiempo de respuesta;
- comportamiento ante fallos;
- alarmas;
- bypass y reset;
- pérdida de energía o utilidades;
- interfaces;
- registros y evidencias.
FAT, SAT y validación no son sinónimos
FAT se realiza en el entorno de fábrica o integración antes de la instalación en campo. SAT verifica aspectos después de la instalación. La validación de Seguridad Funcional tiene un objetivo normativo y funcional más amplio y debe demostrar los requisitos de la SRS conforme al plan aplicable.
Un FAT bien ejecutado reduce el riesgo, pero no puede demostrar todas las condiciones de campo.
Seguridad Funcional durante la operación
La SIF no “mantiene el SIL” por inercia. El desempeño depende de actividades durante la operación:
- proof tests en el intervalo previsto;
- reparación de fallos;
- control de bypasses;
- gestión de cambios;
- investigación de fallos bajo demanda;
- control de repuestos;
- gestión de versiones y configuración;
- mantenimiento de la competencia;
- auditorías y evaluaciones periódicas.
Una instalación que abandona estas prácticas puede perder las hipótesis que sustentaban la verificación original.
Bypasses y overrides
Un bypass puede ser necesario para prueba o mantenimiento, pero elimina temporalmente una capa de reducción de riesgo. Por ello debe controlarse mediante autorización, plazo, registro, compensación cuando sea necesaria y restauración verificada.
Los bypasses permanentes u olvidados son incompatibles con la idea de una función cuya disponibilidad fue calculada bajo hipótesis diferentes.
Management of Change
Cualquier modificación capaz de afectar la SIF debe pasar por un proceso de gestión de cambios.
Ejemplos:
- cambio de setpoint;
- cambio de lógica;
- sustitución de instrumento;
- cambio de válvula;
- cambio del intervalo de prueba;
- actualización de firmware;
- cambio de condiciones de proceso;
- modificación de arquitectura o comunicación;
- modificación de procedimiento operacional.
El MOC debe evaluar el impacto en el análisis de riesgos, la SRS, la verificación y la validación.
Ciberseguridad y Seguridad Funcional
Los sistemas instrumentados modernos utilizan activos digitales. ISA-84 e IEC 61511 reconocen la necesidad de abordar los riesgos de ciberseguridad dentro del ciclo de vida aplicable.
La ciberseguridad no se calcula como “otro SIL”. Debe proteger la integridad de las funciones, impedir cambios no autorizados y preservar la independencia y disponibilidad requeridas.
Esto incluye control de acceso, gestión de configuración, redes, estaciones de ingeniería, backups, patches y procedimientos de mantenimiento.
SIL en proyectos brownfield
Las modernizaciones presentan desafíos adicionales. Muchas instalaciones cuentan con documentación incompleta, lógica modificada, equipos obsoletos e historial de pruebas inconsistente.
Antes de declarar la capacidad de una SIF existente, puede ser necesario reconstruir:
- arquitectura As Built;
- lista de instrumentos;
- versiones de hardware y software;
- lógica real;
- elementos finales;
- proof tests realizados;
- bypasses;
- fallos históricos;
- cambios de proceso.
Este trabajo puede comenzar como Ingeniería Diagnóstica antes de evolucionar hacia un análisis especializado de Seguridad Funcional.
SIL en Procurement
Comprar “un SIS SIL 3” es una especificación insuficiente. Procurement debe partir de las SIF y de los requisitos de aplicación.
Una especificación técnica debe aclarar:
- alcance del proveedor;
- SRS aplicable;
- hardware y software;
- documentos de Safety Manual;
- datos de fallo e hipótesis;
- responsabilidades por los cálculos;
- lógica de aplicación;
- FAT y SAT;
- validación;
- documentación final;
- formación;
- repuestos;
- soporte del ciclo de vida;
- gestión de versiones.
La TBE debe comparar la conformidad técnica y no únicamente la etiqueta SIL del producto.
Design Review y Owner’s Engineering
Una revisión independiente puede verificar si los requisitos de riesgo fueron correctamente convertidos en diseño y contratación.
Owner’s Engineering puede acompañar las interfaces entre proceso, automatización, proveedor, montaje y puesta en marcha, verificando la trazabilidad de las SIF, documentos, cambios, pruebas y pendientes.
Esta actuación es especialmente útil cuando distintas empresas realizan HAZOP/LOPA, diseñan la automatización, suministran el Safety PLC y ejecutan el montaje.
Competencia e independencia
La Seguridad Funcional exige competencia compatible con la actividad. Facilitar LOPA, determinar SIL, verificar PFDavg, desarrollar lógica, validar una SIF y realizar una evaluación independiente son tareas diferentes.
Una organización madura define responsables, criterios de competencia y grado de independencia para cada etapa.
La Ingeniería Consultiva puede coordinar y gobernar el ciclo sin afirmar una competencia de certificación que no posee.
Qué puede entregar una consultoría sin suministrar el SIS
Existe una amplia gama de actuaciones consultivas:
- diagnóstico del ciclo de Seguridad Funcional;
- organización de HAZID, HAZOP y LOPA;
- gobernanza de la determinación de SIL;
- revisión de SRS;
- Design Review de arquitectura e interfaces;
- revisión de documentación de proveedores;
- apoyo a RFP/RFQ y TBE;
- seguimiento de FAT/SAT;
- gestión de recomendaciones;
- gestión de cambios;
- auditoría documental y de trazabilidad;
- coordinación de especialistas responsables de cálculos o validaciones específicas.
Este posicionamiento separa claramente la gobernanza técnica de la certificación.
Errores recurrentes al tratar SIL
Entre los problemas más frecuentes se encuentran:
- especificar SIL antes de analizar el riesgo;
- atribuir SIL a toda la planta;
- confundir el certificado de un componente con el desempeño de la SIF;
- confundir SIL requerido con SIL verificado;
- ignorar el elemento final;
- usar un intervalo de proof test irreal;
- desconsiderar la causa común;
- compartir BPCS y SIS sin evaluar la independencia;
- tratar FAT como validación completa;
- cambiar lógica sin MOC;
- mantener bypasses sin control;
- no actualizar el cálculo después de un cambio relevante.
Documentos que sustentan la trazabilidad
Dependiendo del proyecto, el conjunto documental puede incluir:
- estudios de peligros y riesgos;
- LOPA;
- registro de determinación de SIL;
- SRS;
- arquitectura del SIS;
- diagramas y listas de instrumentos;
- matriz de causa y efecto;
- cálculos de verificación;
- Safety Manuals y certificados de componentes;
- plan y procedimiento de FAT/SAT;
- plan de validación;
- registros de proof test;
- MOC;
- informes de fallo y demanda;
- As Built y backups de configuración.
El valor está en la cadena de trazabilidad entre estos documentos.
Consideraciones finales
SIL es una forma de transformar una necesidad de reducción de riesgo en un requisito medible de una función instrumentada de seguridad. El concepto solo tiene sentido dentro de un ciclo completo: riesgo identificado, SIL determinado, SRS definida, función diseñada, desempeño verificado, implementación validada e integridad mantenida durante la operación.
Para la Ingeniería Consultiva, este ciclo crea una oportunidad clara de actuación en gobernanza, estandarización, revisión independiente, Procurement y Owner’s Engineering. El objetivo no es vender un “sello SIL”, sino asegurar que las decisiones de riesgo sean técnicamente trazables y sobrevivan a las interfaces entre estudio, diseño, proveedor, pruebas y operación.
Referencias técnicas
[1] 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
[2] 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
[3] INTERNATIONAL ELECTROTECHNICAL COMMISSION. IEC 61511:2026 SER — Functional safety — Safety instrumented systems for the process industry sector — All Parts. Geneva: IEC, 2026. Disponible en: https://webstore.iec.ch/en/publication/5527
[4] 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
[5] INTERNATIONAL SOCIETY OF AUTOMATION. ISA84 — Instrumented Systems to Achieve Functional Safety in the Process Industries. Research Triangle Park: ISA. Disponible en: https://www.isa.org/standards-and-publications/isa-standards/isa-standards-committees/isa84
[6] 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
Preguntas frecuentes
SIL significa Safety Integrity Level, o Nivel de Integridad de Seguridad. Expresa el nivel de integridad requerido o alcanzado por una función de seguridad dentro de un ciclo de Seguridad Funcional.
No. Un Safety PLC puede contar con capacidad o certificación adecuada, pero el desempeño SIL de una SIF depende de la función completa, incluidos sensores, logic solver, elementos finales, arquitectura, independencia, fallos, pruebas, aplicación y gestión del ciclo de vida.
El SIL requerido proviene de la reducción de riesgo necesaria. La verificación evalúa si el diseño de la SIF puede cumplir ese requisito bajo las hipótesis de arquitectura, tasas de fallo, proof tests, diagnósticos y demás factores.
PFDavg es la probabilidad media de fallo peligroso bajo demanda. En SIF de baja demanda, es una métrica central para relacionar el desempeño calculado con los rangos SIL.
LOPA puede apoyar la determinación de la reducción de riesgo adicional requerida y, cuando se selecciona una SIF como medida, ayudar a determinar el SIL requerido. La verificación de la SIF es una etapa posterior.
Las hipótesis que sustentan el desempeño de la SIF deben mantenerse durante la operación mediante proof tests, mantenimiento, control de bypasses, gestión de cambios, competencia y documentación actualizada.
Materiales técnicos complementarios
Soluciones relacionadas
Servicios relacionados
- Proyecto de Automatización Industrial: control, supervisión, redes OT e integración
- 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
- Puesta en Marcha de Ingeniería: planificación, pruebas, preparación y handover
Contenidos principales sobre el tema
- LOPA: qué es Layer of Protection Analysis, capas independientes y reducción de riesgo
- HAZID en Ingeniería: qué es Hazard Identification, metodología y aplicación en proyectos industriales
