CÓDIGO:

ESPECIFICACIÓN TÉCNICA
EP-ET-AUT-00032
PÁGINA: FECHA DE VIGENCIA:
1 de 17 Septiembre - 16
SCADA - HMI
PROCESO: REVISIÓN:
Automatización 1

TABLA DE CONTENIDO
PROPOSITO _________________________________________________________________________ 2
ALCANCE____________________________________________________________________________ 2
NORMATIVA _________________________________________________________________________ 2
DEFINICIONES _______________________________________________________________________ 3
1. Definición de HMI____________________________________________________________________ 3
2. Necesidad de un SCADA y/o HMI _______________________________________________________ 3
3. Características de un SCADA / HMI _____________________________________________________ 3
4. Estructura de un despliegue de HMI._____________________________________________________ 4
4.1. Barra de título. _________________________________________________________________ 4
4.2. Área de representación sinóptica del proceso _________________________________________ 4
5. Comunicaciones. ____________________________________________________________________ 4
BUENAS PRÁCTICAS Y RECOMENDACIONES _____________________________________________ 5
1. Buenas prácticas para el desarrollo______________________________________________________ 5
1.1. Despliegues. ___________________________________________________________________ 5
1.2. Seguridad del sistema __________________________________________________________ 11
1.3. Manejo de datos: ______________________________________________________________ 11
1.4. Manejo de Alarmas. ____________________________________________________________ 12
1.5. Comunicaciones. ______________________________________________________________ 15
1.6. Recomendaciones generales _____________________________________________________ 15
SISTEMAS SCADA/HMI ESTANDARIZADOS ______________________________________________ 17

Control de Revisión Histórica

Fecha Revisión Realizado por Descripción

15/09//2016 1.0 Nelson Salcedo Versión Original

REVISADO POR: APROBADO POR:

GERENCIA DE AUTOMATIZACIÓN GERENCIA DE INGENIERÍA

“SI USTED CONSULTA UNA VERSIÓN IMPRESA DE ESTE DOCUMENTO, ASEGÚRESE QUE SEA LA VIGENTE”
 CÓDIGO:
ESPECIFICACIÓN TÉCNICA
EP-ET-AUT-00032
PÁGINA: FECHA DE VIGENCIA:
2 de 17 Septiembre - 16
SCADA - HMI
PROCESO: REVISIÓN:
Automatización 1

PROPOSITO
Generar los lineamientos que permitan desarrollar sistemas SCADA y en particular HMIs de arquitectura
abierta que se consideren buenas interfaces para el operador, basados en diferentes normas internacionales
y trabajos relacionados previamente desarrollados en Empresas Polar.

ALCANCE
Este documento define las normas y criterios para el desarrollo de sistemas SCADA y HMI contratados por
Empresas Polar.

NORMATIVA

I. Normas Internacionales
 Norma ISA 101.
 Norma ISA 88.
 Norma ISA 95
 Norma EEMUA 191 Alarm System: A Guide to Design, Management and Procurement.

II. Trabajos relacionados

 Doc. Especif. Diseño Básico de HMI v2.3.doc - Comunidad de Servicios Industriales.
 Buenas practicas para el diseño HMI segun Norma ISA101.pptx - Ing. José G. Rodríguez.

III. Presentaciones y Papers de fabricantes

 Efficient HMI/SCADA: Driving Decision Support With Fourth Generation Technology (aw_webinar_-
_efficient_hmi_-_driving_ds_-_june_2016_-_v11.pdf) - GE Digital.
 Maximize Operator Effectiveness (partes 1 y 2) – PAS.

NOTA: En caso de contradicciones entre las normas de referencia, regirá la más exigente, que garantice el
máximo funcionamiento y fiabilidad de seguridad. Sin embargo nada de lo contenido en este documento se
considerará para liberar al proveedor de su responsabilidad de un diseño, fabricación e instalación
adecuados.

REVISADO POR: APROBADO POR:

GERENCIA DE AUTOMATIZACIÓN GERENCIA DE INGENIERÍA

“SI USTED CONSULTA UNA VERSIÓN IMPRESA DE ESTE DOCUMENTO, ASEGÚRESE QUE SEA LA VIGENTE”
Especificación Técnica SCADA - HMI PAGE: 3 de 17

