Chapter 1Sp PDF

CAPÍTULO 1
SEGURIDAD
Sistema de Control Industrial TRUSTED
Manual Tecnico de
Seguridad
ÍNDICE DE MATERIAS
Párrafo Página
1. INTRODUCCIÓN ............................................................................................ 1
1.1 PROPÓSITO DE LA SEGURIDAD ............................................................ 1
1.2 DOCUMENTOS ASOCIADOS................................................................... 2
1.3 TERMINOLOGÍA........................................................................................ 2
1.3.1 Tolerancia a Falla y Falla Segura .................................................... 3
1.4 VISIÓN GLOBAL DEL TRUSTED ICS ...................................................... 4
2. PRINCIPIOS DE SEGURIDAD ....................................................................... 5
2.1 INTRODUCCIÓN ....................................................................................... 5
2.2 VISIÓN GLOBAL DE LA IEC61508 ........................................................... 5
2.3 ADMINISTRACIÓN DE SEGURIDAD........................................................ 6
2.3.1 Nivel de Integridad de Seguridad (SIL)............................................ 6
2.3.2 Ciclio de Vida de Seguridad............................................................. 8
2.3.3 Definición del alcance ...................................................................... 9
2.3.4 Requisitos funcionales ..................................................................... 9
2.3.5 Requisitos de seguridad ................................................................ 10
2.3.6 Ingeniería de Sistemas .................................................................. 11
2.4 PROGRAMACIÓN DE LA APLICACIÓN ................................................. 15
2.4.1 Separando la Aplicación ................................................................ 15
2.4.2 Medidas defensivas ....................................................................... 16
2.4.3 Bloques que se pueden probar...................................................... 16
2.4.4 Funciones individuales Relacionadas con Seguridad.................... 16
2.4.5 Minimice la Profundidad Lógica..................................................... 17
2.4.6 Interacción de comunicaciones ..................................................... 17
2.4.7 Definición de Los Casos de Prueba .............................................. 18
2.4.8 Comprobación del programa ......................................................... 18
2.5 PRODUCCIÓN DEL SISTEMA................................................................ 18
2.5.1 Integración del sistema.................................................................. 18
2.6 INSTALACIÓN Y COMISIONAMIENTO .................................................. 19
2.6.1 Validación del Sistema de seguridad............................................. 20
2.6.2 Plan de Operación y Mantenimiento.............................................. 20
2.6.3 Mantenimiento planificado ............................................................. 20
2.6.4 Mantenimiento de Dispositivos de campo ..................................... 21
2.6.5 Manejo de Falla de módulo............................................................ 21
2.6.6 Modificación del sistema................................................................ 21
2.6.7 Líneas de Base .............................................................................. 22
2.6.8 Archivos de la modificación ........................................................... 22
2.6.9 Modificación En Línea.................................................................... 22
2.6.10 Monitoreo ....................................................................................... 23
Doc No TM2244US Versión 2.0

Edición 1 Abril 99 Capítulo 1 Página i
Tabla of Contents
2.6.11 Retiro del equipo ............................................................................23
2.7 EVALUACIÓN DE SEGURIDAD FUNCIONAL ........................................24
2.7.1 Competencia ..................................................................................24
2.8 REQUISITOS DE LA DOCUMENTACIÓN...............................................25
3. RECOMENDACIONES DEL SISTEMA.........................................................26
3.1 INTRODUCCIÓN .....................................................................................26
3.2 ARQUITECTURAS DE E/S ......................................................................26
3.2.1 E/S de Alta Densidad .....................................................................26
3.2.2 E/S de Baja Densidad ....................................................................27
3.2.3 Configuraciones De Energizar para Activar ...................................30
3.2.4 Configuraciones de E/S Relacionadas con Seguridad ..................31
3.2.5 Lista de Verificación de la Arquitectura de E/S ..............................32
3.3 DESARROLLO DE PROGRAMA DE APLICACIÓN ................................33
3.3.1 Selección del idioma ......................................................................33
3.3.2 Desarrollo de la aplicación .............................................................34
3.4 REQUISITOS DEL MEDIO AMBIENTE ...................................................35
3.4.1 Condiciones climáticas...................................................................35
3.4.2 Compatibilidad Electro-magnética (EMC) ......................................36
3.4.3 Precauciones de Manejo electrostáticas........................................37
3.5 REQUISITOS DE PODER DE SISTEMA.................................................38
ILUSTRACIONES
Figura 1 Contactos de Campo del Sistema 1-oo-2 en Condición Saludable 28
TABLAS
Tabla 1 1-oo-2 (2v2) .............................................................................................3
Tabla 2 2-oo-2 (1v2) ............................................................................................3
Tabla 3 Mediciones de Falla de Objetivo - Modo de Operación de Demanda .....7
Tabla 4 Mediciones de Falla de Objetivo -
Modo de Operación de Alta Demanda / Contínuo..............................7
Tabla 5 DIN V VDE 0801 Nivel AK y Equivalente IEC 61508 SIL ........................7
Tabla 6 Configuraciones de Entrada ..................................................................31
Tabla 7 Configuraciones de Salida.....................................................................32
Tabla 8 Lenguaje de programación Relacionado con Seguridad.......................33
Tabla 9 Requisitos de Condición Climática ........................................................35
Tabla 10 Compatibilidad Electromagnética .......................................................36
Doc No TM2244US Versió 2.0

Capítulo 1 Página ii Edición 1 Abril 99
Sistema de Control Industrial TRUSTED
Manual Técnico
CAPÍTULO 1 SEGURIDAD
1. INTRODUCCIÓN
1.1 PROPÓSITO DE SEGURIDAD

El Sistema TRUSTED de Control Industrial (TRUSTED ICS) se ha diseñado y se ha
certificado para el uso en aplicaciones relacionadas con seguridad. Se seguirán las
restricciones y condiciones establecidas en el informe final del Certificado de TÜV.
Para asegurar que los sistemas se construyen en estas fundaciones, es necesario
imponer requisitos en la manera en que se diseñan tales sistemas, como se
construyen, prueban, instalan y comisionan, como se operan, se mantienen y se sacan
de fuera de servicio. Este Capítulo establece los requisitos a ser reunidos durante las
fases del ciclo de vida (“lifecycle”) de los sistemas relacionados con seguridad para
asegurarse que se logran los objetivos de seguridad del sistema de seguridad.
La intención de la información contenida en este Capítulo es que sea para ser usada
por ingenieros e integradores del sistema y no se tiene la intención de que sea un
sustituto para la especialización o experiencia en los sistemas relacionados con la
seguridad. Se incluyen dentro de este documento los requisitos para los sistemas de
calidad, la documentación y competencia; éstos son requisitos (NO son reemplazos)
para los sistemas de calidad, procedimientos y prácticas de una compañía de
operación individual o integrador. La compañía de operación individual o el integrador
sigue siendo responsable de la generación de procedimientos y prácticas aplicables a
su negocio, y es responsable de asegurar que éstos están de acuerdo con los
requisitos definidos aquí dentro. La aplicación de tales procedimientos y prácticas
también es responsabilidad de la compañía individual de operación o del integrador.
Sin embargo, esto debe ser considerado obligatorio para los sistemas para IEC 61508
SIL3 o aplicaciones de DIN V VDE 0801 AK5/6.
El contenido de este Capítulo ha sido revisado por TÜV y representa los requisitos que
deben cumplirse para lograr sistemas relacionados con seguridad que sean
certificables a éstos los niveles de integridad.
Este Capítulo está dirigido principalmente a los integradores del sistema. Se asume
que el lector tiene una comprensión completa de la intención de la aplicación y puede
traducir prontamente entre los términos genéricos usados dentro de este Capítulo y la
terminología específica al área de la aplicación del integrador o proyecto.

Edición 1 Abril 99 Capítulo 1 Página 1 de 38
Seguridad
1.2 DOCUMENTOS ASOCIADOS

Los documentos siguientes están asociados con los requisitos de seguridad aplicables
al TRUSTED ICS.
Título del Documento Requisito

