Entienda qué es un SIS, la diferencia entre SIS, SIF y SIL, arquitectura, SRS, independencia, FAT, SAT, validación, proof tests y gobernanza según IEC 61511.
¡Descúbrelo!
Un Sistema Instrumentado de Seguridad (SIS, Safety Instrumented System) es un sistema de instrumentación y automatización destinado a ejecutar una o más Funciones Instrumentadas de Seguridad (SIF) para llevar o mantener un proceso en estado seguro cuando se detectan condiciones peligrosas. En aplicaciones de la industria de procesos, el SIS no es únicamente un PLC dedicado: cada SIF comprende la cadena completa de sensores, lógica, elementos finales, interfaces, alimentación, diagnóstico, pruebas, procedimientos y gestión durante todo el ciclo de vida. La IEC 61511 establece requisitos para la especificación, proyecto, instalación, operación y mantenimiento de estos sistemas. El valor técnico del SIS reside en una reducción de riesgo efectivamente demostrable, en la independencia respecto de las causas que pueden iniciar el escenario y en la capacidad de cumplir la función de seguridad cuando sea demandada.
Qué es un Sistema Instrumentado de Seguridad
El SIS es una capa instrumentada de protección utilizada cuando el análisis de riesgos demuestra que los controles de proceso, alarmas, barreras mecánicas, procedimientos y demás salvaguardas no reducen un riesgo determinado hasta el criterio definido por la organización. Su finalidad no es optimizar la producción, aumentar el rendimiento ni ejecutar el control regulatorio normal. Su finalidad es actuar ante condiciones previamente especificadas para impedir o limitar una consecuencia peligrosa.
En la terminología de Seguridad Funcional, el SIS puede contener varias SIF. Cada SIF responde a un escenario o requisito de seguridad específico y posee un desempeño requerido, frecuentemente expresado mediante SIL cuando corresponde. Por ello, afirmar que una planta “tiene un SIS SIL 2” sin identificar qué funciones poseen ese requisito puede ocultar un modelado inadecuado. El nivel de integridad se asigna a la función, no al sistema completo como etiqueta comercial.
SIS, SIF y SIL son conceptos diferentes
SIS es el sistema instrumentado que implementa funciones de seguridad. SIF es una función específica que detecta una condición y ejecuta una acción segura. SIL es una medida discreta del nivel de integridad requerido o alcanzado por una determinada SIF dentro de las condiciones establecidas por la norma y por el proyecto.
Ejemplo conceptual: un transmisor detecta presión excesiva en un recipiente; el logic solver procesa la señal; las válvulas de aislamiento cierran y se interrumpe una alimentación. Esta cadena puede constituir una SIF. El conjunto de varias funciones, su infraestructura y los recursos asociados forman el SIS.
El SIS no es lo mismo que el BPCS
El BPCS, Basic Process Control System, ejecuta el control básico del proceso: lazos regulatorios, secuencias normales, supervisión, recetas, permisivos operativos y diversas funciones necesarias para la producción. El SIS actúa como capa de protección para funciones de seguridad definidas.
La distinción arquitectónica importa porque una misma falla no debería invalidar simultáneamente el control normal y la protección que debería responder a la pérdida de ese control. Compartir sensores, comunicaciones, alimentación, software, estaciones de ingeniería o infraestructura puede introducir dependencias que deben evaluarse. La separación física absoluta no es la única forma de lograr independencia, pero cualquier recurso compartido debe justificarse técnicamente y ser compatible con los requisitos de la aplicación.
Cómo se identifica la necesidad de un SIS
La necesidad de una SIF debe permanecer trazable desde el escenario de riesgo hasta la SRS. La Ingeniería Consultiva puede organizar estudios, responsabilidades y criterios antes de contratar al integrador.
Un SIS no debe nacer de la elección de un fabricante o de la preferencia por un “Safety PLC”. La necesidad surge del proceso de identificación y evaluación de peligros. HAZID puede revelar peligros en fases iniciales; HAZOP profundiza el análisis de desviaciones de proceso; LOPA puede verificar si las capas independientes de protección existentes son suficientes y cuantificar, de forma semicuantitativa, la reducción adicional necesaria.
Cuando el riesgo residual permanece por encima del criterio adoptado, puede especificarse una SIF para proporcionar parte de la reducción requerida. La decisión debe permanecer trazable desde el escenario de riesgo hasta el requisito funcional.
Del escenario de peligro a la SIF
Una secuencia técnicamente sólida es:
- identificar el peligro y la consecuencia;
- definir el escenario y sus eventos iniciadores;
- evaluar las salvaguardas y capas independientes existentes;
- comparar el riesgo mitigado con el criterio de tolerabilidad;
- definir la reducción adicional necesaria;
- establecer la función de seguridad apropiada;
- especificar el SIL requerido cuando corresponda;
- registrar los requisitos en la SRS;
- proyectar, verificar, probar y validar la función.
Crear una SIF sin este vínculo puede generar tanto subprotección como sobreespecificación. Una función excesivamente compleja puede aumentar indisponibilidad, mantenimiento, disparos espurios y coste sin un beneficio proporcional de reducción de riesgo.
Arquitectura de una SIF
La representación clásica de una SIF posee tres subsistemas: sensor, logic solver y elemento final. Esta simplificación es útil, pero el desempeño real depende de componentes auxiliares y condiciones de instalación que frecuentemente se ignoran en análisis superficiales.
Subsistema de sensores
El subsistema sensor identifica la variable o condición que demanda la acción. Puede incluir transmisores de presión, temperatura, nivel o caudal; detectores de gas y llama; interruptores; posicionadores; entradas digitales; acondicionamiento de señal; barreras; aisladores; alimentación e infraestructura de campo.
El proyecto debe considerar rangos, precisión, tiempo de respuesta, ambiente, diagnóstico, cobertura de prueba, modo de falla, calibración, instalación, líneas de impulso y la posibilidad de obstrucción, congelación, corrosión u otras condiciones que hagan que la medición no sea representativa del proceso.
La redundancia de sensores puede aumentar la tolerancia a fallos, pero sensores aparentemente independientes pueden sufrir fallos de causa común cuando comparten toma de proceso, tecnología, ubicación, alimentación, ruta de cable o vulnerabilidad ambiental.
Logic solver
El logic solver recibe señales, ejecuta la lógica de la SIF y ordena acciones. Puede ser una plataforma dedicada de seguridad, un sistema electrónico programable apropiado u otra arquitectura aceptada para la aplicación. Su selección debe ser compatible con los requisitos de Seguridad Funcional, arquitectura, capacidad diagnóstica, ciclo de vida del software y ambiente operativo.
La lógica debe controlarse mediante un proceso formal de configuración: requisitos aprobados, versionado, segregación de accesos, revisión, pruebas, backups, gestión de cambios y trazabilidad entre SRS, causa y efecto, código y resultados de prueba.
Elementos finales
El elemento final suele ser la parte dominante del riesgo de falla de una SIF. Válvulas, actuadores, solenoides, contactores, relés, dampers, sistemas de trip y otros dispositivos deben conducir efectivamente el proceso al estado seguro.
Una válvula puede tener un controlador certificado y aun así fallar por atascamiento mecánico, dimensionamiento incorrecto, baja presión de aire, posición de falla inadecuada, solenoide degradado, bypass abierto o mantenimiento deficiente. La Seguridad Funcional no puede reducirse al certificado electrónico de un componente.
Estado seguro y acción de la SIF
La especificación debe definir qué significa “estado seguro” para el escenario analizado. En algunos casos significa cerrar una alimentación; en otros, abrir un alivio, parar un compresor, desenergizar calentamiento, iniciar ventilación, mantener circulación, transferir material o ejecutar una secuencia coordinada.
El estado seguro no significa necesariamente “todo apagado”. Una parada indiscriminada puede crear una consecuencia peor. Por tanto, la función debe derivar del análisis del proceso, de las condiciones transitorias y de las interfaces con otros sistemas.
Tiempo de seguridad del proceso
La SIF debe responder dentro del tiempo disponible antes de que se desarrolle la condición peligrosa. Esto comprende tiempo de detección, filtrado, procesamiento, comunicación, actuación del elemento final y dinámica física del proceso.
Si el proceso alcanza una condición intolerable en pocos segundos, una cadena con retraso excesivo es inadecuada aunque sus componentes sean altamente confiables. El requisito temporal debe constar en la SRS y verificarse mediante pruebas.
Safety Requirements Specification — SRS
La SRS es uno de los documentos centrales del ciclo de Seguridad Funcional. Transforma los resultados del análisis de riesgos en requisitos verificables para cada SIF. No debe confundirse con una lista de I/O ni con una matriz causa-efecto simplificada.
Una SRS robusta normalmente establece, según corresponda:
- identificación y objetivo de la SIF;
- peligros y escenarios asociados;
- entradas y condiciones de demanda;
- acciones y estado seguro;
- SIL requerido;
- tiempo de respuesta;
- lógica y voting;
- requisitos de reset y rearme;
- condiciones de bypass y override;
- comportamiento ante fallos detectados;
- requisitos de independencia;
- interfaces con BPCS y otros sistemas;
- proof test e intervalo asociado;
- requisitos de diagnóstico y alarmas;
- ambiente, alimentación y comunicaciones;
- criterios de validación;
- restricciones operativas y de mantenimiento.
La SRS debe permitir que otro equipo lea el requisito y pueda proyectar, probar y verificar la función sin depender de la memoria informal de reuniones.
Matriz de causa y efecto en el SIS
La matriz de causa y efecto es útil para sintetizar relaciones entre eventos, condiciones y acciones. En proyectos industriales mejora la comunicación entre proceso, automatización, instrumentación, eléctrica, operación e integrador.
Sin embargo, la matriz no contiene necesariamente todos los requisitos funcionales. Puede no registrar tiempo de respuesta, criterios de voting, comportamiento ante fallos, intervalos de prueba, bypasses, prioridades, reset, requisitos de independencia o condiciones de operación degradada. Por ello, debe tratarse como parte de la documentación y no como sustituta automática de la SRS.
Interlock, permisivo y SIF
No todo interlock es una SIF. Muchas lógicas de interlock existen para protección de equipos, secuencia operativa, calidad, disponibilidad o prevención de operación incorrecta. Para que una función sea tratada como SIF debe estar vinculada a un requisito de Seguridad Funcional dentro del proceso de evaluación de riesgos.
Del mismo modo, un permisivo que impide un arranque fuera de condición puede ser importante, pero no recibe automáticamente crédito de reducción de riesgo. Deben verificarse independencia, confiabilidad, especificación, prueba y gobernanza compatibles con el papel atribuido a la función.
SIL y desempeño de la SIF
El SIL especifica rangos de desempeño para funciones relacionadas con la seguridad. En modo de baja demanda, el análisis utiliza frecuentemente PFDavg; en alta demanda o modo continuo se aplican otros parámetros. El valor requerido deriva de la reducción de riesgo necesaria, no del SIL máximo que un fabricante pueda ofrecer.
La verificación de la SIF considera la cadena completa. Tasas de falla, cobertura diagnóstica, intervalo de proof test, cobertura del ensayo, arquitectura, fallo de causa común, tiempo de reparación, restricciones arquitectónicas y capacidad sistemática influyen en el resultado.
Un Safety PLC no define por sí solo el SIL
Una controladora apta para uso en aplicaciones SIL 3 no convierte automáticamente una función en SIL 3. Sensores y elementos finales pueden no cumplir el desempeño necesario; los intervalos de prueba pueden ser incompatibles; una falla de causa común puede invalidar una premisa; la SRS puede estar incompleta; o el software de aplicación puede no haberse desarrollado y validado adecuadamente.
Este es uno de los motivos por los que una adquisición basada únicamente en un certificado de producto es insuficiente.
Independencia entre SIS y BPCS
La independencia es una propiedad de ingeniería, no solo una separación de armarios. Debe analizarse si una misma causa puede comprometer el sistema que inicia o controla el escenario y la capa que debería protegerlo.
Las fuentes de dependencia incluyen:
- sensores o tomas de proceso compartidos;
- alimentación común;
- red o infraestructura de comunicaciones común;
- estaciones de ingeniería compartidas;
- credenciales y administración comunes;
- software o bibliotecas comunes;
- rutas de cables expuestas al mismo evento;
- condiciones ambientales comunes;
- mantenimiento que deja indisponibles simultáneamente BPCS y SIS.
La evaluación debe considerar el escenario específico. Compartir recursos puede ser aceptable en algunas arquitecturas e inadecuado en otras.
Falla segura y falla peligrosa
Una falla que lleva el proceso a una condición segura puede reducir disponibilidad y provocar un trip espurio, pero no tiene el mismo significado que una falla peligrosa no detectada, en la que la SIF permanece aparentemente disponible y falla cuando es demandada.
El proyecto busca controlar ambos efectos: mantener baja probabilidad de falla peligrosa y evitar indisponibilidad excesiva. Una arquitectura que dispara continuamente puede ser técnicamente insostenible porque incentiva bypasses y deteriora la confianza de operación.
Disparos espurios y disponibilidad
La Seguridad Funcional no debe optimizarse de forma aislada respecto de la operabilidad. Los trips espurios frecuentes pueden provocar pérdidas de producción, transitorios, desgaste de equipos y comportamientos operativos adversos.
Redundancia, voting y diagnóstico pueden equilibrar seguridad y disponibilidad, pero cada elección crea nuevas dependencias y requisitos de prueba. La arquitectura debe basarse en riesgo, datos de confiabilidad, condiciones de proceso y filosofía operativa.
Proof test y pruebas periódicas
Los fallos peligrosos ocultos deben revelarse mediante pruebas. El proof test está diseñado para detectar fallos que el diagnóstico automático no identifica. El intervalo entre pruebas influye directamente en la probabilidad de falla bajo demanda en muchas arquitecturas.
Un plan de proof test debe especificar:
- función y componentes probados;
- condición inicial;
- secuencia de prueba;
- cobertura esperada;
- criterios de aceptación;
- instrumentos necesarios;
- restauración tras la prueba;
- registros y evidencias;
- tratamiento de fallos encontrados.
Probar únicamente si “el PLC recibió la señal” puede dejar sin verificar fallos de transmisor, válvula, solenoide, línea de impulso, actuador o lógica de interfaz.
Partial stroke test
Para válvulas críticas, el partial stroke test puede revelar parte de los modos de falla sin ejecutar un cierre completo. No sustituye automáticamente el proof test integral. El crédito de reducción de PFD depende de la cobertura real, frecuencia, arquitectura y datos utilizados en la verificación.
La política de pruebas debe evitar convertir una herramienta de diagnóstico en “crédito matemático” no respaldado por evidencia operativa.
Bypass, override y mantenimiento
Los sistemas reales necesitan mantenimiento, calibración y pruebas. Por tanto, los bypasses pueden ser necesarios. El riesgo aparece cuando un bypass deja de ser una condición temporal controlada y se convierte en un estado operativo normalizado.
La gobernanza debe establecer autorización, justificación, tiempo máximo, compensaciones, alarmas, registro, revisión de riesgo y retirada del bypass. La sala de control debe conocer claramente qué funciones están degradadas.
Filosofía de alarmas del SIS
Las alarmas de diagnóstico, falla, bypass, pérdida de alimentación, inconsistencia de voting y otras condiciones del SIS deben racionalizarse. El objetivo no es simplemente enviar todos los bits de diagnóstico al operador.
Cada alarma debe tener significado operativo, prioridad compatible, respuesta definida y documentación. Las alarmas críticas perdidas en una avalancha de mensajes comprometen la capacidad de intervención.
Interfaces con SCADA, HMI e historiador
La supervisión del SIS puede proporcionar estado de SIF, trips, bypasses, fallos y diagnósticos, pero la integración debe preservar la independencia y la seguridad de la función. La vía utilizada para visualizar información no debe crear un medio no controlado de modificar lógica o setpoints.
Los históricos de eventos, registros de secuencia de eventos y sincronización de tiempo ayudan a investigar trips e incidentes. La calidad temporal es particularmente relevante para distinguir la causa inicial de los efectos posteriores.
Ciberseguridad aplicada al SIS
Los sistemas instrumentados modernos utilizan tecnologías digitales, estaciones de ingeniería, redes e interfaces que pueden introducir riesgos cibernéticos. Seguridad Funcional y ciberseguridad no son disciplinas sustitutas: una amenaza puede convertirse en causa de falla de la función de seguridad y, por tanto, debe considerarse en el ciclo de vida.
Los controles relevantes incluyen segmentación, gestión de acceso, hardening, control de medios, backups validados, gestión de patches, monitoreo, protección de estaciones de ingeniería y gobernanza de cambios. La estrategia debe respetar disponibilidad y requisitos de seguridad del proceso.
Ingeniería de aplicación y software
El software de aplicación forma parte del desempeño sistemático de la función. Los fallos lógicos pueden surgir de requisitos ambiguos, implementación incorrecta, conversión de unidades, timers, secuencias, reset, estados degradados o tratamiento inadecuado de señales inválidas.
Las buenas prácticas incluyen trazabilidad de requisitos, estándares de programación, revisión, control de versiones, pruebas unitarias cuando corresponda, simulación, FAT, gestión de cambios y segregación entre ambientes de desarrollo y producción.
FAT de un SIS
El Factory Acceptance Test debe verificar el sistema antes de la instalación en campo, dentro de los límites del ambiente de fábrica. Un FAT maduro prueba lógica, I/O simulados, voting, fallos, diagnósticos, alarmas, reset, bypasses, tiempos, interfaces y escenarios definidos en la SRS.
El FAT no demuestra por sí solo que la SIF instalada funciona en el proceso real. Sensores, elementos finales, cableado, utilidades y condiciones de campo pueden no estar representados.
SAT y pruebas de campo
El Site Acceptance Test verifica la instalación y la integración en sitio. Según el alcance, debe confirmar identificación, cables, señales, alimentación, redes, lógica cargada, interfaces, actuación de elementos finales y condiciones de campo.
Es esencial mantener la distinción entre SAT y validación de Seguridad Funcional. Un SAT puede verificar elementos de instalación sin demostrar integralmente que cada SIF cumple todos los requisitos de la SRS.
Validación de Seguridad Funcional
FAT, SAT, validación y puesta en marcha necesitan criterios documentados y evidencias. El comisionamiento independiente reduce el riesgo de aceptar un sistema únicamente porque el hardware fue instalado y energizado.
La validación demuestra que las SIF instaladas y configuradas cumplen los requisitos especificados. Debe planificarse, ejecutarse mediante procedimientos aprobados y documentarse con resultados, desviaciones y evidencias.
La prueba debe partir de los requisitos: condición de demanda, sensores, lógica, voting, acción final, tiempo de respuesta, reset, diagnósticos, bypasses y comportamiento ante fallos. Una validación incompleta supone un riesgo documental y técnico, porque una función puede “disparar” y aun así no cumplir íntegramente su especificación.
Mechanical Completion y precomisionamiento
Antes de las pruebas funcionales completas, el sistema debe alcanzar condiciones de conclusión física y preparación. Inspecciones, loop checks, verificación de alimentación, continuidad, identificación, calibración y documentación reducen el riesgo de utilizar la validación para descubrir defectos básicos de montaje.
Separar las etapas evita que punch items de instalación se confundan con fallos de requisitos funcionales.
Comisionamiento y puesta en marcha
Durante el comisionamiento, algunas funciones pueden estar temporalmente bloqueadas u operar con premisas diferentes de las condiciones normales. La gestión de Seguridad Funcional debe controlar estas transiciones.
Los planes de puesta en marcha deben identificar protecciones disponibles, condiciones temporales, responsabilidades, pruebas previas, criterios para abortar y restauración de la configuración final. Los sistemas críticos no deben llegar a operación comercial con bypasses provisionales sin gestión formal.
SIS en proyectos brownfield
Las modernizaciones en plantas existentes son especialmente desafiantes porque documentación, lógica y condiciones de campo pueden divergir. Antes de modificar un SIS es necesario construir una base confiable del estado existente.
Los levantamientos pueden incluir As Built, listas de I/O, lógica cargada, firmware, redes, paneles, bypasses, historial de trips, proof tests, certificados, cálculos SIL y cambios acumulados. Una migración puede fallar incluso con una nueva plataforma técnicamente superior si se pierden requisitos anteriores o se ignoran interfaces no documentadas.
Migración de SIS
La migración exige una estrategia de cutover y rollback. El proyecto debe definir qué funciones quedarán indisponibles, qué protecciones compensatorias se utilizarán, cómo se congelarán versiones, quién autoriza cada etapa y qué criterios determinan el retorno a la configuración anterior.
La ventana de parada debe contemplar no solo instalación, sino también pruebas y validación. Finalizar la intervención apenas el nuevo hardware “enciende” es insuficiente.
Management of Change — MOC
Las modificaciones de setpoints, lógica, voting, instrumentos, tiempo de trip, bypasses permanentes, intervalos de prueba o elementos finales pueden cambiar el riesgo. Por ello, la gestión de cambios debe evaluar impacto antes de la implantación y actualizar la documentación después de la aprobación.
Un MOC eficaz conecta cambio, análisis de riesgos, SRS, proyecto, pruebas, formación, As Built y registros operativos. Los cambios de software sin trazabilidad son especialmente críticos porque pueden ser difíciles de detectar visualmente en campo.
Operación y mantenimiento del SIS
El SIS debe continuar cumpliendo el desempeño requerido durante toda su vida útil. Esto exige mantenimiento, pruebas, gestión de fallos, formación, control de bypasses, revisión de datos y actualización de documentación.
Los indicadores útiles pueden incluir funciones en bypass, proof tests vencidos, fallos detectados, trips espurios, demandas reales, tiempo de reparación, recurrencia de defectos y backlog de recomendaciones. El objetivo no es generar un dashboard ornamental, sino identificar degradación de barreras.
Demanda real sobre la SIF
Cada demanda real es una oportunidad para verificar desempeño y aprender. Debe evaluarse si la SIF actuó según lo especificado, cuál fue el evento iniciador, cómo respondieron las otras capas y si hubo retraso, fallo parcial o una consecuencia no prevista.
Esta información puede modificar frecuencias utilizadas en LOPA, premisas de confiabilidad y estrategia de mantenimiento.
Auditorías y Functional Safety Assessment
El ciclo de vida exige verificaciones y evaluaciones en momentos apropiados. Una auditoría de proceso verifica si procedimientos y gestión se siguen; las evaluaciones de Seguridad Funcional examinan si las actividades y evidencias sustentan la confianza necesaria para avanzar.
El grado de independencia del equipo evaluador depende de la fase, complejidad y requisitos aplicables. La organización debe definirlo en la planificación de Seguridad Funcional en lugar de improvisarlo únicamente antes de la puesta en marcha.
Procurement de SIS
Una contratación madura especifica requisitos funcionales y de ciclo de vida, no únicamente una lista de hardware. Las RFP y especificaciones deben definir responsabilidades sobre SRS, datos de confiabilidad, cálculos, software, FAT, documentación, formación, pruebas, certificados y soporte.
También deben establecer límites entre propietario, proyectista, integrador, fabricante y empresa de comisionamiento. Los gaps de responsabilidad son frecuentes cuando todos presuponen que “el proveedor del PLC” entregará la Seguridad Funcional completa.
Technical Bid Evaluation
La evaluación técnica de propuestas debe verificar adherencia a los requisitos y no limitarse a comparar marcas. Los puntos relevantes incluyen arquitectura, independencia, capacidad sistemática, datos utilizados, herramientas, versiones, licencias, filosofía de pruebas, documentación, experiencia del equipo y tratamiento de obsolescencia.
Las excepciones y desviaciones deben permanecer trazables. Una solución más barata puede transferir coste a ingeniería, operación o mantenimiento.
Ingeniería del Propietario en proyectos de SIS
Los proyectos SIS involucran proceso, instrumentación, automatización, eléctrica, operación, mantenimiento y proveedores. La Ingeniería del Propietario ayuda a preservar requisitos, interfaces y decisiones del propietario durante la implantación.
La Ingeniería del Propietario puede actuar como capa independiente entre los requisitos del activo y los proveedores. El papel incluye gobernar interfaces, revisar documentos, acompañar decisiones, controlar desviaciones, coordinar respuestas técnicas y preservar trazabilidad.
Esto es especialmente útil cuando proceso, instrumentación, automatización, eléctrica, TI/OT, operación, mantenimiento e integradores diferentes comparten responsabilidades sobre la misma función.
Design Review
Un Design Review de SIS debe verificar que el proyecto traduzca la SRS sin introducir dependencias u omisiones. La revisión puede examinar arquitectura, voting, segregación, I/O, alimentación, redes, lista de instrumentos, causa y efecto, software, bypasses, diagnóstico, pruebas y mantenimiento.
El objetivo no es rehacer el proyecto del proveedor, sino identificar incompatibilidades antes de que se materialicen en paneles, programación y campo.
Ingeniería Consultiva sin suministro del SIS
Una empresa de Ingeniería Consultiva puede generar valor sin suministrar controladores, programar Safety PLC ni emitir certificación de producto. El alcance puede abarcar diagnóstico, organización del ciclo de vida, facilitación de análisis, definición de requisitos, estandarización documental, Design Review, soporte a Procurement, seguimiento de FAT/SAT, gestión de interfaces y gobernanza de acciones.
Este modelo separa la función de representar técnicamente al propietario de la función de vender la plataforma de automatización. La independencia comercial puede mejorar la calidad de especificaciones y evaluaciones, siempre que el equipo posea competencia adecuada al alcance asumido.
Límites de responsabilidad y competencia
La Seguridad Funcional exige competencia demostrable por actividad. Facilitar un workshop, revisar gobernanza, verificar documentación, calcular PFDavg, desarrollar una aplicación o ejecutar validación son trabajos distintos.
El contrato debe dejar explícitos alcance, premisas, responsabilidades y exclusiones. Deben evitarse expresiones genéricas como “certificar SIL” cuando no correspondan a un proceso o acreditación claramente definidos.
Documentación mínima durante el ciclo de vida
La documentación exacta varía según el proyecto, pero un conjunto típico puede incluir:
- política y plan de Seguridad Funcional;
- estudios de riesgos y registros de recomendaciones;
- lista de SIF;
- SIL requerido y memoria de determinación;
- SRS;
- filosofía de SIS;
- arquitectura y diagramas;
- listas de I/O e instrumentos;
- matrices de causa y efecto;
- memoria de verificación SIL;
- especificaciones y datasheets;
- documentos de software;
- procedimientos e informes FAT/SAT;
- plan e informe de validación;
- procedimientos de proof test;
- registros de bypass y MOC;
- As Built y backups controlados.
La documentación no es burocracia paralela: es la evidencia que conecta riesgo, requisito, implantación y condición actual de la instalación.
Errores recurrentes en proyectos SIS
Entre los errores más críticos están comprar hardware antes de consolidar requisitos; llamar SIF a todo interlock; atribuir SIL al PLC; utilizar causa y efecto como única SRS; compartir recursos sin evaluar independencia; aceptar datos de confiabilidad sin premisas; considerar FAT como validación final; dejar el proof test para después de la puesta en marcha; y permitir cambios de lógica sin MOC.
Otro error es tratar el SIS como un proyecto exclusivo de automatización. Proceso, instrumentación, mecánica, eléctrica, operación y mantenimiento influyen directamente en el desempeño de las funciones.
Criterios para contratar apoyo independiente
El apoyo consultivo es especialmente útil cuando la organización posee múltiples proveedores, retrofit brownfield, requisitos dispersos, documentación inconsistente, gran volumen de SIF, cambios frecuentes, baja madurez de proof tests o necesidad de estructurar gobernanza corporativa.
También es recomendable antes de una contratación relevante, porque corregir ambigüedades en la especificación cuesta menos que corregir arquitectura, software y campo tras la fabricación.
Consideraciones finales
El Sistema Instrumentado de Seguridad debe entenderse como una capa de protección gobernada durante todo el ciclo de vida. Su desempeño depende de la coherencia entre análisis de riesgos, SRS, arquitectura, sensores, lógica, elementos finales, pruebas, operación, mantenimiento y gestión de cambios.
El error más común es reducir el sistema al equipo más visible. Un Safety PLC puede ser excelente y aun así estar inserto en una función especificada o mantenida de forma inadecuada. La ingeniería debe preservar la cadena causal completa: por qué existe la SIF, qué reducción de riesgo debe proporcionar, cómo fue implantada, cómo será verificada y cómo se sostendrá su integridad durante la operación.
Para el propietario, la gobernanza técnica independiente es especialmente valiosa cuando varias disciplinas y proveedores comparten responsabilidades. Permite convertir la Seguridad Funcional en requisitos verificables, decisiones trazables y criterios objetivos de contratación y aceptación.
Referencias técnicas
[1] INTERNATIONAL ELECTROTECHNICAL COMMISSION (IEC). IEC 61511-1:2016+AMD1:2017 CSV — Functional safety — Safety instrumented systems for the process industry sector — Part 1. Disponible en: https://webstore.iec.ch/en/publication/61289
[2] INTERNATIONAL SOCIETY OF AUTOMATION (ISA). ISA-84 Series of Standards — Functional Safety and Safety Instrumented Systems. Disponible en: https://www.isa.org/standards-and-publications/isa-standards/isa-84-standards
[3] INTERNATIONAL SOCIETY OF AUTOMATION (ISA). ISA84 — Instrumented Systems to Achieve Functional Safety in the Process Industries. Disponible en: https://www.isa.org/standards-and-publications/isa-standards/isa-standards-committees/isa84
[4] CENTER FOR CHEMICAL PROCESS SAFETY (CCPS). Layer of Protection Analysis — LOPA resources. Disponible en: https://www.aiche.org/ccps/resources/tools/lopa
Preguntas frecuentes
Es un sistema instrumentado destinado a ejecutar una o más Funciones Instrumentadas de Seguridad para llevar o mantener un proceso en estado seguro cuando se detectan condiciones peligrosas especificadas.
SIS es el sistema que implementa funciones de seguridad; SIF es una función específica de detección y acción segura; SIL es el nivel de integridad requerido o alcanzado por una SIF según los criterios aplicables.
No. El desempeño se evalúa para la SIF completa, incluidos sensores, logic solver, elementos finales, arquitectura, pruebas, fallos de causa común y requisitos sistemáticos.
No. Muchos interlocks tienen finalidad operativa o de protección de equipos. Una SIF debe estar vinculada a un requisito de reducción de riesgo definido por el proceso de Seguridad Funcional.
Safety Requirements Specification es la especificación que transforma los requisitos de riesgo en requisitos verificables para las SIF, incluidos acciones, estado seguro, SIL, tiempos, voting, interfaces, pruebas, bypasses y criterios de validación.
No necesariamente. FAT y SAT verifican partes importantes de la solución, pero la validación de Seguridad Funcional debe demostrar que las SIF instaladas cumplen los requisitos de la SRS.
Sí. Puede actuar en gobernanza del ciclo de vida, requisitos, Design Review, Procurement, Ingeniería del Propietario, seguimiento de FAT/SAT, documentación y gestión de interfaces, siempre que delimite claramente el alcance y disponga de competencia para las actividades asumidas.
El proof test se utiliza para revelar fallos peligrosos ocultos no detectados por el diagnóstico automático. La frecuencia, cobertura y procedimiento deben definirse según la SIF y su verificación.
Materiales técnicos complementarios
Soluciones relacionadas
- Sistemas Digitales de Supervisión y Control (SDSC): automatización y operación integrada
- Sistemas SCADA
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
- Ingeniería del Propietario
- Comisionamiento de Ingeniería: planificación, pruebas, preparación y handover
Contenidos principales sobre el tema
- SIL: qué es Safety Integrity Level, cómo definir y verificar el nivel de integridad de seguridad
- LOPA: qué es Layer of Protection Analysis, capas independientes y reducción de riesgo
Contenidos técnicos relacionados
- 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
- Automatización Industrial: qué es, arquitectura, sistemas y aplicaciones en Ingeniería
- Comisionamiento Industrial: precomisionamiento, puesta en marcha, pruebas en frío y en caliente