DEFINICIONES

1. Definición de HMI
Viene del inglés Human Machine Interface. Se refiere a la(s) aplicación(es) de software cuya función es
proporcionar a un operador una representación ya sea gráfica o numérica del estado actual del proceso,
permitiéndole la supervisión del mismo y tomar acciones en función de la información presentada.
Adicionalmente puede mostrar alarmas para alerta de una condición de peligro o no deseada del proceso.

Un HMI forma parte de un sistema más complejo denominado SCADA, de las siglas en inglés Supervisory
Control and Data Acquisition, que traducido al castellano significa Control Supervisorio y Adquisición de
datos. Un sistema SCADA tiene varios componentes, los cuales le permiten cumplir su función de recoger
datos del proceso, almacenarlos, presentarlos al operador a través del HMI, etc. Esos componentes son:
a. Protocolo de comunicaciones con campo, es decir con los controladores, ya sean PLCs, PACs, DCS,
etc.
b. Base de datos.
c. HMI.
d. Históricos.
e. Comunicaciones con otros sistemas.

2. Necesidad de un SCADA y/o HMI

A continuación se presentan varios indicadores que demuestran la necesidad de un sistema SCADA
 El número de variables del proceso que se necesita monitorear es alto.
 Se requiere supervisar varios procesos que ocurren simultáneamente.
 Se requiere que el operador ejecute acciones sobre diferentes componentes del proceso, donde por la
distancia y el tiempo requerido no le sea posible ejecutar de manera oportuna.
 El proceso está geográficamente distribuido. Esta condición no es excluyente, ya que puede instalarse
un SCADA para la supervisión y control de un proceso concentrado en una localidad, como es el caso
de los procesos de Empresas Polar.
 Las información del proceso se necesita en el momento en que los cambios se producen en el mismo, o
en otras palabras, la información se requiere en tiempo real.
 Es necesario llevar un registro histórico de los datos del proceso.

3. Características de un SCADA / HMI

Para que un sistema sea considerado SCADA debe cumplir ciertas funciones. A continuación se presentan
las más resaltantes:
 Manejo de las comunicaciones, ya sea con:
 campo a través de uno o varios protocolos de comunicaciones, también conocidos como drivers y
sobre uno varios buses de campo.
 otras aplicaciones como historiadores externos, generadores de reportes, MES, etc. a través de una
red.
 Manejo y actualización de una Base de Datos ya sea propietaria o estándar.
 Transferencia de datos en tiempo real
 Presentación y administración de alarmas (Eventos).
 Generación de archivos históricos.
 Interfaces con el operador (HMI - Human Machine Interface).
 Capacidad de programación (Visual Basic, C).
Especificación Técnica SCADA - HMI PAGE: 4 de 17

4. Estructura de un despliegue de HMI.

Los despliegues en Empresas Polar tienen una estructura estándar que se describe a continuación

4.1. Barra de título.

Se compone de varias secciones que suministran información acerca de fecha y hora, alarmas, el
sistema que se está supervisando y el usuario.
4.1.1. Información General: son enlaces o links que suministran la fecha y hora del sistema.
4.1.2. Área de alarmas: se compone de tres botones que al ser seleccionados presentarán paneles de
alarmas según su prioridad (alta, media o baja/info).
4.1.3. Título: muestra el nombre del sistema o proceso presentado en el área de representación
sinóptica.
4.1.4. Usuario: muestra el nombre de la persona cuyas credenciales se suministraron al sistema para
ejecutar las diferentes operaciones.

4.2. Área de representación sinóptica del proceso

Es el área de mayor ocupación dentro de un despliegue y allí donde se representa el proceso junto
con sus variables. Usualmente se representa en forma intermedia entre un P&ID y un diagrama de
flujo.

4.2.1. Objetos dinámicos: existen diferentes formas de presentar la información el tiempo real según sea
necesario a continuación se presentas las estandarizadas
i. Gráficos: se usan para representar válvulas, motores, niveles, etc. y su respectivo estado
ii. Alfa – numéricos: se usan para presentar en forma numérica el valor actual de variables de
proceso como temperatura, presión, flujo, nivel, pH y otras variables

4.2.2. Tablas de datos: se utilizan para mostrar los parámetros de recetas, tablas de valores actuales de
variables, etc.