IEC 61508: ‘Seguridad Una comprensión de seguridad básica y principios
Funcional de Sistemas funcionales de seguridad y el contenido de estas
Electrónicos Programables' normas se recomienda altamente. Deben entenderse
los principios de estas normas completamente antes
IEC 61511: ‘Seguridad
de generar procedimientos y prácticas para cumplir
Funcional: Sistemas
los requisitos de este Capítulo de Seguridad.
Instrumentados de
Seguridad para el sector de
industria de proceso '
DIN V VDE 0801:
`Principios aplicables a las
Computadoras en los
Sistemas Relacionados con
la Seguridad’
YTMR793010: Guía de Donde la aplicación en referencia haga uso de los
Usuario de Regent+Plus módulos de E/S (“I/O”) de baja densidad, también se
(YTMR793010) recomienda que el lector esté familiarizado con el
producto Regent+Plus.
1.3 TERMINOLOGÍA
Los términos `Certificación' y `Certificado' se usan ampliamente dentro de este
Capítulo. Dentro del contexto de este Capítulo, estos términos se refieren a la
certificación funcional de seguridad del producto de acuerdo con IEC 61508 SIL3 y DIN
V VDE 0801. El TRUSTED ICS como un producto, se certifica a un rango más amplio
de normas que están fuera del alcance de este Capítulo.
Este Capítulo contiene reglas y recomendaciones:
Deben seguirse las reglas si el sistema resultante debe ser certificado. Éstas se
identifican por términos obligatorios como `Debe Ser' y `No está permitido '.
Las recomendaciones no son obligatorias, pero si ellos no se siguen, deben tomarse
precauciones de seguridad extras para certificar el sistema. Las recomendaciones son
identificadas por los términos como `Se recomienda fuertemente'.

Capítulo 1 Página 2 de 38 Edición 1 Abril 99
Seguridad
1.3.1 Tolerancia de Falla y Falla Segura

Las definiciones de tolerancia a falla / falla segura difieren. Para propósitos de este
documento las Tablas de verdad siguientes se utilizan:
A B Salida
0 0 0
0 1 0
1 0 0
1 1 1
Tabla 1-oo-2 (2v2)
A B Salida
0 0 0
0 1 1
1 0 1
1 1 1
Tabla 2 2-oo-2 (1v2)
Doc Número TM2244US Versión 2.0

Seguridad
1.4 VISIÓN GLOBAL DEL TRUSTED ICS

El Sistema TRUSTED ICS está basado en un microprocesador triplicado con
redundancia interior de todos los circuitos críticos. El diseño del TRUSTED ICS ofrece
las siguientes características:
• Procesamiento para los productos del grupo ICS (DCS, SCADA, la
Seguridad)
• Estación de trabajo de la ingeniería multi-lingue
• Montaje en bastidor batible (“swingframe”) / chasis sencillo / montaje en
panel
• Sistema operativo Kernel aprobado por TÜV (IEC 61508 SIL3)
• Diseño patentado de reloj con Tolerancia a Falla Implementada por
Hardware (HIFT)
• Diagnósticos remotos.
El TRUSTED ICS controla procesos complejos y a menudo críticos en tiempo real -
ejecutando programas que aceptan señales de sensores externos, mientras está
resolviendo ecuaciones lógicas, realizando cálculos para el control de proceso
contínuo y está generando señales de control para uso externo. Estos programas de
aplicación definidos por el usuario monitorean y controlan procesos de mundo real en
industrias de Petróleo y Gas, refinación, tránsito ferroviario, generación de potencia e
industrias relacionadas a través de una gama amplia de aplicaciones de seguridad y
control. El TRUSTED ICS está certificado para el uso en las aplicaciones relacionadas
con seguridad como detección de fuego y gas, y parada de emergencia.
Los programas de aplicación para el TRUSTED ICS son escritos y monitoreados
usando el IEC1131 TOOLSET, un software basado en Microsoft® Windows NT™ que
corre en una computadora personal.
La arquitectura del TRUSTED ICS proporciona una flexibilidad que permite adaptar
cada sistema fácilmente a las necesidades diversas de cualquier instalación. Esta
flexibilidad le permite al usuario escoger de los niveles diferentes de protección de falla
de E/S y proporciona una variedad amplia de interfase de E/S y métodos de
comunicaciones, permitiéndole al TRUSTED ICS comunicarse con otros equipos y
dispositivos de campo.
Los elementos del TRUSTED ICS que serán usados en operaciones relacionadas con
seguridad están certificados según DIN-V-VDE-0801, AK6. Los elementos restantes
del sistema son certificados para operación “sin-interferencia”.

Seguridad
2. PRINCIPIOS DE SEGURIDAD
2.1 INTRODUCCIÓN
Este párrafo proporciona una visión global de los principios de seguridad genéricos;
estos principios son aplicables a todos los sistemas relacionados con la seguridad. Los
párrafos inlcuídos dentro de este Capítulo proporcionan guía extensa dónde las
características del TRUSTED ICS requieren expansión, o una aplicación más
específica de estos principios de seguridad.
Seguridad y la Seguridad Funcional
Seguridad: Es la expectativa que un sistema no ocasionará riesgo a la vida humana o
la salud.
La seguridad es tradicionalmente asociada con las características o riesgos que son el
resultado del propio sistema; incluyendo los riesgos de incendio, seguridad eléctrica,
etc. Los requisitos a ser satisfechos aquí por el integrador incluyen instalación
eléctrica, las cubiertas protectoras, selección de materiales, etc.,
Seguridad Funcional: Es la habilidad de un sistema de llevar a cabo las acciones
necesarias para lograr o mantener un estado seguro para el proceso y su equipo
asociado.
La seguridad funcional es considerada la habilidad del sistema de realizar su función
de seguridad requerida. Los requisitos del integrador en este caso son tomar los pasos
necesario para asegurar que ese sistema esté libre de fallas, errores, y que
correctamente implemente las funciones de seguridad requeridas.
Este párrafo se concentra en la seguridad funcional; se supone que el lector está
familiarizado con los métodos de lograr la seguridad básica. La norma primaria para la
seguridad funcional es la IEC 61508; este párrafo incluye una apreciación global breve
de esta norma. Refiérase a la norma pertinente para más detalle.
2.2 VISIÓN GLOBAL DE LA IEC 61508

IEC 61508 es una norma internacional que cubre la seguridad funcional, mientras
abarcando sistemas electrónicos eléctricos, electrónicos y programables, hardware y
aspectos del software. Se resumen los principios básicos siguientes de esta norma
dentro de este documento:
• Administración de seguridad
• Definición de Niveles de Integridad de Seguridad (SIL)
• Ciclo de Vida Global de la Seguridad
• Evaluación de seguridad funcional
• Competencia
• Documentación
Normas específicas a la Aplicación están en proceso de ser derivadas de esta norma;
La IEC 61511 es una derivación para la industria del proceso de la IEC 61508 y debe
ser considerada para los sistemas de este sector.

Seguridad
2.3 ADMINISTRACIÓN DE SEGURIDAD

Un requisito previo para el logro de seguridad funcional es la aplicación de medidas de
procedimineto aplicables al ciclo de vida de la seguridad; éstas son llamadas
colectivamente ‘Sistema de Administración de Seguridad’. El sistema de
Administración de Seguridad define la administración genérica y las actividades
técnicas necesarias para lograr la seguridad funcional. En muchos casos, se definirán
la administración de seguridad y los sistemas de calidad como un solo juego de
procedimientos. Es muy recomendable que el integrador tenga un sistema de
administración o gerencia de calidad de acuerdo con ISO9000.
El sistema de administración de seguridad debe incluir:
• Una declaración de la política y estrategia adoptada para lograr la seguridad
funcional.
• Un Procedimiento de Planificación de Seguridad. Esto producirá la definición
de las etapas del ciclo de vida de seguridad a ser aplicado, las medidas y
técnicas a ser aplicadas dentro de cada fase y la responsabilidad por
completar estas actividades.
• Las definiciones de los archivos a ser producidos y los métodos de manejar
estos archivos, incluyendo el control del cambio. Los procedimientos de
control del cambio deben incluir los archivos de solicitud de modificación, el
análisis de impacto de las modificaciones propuestas y la aprobación de
modificaciones. La línea de base para el control del cambio debe definirse
claramente.
• Deben identificarse los artículos de la configuración singularmente y deben
incluír la información de la versión, como por ejemplo: requerimientos del
sistema y de seguridad, documentación y planos de diseño del sistema,
código fuente del software de aplicación, planes de prueba, procedimientos
de prueba y resultados.
• Los métodos para asegurar que las personas son competentes para
emprender sus actividades y cunplir con sus responsabilidades.
2.3.1 Niveles de Integridad de Seguridad (SIL)

Un Nivel de Integridad de Seguridad (SIL) es uno de cuatro posibles niveles discretos
para especificar los requisitos de integridad de seguridad de las funciones de
seguridad ser asignadas al sistema relacionado con la seguridad. SIL 4 tiene el nivel
más alto de integridad de seguridad; SIL 1 tiene el más bajo.
IEC 61508/IEC 61511 definen dos modos de funcionamiento:
Modo de Demanda. La mayoría de sistemas relacionados con la seguridad dentro del sector del
proceso opera en el modo de demanda, en dónde la función relacionada con la seguridad es la función de
una protección necesaria para prevenir que una condición peligrosa se presente y/o mitigando las
consecuencias. La falla de una función de modo de demanda o sistema sólo llevaría a una condición
peligrosa si una demanda ocurre durante el periodo del falla.
Modo de Demanda Alta / Continuo. Una función de modo de demanda contínua es uno que se exige
operar continuamente para mantener la planta dentro de los límites de operación seguros. La falla de una
función de modo de demanda contínua o sistema llevaría directamente a una condición peligrosa.
Las mediciones de falla de objetivo para los dos modos de operación según IEC
61508/IEC 61511 se muestran en la Tabla 3 y la Tabla 4.

Seguridad
SIL Modo de Demanda de Operación

(probabilidad promedio de falla para realizar
su función de diseño ante una demanda)
4 ≥ 10-5 to < 10-4
3 ≥ 10-4 to < 10-3
2 ≥ 10-3 to < 10-2
1 ≥ 10-2 to < 10-1
Tabla 3 Medición de Falla de Objetivo – Modo de Demanda de Operación
SIL Modo de Operación de Demanda Alta /

Contínua (frecuencia de falla peligrosa por
hora)
4 ≥ 10-9 to < 10-8
3 ≥ 10-8 to < 10-7
2 ≥ 10-7 to < 10-6
1 ≥ 10-6 to < 10-5
Tabla 4 Medidas de Falla Objetivo (“Target”) – Modo de Operación de Demanda Alta / Contínua
Nota: Las probabilidades especificadas aquí (de IEC 61508) incluyen todas las fuentes
potenciales de falla y no deben usarse para comparar métodos anteriores de cálculo
de confiabilidad del sistema y disponibilidad. Estos métodos anteriores consideraban a
menudo fallas relacionadas con el hardware, con alguna provisión para causas de falla
común y cobertura de la prueba, y produce figuras que son frecuentemente más
optimistas que están adoptadas actualmente.
La Norma alemana DIN VDE 0801 frecuentemente se usa para especificar el nivel de
integridad de seguridad requerido. DIN VDE 0801 especifica ocho posibles niveles conocido
como los niveles de AK. Se muestran los niveles de AK equivalentes y niveles de IEC 61508 en
la Tabla 5.
Nivel AK DIN V VDE 0801 SIL IEC 61508
1 Ningún equivalente
2
SIL 1
3
4 SIL 2
5
SIL 3
6
7 SIL 4
8 Ningún equivalente
Tabla 5 Nivel de AK DIN V VDE 0801 y el Equivalente SIL IEC 61508

Seguridad
2.3.2 Ciclo de Vida de la Seguridad

El Ciclo de Vida de la Seguridad se diseña para estructurar la producción de un
sistema en fases y actividades bien definidas. Los elementos siguientes deben
definirse dentro del ciclo de vida de la seguridad:
• Definición del alcance
• Especificación de Requisitos funcionales
• Especificación de Requisitos del sistema seguridad
• Ingeniería del sistema
• Programación de la aplicación
• Producción del sistema
• Iintegración del sistema
• Validación del sistema de seguridad
• Instalación y comisionamiento del sistema
• Procedimientos para la operación y mantenimiento del Sistema
• Modificación del sistema
• Sacando el Sistema fuera de Servicio
La definición de cada fase del ciclo de vida debe incluir sus entradas, salidas y
actividades de verificación.

Seguridad
2.3.3 Definición del alcance

Es importante que el paso inicial en el ciclo de vida del sistema establezca los límites
del sistema relacionado con la seguridad relacionaron y una definición clara de sus
interfazes con el Equipo Bajo Control (EUC) y todo el equipo de terceros. Esta fase
también debe establecer los requisitos que resulten del ambiente requerido de la
instalación, incluyendo las condiciones climáticas, fuentes de poder, etc. Esta fase
normalmente se realizará antes que una orden sea colocada, es decir en la etapa de
cotización.
En la mayoría de los casos, esta información es proporcionada por el cliente. Es
necesario repasar esta información y establecer una comprensión completa de la
intención de la aplicación, los límites del sistema a ser proporcionado y sus
condiciones que deseadas de operación. Se deben hacer las siguientes preguntas:
• Se ha proporcionado una descripción en resúmen de la intención de la
aplicación?
• Se ha definido el ambiente de la instalación?, y en ese caso:
- Incluye esto condiciones normal y posibles condiciones
anormales?
- Incluye esto los requisitos de distribución geográfica?
• Se ha proporcionado una lista de todas las interfazes de equipo de terceros y
se han establecido las definiciones del protocolo y los datos a ser
intercambiados?
• Se han definido todas las interfazes de la planta, incluyendo la calidad de las
señales y sus características?
• Se ha provistto de una descripción resúmen de la convención de
Nomenclatura donde se haga referecia de `Tag’ para facilitar la comprensión
de la función o rol de la señal?
• Se ha resaltado alguna condición especial o anormal que exceda las
capacidades normales del equipo para permitir llevar a cabo una medida
especial?
• La información presentada es adecuada apoyar el nivel necesario de
compresión de la planta / EUC (Equipo bajo Control) y su ambiente?
2.3.4 Requisitos funcionales

Esta fase es para establecer el juego completo de funciones a ser llevadas a cabo por
el sistema. Los requisitos de tiempo para cada una de las funciones también serán
esablecidos. Donde sea posible, las funciones deben asignarse a los modos definidos
de funcionamiento del EUC (Equipo bajo Control).
Para cada función, es necesario identificar las interfazes de proceso involucradas en
cada una de las funciones. Similarmente, dónde la función involucre datos
intercambiados con equipos de terceros, los datos e interfazes deben ser identificadas
claramente. Donde se requieran dispositivos del campo que no sean estándares,
interfazes de comunicaciones o protocolos de comunicaciones, es importante que los
requisitos detallados para estas interfazes se establezcan y se registren en esta fase.

Seguridad
En general, los requisitos funcionales serán proporcionados por el cliente. Es, sin
embargo, necesario intercalar estos requisitos en un documento, o juego de
documentos, incluyendo cualquier clarificación de los requisitos funcionales. En los
casos dónde los requisitos funcionales se proporcionan por el cliente en una forma
ambigua será necesario clarificar, documentar y establecer acuerdos en los requisitos
con el cliente. Se recomienda que los diagramas lógicos se usen para representar la
funcionalidad requerida. Las preguntas siguientes deben hacerse:
• Está completa la definición de cada una de las funciones requeridas?
• Están claramente identificadas las interfazes, señales, y datos asociados con
cada función?
• Se han definido los requisitos de operación para cada función, o funciones
colectivas?
• Se han definido claramente los modos de operación del EUC (equipo bajo
control), proceso o planta?
• Se han indentificado las funciones que se requiren para operar en cada
modo de operación de planta?
• Se han definido las transiciones entre cada modo de operación de planta? Se
han establecido las funciones necesarias para poder efectuar estas
transiciones?
2.3.5 Requisitos de Seguridad

Los requisitos funcionales deben analizarse para determinar su relevancia de
seguridad. Donde sea necesario, se deben establecerse requisitos adicionales para
asegurar que la planta fallara en modo de ‘falla segura’ en caso de fallas dentro de la
planta, el sistema realcionado con la seguridad, equipo externo y de comunicaciones o
del ambiente del sistema relacionado con la seguridad.
Para cada función relacionada con la seguridad deben definirse los SIL requeridos y
los requisitos de tiempo relacionados con la seguridad. Esta información debe ser
proporcionada por el cliente. Donde esta información no se proporcione, debe ser
entonces establecerse y se debe estar de acuerdo con el cliente como parte de esta
fase. Es muy recomendable que los requisitos de seguridad resultantes se aprueben
por el cliente.
• Se ha asignado un SIL requerido a todos los requisitos funcionales?
• Se ha definido el tiempo relacionado con la seguridad para cada función
relacionada con la seguridad, incluyendo el tiempo de seguridad del proceso
y el período de tolerancia de falla?
• Han sido aceptados los requisitos de seguridad?
• Hay una definición clara de las interfazes externas involucrada en cada una
de las funciones relacionadas con la seguridad (éstas pueden estar ya
definidas en los requisitos funcionales)?
• Hay información suficiente ahora para entender claramente cómo la planta
debe controlarse en forma segura en cada uno de sus modos de operación
desados?

Seguridad
2.3.6 Ingeniería de Sistemas

Esta fase comprende el diseño del sistema relacionado de seguridad. Se recomienda
que la ingeniería comprenda dos fases, la primera fase definiendo la arquitectura del
sistema global, y la segunda fase detallando la ingeniería de los bloques de la
arquitectura.
La arquitectura del sistema global definirá los sistemas individuales. La arquitectura
para estos sistemas y para sus sub-sistemas cualquier elemento diverso o de otra
tecnología.
La definición arquitectónica también definirá el SIL requerido para cada elemento de la
arquitectura e identificará las funciones de seguridad asignadas a ese elemento.
Funciones adicionales de seguridad que resulten de la arquitectura del sistema
seleccionada se definirán en esta fase. La ingeniería de detalle refinará los elementos
de la arquitectura y culminará en la información detallada para la construcción del
sistema. El diseño detallado estará en una forma que sea leíble, que se pueda
entender prontamente y permitirá la inspección / revisión simple.
Herramientas usadas dentro del proceso de ingeniería del sistema deben ser
seleccionadas cuidadosamente, con la consideración debida del potencial de
introducción de errores y el SIL requerido. Donde permanezca aún la posibilidad de
error, los métodos procesales para descubrir tales errores deben ser incluidos dentro
del proceso.
2.3.6.1 Asignaciones de Requisitos de seguridad

La arquitectura del sistema global definirá el sistema individual. La arquitectura para estos
sistemas, y para sus sub-sistemas, incluirá cualquier elemento diverso o de otra
tecnología. La definición de la arquitectura también definirá el SIL requerido para cada
elemento de la arquitectura e identificará las funciones de seguridad asignadas a ese
elemento. Funciones adicionales de seguridad resultantes de la arquitectura del sistema
seleccionada se definirán en esta fase.
La ingeniería de detalle refinará los elementos arquitectónicos y culminará en la
información detallada para la construcción del sistema. El diseño detallado estará en una
forma que sea leíble, prontamente entendible y que permita la inspección / revisión simple.
Herramientas usadas dentro del proceso de ingeniería del sistema deben ser
seleccionadas cuidadosamente, con la consideración debida del potencial para la
posibilidad de introducción de errores y el SIL requerido. Donde exista aún la posibilidad
de error, los métodos procesales para descubrir tales errores deben ser incluídos dentro
del proceso.
2.3.6.2 Tiempo de Seguridad del Proceso (PST)

Cada proceso tiene un tiempo de seguridad que es el período en que el proceso puede
controlarse por una señal de salida de control defectuosa sin entrar en una condición
peligrosa. Ésta es una función de la dinámica del proceso y del nivel de seguridad
construído en la planta de proceso. El Tiempo de Seguridad del Proceso (PST) puede ir de
segundos a horas, dependiendo del proceso. En casos dónde el proceso tiene una
proporción de demanda alta y/o el proceso es muy dinámico el PST será corto, como por
ejemplo, en las aplicaciones de control de turbinas pueden dictar tiempos de seguridad de
proceso alrededor de 10ms. Para los procesos más lentos, el tiempo de seguridad del
proceso puede ser muchos segundos.

Seguridad
El PST dicta el tiempo de respuesta por la combinación del sensor, actuadores y cada
función de control o de seguridad comprendida. Para elementos del sistema
dependientes de la demanda o del evento, el tiempo de respuesta del sistema será
considerablemente menor que:
(PST – Retraso del Sensor y del actuador)
Para los elementos cíclicos del sistema, es decir basedos en Regent+Plus, el tiempo
de barrido del sistema será considerablemente menor que:
½ (PST - Retraso del Sensor y del actuador)
Donde la función de seguridad es implementada a través de un número de varios

sistemas enlazados, como por ejemplo comunicaciones de Puerto, los retrasos de
comunicaciones y la respuesta de cada sistema o el tiempo de barrido deben
agregarse al retraso sensor y del actuador.
El momento de entrada de la contestación el contexto del tiempo de seguridad de
proceso debe considerar la habilidad del sistema de responder, es decir su
probabilidad de falla ante demanda (incluyendo su abilidad para cumplir con la función
requerida dentro del tiempo requerido). La probabilidad de falla ante demanda is una
función de la arquitectura del sistema, su intervalo de auto-prueba y su factor β 1. Si la
arquitectura del sistema no proporcionara la tolerancia a falla, sería necesario asegurar
que la suma de los tiempos de respuesta (incluyendo los sensores y actuadores) y que
el tiempo de detección de falla no exceda el tiempo de seguridad de proceso.
En la práctica, muchos de los intervalos de auto-prueba de un sistema varían de
segundos a horas, dependiendo del elemento del sistema bajo prueba. IEC61508
permite a este acercamiento ser tomado para el requerimiento más bajo, SIL1.
Para los requerimientos más altos, es por consiguiente necesario asegurar que la
arquitectura del sistema proporcione la tolerancia de falla adecuada o que las Fallas
producen las acciones de Falla-seguras, es decir que no deben haber modos de falla
potencial ‘cubierta’ para aquellos elementos del sistema relacionados con la seguridad.
Puede haber un número de sistemas implentando los funciones de seguridad
requeridas2, como por ejemplo: el sistema de parada de emergencia, sistema de
parada de proceso y sistema de control del proceso. Donde los sistemas múltiples
proporcionan aplicación redundante de la función requerida, se puede asumir crédito
de que cada sistema es capaz de funcionar dentro del tiempo de seguridad de
proceso.
La única fuente de información sobre el PST es el Ingeniero de Diseño de Prevención
de Pérdis. Estos datos normalmente no se proporcionan en la oferta o en la fase ide
construcción, así que se debería hacer una solicitud directa para obtener la
información. Estos datos deben formar parte de las consideraciones de seguridad para
el sistema y las revisiones del diseño deben ser una parte fundamental de la ingeniería
de seguridad.
1El factor β es dependiente de los requerimientos de diseño original, los cuales son evaluados y certificados
independientemente, y la implementación de las guías provistas en esta Capítulo de Seguridad.
2 Las funciones pueden diferir pero alcanzar el mismo efecto general, como por ejemplo: el sistema de control del
proceso mantendrá el proceso dentro de sus límites seguros bajo condiciones normales y el sistema de parada de
emergencia llevará a la planta a su estado seguro en caso de que ocurran condiciones anormales.

Seguridad
2.3.6.3 Forzamiento de entradas y salidas

El Bloqueo y forzamiento de entradas y salidas individuales del paquete “IEC1131
Workbench” son soportados para propósitos de diseño, instalación y comisionamiento.
El uso de los “puentes” (‘overrides’) de mantenimiento en servicio para las entradas y
salidas relacionadas con la seguridad debe llevarse a cabo usando el programa de la
aplicación, vea el para. 2.3.6.4. El Bloqueo y forzamiento a través del IEC1131
Workbench requieren lo siguiente:
§ El interruptor de llave del Procesador TMR debe estar en la posición de ingeniería

para hacer los cambios de bloqueo o forzamiento de cualquier punto
§ Acceso a los comandos de bloqueo y de esritura del Workbench los cuales están
protegidos por contraseña (“password”).
§ Una lista de los puntos actualmente bloqueados se lee de vuelta del sistema de
TRUSTED ICS y es hecha disponible dentro del IEC1131 Workbench.
El LED de inhibir del Procesador TMR se iluminará cuando se bloquean uno o más puntos
de E/S. El programa de la aplicación puede determinar cuántos puntos están bloqueados
actualmente usando la información disponible del Procesador de TMR el equipo complejo;
se recomienda que esto se use para controlar el despliegue de estado adicional y/o por
registrar los propósitos.
Todos bloqueos (y forzamientos) de entradas y salidas pueden quitarse usando bien sea
una sola función del IEC1131 Workbench o por medio de salida activada por un borde
(“edge triggered”) al Procesador TMR del equipo complejo dentro del programa de la
aplicación. Si bloqueo del IEC1131 TOOLSET se usa, uno o ambos de éstos métodos de
forzamiento se implementarán.
Es importante que los efectos de forzar los puntos de entrada y salida en el proceso y el
impacto a la seguridad sea entendido por cualquier persona que use estos métodos. El
sistema permitirá mantener las condiciones forzadas durante el funcionamiento normal.
Cuando retorne al funcionamiento normal se recomienda que todos los puntos bloqueados
y forzados se devuelvan al funcionamiento normal. Es responsabilidad de los operadores
de planta el asegurar que si las condiciones forzadas están presentes, éstas no arriesgan
la seguridad funcional.
2.3.6.4 “Puentes” (‘overrides’) para Mantenimiento