5. Comunicaciones.
5.1 Con los controladores: se efectúa a través de diferentes protocolos o drivers de comunicación. Se
requiere que este componente de software además comunicarse con el controlador usando el
protocolo nativo del fabricante, también sea servidor OPC.
5.2 Con otros sistemas: se privilegia el uso de del protocolo OPC para intercambio de datos con otras
aplicaciones, ya sea en mismo equipo o con otros a través de la red. Dada esta característica el
SCADA debe ser tanto servidor como cliente OPC siendo esta última característica de especial
importancia para el HMI, ya que permite el ahorro de puntos en la base de datos, lo cual impacta
favorablemente el aspecto de costos.
Especificación Técnica SCADA - HMI PAGE: 5 de 17

BUENAS PRÁCTICAS Y RECOMENDACIONES

1. Buenas prácticas para el desarrollo

Los nuevos desarrollos contratados por Empresas Polar deben regirse por las normas que se presentan a
continuación. En caso de dudas o de necesidad de implementar una solución con criterios diferentes a los
planteados en este documento deberá consultarse con la Gerencia de Automatización. Con ello lo que se
persigue es lograr HMIs que se puedan considerar buenas interfaces para el operador y para lograrlo se
busca que los despliegues:

i. Sean simples, lo cual permitirá al operador reconocer y entender la información con facilidad y rapidez.
ii. Sean intuitivos, con lo cual el operador pueda anticiparse y reconocer problemas rápidamente y
responder de manera instantánea.
iii. Generen confianza en el operador y se sienta comodo con el sistema de control.
iv. Sean sencillos para que el operador pueda navegar y completar sus tareas sin problemas.

1.1. Despliegues.
También se les denomina pantallas o esquemáticos y serán desarrollados de acuerdo a:

1.1.1. Tipos de despliegues.

1.1.1.1. Gráficos: son aquellos donde se representa el flujo del proceso en conjunto con objetos
dinámicos (dynamos) que representan variables de proceso, como barras niveles y los
accionamientos ya sea válvulas o motores; también se incluyen objetos alfanuméricos
para representar valores de proceso. Constituyen la representación tradicional hasta
hace pocos años. Aún siguen siendo muy utilizados cuando seguir la secuencia del
proceso es de utilidad para los operadores. Por ejemplo en áreas de elaboración.
Especificación Técnica SCADA - HMI PAGE: 6 de 17

1.1.1.2. Tabulares: constituyen la nueva tendencia en la forma de presentar la información al

operador en áreas donde la toma de decisiones del operador dependa fuertemente de
la información presentada en el HMI. Por ejemplo salas de control de Servicios
Industriales (Sala de Máquinas).

1.1.1.3. PID: Cada lazo de control PID tendrá una sub-pantalla que permita la verificación
detallada de su comportamiento. En esta sub-pantalla los parámetros para la entonación
del lazo solo se visualizarán y permitirán modificar al usuario perteneciente al grupo de
seguridad asignado a los Ingenieros de mantenimiento. Ej.

1.1.1.4. Módulos de equipos: muestran los set points, estrategias de control y botones de
operación de los diferentes módulos de equipos de un sistema.
Especificación Técnica SCADA - HMI PAGE: 7 de 17

1.1.1.5. Módulos de control: muestra el estado y botones de operación para módulos control
como válvulas y motores, así como los estados y valores actuales de otros tipos de
módulos de control como transmisores de temperatura, flujo, presión, etc.

1.1.1.6. Tendencias: deben ser fáciles de entender y manejar para el operador, pudiendo permitir
modificaciones en línea en cuanto cantidad de plumillas, colores de la plumilla, span de la
escala de tiempo (intervalo de tiempo mostrado), rango mostrado de la variable
observada, etc.
Existen dos tipos básicos de tendencia a usar. A continuación se mencionan ambos
casos.

• Tiempo real: se utilizan para saber es comportamiento de una variable justo en el

momento que se muestra en pantalla. Su uso: en tendencias de lazos PID, análisis de
velocidad de alguna máquina, flujos, etc. A continuación se presenta la plantilla
propuesta para PIDs.
• Históricas: como su nombre lo indica, en ellas se representan, en forma gráfica, datos
previamente recolectados de todas aquellas variables que se consideren de utilidad.