Los “Puentes” (‘overrides’) para Mantenimiento hacen que las entradas o salidas se
coloquen en un estado definido que puede ser diferente al estado real durante el
funcionamiento de seguridad. Se usa durante el mantenimiento, normalmente para
“puentear” (‘overrides’) las condiciones de entrada o salida para realizar una prueba
periódica, calibración, o reparación de un módulo, sensor o actuador.
Para llevar a cabo un esquema de “puenteo” (‘overrides’) de mantenimiento dentro del
Controlador TRUSTED ICS es muy recomendado que el “puente”, o `Bypass lógico’ se
programe a través de un Programa de la Aplicación, con un juego separado de puntos de
entrada o variables relacionadas con seguridad designadas para habilitar la lógica de
desviación (‘Bypass’).
Para acomodar los “puentes” (‘overrides’) para mantenimiento en forma segura, TÜV ha
documentado un juego de principios que deben seguirse. Estos principios se publican en el
documento “Puentes papa Mantenimiento“ (‘Maintenance Overrides’) por TÜV Baviera y
TÜV Rheinland.

Seguridad
Hay ahora dos métodos básicos usados para verificar periféricos relacionados con la
seguridad conectados al TRUSTED ICS:
1. Interruptores especiales conectados a las entradas del sistema convencionales.
Estas entradas se usan para dejar fuera de funcionamiento sensores y
actuadores durante el mantenimiento. La condición de mantenimiento se maneja
como parte del programa de aplicación del sistema.
2. Los sensores y actuadores se apagan eléctricamente durante el mantenimiento
y se verifican a mano.
En algunas instalaciones, la consola de mantenimiento puede integrarse con el
despliegue del operador, o el mantenimiento puede cubrirse por otras estrategias. En
las tales instalaciones, las guías incluídas en el párrafo 2.4.6 deberán ser seguidas.
2.3.6.5 Lista de Verificación de Requisitos de “Puenteo”

La siguiente es una lista de verificación recomendada de los requisitos de “puenteo”:
• ¿Los efectos de “puentear” (‘override’) están totalmente entendidos,
particularmente dónde la acción de “puenteo” acción afectará partes
independientes de una aplicación?
• Se ha proporcionado un método de habilitar el “puente” (‘override’) en
conjunto para el sistema o sub-sistemas?
• Se han definido medidas de Programación o de Procedimiento para
asegurarse que no se puede aplicar mas de un “puente” (‘override’) a una
unidad del proceso dada relacionada con la seguridad?
• Se ahn definido métodos adecuados de desplegar la presencia de la
condición del “puente” (‘override”) y el registro de su aplicación y remoción?
• Hay un método alternativo de remover un “puente” (‘override’)?
• Están definidas medidas de programación o de procedimiennto para limitar el
período de “peunteo” (‘override’)?

Seguridad
2.4 PROGRAMACIÓN DE LA APLICACIÓN

Una Aplicación Programa software arquitectura global será definida. Esta arquitectura
identificará los bloqueos del software bloquea y sus funciones asignadas.
La aplicación del diseño de la arquitectura se usará para definir los requisitos adicionales
que resultan del diseño del hardware del sistema. Específicamente, los métodos para
dirigir la comprobación específica, diagnósticos y reportes de Falla del sistema serán
incluidos.
Es muy recomendable que las pruebas de simulación se realizen en cada bloque del
software. Esta prueba de simulación deben usarse para mostrar que cada bloque realiza
sus funciones deseadas y no realiza las funciones imprevistas.
También se recomienda altamente que la prueba del software de integración se realize
dentro del ambiente de la simulación antes de la integración del hardware con el software
sea ejecutada. Las pruebas del software de integración mostrarán que todos los bloques
del software interactúan para realizar sus funciones deseadas correctamente y que no
realizan las funciones imprevistas.
El desarrollo del paquete de programación debe seguir un ciclo de desarrollo estructurado;
cuyos requisitos mínimos son:
• Definición de la Arquitectura. El programa de la aplicación debe ser dividido en
‘bloques’ grandes auto-contenidos para simplificar la implementación y pruebas.
Las funciones de seguridad y lass no relacionadas con la seguridad deben
separarse hasta donde posible en esta fase.
• El Diseño detallado y codificación. Esta fase detalla el diseño, e implementa
cada uno de los bloques identificados durante la definición de la arquitectura.
• Prueba. Esta fase verifica el funcionamiento de la aplicación; se recomienda que
los bloques de aplicación se pruebe primero individualmente y después
integrados y probados en conjunto. Esto debe emprenderse inicialmente dentro
del ambiente de la simulación.
Los Programas de Aplicación resultantes deben integrarse con el hardware del sistema y
realizar las pruebas de integración.
2.4.1 Dividiendo la Aplicación

Es impráctico e innecesario aplicar el mismo grado de desarrollo riguroso y pruebas a todas las
funciones dentro de la Aplicación dónde algunas de esas funciones no están relacionadas con
la seguridad.
La identificación de funciones de seguridad es, en parte, dependiente de la filosofía de
seguridad específica. Los ejemplos de funciones no relacionadas con la seguridad pueden
incluir la indicación de estado, reporte de datos y secuencia de eventos. Es importante
establecer que estos elementos no están relacionados con la seguridad. Por ejemplo, algunos
casos relacionados con la seguridad confían en la intervención humana y por consiguiente el
funcionamiento correcto de indicación de estado.
Los elementos relacionados con la seguridad deben implementarse dentro de programas
separados de aquellos elementos que no están relacionados con la seguridad. Donde la
información pase entre estos elementos, debe prepararse que la dirección del flujo de
información sea de “relevante a la seguridad” a “no relevante a la seguridad”.

Seguridad
2.4.2 Medidas defensivas

Al definir la Aplicación, el programador debe considerar las fuentes potenciales de
error y debe aplicar las técnicas de la programación defensivas razonables. Donde se
reciben los valores de otros programas o de interfazes de comunicaciones externas, la
validez de los valores debe verificarse donde sea posible. Semejantemente, deben
verificarse valores recibidos de las interfazes de entrada donde sea posible. En
muchos casos, será también posible monitorear permutaciones de datos, entradas y
modos de operación de planta para establecer la plausibilidad de la información y
programar medidas para asegurar las respuestas seguras en caso de condiciones
inverosímiles.
2.4.3 Bloques de Prueba

Cada bloque del software relacionado con la seguridad debe ser 100% capaz de ser
probado. Un Bloque 100% capaz de ser Probado es la lógica de la aplicación que
pertenece a una función de seguridad. Tales funciones podrían ser:
• Supervisión de llama de quemador incluyendo la temperatura, monitoreo de
la presión de aire/gas, etc.,
• El control/supervision de la relación gas-a-aire del quemador
• Partes o toda la secuencia de arranque de un reactor de horno
Mientras mnor es el número de entradas, salidas y caminos de las señalaes, es menor
el número de permutaciones que requieren comprobación. Sin embargo, una sola
función de seguridad no debe ser partida en bloques separados; es probable que tal
división conlleve a la introducción de errores durante las actividades de mantenimiento.
La interacción entre los bloques del software individuales se minimizará. Donde la
interacción sea necesaria, debe guardarse tan simple como sea posible, por ejemplo
una sola señal de iniciación de paro.
Cada función de seguridad debe ser responsable para el control de las saldias
correspondientes. Salidas compartidas entre las funciones no se deberán permitir.
2.4.4 Funciones individuales Relacionadas con la Seguridad

El Toolset de IEC1131 permite la definición de hasta 250 programas individuales
dentro de un solo proyecto. Esta facilidad debe ser explotada para habilitar la
asignación de las funciones individual relacionadas con la seguridad para separar los
programas. Donde los tales programas contienen caminos lógicos independientes,
éstos deben investigarse para determinar si estos son funciones de seguridad
separadas. Donde estas están separadas, se recomienda que éstas se asignen más
allá de su propio programa, de acuerdo a las recomendaciones en el Párrafo N 2.4.3.
Deben buscarse los casos que permitan la creación de caminos de lógica individuales
repitiendo secciones pequeñas de lógica en lugar de ventilar (“fanning out”) la
señal(es) resultante(s).

Seguridad
2.4.5 Minimice la Profundidad Lógica

Donde sea posible, la profundidad lógica debe minimizarse. Esto ayuda a reducir la
complejidad visual, simplifica la comprobación, minimiza el número de
interconecciones requerido y mejora la eficacia del programa.
Donde existan ahorros de lógica, debe ser posible establecer el funcionamiento
correcto de todas las conexiones lógicas intermedias.
El uso de memoria, es decir enclavamientos (‘latches’), componentes dentro de la
función de seguridad debe minimizarse. Semejantemente, la permutación de
condiciones que llevan a su activación se minimizará.
2.4.6 Interacción de comunicaciones

TRUSTED ICS proporcia un rango de opciones de comunicaciones para permitir la
interacción con los sistemas externos. Donde esta comunicación se usa por reportar (o
para exportar) las comunicaciones no hay ningún requisito de seguridad específico.
Los datos recibidos de equipo externo que bien sea que controle funciones
relacionadas con la seguridad o que afecta su funcionamiento deben ser manejados
con cuatela. Los datos recibidos deben manejarse bien sea directamente por el
Programa de Aplicación o usando los bloques de función proporcionados.
Donde sea posible, los datos recibidos deben ser tales que se limiten a la interacción
que:
• Comience las funciones de seguridad, es decir que comience secuencias de
parada (“shutdown”)
• Restablece (“Reset”) las señales, siendo la acción restablecimiento sólo
posible una vez que las condiciones de comienzo han sido removidas
• Inicia la temporización de señales de “puenteo” (‘overrides’) que son
removidas automáticamente bien sea por haber expirado el periodo de
arranque o una vez qie la señal asociada ha sido estabilizada en la condición
de operación normal
• Ajuste los parámetros de control dentro de los límites operacionales seguros
definidos, como por ejemplo: bajando de umbrales de disparo
Donde la interacción no cae dentro de estas categorías, el efecto de valores
incorrectos y secuencias de valores debe ser considerado y deben tomarse medidas
para asegurar que el sistema responderá en forma segura en caso de los datos sean
erróneos. Alternativamente, pueden implementarse medidas dentro de la aplicación
para asegurar la integridad y validez de los datos.

Seguridad
2.4.7 Definición de Los Casos de Prueba

Incluso con un número pequeño de entradas, es posible alcanzar un punto dónde el
número de pruebas se vuelve irrazonable. El número de pruebas de camino lógicas
que necesitan ser realizadas puede reducirse eliminando los escenarios imposibles o
improbables. La selección de lo que constituye un escenario que no requiere la
comprobación sólo puede realizarse después de un análisis de riesgo detallado.
Los escenarios deben incluir posibles condiciones de la planta, las permutaciones de
las condiciones de la planta, condiciones del sistema (incluyendo las condiciones de
potencia parcial, remoción de módulo y condiciones de Falla).
Donde no es posible definir un juego representativo de casos de prueba, todas las
permutaciones de condiciones de la entrada, es decir todos los estados posibles de
todas las entradas posibles deben ser ejercitados. Donde la lógica incluye elementos
de memoria o de temporización, se definirán las pruebas adicionales para ejercer
todas las posibles secuencias de permutaciones de entrada que llevan a su
funcionamiento.
2.4.8 Verificación del programa

Todos los casos de prueba (definidos en el párrafo N 2.4.7) para las funciones
relacionadas con la seguridad se ejecutarán y los resultados de las pruebas serán
registrados.
Las pruebas deben incluir el tiempo de barrido del sistema, tiempo de detección de
Falla, tiempos de reacción de la Falla y retraso del tiempo global (“throughput”) de
tretardo para la lógica de parada. El tiempo de barrido del programa de la aplicación
debe ser menos de la mitad del periodo de tolerancia de Falla del proceso controlado
por el sistema TRUSTED ICS.
2.5 PRODUCCIÓN DEL SISTEMA

La etapa de producción del sistema implementa el diseño detallado del sistema. Las
técnicas de producción, herramientas y equipos usados dentro de la prueba de
producción del sistema deben ser correspondientes con el SIL requerido.
2.5.1 Integración del sistema

Esta fase integrará los Programas de la Aplicación con los sistemas objetivo. Donde se
usen los sistemas múltiples para alcanzar el requerimiento global, se sugiere que que
cada sistema sea sujeto a integraciónes individuales de programas de aplicación y de
sistema objetivo antes de realizar una integración global del sistema. Para reunir los
requisitos del SIL intencional, la integración del sistema debe asegurar la
compatibilidad del software y hardware.

Seguridad
2.6 INSTALACIÓN Y COMISIONAMIENTO

La fase de instalación de sistema definirá los pasos a ser emprendidos para asegurar
que el sistema se instala correctamente y es comisionado en la planta. Estos pasos
incluirán la instalación física y eléctrica del sistema.
El ambiente de la instalación es una fuente potencial de falla de causa común. Por
consiguiente, es vital que la compatibilidad del equipo se establezca. El `Medio
Ambiente` para estos propósitos incluye las condiciones climática, área peligrosa,
potencia, aterramiento y condiciones de EMC. En muchos casos, no puede haber un
solo ambiente de la instalación. Pueden instalarse elementos del sistema difiriendo la
situación, es decir: cuarto de control central, cuartos de equipos e instalaciones. En
estos casos, es importante establecer el equipo y la compatibilidad del medio ambiente
para cada sitio.
El primer paso en la secuencia de la instalación es típicamente la instalación física del
sistema. Donde el sistema comprende varias unidades físicamente separadas, es
importante que la secuencia de instalación se establazca. Esto puede incluir la
instalación de medios de la terminación antes de los elementos restantes del sistema.
En estos casos, es importante establecer que las facilidades de instalación y pruebas
independientes están disponibles.
Cada instalación debe diseñarse para asegurar que el equipo del control no opera en
ambientes que están más allá sus tolerancias de diseño. Por consiguiente, debe
considerarse el cotrol apropiado de temperatura, humedad, vibración y movimiento
súbito (“shock”), así como se el adecuado apantallamiento y aterramiento para
asegurar que la exposición a la interferencia electromagnética y las fuentes de la
descarga electrostáticas sea minizada.
La fase de comisionamineto es para establecer el conexionado (“hook-up”) del sistema
y verificar su correcto funcionamiento ‘de extremo a extremo', incluyendo la conexión
entre el sistema de TRUSTED ICS y los sensores requeridos y elementos finales. Es
probable que grupos de funciones sean comisionados en lugar del sistema en
conjunto, es decir, funciones de area de planta (“accommodation”) antes que las
funciones de producción. En estos casos, es importante establecer la secuencia de
comisionamiento y las medidas a ser tomadas para asegurar el funcionamiento seguro
durante los periodos de comisionamiento parcial. Estas medidas serán específicas al
sistema y se definirán claramente antes de comisionarse. Es importante establecer
que cualquier medida temporal se llevará a cabo para propósitos de la prueba o para
permitir el comisionamiento parcial serán retiradas ante que el sistema, en conjunto, se
energize.
Se mantendrán los registros a lo largo del proceso de comisionamiento. Estos
registros deben incluir los registros de que las pruebas sean completadas, los reportes
de problemas y la resolución de estos problemas.

Seguridad
2.6.1 Validación del Sistema de Seguridad

La validación de sistema de seguridad deberá probar el sistema integrado para
asegurar el cumplimiento con los requisitos de la especificación al nivel de integridad
de seguridad deseado. Las actividades de validación deben incluir aquellas que sean
necesarias para establecer que las funciones de seguridad requeridas se han
implementado bajo los modos de arranque normal, parada y modos de la Falla
anormal.
La validación asegurará que cada requisito de seguridad funcional se ha implementado
al nivel de integridad de seguridad requerido, y que el realización de la función logra su
criterio de actuación, específicamente que los requerimientos de tiempo de seguridad
del proceso se han cumplido. La aprobación también considerará las fallas potenciales
de causa común externas, es decir fuentes de suministro de poder, condiciones
ambientales, y asegurar que el sistema proveera operación de falla segura en caso de
que ocurran condiciones que ecedan su capacidad.
2.6.2 Operación y Plan de Mantenimiento

Los requerimientos de Operación y de Mantenimiento aseguran que la seguridad
funcional continúa más allá del diseño, la producción, la instalación y comisionamiento
del sistema. La operación en servicio y el mantenimiento normalmente están más allá
de la responsabilidad del integrador de sistema. Sin embargo, deben proporcionarse
guías y procedimientos para asegurar que las personas u organisaciones responsable
de la Operación y Mantenimiento mantengan los niveles de seguridad deseados.
La Operación y el Plan de Mantenimiento incluirán a lo siguiente:
• Aunque el producto de TRUSTED ICS no requiere ningún requisito específico de energización y
desenergización, es posible que la implementación especifica del proyecto dictará secuencias
de acción específicas. Estas secuencias deben definirse claramente, asegurando que las
secuencias no puedan producir periodos de incapacidad del sistema para responder en forma
segura mientras un riesgo esté presente.
• El Plan de Mantenimiento detallará los procedimientos a ser adoptados cuando recalibran
sensores, actuadores y módulos de E/S. Los periodos de la calibración recomendados también
deben ser incluidos.
• El Plan de Mantenimiento incluirá el procedimiento a ser adoptado para probar el sistema, y los
intervalos máximos entre la comprobación manual.
• El mantenimiento del sensor y del actuador requerirán la aplicación de “puentes” (‘Overrides’)

en ciertas circunstancias. Donde éstos se requieren, ellos se llevarán a cabo de acuerdo con la
guía proporcionada dentro de este documento.
2.6.3 Mantenimiento planificado

En la mayoría de las configuraciones de sistemas habrán algunos elementos que no
se prueban por los medios de la prueba internos del sistema. Éstos pueden ser los
elementos pasivos finales en algunos tipos de módulos de E/S, los propios sensores y
actuadores y la instalación eléctrica del campo. Un régimen de pruebas de
Mantenimiento Planificado debe adoptarse para asegurar que las Fallas no se
acumulen dentro de esos elementos que podrían llevar finalmente a incapacitar al
sistema para poder realizar sus funciones de seguridad requeridas. El intervalo
máximo entre estas pruebas debe definirse durante el diseño del sistema, es decir
antes de la instalación. El intervalo de la prueba en todos los casos debe ser menor
de 12 meses.

Seguridad
2.6.4 Mantenimiento de Dispositivos de campo

Durante la vida del sistema, será necesario emprender varias actividades de
mantenimiento de campo que incluirán la recalibración, comprobación y reemplazo de
dispositivos. Deben incluírse medios dentro del diseño del sistema para permitir emprender
éstas actividades de mantenimiento. Semejantemente, el plan de operación y de
mantenimiento necesita incluir éstas actividades de mantenimiento, y su efecto en el
funcionamiento y diseño del sistema. En general, el provisionamiento adecuado para estas
medidas se definirá por el cliente, y con tal de que los medios, es decir “puentes de
mantenimiento” (“maintenance overrides”) se implementan dentro de los requerimientos
especificados en este documento. No se requireren mas requisitos de seguridad.
La capacidad de forzamiento de E/S no será usada para soportar el mantenimiento de
dispositivo de campo; esta facilidad se proporciona para sólo para soportar pruebas de la
aplicación.
2.6.5 Manejo de Falla de Módulo

Cuando se configura e instala apropiadamente, el TRUSTED ICS está diseñado para
operar contínuamente y correctamente aún cuando uno de sus módulos Falla. Cuando un
módulo falla debe reemplazarse para asegurar rápidamente que las Fallas no aumentan,
causando condiciones de falla múltiples que podrían causar una parada de planta por esta
causa. Deben reemplazarse los módulos fallados antes del ‘Tiempo de Ocurrencia de la
Segunda Falla’. Todos los módulos permiten la remoción y reemplazo en vivo, y pueden
quitarse módulos dentro de una configuración tolerante a Falla sin posteriores acciónes.
Los módulos en una configuración no redundante o de Falla segura requerirán la
aplicación de señales de puentes (“overrides”) o desvíos (“bypass”) durante el período de
remoción del módulo para asegurar que no se generen inadvertidamente respuestas de
seguridad no deseadas.
La reparación del en sitio de módulos no es soportada; todos los módulos fallados deben
devolverse para su reparación y/o diagnóstico de Falla. El procedimiento del retorno para
los módulos debe incluir los procedimientos para identificar la naturaleza y circunstancias
de la Falla y la respuesta del sistema. Se mantendrán archivos de fallas del módulo y
acciones de la reparación.
2.6.6 Modificación del sistema

Los cambios de diseño ocurrirán inevitablemente durante el ciclo de vida del sistema, y
para asegurar que la seguridad del sistema se mantiene, deben manejarse los tales
cambios cuidadosamente. Deben documentarse los Procedimientos que definen las
medidas a ser adoptadas al actualizar la planta o el sistema. Estos procedimientos
serán la responsabilidad del usuario final. Sin embargo, el integrador del sistema debe
proporcionar guía suficiente para asegurar que estos procedimientos mantienen el
nivel requerido de seguridad funcional. También debe darse consideración especial a
los procedimientos a ser adoptados en caso de actualizaciones de nivel del producto y
mejoras, es decir actualizaciones de módulos y de “firmware”. Las actualizaciones al
sistema deben incluír consideraciones de los requisitos para efectuar los cambios de la
aplicación y cambios del “firmware”. Estas medidas de procedimiento deben incluir:
• Requerimiento para emprender el análisis de impacto de cualquiera de estos cambios
• Las medidas a ser llevadas a cabo durante la modificación al sistema y su programación. Estas
medidas deben estar en la línea con los requisitos dentro de este documento.
• La definición de estos procedimientos debe incluir la revisión y los autorización del proceso
para ser adoptado para efectuar los cambios del sistema.

Seguridad
2.6.7 Líneas de base (“baselines”)

Se declararán las líneas de base (“baselines”) más allá de las cuales cualquier cambio
debe seguir el procedimiento de administración de cambio formal. El punto dentro del
ciclo de vida en el que estas líneas de base (“baselines”) se declaran depende del
detalle de los procesos involucrados, la complejidad del sistema, que tan fácil es
cambiar estos procesos, y el SIL requerido. Se recomienda que la línea de base
(“Baseline”) para el proceso de cambio formal sea la realización de cada paso en el
ciclo de vida. Sin embargo, como mínimo la línea de base debe declararse antes de
que se presenten los riesgos potenciales, es decir antes del arranque.
2.6.8 Archivos de la modificación

Se mantendrán archivos de cada solicitud o requirimiento de cambio. El procedimiento
de Administración del cambio incluirá la consideración del impacto de cada uno de los
cambios requiridos / solicitados antes de la autorización del cambio de la aplicación. La
aplicación del cambio debe repetir aquellos elementos del ciclo de vida que sean
apropiados para el cambio. La prueba de los cambios resultantes debe incluir pruebas
no regresivas además de la prueba del propio cambio.
2.6.9 Modificación En Línea

TRUSTED ICS permite la modificación en línea del sistema dentro de los límites pre-
definidos. Estos límites pre-definidos restringen los cambios de la aplicación al
funcionamiento lógico, las modificaciones a las E/S o estructura de variables, o la
adicióin / borrado de programas que excedan estos límites. Modificaciones que
exceden estos límites pre-definidos automáticamente excluyen la modificación en línea
y dictan que el programa de la aplicación se pare antes de hacer actualizaciones.
Incluso dentro de estos límites, se recomienda que no se realicen modificaciones en
línea.
Sin embargo, dónde es necesario realizar las modificaciones en línea, debe tomarse
cuatela extrema para asegurar que no se generan respuestas o cambios inseguros. En
todo caso debe seguirse la guía para la modificación del programa de aplicación.
El producto permite la adición módulos en línea, aunque en la mayoría de los casos
esto requiere una modificación del programa que dicta la parada y recarga de la
aplicación. La adición de módulos en línea puede realizarse para minimizar el período
de tiempo fuera de servicio de la planta. Las modificaciones al cableado de campo y la
instalación eléctrica de potencia para acomodar los nuevos módulos debe ser
considerado cuidadosamente. Cambios que afecten la habilidad del sistema de
responder en forma segura, o que pueden causar otra perturbación de la planta no
debe realizarse en línea a menos que medidas de protecciones alternas puedan
llevarse a cabo durante la duración de tales modificaciones.

Seguridad
2.6.10 Monitoreando
Para establecer que los objetivos de seguridad se han reunido a través de la vida del
sistema es importante mantener archivos de las Fallas, fracasos y anomalías. Esto
requiere el mantenimiento de archivos por el usuario final y el integrador del sistema.
Los archivos mantenidos por el usuario final están fuera del alcance de este
documento; sin embargo, se recomienda que la información siguiente sea incluida:
• Descripción de la Falla o anomalía
• Detalles del equipo involucrado, incluyendo los tipos del módulo y números
de serie dónde sea apropiado
• Cuando la Falla fue experimentada y cualquier circunstancia que llevó a su
ocurrencia
• Cualquier medida temporal que se haya llevado a cabo para corregir o
trabajar sobre del problema
• Descripción de la resolución del problema y referencia a los planes de acción
correctiva y análisis de impacto
Cada integrador del sistema debe definir los retornos del campo, y los procemientos de
manejo de reparación y de fallas. Los requisitos de información puestos en el usuario
final deben documentarse ya que estos procedimiento debe documentarse claramente
y deben proporcionarse al usuario final. El procedimiento de manejo de fallas debe
incluir:
• El método para detectar defectos recalcionados con el producto y el reporte
de éstos a los diseñadores originales.
• Los métodos para detectar fallas sistemáticas que puede efectuar otros
elementos del sistema u otros sistemas, y que conlleven a la resolución
satisfactoria de los problemas.
• Los procedimientos para rastrear todas las anomalías reportadas, su
resolución y/o las acciones corectivas resultantes en dónde sea aplicable.
2.6.11 Retirando (“Decommissioning”)

Se definirá el procedimiento para retirar el sistema (ponerlo fuera de servicio). Este
procedimiento se hace para incluir cualquier requisito específico para el retiro en forma
segura del sistema y, dónde sea plicable, la disposición segura o retorno de
materiales.

Seguridad
2.7 EVALUACIÓN DE LA SEGURIDAD FUNCIONAL

El proceso de evaluación de la seguridad funcional confirmará la efectividad del logro
de seguridad funcional para el sistema. La evaluación de seguridad funcional, en este
contexto, se limita al sistema relacionado con la seguridad y asegurará que el sistema
se diseña, se construye y se instala de acuerdo con los requisitos de seguridad.
Cada función de seguridad requerida y sus propiedades de seguridad deben ser
consideradas. Los efectos de Fallas y errores dentro del sistema y programas de
aplicación, fallas externas al sistema y deficiencias de procedimiento en estas
funciones de seguridad serán consideradas.
Las evaluaciones serán emprendidas por un equipo de auditoría que debe incluir
personal fuera del proyecto. Por lo menos una evaluación de la seguridad funcional
debe realizarse antes que se presenten riesgos potenciales, es decir, antes del
arranque.
2.7.1 Competencia
El logro de seguridad funcional requiere la implementación del ciclo de vida de
seguridad y asegurarse que las personas que son responsables para cualquier
actividad de ciclo de vida de seguridad sean competentes para ejecutar esas
responsabilidades.
Todas las personas involucradas en cualquier actividad de ciclo de vida de seguridad,
incluyendo actividades de gerenciación, deben tener el entrenamiento apropiado,
conocimiento técnico, experiencia y calificaciones pertinentes a los deberes
específicos que ellos tienen que realizar. La selección de las personas designadas
para las actividades del ciclo de vida de seguridad será basada en factores de
competencia específicos pertinentes a la aplicación particular y serán registrados.
Los factores de competencia siguientes deben dirigirse cuando se esté evaluando y
justificando la competencia de personas para llevar a cabo sus deberes:
• Experiencia en Ingeniería que sea apropiada al área de la aplicación.
• Experiencia en Ingeniería apropiada a la tecnología.
• Experiencia en Ingeniería deSeguridad apropiada a la tecnología.
• Conocimiento del marco de regulaciones legal y de seguridad.
• Consecuencias de las fallas del sistema relacionado con la seguridad.
• El SIL de los sistemas relacionados con la seguridad.
• La novedad del diseño, procedimientos de diseño o aplicación.
• La experiencia anterior y su relevancia a los deberes específicos a ser
realizados y la tecnología a ser empleada.
En todos lo anterior, el riesgo más alto requerirá un mayor rigor en la especificación y
evaluación de la competencia.

Seguridad
2.8 REQUISITOS DE LA DOCUMENTACIÓN

Los archivos siguientes se mantendrán para demostrar la aplicación segura de la
seguridad relacionada el sistema:
• Informe de Riesgo y del Análisis de Riesgo. El Informe de Riesgo y el
Análisis de Riesgo registrarán las fuentes potenciales de riesgo hasta, y
dentro de, el propio sistema. Para cada uno de los riesgos potenciales, los
métodos a ser adoptados para reducir el riesgo, mando y/o mitigar las
consecuencias deben registrarse.
• Informe de Análisis del Tiempo de Seguridad del Proceso. Este informe
registrará el Tiempo de Seguridad del Proceso recomendado, o los tiempo
para las recolecciones individuales de planta, dónde el tiempo se ha
recomendado de tal manera. El informe incluirá el cálculo del tiempo de
respuesta del sistema requerido (incluyendo los tiempos que resulten de los
sensores y actuadores) y los tiempos de detección de Falla del sistema
requeridos.
• Registro del entrenamiento del personal, experiencia y calificaciones.
Se mantendrán los archivos de los individuos involucrados dentro de las
actividades de ciclo de vida de seguridad y su responsabilidad. Estos
archivos apoyarán los juicios más adelante, y registrará la conveniencia de
del personal para ejecutar sus responsabilidades dentro del ciclo de vida de
seguridad.
• Las listas de chequeo y revisión de evidencia recopiladas durante las fases
del ciclo de vida de la integración del sistema
• Las condiciones y restricciones aplicadas al sistema
• Reportes de Auditorías de Seguridad Funcional
• Datos del campo (colectados de la planificación de funcionamiento y de
mantenimiento). La actuación en servicio del sistema será monitoreada y
será registrada. Fallas en el sistema, su funcionamiento y los errores de
procedimiento deben ser específicamente registrados. Para cada Falla, se
recomienda que la fuente de la Falla, cualquier trabajo alrededor de la misma
o la acción correctiva aplicada y la ruta de su corrección sea registrada.
• Los archivos de mantenimiento, modificación, y reparación a TRUSTED ICS
y EUC.

Seguridad
3. RECOMENDACIONES PARA EL SISTEMA
3.1 INTRODUCCIÓN
Este párrafo amplía y aplica los principios de seguridad descritos anteriormente en
este Capítulo. Muchas de las recomendaciones dentro de este párrafo son igualmente
aplicables a otros sistemas relacionados con la seguridad. Sin embargo, los detalles
de las recomendaciones o requisitos son específicos al TRUSTED ICS.
3.2 ARQUITECTURAS DE E/S

El TRUSTED ICS tiene un sistema de diagnóstico interior muy extensivo que revela las
fallas cubiertas (“covert”) y abiertas (“overt”). La aplicación del hardware de muchos de
los mecanismos de tolerancia de Falla y de detección de Falla provistos para los
tiempos de detección de Falla se acerca a cero para la mayoría de los elementos del
sistema. Los medios de auto-prueba utilizados para diagnosticar las Fallas dentro del
resto del sistema se define para proporcionar la disponibilidad de seguridad óptima.
Estos medios de auto-prueba pueden requerir períodos cortos de funcionamiento fuera
de línea o pueden introducir condiciones, como por ejemplo de de alarma o de
condiciones de prueba de falla, las cuales efectivamente resultan en que el punto esté
fuera de línea (“off-line”) dentro de un canal redundante. Dentro de las configuraciones
de TMR, éste periodo de funcionamiento fuera de línea afecta sólamente la habilidad
del sistema a la respuesta bajo las condiciones de falla múltiple.
Los Procesadores de TMR TRUSTED ICS, Interfazes TMR TRUSTED ICS, Interfazes
del Expansor y Procesadores del Expansor son naturalmente redundantes y se han
diseñado resistir fallas múltiples y apoyar una configuración de reparación en línea fija
en las ranuras adyacentes y por consiguiente requiere consideración extensa pequeña.
Los módulos de entrada y salida soportan varias opciones de arquitectura, deben
evaluarse los efectos de la arquitectura escogida contra el sistema y los requisitos
específicos de la aplicación.
3.2.1 E/S de Alta Densidad

Los módulos de E/S de Alta Densidad son inherentemente triplicados con auto-prueba
(Prueba automática) intensiva y medios del diagnóstico. Las auto-pruebas son
coordinadas para asegurarse que una mayoría puede establecerse en caso de que
ocurra una demanda durante la ejecución de las pruebas. El monitoreo de la
discrepancia y la desviación refuerzan aún más la comprobación y detección de Fallas.
Las interfazes interiores al controlador son probadas por el Procesador de TMR. La
culminación de estas medidas resulta en niveles altos de detección y tolerancia de
Fallas, llevando finalmente al funcionamiento ‘Falla segura’ en caso de condiciones de
la falla múltiples. El tiempo de detección de Falla para cada tipo del módulo se
especifica, en todos los casos aún ante la presencia de una Falla cubierta (“covert”)
durante este período, el sistema continuará respondiendo. Bajo las condiciones de la
falla múltiples el período de detección de segunda Falla dentro del tiempo de
reparación puede necesitar ser considerado donde el sistema se usa en aplicaciones
de seguridad de demanda alta o contínua.

Seguridad
El TRUSTED ICS soporta módulos sencillos dónde es aceptable bien sea detener el
sistema o permitir que las señales que corresponden a ese módulo cambien a su estado
predefinido (“default”), y dos configuraciones de ‘activo-en espera’ (“Active/Standby”). La
primera configuración ‘activo-en espera’ (“Active/Standby”) es para acomodar los módulos
activos y de repuesto en las posiciones de la reanura adyacente, el segundo es el uso la
configuración de ‘Ranura Inteligente’ (“SmartSlot”) dónde una sola posición del módulo
puede usarse como suplente para varios módulos activos. Todas las configuraciones
pueden usarse para las aplicaciones relacionadas con la seguridad; la opción entre el
configuraciones soportadas la reparación en línea (en vivo) es dependiente en la
preferencia del usuario final y el número de módulos defectuosos que se requieren reparar
simultáneamente.
Los módulos de E/S TRUSTED ICS usan el arreglo de ‘activo-en espera’ para soportar
la reparación en línea ‘sin saltos’ (“bumpless”). La arquitectura del módulo triplicada
permite que el módulo defectuoso continúe en servicio normal hasta que un reemplazo
(triplicado) del módulo esté disponible y a diferencia de las configuraciones de ‘en
espera-caliente’ (“Hot-standby”) convencionales, permite una trasferencia controlada
incluso ante la presencia de una condición de Falla. El módulo de reserva puede
instalarse permanentemente para reducir el tiempo de la reparación a un mínimo
absoluto.
3.2.2 E/S de Baja Densidad

Los módulos de E/S de baja densidad TRUSTED ICS proporcionan la interfaz TMR interna. Otros
elementos de los módulos individuales pueden ser non-redundantes (dependiendo del tipo del módulo) para
sportar la “redundancia de rodaja” (`Slice') en las configuraciones del módulo redundantes. Para
perfeccionar la disponibilidad de seguridad del sistema, las funciones de auto-prueba se cronometran para
tomar sólo una parte pequeña de los recursos del sistema.
En las configuraciones no-redundantes, es importante que el intervalo de la prueba resultante sea lo
suficientemente corto para asegurar la habilidad del sistema de responder dentro del tiempo de seguridad
de proceso. Para estas configuraciones, el intervalo de la prueba (TI) se da por:
TI = (172 × IOU × Tscan) + 2

Donde:
TI = Intervalo de Prueba en segundos
IOU = numero de chasises de E/S
Tscan = Tiempo de barrido del sistema en segundos
Si la suma del intervalo de la prueba, multiplicada dos veces por Tscan, y el tiempo de reatraso del sensor
y del actuador no es significativamente menor que el tiempo de seguridad del proceso, entonces una
arquitectura de E/S alternativa debe escogerse. Si el TRUSTED ICS puede detectar la falla dentro del
tiempo de seguridad del proceso, entonces ninguna acción especial se requiere.
3.2.2.1 Efecto de Arquitecturas de Entrada

Si se consideran las cuatro configuraciones de entrada de baja densidad básicas y el
efecto del tiempo de detección de Falla, entonces:
1. Para una configuración de entrada simple, la señal lógica en la aplicación
permanecerá en el estado anterior a la detección de la falla hasta que el tiempo de
detección de Falla ha expirado, y timrá la condición lógica de ‘0'. Ésto, ni es
Tolerante a Falla, ni es Falla segura. Si la proporción de la demanda es baja, esto
puede ser aceptable para las funciones de parada. Deben discutirse los efectos de
PST (Tiempo de Seguridad del Proceso) con el usuario.
2. En situaciones de uno-de-dos (1-oo-2), el sistema permanece activo durante el
tiempo de detección de Falla pero dispara cuando el tiempo de detección de
Falla expira.