1.1.2. Fondo del despliegue - Uso del Color

Se deben usar colores de baja intensidad que no causen fatiga en la vista del operador o
persona que observa la pantalla. El fondo de las pantallas debe ser de un color neutro (por
Especificación Técnica SCADA - HMI PAGE: 8 de 17

ejemplo, de color gris claro) con el fin de limitar las distorsiones cromáticas y garantizar la
relevancia de la información mostrada.
El color recomendado para uso en los desarrollos, como fondo del despliegue, es el gris, en
particular el que aparece en la paleta RGB del sistema como: Red: 217, Green: 217, Blue: 217.

1.1.3. Objetos dinámicos.

1.1.3.1. Librerías estándar.
Todo conjunto de objetos agrupados que contengan animación en el SCADA deben ser
convertidos en un objeto único dinamizado y tendrán expuestas sus propiedades, es
decir, todo enlace dinámico a un Tag o punto de la base datos del sistema al cual esté
asociado, así como a los campos para las unidades de ingeniería y otros datos. Esta
recomendación aplica aun cuando este objeto sea utilizado sólo una vez en la pantalla.
Se conformará una librería con el conjunto de dichos objetos. Ejemplo: módulos de
control.

1.1.3.2. Controles ActivX.

En el caso de que se desee usar controles ActivX en los despliegues, es necesario
asegurarse de que estos objetos sea independientes de la versión de la aplicación
(sistema supervisorio) y del sistema operativo (SO), ya que de lo contrario, será
necesario actualizarlos y/o recompilarlos cada vez que se haga una actualización a las
nuevas versiones tanto de supervisorio como de SO, lo cual no es buena práctica.

1.1.3.3. Uso del color.

La información de proceso presentada en pantalla, debe ser fácil de entender y de
visualizar. Evitar la superposición de objetos y el uso de colores que puedan confundirlos
con el fondo. No usar tampoco colores fuertes, ni brillantes. Estos colores tienden a
provocar cansancio visual al operador. Debe ser utilizado para dirigir la atención y añadir
significado a la pantalla, es decir enfatizar la información clave, tales como alarmas y
condiciones anormales.
En general, debe restringirse el uso del color rojo solo para representar alarmas.

El color no debe ser utilizado como el único método para diferenciar los objetos y sus
respectivos estados dentro de la pantalla.
A continuación se muestra el ejemplo del uso de color para los todos los accionamientos,
tomando como base los motores. Se observará que en la actualidad hay estándares
diferentes según el negocio, pero la premisa en los nuevos desarrollos es hacer la
migración hacia un estándar que se acerque lo más posible a la norma ISA101. En caso
de ser necesaria alguna aclaratoria, debe consultarse a Gerencia de Automatización de la
Dirección de Ingeniería de Empresas Polar.
Especificación Técnica SCADA - HMI PAGE: 9 de 17

1.1.3.4. Movimiento.
Esta propiedad debe ser usada solo donde sea estrictamente necesario mostrar algún
desplazamiento, por ejemplo: niveles de tanques, valores de las variables de una interfaz
(faceplate) de PID. De lo contrario, aun cuando cause buena impresión a primera vista,
con el pasar del tiempo, se convierte solo en un distractor para el operador que no da
ningún valor agregado.
Se debe evitar esta animación donde no proporcione información importante. Por
ejemplo: motores en rotación, transportadores en movimiento, Líquidos rociando, etc.
1.1.3.5. Intermitencia.
También conocido como parpadeo, blinking o titileo. Al igual que las propiedades
anteriormente mencionadas, se debe usar solo en caso de ser estrictamente necesario,
siendo las alarmas un caso típico de uso permitido.

1.1.4. Diseño de navegación entre pantallas.

 El acceso entre pantallas debe ser diseñado con el mínimo de acciones posibles.
 No utilizar método de introducir texto para acceder a la visualización de las pantallas.
 Los símbolos utilizados en la navegación para acceder a las pantallas deben tener una
codificación visual consistente y distinta.
 El HMI debe mantener disponible las opciones de navegación en condiciones normales y
anormales.

1.1.5. Programación de tareas específicas y/o particularizadas.