Seguridad
3. En situaciones dee dos-de-dos (2-oo-2), la entrada permanece estática durante
el período de descubrimiento de Falla, pero retorna al funcionamiento cuando el
período de detección de Falla expira. Ésto es tolerante a Falla pero el sistema
está inactivo durante el tiempo de detección de Falla. Como antes, los efectos
de Tiempo de Seguridad del Proceso (PST) debe discutirse con el cliente.
4. Cuando se usa dos-de-tres (2-oo-3) el sistema permanece operacional en todo
momento y tolerante a falla.
2-oo-3 son la solución técnica más simple al problema pero requerirá el uso de tres
entradas de variable de campo, con el hardware y alambrando extra asociados.
Puede generarse una la solución eficaz y segura usando la aplicación 2-oo-2, con tal
de que el tiempo de seguridad de proceso no sea un problema, o el uso de la
estructura 1-oo-2 y de los bits de Falla si el tiempo de seguridad de proceso es un
factor decisivo. El sistema 2-oo-2 tendrá una disponibilidad ligeramente más baja,
mienntras que con el 1-oo-2 aumentará la proporción de disparos espúreos
ligeramente cuando se compara con el sistema 2-oo-3. Sin embargo, el conteo de
hardware reducido aumenta la confiabilidad en ambos casos. Una configuración
alternativa 1-oo-2 se muestra en la Figura 1 debajo:
Figura 1 Contactos de Campo del Sistema 1-oo-2 en la Condición Saludable
En este caso, ambas entradas pueden fallar en forma cubierta (“covertly”) sin que se
afecte la respuesta del sistema. El voto básico es 1-oo-2 con una enmienda por los
bits de Falla. En caso de una falla del módulo, el estado de ese módulo es mantenido
estático (“staticised”) durante el periodo de detección de Falla. Sin embargo, el módulo
permanece operacional. Después del periodo de detección de Falla, el Bit de Falla del
módulo fallado se cerrará y la condición lógica del módulo fallado se tomará al estado
abierto por los diagnósticos de TRUSTED ICS. (el Bit de Falla cierra antes de que el
Bit lógico abra).
En caso de que ambos módulos se vuelvan defectuosos, el estado de parada es
generado. Las entradas deben localizarse en los módulos de entrada separados, pero
que pueden estar en el mismo chasis.

Seguridad
3.2.2.2 Asignación de E/S

Además del tipo y arquitectura de módulo de E/S, es necesario considerar la
asignación de señales cuidadosamente a las localidades de los módulo de E/S. Esta
asignación debe ser considerada para las arquitecturas no-redundantes y redundantes
tanto de los dispositivos del campo y como de las interfazes de E/S de baja densidad.
Dentro de las arquitecturas redundantes, es importante asegurarse que una sola falla
resulta en el modo de falla deseado, es decir falla segura o tolerado. En casi todos
casos, esto dictará que los canales redundantes residan en módulos diferentes dentro
del sistema. Donde el mismo módulo se use, la razón de usar esta opción debe
registrarse y ser revisada.
La función de una señal debe ser considerada al asignar el módulo y lso canales
dentro del sistema. En muchos casos, pueden usarse sensores redundantes y
configuraciones redundantes del actuador, o variantes del sensor y de los tipos del
actuador podrían proporcionan posibilidades de detección y control alternas.
Frecuentemente, las instalaciones de la planta tienen señales relacionadas, por
ejemplo: señales de arranque y de parada. En estos casos es importante asegurarse
que las fallas dentro del sistema no producen ni la incapacidad del sistema para
responder seguramente, ni en el funcionamiento inadvertido. En algunos casos, esto
requerirá que los canales sea ubicados en el mismo módulo, para asegurarse que una
falla del módulo produzca las señales falla segura asociadas.
Sin embargo, en la mayoría de los casos, será necesario separar las señales entre
varios módulos. Donde las configuraciones non-edundantes son empleadas, es
especialmente importante asegurarse que la acción Falla segura se genere en caso de
fallas dentro del sistema.
Al considerar la función de señal, el sentido (normalmente energizada, normalmente
des-energizada) de la señal también forma un factor importante. Donde el sentido de la
señal parece ser contrario a su función, o puede producir la incapacidad del sistema
para responder seguramente en caso de Falla, es importante resaltar esto al cliente y
asegurarse que se tomen las medidas apropiadas.

Seguridad
3.2.3 Configuraciones de Energizar para Actuar

Ciertas aplicaciones pueden requerir saldias en una configuración de “Energizar para
Actuar”. El Energizar para Actuar sólo se usará si:
• la activación del sistema solo está mitigando un Peligro (“hazard”), o
• la activación del sistema es un Peligro por sí misma, o
• el sistema se usa en aplicación de fuego y de gas, o
• el sistema se usa en una aplicación con requisito de SIL1 a SIL2 (AK1 a AK4)
Adicionalmente las restricciones siguientes aplican:
• Por lo menos deben usarse dos fuentes de poder independientes. Estas
fuentes de poder deben mantener la energía de emergencia para un paro de
proceso seguro. Se recomiendan Fuentes de Poder Ininterrumpibles (UPS).
• Cada fuente de potencia debe proporcionarse con monitoreo de la integridad
de potencia con lectura de retorno de seguridad crítica al Controlador
TRUSTED ICS o monitoreo de potencia implícito proporcionado por los
módulos de E/S. Cualquier falla de poder llevará a una alarma.
• A menos que se proporcione implícitamente en los módulos de E/S, todas las
entradas y salidas críticas de seguridad deben contar con monitoreo de
integridad de la carga y de la línea externa y retorno crítico de seguridad de
las señales de estado de línea. Cualquier falla de línea o de carga llevará a
una alarma.
En los casos dónde uno o más de una salida se usa en configuración de energizar
para disparar todos los requisitos específicos establecidos arriba serán seguido.

Seguridad
3.2.4 Configuraciones de E/S Relacionadas con la Seguridad
Tipo de Modulo Configuracion Condiciones

Entradas Digitales Todos los tipos incluyen monitoreo de
monitoreadas de Alta línea opcional y pueden usarse para las
Integridad 2-oo-3 aplicaciones relacionadas con la
T8403, 24V dc seguridad en configuraciones de
T8423, 120V dc desenergizar para disparar o de
energizar para actuar. Las
configuraciones de Energizar para actuar
deben incluir los dispositivos de
monitoreo de línea a nivel del dispositivo
de campo.
Entradas Digitales Desenergizada para disparar: con tal de
T7401, 24V dc 1-oo-2 (2v2) que las entradas cambien (“transitioned”)
T7402, 48V dc or dinámicamente en un periodo no mayor
T7404, 110V ac 2-oo-3 (2v3) que el tiempo de ocurrencia de segunda
T7408, 120V ac or Falla.
1-oo-3 (3v3) La configuración 1-oo-3 significa que las
3 señales de entrada no pueden votarse.
Cualquier discrepancia (“mismatch”) de
de las señales conlleva a una
anunciación de alarma.
Entradas Digitales 2-oo-2 (1v2) o 1-oo-2 Desenergizar para disparar y energizar
Supervisadas (2v2) o 2-oo-3 (2v3) para actuar.
T7411, 24V DC T7411F, Energizar para activar entradas debe
24V DC T7418F, 120V AC, incluír dispositivos de monitoreo de línea
en el interruptor de campo.
T7419, Detector de fuego, M-oo-N Para uso seguro en la configuración de
M-oo-N dentro de aplicaciones delfuego
y de gas.
Entradas Analógicas de Para uso relacionado con la seguridad
Aalta Integridad dentro de la exactitud de seguridad
T8431 Triplicado especificada.
Entradas analógicas Triplicado con Para uso relacionadao con la seguridad,
T7420A, T7420AF normal la selección del valor con tal de que las entradas son
contestación rápida medio o seleción de ajustadas dinámicamente en rango a
alto/bajo dual plena escala a un periodo no mayor que
el tiempo de ocurrencia de segunda
Falla.
Otras Entradas No-interferencia Para uso de no-interferencia y puede
T7431A, termocupla, usarse para dispositivos de entrada de
seguridad no críticos.
Multiplexor de entrada y No-interferencia Para uso de no-interferencia y puede
salida usarse para dispositivos de entrada de
T7491 seguridad no críticos.
Tabla 6 Configuraciones de Entrada

Seguridad
Tipo del módulo Configuracion Condiciones

Salida Digital de Alta Para uso relacionado con seguridad en
Integridad y Supervisada configuraciones de des-energizar para
disparar o de energizar para actuar. Las
T8451, 24V DC T8471, 120V Triplicado salidas de energizar para actuar debe
DC, estar conforme a los requisitos definidos
en “las Configuraciones de energizar
para Actuar”
Salidas Digitales Módulo simple falla Desenergizado para disparar:
Resguardadas segura (1-oo-1 / 1v1) certificado.
o módulos duales
T7461A, 24V DC, tolerantes a falla (2- Energizar para activar: sólo es
oo-2 / 1v2) certificado si las saldias cambian
dinámicamente de 0-1-0 o 1-0-1 en un
período no mayor que el tiempo de
ocurrencia de segunda Falla.
Saldias supervisadas Módulo simple Falla Para uso relacionado con la seguridad
Resguardadas Segura (1-oo-1 / 1v1) en configuraciones de desenergizar para
o módulos duales disparar o de energizar para activar.
T7481, 24V DC T7484, 110V tolerantes a falla (2-
AC T7488, 120V AC, oo-2 / 1v2)
Otras Salidas No-interferencia No-interferencia, y puede usarse para
los dispositivos de salida de seguridad
T7441A, 24V dc T74444, no críticos.
110V ac T7446L/H, la
parada T7454, 110V ac,
T7464 aislado, 110V ac,
T7470A Resguardada,
T7480A Analógico,
Analógico,,
Multiplexor de entrada y No-interferencia No-interferencia, y puede usarse para
salida T7491 los dispositivos de salida de seguridad
no críticos.
Tabla 7 Configuraciones de Salida
3.2.5 Lista de control de La Arquitectura de E/S

Los artículos siguientes forman una lista de chequeo básica de la arquitectura de E/S:
1. El PST se ha establecido?
2. El tiempo de detección de Falla para el sistema se ha establecido?
3. Si el tiempo de detección de Falla es mayor que el PST, Estan las E/S relacionadas con
la seguridad usando una configuración Falla segura? Si no, ha sido discutida con el
cliente la topología del sistema para asegurar que la aplicación del sistema sea segura?
4. Si una probabilidad de falla ante demanda se ha especificado, se ha cumplido esto?
5. Las arquitecturas seleccionadas proporcionan una solución dónde no hay ningún punto
de falla de Fuente de Poder Ininterrumpible que se pueda probar que podría llevar a que
el sistema no funcione en forma segura cuando sea requirió?
6. Dónde se usen arquitecturas redundantes, son los elementos redundantes también
capaces de ser probados totalmente para asegurar que la acumulación de fallas no
produce ningún funcionamiento impropio?

Seguridad
7. Mantiene el módulo de E/S las características correctas y el comportamiento del sensor

o actuador deseados para cada uno de los tipos de señales de E/S,?
8. Son los tipos de módulos de E/S seleccionados compatibles con la arquitectura de E/S
requerida?
9. Consideró la asignación de señales a los módulos de E/S y canales cada una de las
funcións de las señales?
10. Consideró la asignación de señales a los módulos de E/S y canales los efectos de fallas
del módulo?
3.3 DESARROLLO DEL PROGRAMA DE APLICACIÓN
3.3.1 Selección del Lenguaje

El IEC1131 Toolset ofrece muchas herramientas de programación para desarrollar algoritmos
para satisfacer las necesidades de virtualmente cualquier aplicación de control en tiepo real.
Los lenguajes de configuración y de programación aprobados para el uso en aplicaciónes
SIL3/AK6 relacionadas con la seguridad se muestran en la Tabla 6.
Relacionados con La Bloque de la función (FB)

seguridad
Lista de Instrucciones (IL))
Texto Estructurado (ST)
Lógica de Escalera (LD)
No relacionado con la Diagrama de Función Sequencial (SFC)
Seguridad
‘C’
Tabla 8 Lenguajes de Programación Relacionados con Seguridad
• Los Lenguajes relacionados con la seguridad. Para aquellos lenguajes que han
sido clasificado como relacionados con la seguridad, se han probado las funciones
normalmente usadas exhaustivamente y se han usado libremente. Pueden usarse
funciones extensas dentro de estos idiomas sujetas a la realización de las pruebas
correspondientes con el nivel usado para las funciones normalmente utilizadas.
• No relacionados con la seguridad. Los lenguajes que han sido clasificados sólo
para aplicaciones no relacionadas con la seguridad no pueden usarse dentro de un
sistema relacionado con la seguridad.
IL y ST incluyen funciones de control de flujo del programa; estas funciones deben usarse con
cautela para asegurar que no producen lazos infinitos o condiciones lógicas omitidas. Donde
estas estructuras se usan, se recomienda que pruebas a fondos de cada rama se realicen en
éstas secciónes de programa.
Bloques de Función generados por el programador de la aplicación pueden crearse bien sea en
un proyecto específico o en base a la biblioteca. Donde estas funciones sean usadas para las
aplicaciones sean relacionadas con la seguridad, éstos deben estar sujeto a la comprobación
exhaustiva, correspondiente con las funciones normalmente usadas. Una vez que el bloque de
función ha estado sujeto a este nivel de pruebas, puede usarse en las funciones normalmente
usadas.

Seguridad
Hay provisión para la TRUSTED ICS soportar programas múltiples dentro de un
proyecto. Un proyecto completo puede ser clasificado como relacionado con la
seguridad o no relacionado con la seguridad. Un proyecto relacionado con la seguridad
puede usar los lenguajes de programación de seguridad; no pueden usarse los
lenguajes de programación de no relacionados con la seguridad. Un proyecto
clasificado como el no relacionado con la seguridad puede usar cualquiera de los
lenguajes de programación y el conjunto de instrucciones completo pero no debe
usarse para llevar a cabo funciones relacionadas con la seguridad.
3.3.1.1 Lista de control de Selección de Lenguaje

Lo siguiente proporciona una lista de control de selección de idioma:
1. Donde posible restrinja la programación de la aplicación al lenguaje de
programación de FB.
2. Si es necesario usar otros lenguajes de programación, asegúrese que sólo el
subconjunto seguro convenido del idioma se usa para las aplicaciones
relacionadas con la seguridad.
3. Asegúrese que los lenguajes de programación clasificados como no
relacionados con la seguridad no se usan para los proyectos relacionados con
seguridad.
3.3.2 Desarrollo de la aplicación

El desarrollo de la aplicación comprenderá lo siguiente:
3.3.2.1 Comprobación de la Referencia cruzada

Mientras el objetivo será minimizar el acoplamiento y dependencias entre los
programas individuales, habrá ocasiones inevitablemente dónde, por ejemplo, una
variable se usa dentro de dos o más programas. La utilidad de chequeo de referencia
cruzada debe usarse para verificar las inter-dependencias del programa. Siempre que
un programa que usa tal una variable se modifique, todos los programas que usan la
misma variable deben probarse de nuevo.
3.3.2.2 Comparación de Código