En el desarrollo de las IHM, se deben utilizar lenguajes de programación estándares. Se
recomienda evitar el uso de lenguajes propietarios, ya que estos particularizan la aplicación,
alejándola del concepto de aplicación abierta. Entre los lenguajes de programación
recomendados se pueden citar:

i. Visual Basic
Este lenguaje de programación es una evolución de BASIC, con importantes añadidos,
completamente gráfico que facilitara la creación de interfaces gráficas y en cierta medida
Especificación Técnica SCADA - HMI PAGE: 10 de 17

también la programación misma. Posee características típicas de los lenguajes

estructurados modernos. Y presenta una implementación limitada de la programación
orientada a objetos. Los paquetes comerciales ofrecen librerías de funciones API
(Application Program Interface) que permitirán al programador interactuar con la aplicación
usando sus propias librerías.

Existen una derivación del Visual Basic denominada VBA (Visual Basic for Applications), el
cual viene incorporado en algunas aplicaciones entre ellas: Microsoft Office así como
algunos SW SCADA y ofrece diversas ventajas. Está muy extendido y es utilizado por
diversos fabricantes para facilitar la integración con otras aplicaciones y el intercambio de
datos.

ii. Lenguaje C++

Lenguaje de programación derivado del lenguaje C que maneja programación estructurada,
programación orientada a objetos y programación genérica (centrada más en el algoritmo
que en los datos). Al igual que Visual Basic, puede interactuar con las API proveídas por los
fabricantes de los sistemas SCADA.

iii. Lenguajes propietarios

Estos lenguajes son proveídos directamente por los fabricantes de algunos paquetes
SCADA, vienen integrados con el sistema, pero presentan las desventajas que tienen
limitaciones y no son lenguajes universales. No se recomienda su uso.

1.1.6. Alarmas
Deben presentarse en un área de la barra de título del despliegue.

Adicionalmente, toda pantalla o esquemático debe poseer un resumen de las alarmas del
sistema. Preferentemente un objeto (Sumario de Alarmas) donde se lea: hora de ocurrencia de
la alarma, estación o nodo SCADA donde se generó la alarma, nombre del punto o Tagname
asociado a la alarma, y descripción breve y fácil de entender de la alarma. Adicionalmente se
requieren tres botones que llamarán resúmenes de alarmas según la prioridad de estas: alta,
media o baja. Ese Sumario de Alarmas deberá tener un filtro por defecto que sólo permita
visualizar las alarmas propias del área operativa del nodo SCADA. Ej.
Especificación Técnica SCADA - HMI PAGE: 11 de 17

 Cuando sea útil y conveniente, pueden emplearse técnicas avanzadas de HMI para mostrar
automáticamente la información relevante.

1.2. Seguridad del sistema

Se deben implantar diferentes niveles de seguridad para jerarquizar las operaciones y evitar acciones
indebidas por personal no autorizado. Se propone para ello implementar los siguientes grupos de
usuarios de seguridad como estándar: Guest, Operadores, Supervisores, Tecnólogo, Mantenimiento e
Ingenieros teniendo cada uno asociado los derechos y configuración propia de la actividad que
desempeñará el usuario.

1.3. Manejo de datos:

El nombre o tagname de todo punto en la base de datos del sistema se iniciará por el número del PLC
que le corresponda, seguido por: un guión bajo, luego por el identificador de tipo de señal y finalmente
por el consecutivo del Módulo de control. Todo tag que sea necesario crear adicionalmente a los tag
estándar del TF, debe comenzar por el número del PLC que le corresponda, seguido por un guion
bajo.

Ejemplo:

Tagname N° PLC Identificador tipo de señal Consecutivo

03_DCM_V065 03 DCM_V 065
03_ALARM225 03 ALARM 225
Especificación Técnica SCADA - HMI PAGE: 12 de 17

03_AINPUT22 03 AINPUT 022

´

Nota: Es importante tener en cuenta que para el tagname se permite el uso de símbolo guion bajo
(también conocido como: piso o under score “_”) después de un número, solo para identificación del
PLC. En caso de quesea necesaria la separación del algún consecutivo u otro número se debe usar el
símbolo guionmedio o signo menos (-)

La descripción de todo tagname de Alarma, Información, Accionamiento o de Medición debe empezar

siempre por el código o etiqueta del módulo de control o el nombre abreviado del equipo, seguido por
la descripción de la alarma, Información, Accionamiento o Medición. Ejemplo:

Código TAG Nombre

Tagname Descripción del tagname en P&ID abreviado del
equipo
03_DCM_V065 HE46PV83. PH2 VALV. CORTE SUM. VAPOR HE46PV83
03_ALARM225 PH2. TEMPERATURA ALTA EN MEZCLA PH2
03_AINPUT22 HE46LT41 NIVEL PAILA MEZCLA HE46LT41

En general, tanto para datos tiempo real, como históricos, las marcas de sistemas supervisorios
estandarizados en Empresas Polar tienen una base de datos que pudiera ser alguno de los
mencionados a continuación:

 Formato propietario:
Se tienen los datos organizados de acuerdo a un formato propio del fabricante, pero es posible
establecer comunicaciones con otras aplicaciones al mismo u otro nivel del modelo de capas de la
norma ISA 95 vía OPC. También se permite el uso de SQL, pero es mandatorio el uso de OPC
cuando existen ambas posibilidades de comunicación.

 Formato estándar
Los datos se organizan usando el estándar SQL/ODBC, pero las comunicaciones con otras
aplicaciones se rigen según lo expresado en el punto anterior.

1.3.1. Consideraciones para datos históricos.

 Se requiere que todas las variables analógicas sean recolectadas y grabadas como datos
históricos, aun cuando en el diseño original del SCADA no sean consideradas para tendencias
históricas. Esto obedece a que siempre existe la posibilidad de que sea requerida en el futuro.
 Las tasas de muestreo deben ser acordes a la velocidad con que la variable puede cambiar en
tiempo real. Por ejemplo: la temperatura no requiere tasas menores a 2 segundos, mientras es
recomendable tomar muestras de la presión cada 1 segundo.

1.4. Manejo de Alarmas.

Definición: Es toda señal o aviso que se activa por algún evento que representa peligro o una
situación anormal y que debe generar la acción de un operador. Se sugiere el uso de tags en la base
Especificación Técnica SCADA - HMI PAGE: 13 de 17

de datos del SCADA dedicados para tal fin. Algunos fabricantes los denominan tag’s tipo “Digital
Alarm”.

El sistema de alarmas es crítico no sólo por su función si no, por la credibilidad que debe tener. Es allí
donde debe tenerse presente la existencia de malos actores, tiempo entre ocurrencia de una misma
alarma, niveles de criticidad, etc.

Se define un mal actor como: Toda alarma que se activa frecuentemente, impacta la operación por
su importancia o por generar la distracción del operador no permitiendo identificar los motivos reales
de una perturbación real.

Se debe tener presente que si la única acción del operador es reconocer la alarma, ésta es
considerada como un mal actor y su proliferación crea ruido y distracción a los operadores. Con el
tiempo, incide en la degradación de la atención que los operadores le prestan a las alarmas.

Las alarmas deberán ser diseñadas para que tengan las siguientes características o propiedades:

 Relevante: que no sea espuria o de bajo valor operacional.

 Única: no debe ser duplicado de otra alarma.

 Oportuna: no debe aparecer mucho antes de que la acción deba ser tomada ó no tan tarde para
que no se pueda hacer nada.

 Priorizada: indicándole al operador la importancia que debe darle al problema.

 Entendible: el mensaje que la acompaña debe ser claro y fácil de entender.

 Diagnostica: identifica el problema que ha ocurrido.

 Consultiva: indica la acción que debe ser tomada.

 Enfocada: orienta la atención a los más importantes asuntos a ser atendidos.

Existen principios claves en el diseño e implantación de sistemas de alarmas. Algunos de los

aplicables a la IHM son:

 Cada alarma deberá alertar, informar y guiar. En otras palabras: cada alarma deberá mostrarse en
pantalla y en algunos casos también emitir un sonido, el cual sería deseable que se diferencie
según el tipo de alarma.

 Cada alarma presentada debe ser útil y relevante para el operador. Para que una alarma sea útil y
relevante debe implicar que el operador ejecute acciones adicionales al reconocimiento de la
misma y que su ocurrencia sea provocada por un evento que realmente sea anormal y/o que
implique potenciales riesgo o peligros para personas, equipos o proceso.

En relación al desarrollo de pantallas o esquemáticos se tienen los siguientes requerimientos:

Toda pantalla deberá tener la posibilidad de cambiar el filtro de alarmas. Dicho cambio no será
permanente y se perderá una vez se salga de la pantalla donde se efectuó.
Especificación Técnica SCADA - HMI PAGE: 14 de 17

El sistema dispondrá de una pantalla Sumario de Alarmas extenso, a la cual se tendrá acceso a través
de un enlace en la barra de título de las pantallas de proceso. Esta pantalla presentará una lista de las
alarmas que ocurrieron en el proceso y deberán estar clasificadas de acuerdo a niveles de criticidad.
El operador o el supervisor pueden reconocer las alarmas sobre la pantalla o hacer consultas
selectivas a esta lista.

Niveles de criticidad de las alarmas:

Es imprescindible establecer en conjunto con Empresas Polar prioridades definidas para las alarmas a
fin de que en un determinado momento el personal sepa que alarma atender primero o dedicarle
mayor atención en caso de se disparen varias al mismo tiempo.
Aplicando la norma EEMUA (Engineering Equipment & Materials Users' Association) 191 se definen
los siguientes niveles de criticidad: Crítica, Alta, Media y Baja. Los criterios son:

 Critica: se considera que una alarma tiene esta prioridad debido a que advierte para evitar una
consecuencia que acarrearía riesgos de seguridad en equipos, en procesos o en personas. Es
recomendable según la norma EEMUA 191 que las alarmas con prioridad crítica sean asignadas a
un sistema independiente (Stand-alone).

 Alta: esta prioridad se asigna a una alarma cuando el impacto posible de la consecuencia es
económicamente alto y representa costos de operación, pérdidas de producción o reparación a
daños a equipos, incluso el costo de pequeñas lesiones al personal. Adicionalmente el tiempo
disponible para evitar la consecuencia es bajo comparado con el tiempo requerido por la acción
correctiva del operador.

 Media: esta prioridad se asigna a una alarma cuando el impacto posible de la consecuencia es
económicamente medio y representa costos de operación, pérdidas de producción o reparación
de daños a equipos, incluso el costo de pequeñas lesiones al personal. En este caso el tiempo
disponible para evitar la consecuencia es suficiente comparado con el tiempo requerido para la
acción correctiva del operador.

 Baja: esta prioridad se asigna a una alarma cuando el impacto posible de la consecuencia es
económicamente bajo.

Los criterios de distribución de prioridades durante el diseño se resumen en la siguiente tabla:

Alarmas configuradas durante el diseño

Nivel de prioridad
por celda de proceso
Crítica Alrededor de 20 en total
Alta 5% del total
Media 15% del total
Baja 80% del total

Si durante el desarrollo de la aplicación se observa alguna desviación de los valores sugeridos por la
tabla anterior, se debe contactar al personal encargado de Empresas Polar con el fin de aplicar
criterios que permitan cumplir con dichos valores.
Especificación Técnica SCADA - HMI PAGE: 15 de 17

Mediante el servicio de impresión de alarmas siempre existe la posibilidad de imprimir la lista entera o
únicamente una parte seleccionada.

La representación de las alarmas y avisos se hará de acuerdo al siguiente criterio:

 Avisos. Color Azul

 Alarmas de prioridad Baja. Color Amarillo
 Alarmas de prioridad Media. Color Naranja
 Alarmas de prioridad Alta. Color Rojo
 Alarmas de prioridad Crítica. Color Violeta

La visualización y el reconocimiento de las alarmas estarán limitados en cada caso al sistema al cual
pertenece el Nodo y a las áreas de alarma destinadas a ser visualizadas por este sistema. En tal
sentido, para todos los sistemas de planta se definen como estándar, grupos de áreas de alarma
distribuidas de forma que permitan la visualización y reconocimiento sólo de las alarmas configuradas
para el sistema que corresponda.

1.5. Comunicaciones.
En este punto se definen los métodos o protocolos a usar en los diferentes tipos de comunicaciones
que un sistema SCADA pueda establecer. Teniéndose como premisa la independencia entre
plataformas, se recomienda que el protocolo base a usar es el OPC.

1.5.1. Con campo:

Se efectuará la comunicación usando protocolos estándar de organizaciones internacionales
como OPC, Profibus (clásico o Profinet), Ethernet IP, etc. o protocolos estándar de los
fabricantes de los controladores.

1.5.2. Con sistemas del mismo fabricante:

Se permite el uso de comunicaciones con lenguaje propietario entre sistemas del mismo
fabricante, dado que en estos casos se optimiza el funcionamiento de estas.

1.5.3. Con otros sistemas:

En Empresas Polar se establece como estándar el uso del protocolo OPC para las
comunicaciones entre los sistemas de diferentes fabricantes, ya sean SCADA, MES, ERP, etc.

1.6. Recomendaciones generales

i. De acuerdo a estudios realizados por varios entes, a continuación se muestra la manera eficiente
de abordar el desarrollo de un SCADA/HMI, la cual se diferencia de la manera tradicional en el uso
de un modelo (norma ISA 88) durante la ingeniería de detalle para facilitar la definición de la
estructura de datos y la lógica operacional del HMI:
Especificación Técnica SCADA - HMI PAGE: 16 de 17

Definición conceptual
• Revisión de planos de ingeniería (P&ID).
• Entender el proceso y su lógica, Interlocks, operación.
• Formular la estructura de datos (puede ser en Excel).
• Entregar la estructura de datos al integrador.
Definición de datos
• Definir los tags usando un modelo.
• Definir propiedades como alarmas, unidades de ingeniería, I/O
drivers (protocolos), históricos.
• Configurar el modelo de activos basándose en la norma ISA
88.
 Este modelo manejará la relación entre equipos de
diferentes capas del modelo de integración de la norma ISA
95.
 Con ello la jerarquía de navegación estará automáticamente
definida.
 Navegación, interacción con alarmas, interacción con
Diseño del HMI
• Para ser eficientes, usar una la librería de objetos dinámicos
del HMI o crear una propia si es necesario.
• Enlazar los objetos dinámicos al modelo.
• No habrá esfuerzos, ni costos adicionales en H/H para replicar
el HMI.

ii. En cuanto al PC a utilizar:

 La memoria RAM. Debe ser lo más grande posible tomando en cuenta que la base de datos se
almacena en memoria redundando en mayor velocidad de acceso a datos así como a los
paquetes de SW necesarios que se ejecuten en forma simultánea.
 Resolución de los esquemáticos: dependerá de la capacidad del monitor. Como mínimo será
1024x768.
 Monitores. Deberán ser de al menos 19 pulgadas considerando que permitirán una mayor
definición y por consiguiente detalle en la visualización del sistema.
 La unidad de disco duro debe ser lo más grande posible tomando en cuenta que se estarán
almacenando archivos históricos.
 Se recomienda usar PC’s de última generación dadas sus capacidades de procesamiento y
mayor tiempo para caer en obsolescencia.

iii. Sistema operativo. Utilizar la última versión liberada y aprobada por Empresas Polar.
iv. La información de proceso presentada en pantalla, debe ser fácil de entender y de visualizar.
v. Los tiempos de respuesta para el refrescamiento de los valores de campo deben ser cortos, es
decir, de actualización rápida. Se estima que el tiempo ideal de refrescamiento es menor o igual a 2
segundos.
vi. Colocar botones o enlaces que permitan la navegación entre las diferentes pantallas del sistema.
vii. La pantalla principal debe tener la una configuración propia de un menú general del sistema que
permita mediante algún tipo de enlace ir a otras pantallas con mayor detalle.
viii. Evitar sobrecargar las pantallas. En caso de que un sistema tienda a contener excesiva cantidad de
objetos, se deberá considerar la necesidad de generar una o más pantallas adicionales con los
debidos enlaces que permitan acceso entre ellas así como al menú o pantalla principal.
Especificación Técnica SCADA - HMI PAGE: 17 de 17

ix. Usar el mismo tipo de letra para títulos y cualquier otro texto indicativo usado en los esquemáticos.
En lo referente al tamaño del texto el cual se asignará de acuerdo a la necesidad siempre
manteniendo el sentido de estética.

SISTEMAS SCADA/HMI ESTANDARIZADOS

Los sistemas SCADA/HMI estandarizados para Empresas Polar son:

1. Proficy HMI SCADA iFIX® de GE Digital

2. InTouch® de Wonderware
3. FTView® de Rockwell