En conjunto, después de cada fase de modificación a la aplicación como un todo, la
utilidad de comparación de Código TRUSTED ICS se usará para identificar que esos
programas han cambiado. Aquéllos que hayan sido identificados como que han sufrido
algún cambio (diferente que las direcciones de variables compiladas) debe probarse
de nuevo.

Seguridad
3.4 REQUISITOS MEDIOAMBIENTALES

El ambiente de la instalación del sistema presenta una fuente potencial de falla de
causa común. Es necesario asegurarse que el equipo sea conveniente para el
ambiente en cual se desea instalar. Alternativamente, métodos para mantener las
condiciones del medio ambiente del equipo dentro de sus capacidades deben
proporcionarse. Esto es aplicable a todos los sistemas; sin embargo el resto de esta
sección da las recomendaciones para el medio ambientale específicas para el sistema
de TRUSTED ICS.
3.4.1 Condiciones climáticas

Se muestran las condiciones climáticas recomendadas y máximas para el equipo TRUSTED ICS en
la Tabla 9 debajo:
Estas condiciones ap[plican para las configuraciones representativas y típicas del sistema. Donde se
acomodan densidades de equipo altas dentro de un sistema o las grandes cantidades de equipo de
gran potencia se condensa estrechamente, es necesario considerar la generación de calor localizada
y su impacto en las condiciones medioambientales globales de operación del sistema.
Se tiene la intención de que la Tabla 9 sea una guía para un sistema como un todo. Es posible
lograr un sistema capaz de funcionamiento en un rango más ancho de condiciones climáticas
usando un análisis detallado de las características del sistema y de las condiciones resultantes
para el equipo montado dentro del sistema.
Debe notarse que la temperatura de funcionamiento para el equipo dentro de cualquier sistema
electrónico tiene un impacto significante en la vida potencial de ese equipo. Altas temperaturas
de funcionamiento alta y ratas de cambio de temperatura reducen la vida operacional de
cualquier dispositivo electrónico significativamente; por consiguiente, deben tomarse medidas
para asegurar que los medios de ambiente de operación permanecen dentro del rango
recomendado. Semejantemente, es muy recomendado que los periodos que el equipo se
expone a las condiciones fuera del rango recomendado se minimicen.
Parametro Comentario Recomendado Limite

Min Max Min Max
Temperatura de Con enfriamiento 10°C 30°C 0 °C 40°C
Operacion natural
(seco) 50°F 86°F 32°F 113°F
Con enfriamiento 10°C 30°C -20°C 50°C

/ Calefaccion
forzada 50°F 86°F -13°F 120°F
Temperatura de 10°C 30°C -40°C 85°C

Almacenamiento
(seco) 50°F 86°F -40°F 185°F
Humedad de Operacion No condensante 5%RH 95%RH
Humedad de No condensante 5%RH 95%RH
Almacenamiento
Cambio de Temperatura 0.5°C/min Nota
Tabla 9 Requisitos de Condiciónes Climática

Seguridad
Nota: Aunque no hay ningún máximo definido, es importante evitar cambios de humedad y
temperatura que podrían producir condensación. Los efectos de condensación en
cualquier tipo de equipo eléctrico pueden producir fallas del equipo o funcionamiento
impropio.
3.4.2 Compatibilidad Electro-magnética (EMC)

La TRUSTED ICS se ha diseñado y se ha probado para resistir los niveles normales
de interferencia electromagnética y la descarga electrostática conducidas e irradiadas.
Las condiciones de ruido eléctrico pueden variar grandemente, dependiendo de la
instalación de equipo, alambrado, otro equipo instalado, y su proximidad al equipo de
TRUSTED ICS. Un análisis detallado de las condiciones eléctricas y magnéticas de la
instalación es raro. Es por consiguiente necesario asegurar que el sistema cumpla con
los requisitos del cliente o las normas apropiadas en conjunto. Dentro de Europa, los
requisitos de la marca CE forman un mínimo legal. Para los sistemas para
aplicaciones fuera de Europa se recomienda que por lo menos las mismas medidas se
apliquen, y que se confirme a través del cliente o usuario final que los niveles de
interferencia electromagnética (EMI) no excederán aquéllos mostrados en Tabla 10
debajo.
Parámetro Condiciones Notas
Descarga Decarga al Aire de 15kV Contacto directo al
electrostática Descarga de Contacto de 8kV equipo
Campo 10V/m
Electromagnético 23MHz a 1GHz
Ruido Conducido / Voltaje de Prueba de 2kV – En las conexiones
Prueba de Inmunidad Fuentes de Poder externas del
a Transiente Rápido Voltaje de Prueba de 1kV – E/S sistema (por
(‘Picos’ o “Burst”) digitales (≥24V) ejemplo: en los
Voltaje de Prueba de 0.25kV – E/S terminales)
digitales (<24V), analógicas y de
comunicación
Tabla 10 Compatibilidad Electromagnética
Si los EMI anticipados exceden estos niveles, deben aplicarse medidas de protección
adicionales.
3.4.2.1 Apantallamiento de la Instalación

En caso de mantenimiento del sistema y durante el comisionamiento es muy probable
que el sistema tendrá sus puertas abiertas dirante periodos significantes. El Gabinetes
en general forma parte de los sistemas protección de EMC, y por consiguiente es
particularmente importante que durante estos períodos los métodos de las
protecciones interiores intencionales se utilizen. Los módulos del TRUSTED ICS y del
Regent+Plus junto con su chasises, forman parte de la protección de EMC interna del
sistema. Por consiguiente, debe colocarseles escudo (“shield”) a todas las posiciones
de módulo vacías dentro del sistema.

Seguridad
3.4.2.2 ATERRAMIENTO PARA EMI

En la esquina de a mano izquierda superior de cada chasis, en la placa posterior
(“backplate”), está un terminal de tierra. Estos terminales pueden proporcionar el
aterramiento adicional para alta frecuencia (EMI) entre chasises múltiples de un solo
sistema.
Hay dos métodos que pueden usarse para el aterramiento de EMI:
1. El terminal de tierra en cada chasis del TRUSTED ICS local debe conectarse a
un solo punto de tierra (tal como un perno del gabinete) usando una trenza de
aterramiento de 0.5 pulgada (13 mm) soldada a una agarradera de anillo.
2. Alternativamente, la trenza de tierra puede conectarse entre el terminal de tierra
del chasis y los rieles de montaje del. Este método sólo es aceptable si todos los
equipos TRUSTED ICS se localizan en un solo gabinete o en gabinetes
múltiples que se instalan juntos.
3.4.3 Precauciones de Manejo electrostáticas

Las precauciones del manejo siguientes también deben observarse:
1. El personal debe aterrarse antes de que ellos manejen los módulos.
2. Los módulos no deben ser manejados por sus conectores.
3. No quite los módulos de su empaquetamiento hasta que requira usarlos.
4. El material de la empacadura EMI en el chasis y los módulos es frágil. No toque
la empacadura ya que esto puede dejar un residuo de aceite que dañará la
efectividad de la empacadura. El tocar la empacadura pueden tambien dañar las
bridas (pestañas) de la empacadura.

Seguridad
3.5 REQUISITOS DE POTENCIA DEL SISTEMA

Las alimentaciones eléctricas del sistema y distribución, si se diseñaron
incorrectamente, presentan un causa de falla común potencial. Es por consiguiente
necesario lo siguiente:
• Establezca la filosofía de los requerimientos de potencia, filosofía del
aterramiento (“earthing”) específica, el voltaje requerido y requisitos de
potencia, y los requisitos de la separación dónde se proporcionan artículos
de equipo separadamente, por ejemplo fuentes de poder internas del sistema
y fuentes de poder de lazo de campo.
• Defina la arquitectura de las Unidades de Fuentes de Suministro (PSU), por
ejemplo redundancia del 100%, redundancia dual, redundancia N+1, etc. y
asegúrese que cada fuente de poder es de capacidad adecuada.
• Asegure que los PSUs son compatibles con las alimenciones de poder
proporcionadas. Alternativamente, deben llevarse a cabo las medidas para
asegurar que que los alimentadores de las PSU permanecen dentro de las
especificaciones de las PSU.
• Defina los requisitos de distribución de poder, junto con la filosofía de
protección para cada distribuidor, por ejemplo: limitación de corriente en la
fuente o en los dispositivos de protección. Donde se usan los dispositivos de
protección, es importante establecer habrá la corriente suficiente disponible
para asegurar su acción de protección y que el dispositivo de protección
puede interrumpir la corriente de Falla probable máxima.
• Asegúrese que el medios de distribución de poder se dimensionan para
acomodar las corrientes de la Falla probables máximas y las pérdidas de
voltaje tolerables. Esto es específicamente importante que donde se usan
fuentes de poder de suministros flotantes y otras fuentes que puedan
producir corrientes de la Falla probables altas en caso de las condiciones de
Falla a tierra múltiples.
Los módulos de TRUSTED ICS requieren de dos alimentaciones de 24V dc, con un
camino del retorno común, es decir que el retorno de 24V es común entre las
alimentaciones de poder. Los chasises de E/S Regent o Regent+Plus requieren
alimentación de triplicada 15V dc.


Chapter 1Sp PDF

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Chapter 1Sp PDF

Cargado por

Copyright:

Formatos disponibles

CAPÍTULO 1

Doc No TM2244US Versión 2.0

Doc No TM2244US Versió 2.0

1.1 PROPÓSITO DE SEGURIDAD

Doc No TM2244US Versión 2.0

1.2 DOCUMENTOS ASOCIADOS

Título del Documento Requisito

Doc No TM2244US Versión 2.0

1.3.1 Tolerancia de Falla y Falla Segura

Tabla 1-oo-2 (2v2)

Tabla 2 2-oo-2 (1v2)

Doc Número TM2244US Versión 2.0

1.4 VISIÓN GLOBAL DEL TRUSTED ICS

Doc No TM2244US Versión 2.0

2.2 VISIÓN GLOBAL DE LA IEC 61508

Doc Número TM2244US Versión 2.0

2.3 ADMINISTRACIÓN DE SEGURIDAD

2.3.1 Niveles de Integridad de Seguridad (SIL)

Doc No TM2244US Versión 2.0

SIL Modo de Demanda de Operación

Tabla 3 Medición de Falla de Objetivo – Modo de Demanda de Operación

SIL Modo de Operación de Demanda Alta /

Tabla 5 Nivel de AK DIN V VDE 0801 y el Equivalente SIL IEC 61508

Doc Número TM2244US Versión 2.0

2.3.2 Ciclo de Vida de la Seguridad

Doc No TM2244US Versión 2.0

2.3.3 Definición del alcance

2.3.4 Requisitos funcionales

Doc Número TM2244US Versión 2.0

2.3.5 Requisitos de Seguridad

Doc No TM2244US Versión 2.0

2.3.6 Ingeniería de Sistemas

2.3.6.1 Asignaciones de Requisitos de seguridad

2.3.6.2 Tiempo de Seguridad del Proceso (PST)

Doc Número TM2244US Versión 2.0

Donde la función de seguridad es implementada a través de un número de varios

Doc No TM2244US Versión 2.0

2.3.6.3 Forzamiento de entradas y salidas

§ El interruptor de llave del Procesador TMR debe estar en la posición de ingeniería

2.3.6.4 “Puentes” (‘overrides’) para Mantenimiento

Doc Número TM2244US Versión 2.0

2.3.6.5 Lista de Verificación de Requisitos de “Puenteo”

Doc No TM2244US Versión 2.0

2.4 PROGRAMACIÓN DE LA APLICACIÓN

2.4.1 Dividiendo la Aplicación

Doc Número TM2244US Versión 2.0

2.4.2 Medidas defensivas

2.4.3 Bloques de Prueba

2.4.4 Funciones individuales Relacionadas con la Seguridad

Doc No TM2244US Versión 2.0

2.4.5 Minimice la Profundidad Lógica

2.4.6 Interacción de comunicaciones

Doc Número TM2244US Versión 2.0

2.4.7 Definición de Los Casos de Prueba

2.4.8 Verificación del programa

2.5 PRODUCCIÓN DEL SISTEMA

2.5.1 Integración del sistema

Doc No TM2244US Versión 2.0

2.6 INSTALACIÓN Y COMISIONAMIENTO

Doc Número TM2244US Versión 2.0

2.6.1 Validación del Sistema de Seguridad

2.6.2 Operación y Plan de Mantenimiento

• El mantenimiento del sensor y del actuador requerirán la aplicación de “puentes” (‘Overrides’)