DISEÑO DE PANTALLA
MIPO
Máster en Interacción Persona Ordenador
Pere Ponsa Antoni Granollers
3 Diseño de pantalla
3.1 Sala de control industrial
3.2 Ingeniería de la usabilidad aplicada al diseño de sala de control 3.3 Ergonomía aplicada al diseño de sala de control
3.4 Supervisión industrial
3.5 Guía para diseño de pantalla en supervisión 3.6 Aplicación en planta azucarera
3.7 Aplicación en campus universitario
3.5 Guía para el diseño de pantalla en supervisión
A continuación se presenta la metodología propuesta para la guía ergonómica de diseño de interfaces de supervisión (GEDIS), la cual ha sido enfocada a ambientes industriales con salas de supervisión computerizadas y centralizadas. La primera fase de GEDIS consiste en la especificación de los principales elementos de la interfaz tales como la arquitectura, la navegación los estándares de colores, fuentes, simbología, etcétera, siguiendo un orden que será propuesto más adelante en esta sección. Por otro lado, como su especificación no es el producto final de la interfaz, es necesario desarrollar las pantallas de la misma ya sea conforme se vayan definiendo los elementos o bien, al final cuando la especificación este completa. El consejo para la fase de desarrollo de las pantallas es el de seguir el primer enfoque, esto es, generar pantallas tan pronto existan elementos suficientes para iniciarlas, ya que de esta manera podemos ir depurando los prototipos y teniendo retroalimentación del producto elaborado.
3.5.1. Especificación de los Elementos de la Interfaz
Para determinar cuales son los elementos de la interfaz más importantes a definir se realizó (como se planeó en la sección anterior) una investigación documental extensa.
Después de haber establecido los elementos más relevantes, entonces se han ordenado de lo general a lo particular tal como se muestra en la figura 3.14.
Fig.3.14 Esquema general de la metodología de desarrollo de la interfaz
La secuencia que se debe seguir para la especificación de la interfaz parte de los niveles superiores de la figura 3.14 y va descendiendo hasta definir los aspectos específicos tales como la representación de los equipos, los valores analógicos, las alarmas y los comandos del operador.
Ahora bien, para cada uno de los diez pasos de la metodología descritos arriba y con la finalidad de obtener las directrices más relevantes de cada uno de ellos se aplicó el procedimiento de investigación documental descrito anteriormente, obteniéndose los siguientes resultados relativos a la especificación de los elementos de una interfaz persona-máquina en salas de control centralizadas y computerizadas para procesos industriales
Como cada proceso tiene particularidades propias, los elementos de interfaz que serán descritos no son los únicos pero si los más comunes, lo que significa que al aplicar la metodología propuesta, estos conceptos podrán enriquecerse de acuerdo a las características específicas de cada aplicación.
Arquitectura.
Para iniciar con el proceso de desarrollo el diseñador debe establecer un mapa donde se definirán de manera general las diferentes pantallas con las que contará el operador para interactuar con el sistema de automatización y control. Este mapa deberá establecer las relaciones lógicas entre las pantallas de manera que pueda también servir posteriormente al diseño de la navegación del sistema. Aunado al mapa se debe generar un listado que muestre las pantallas y su función específica. Los tipos de pantallas que deberán ser incluidas en este primer paso de la metodología son las siguientes:
Fig.3.15 Ejemplo de arquitectura y navegación entre pantallas de distintos niveles en el que se ha simplificado el detalle (no aparecen las barras de botones en las pantallas, y no se ha dibujado la
posibilidad de regresar al nivel de área desde cualquier pantalla del nivel de equipo)
Pantallas de Proceso, las cuales muestran el estado de los equipos y del proceso mismo. Estas a su vez se pueden dividir en general de planta, general de área, de detalle y de equipo. También son conocidas como mímicos o sinópticos de proceso.
Pantallas de Comandos, estas pantallas permiten al operador realizar acciones generales tales como el arranque/paro de equipos y selecciones diversas.
Pantallas de Configuración, las cuales permiten al operador y al ingeniero de proceso establecer los parámetros de configuración del sistema tales como límites de alarmas, sintonización de PID’s, calibración, recetas de producción, etc.
Pantallas de tendencias, donde se muestran las valores de las variables mas importantes del proceso en el tiempo
Pantallas de alarmas
Una consideración importante para la arquitectura de la interfaz es la cantidad de pantallas disponibles para este fin, ya que si el número de estas es mucho menor al de las áreas del proceso que se deben supervisar a la vez y con ello el operador debe cambiar muy frecuentemente de sinóptico, se deben tomar provisiones en la arquitectura y la navegación para facilitar el paso entre diferentes áreas de la planta sin requerir de muchos pasos intermedios (como puede suceder al subir en la jerarquía de la arquitectura).
Es importante notar que en este paso de la metodología solamente se establecerá que pantallas deberán desarrollarse pero NO se diseñarán propiamente. Recuérdese que el objetivo de este punto es el de generar la arquitectura del sistema y NO el de generar gráficos específicamente.
Con la finalidad de llevar a cabo la especificación de la arquitectura se sugiere las siguientes directrices:
La arquitectura en forma de mapa debe reflejar la organización de la planta
La arquitectura jerárquica basada en planta, área, subárea, equipo es la más recomendable
Es mejor definir arquitecturas anchas que profundas para que el operador pueda acceder más rápidamente la información requerida
Se recomienda también que el número de capas de la jerarquía no exceda de cuatro niveles
Resumiendo, en este punto de la metodología se deben obtener dos productos: primero, el mapa gráfico de la arquitectura que muestra las pantallas que componen el sistema y sus relaciones lógicas y segundo, el listado de las mismas pantallas con las funciones que desarrollarán cada una de ellas.
Distribución de las Pantallas.
En el segundo paso de la metodología se deben desarrollar las plantillas que regirán el desarrollo de la interfaz. Como primera actividad se deberá definir formalmente la tipología de las pantallas, esto es, se deberá establecer cuantas clases de pantallas serán desarrolladas (mientras menor el número es mejor), para posteriormente generar una plantilla general para cada una de ellas. En estas plantillas se deberán establecer los siguientes conceptos:
Ubicación del título de la pantalla, hora, fecha y logotipo de la empresa.
Si será utilizado, ubicación del menú del sistema
Ubicación de las alarmas del proceso
Ubicación del mímico del área o subárea
Ubicación de funciones genéricas, tales como confirmación de alarmas
En caso de existir elementos como tendencias, tablas, definir su ubicación
Con la finalidad de llevar a cabo la especificación de la distribución de las pantallas se sugiere las siguientes directrices:
Considerar que según el Diagrama de Gutenberg, el Movimiento del ojo va de arriba a abajo y de izquierda a derecha
Considerar entonces que la información mas importante debe ir arriba
El centro de la pantalla es también un lugar de alta visibilidad
La información miscelánea debe ir abajo a la izquierda
Sobretodo las funciones e información criticas deben tener un lugar fijo en la pantalla
La mejor posición para los gráficos es a la izquierda del campo visual
Se debe establecer una estructura de rejilla (grid) regular
Al desarrollar los prototipos de los sinópticos de proceso se debe controlar la densidad de los gráficos, la cual no debe sobrepasar del 50%, para que no se vean muy aglutinados
En este mismo sentido, la simetría del gráfico debe ser también considerada, de manera que la carga de elementos en los sinópticos este balanceada en toda la pantalla
Para el mismo nivel de información efectiva, se debe dar preferencia a las distribuciones simples sobre las complejas
Los productos que se deben obtener en esta etapa son: la tipología o clasificación de las pantallas y las plantillas para cada una de estas clases. Un ejemplo simple de una plantilla de sinópicos se muestra en la siguiente figura:
Fig.3.16 Ejemplo de una plantilla para un sinóptico de proceso
Navegación.
Con ayuda de la arquitectura definida anteriormente se debe ahora determinar como navegará el operador dentro del sistema. El objetivo es que el esquema de navegación sea intuitivo y fácil de usar, para este fin se puede utilizar alguno de los siguientes métodos sugeridos (o bien alguna combinación de ellos):
Menús y submenús
Barra de Botones
Barras de Iconos gráficos
Link con hipertexto
Link con gráficos de proceso
Teclas de Función
Cajas Combo o Listas Desplegables (‘Combo boxes’)
Actualmente se prefiere la navegación utilizando dispositivos de apuntar y pulsar (point and click) sobre la navegación soportada con el teclado, por lo que este argumento
descartaría la sexta opción de las anteriormente listadas, aunque bien puede usarse como complemento de las otras opciones. La diferencia entre barras de botones y de iconos es que estos últimos utilizan representaciones gráficas en lugar de texto para establecer su funcionalidad al usuario. Si se van a usar íconos es recomendable que estos sean simples, fáciles de reconocer y que no sobrecarguen el tamaño en bytes del gráfico para que no se pague una penalidad en tiempo de respuesta. Respecto a los menús, ligas con hipertexto y cajas combo, se debe tomar en cuenta que a diferencia de aplicaciones de escritorio, el operador debe poder hacer clic con el apuntador fácilmente, esto es, que el área de contacto sea lo suficientemente grande para que el usuario no tenga dificultades al utilizar estos medios de navegación. Dado lo anterior, los menús y los combos se recomiendan para proporcionar al operador acceso a funciones usadas con poca frecuencia. Finalmente respecto a las ligas dentro del cuerpo del gráfico de proceso, estos tienen la desventaja de ser poco intuitivos y sujetos al contexto de cada pantalla, por lo que no son recomendables.
Las siguientes directrices se deben tomar en cuenta cuando se establece la forma de navegación:
Cuando la sala de control cuenta con pocos dispositivos de visualización se deben proporcionar más medios para navegar horizontalmente de manera que el operador pueda cambiar de área frecuentemente con mayor facilidad.
La navegación no debe ser un obstáculo a las acciones del operador en situaciones de emergencia.
El área de contacto para pulsar debe ser lo suficientemente grande para que se fácil de usar. Si se usa una pantalla táctil se deben hacer las consideraciones antropométricas de los dedos índices de los operadores.
Es recomendable proporcionar al operador la posibilidad de desplazarse a la pantalla anterior o la siguiente dentro del mapa de navegación así como la de regresar al inicio del sistema y la de cierre de pantalla en los casos en que sea aplicable
Si se utilizan íconos, se recomienda proporcionar una ayuda textual ulterior al usuario (puede ser fuera de línea, o bien en línea, con una ayuda visible solamente cuando se pasa el cursor por el área de contacto para no sobrecargar el sinóptico permanentemente). Este aspecto puede mejorarse notablemente si se especifica un estándar de íconos del sistema.
Se recomienda utilizar zonas predefinidas de la pantalla para ubicar los menús, barras de botones, de íconos, botones de atrás, adelante, inicio, cierre, etc.
Dado que la navegación no es una actividad de la sensación ni de la percepción del operador, se recomienda el fondo de la pantalla como una zona factible para esta actividad.
De usarse menús estos deben ser agrupados en base a la similitud funcional de sus elementos
Los menús deben presentarse en una sola columna vertical, evitando en lo posible anidar submenús
El orden en que se muestran las opciones de los menús debe basarse en conceptos como la importancia de la función o la frecuencia de su uso
El texto que describe las funciones debe ser corto y conciso
Si favorece la claridad se pueden usar separadores entre diferentes grupos de opciones del menú
Se recomienda también proporcionar al operador el mapa general de navegación
El producto que se debe obtener de este paso de la metodología es la definición formal de él o las formas de navegación (barra de botones, de íconos, menús, etc.), los botones especiales que se utilizarán (atrás, adelante, inicio, alarmas, etc.), las zonas de la pantalla en las que serán ubicadas estas funciones, el tamaño de las barras, los botones, los menús, combos, etc, así como la definición general de los íconos en caso de que esta opción sea utilizada.
Uso del Color.
El color es uno de los elementos más importantes dentro del contexto de las interfaces persona-máquina, su uso adecuado (conservador, convencional y consistente) es determinante para la generación de una excelente interfaz.
En esta fase se deben definir los siguientes estándares referidos al color:
Color para representar el estatus de los equipos de la planta (marcha, paro, falla, manual, etc.)
Color de los principales materiales y fluidos del proceso (agua, aire, gases, materias primas, productos terminados, etc.)
Color de las alarmas (críticas, advertencias, mensajes, etc.)
Color del texto en general (Títulos, etiquetas, etc.)
Colores del fondo de la pantalla (general, de detalle, etc.)
Color de valores de proceso (Temperaturas, presiones, niveles, etc.)
Al definir cada uno de estos estándares es muy importante que sean congruentes entre ellos y que no supongan contradicciones, por ejemplo sería poco apropiado definir que el color rojo será asociado a las alarmas críticas y a su vez establecer que este color será utilizado para los títulos de la pantalla. Otro factor que se debe tomar en cuenta es tanto el perfil de los operadores, así como la observación y cumplimiento de los estándares locales, nacionales e internacionales.
Algunas directrices que se deben tomar en cuenta para la especificación del color son las siguientes:
Limitar el número de colores a cuatro para principiantes y no utilizar más de siete colores para los expertos en una pantalla y asegurase que estos sean perfectamente diferenciables entre ellos.
Cuando se combinen colores se debe maximizar el contraste entre ellos
No utilizar combinaciones con contrastes incompatibles como Rojo-Azul, Rojo- Verde, Azul-Amarillo, Amarillo-Blanco, Verde-Azul.
Debido a problemas fisiológicos que pudieran tener los operadores respecto a la distinción de colores, reforzar estos con otros elementos: texto, tamaño, forma o posición, cuando sea necesario (evitar entonces las combinaciones de texto y color del tipo texto rojo sobre fondo verde, texto azul sobre fondo amarillo)
Usar el color blanco para la información periférica
El color debe usarse para indicar calidad y no cantidad
Para que el color sea visible, se debe usar en objetos de buen tamaño
Evitar el uso de intermitencia (blink) de colores salvo en casos especiales y aislados
Cuando se llegue a usar la intermitencia, se debe proporcionar un medio al operador para detenerla una vez que ha reconocido el evento
Particularmente respecto a la selección de los colores del fondo de la pantalla se recomiendan las siguientes directrices:
Usar colores neutros para el fondo de la pantalla (gris, beige, arena, azul)
No usar blanco y negro dado que dan mucho resplandor
Los colores de fondo deben ser contrastantes con los demás elementos
El uso de diferentes colores de fondo puede ser utilizado para diferenciar o agrupar procesos o áreas de la planta
Evitar el uso de colores primarios o fuertes en zonas grandes de la pantalla
El producto que se debe obtener de esta fase de la metodología es la especificación del estándar de colores de los elementos previamente mencionados (estatus de equipos, fondo de pantalla, materiales y fluidos, alarmas, texto y valores numéricos). Es útil para los fines de documentar y distribuir la especificación del uso del color generar una tabla con la información relativa a este punto, tal como se muestra en el ejemplo de la figura 3.17:
Fig.3.17 Ejemplo de paleta de colores del sistema SCADA comercial Intouch de Wonderware
Fondos de Pantallas
Item Color Descripción Matiz/Sat/Lum Rojo/Verde/Azul
Sinópticos de Área y Subárea Arena 208/204/191 31/37/188 Detalle Máquinas Verde Oscuro 120/80/90 64/128/128
Menus y Analógicas Gris Plata 160/0/224 238/238/238
Tablas en Sinópticos Gris Plata 160/0/224 238/238/238
Estatus de Equipos de Proceso
Item Color Descripción Matiz/Sat/Lum Rojo/Verde/Azul
Equipo Parado Blanco 160/0/240 255/255/255
Equipo Trabajando Verde 80/240/53 0/113/0
Alarmas
Item Color Descripción Matiz/Sat/Lum Rojo/Verde/Azul
Alarma Crítica Rojo 0/240/120 255/0/0
Alarma de Advertencia Amarillo 40/240/120 255/255/0 Mensaje General Azul Claro 120/240/120 0/255/255
Materiales de Proceso
Item Color Descripción Matiz/Sat/Lum Rojo/Verde/Azul
Gas con Material Amarillo Claro 40/240/180 255/255/128
Aceite Café Oscuro 80/240/190 148/255/148
Agua Verde 80/240/53 0/113/0
Aire Azul Claro 120/240/120 0/255/255
Señales Analógicas
Item Color Descripción Matiz/Sat/Lum Rojo/Verde/Azul
Temperatura Marrón 0/240/46 98/0/0
Presión, Depresión Azul Rey 160/240/120 0/0/255
Potencia Violeta 200/240/60 128/0/128
Caudal Azul Marino 140/240/60 0/64/128
Velocidad Verde Oscuro 80/240/53 0/113/0
Otras Negro 160/0/0 0/0/0/
Items Varios
Item Color Descripción Matiz/Sat/Lum Rojo/Verde/Azul
Código Equipos Normal Negro 160/0/0 0/0/0/
Botón Confirmar Alarmas Amarillo Claro 40/240/180 255/255/128 Títulos de Pantallas Azul Marino 140/240/60 0/64/128
Texto Fallas Críticas Rojo 0/240/120 255/0/0
Texto Advertencias Amarillo 40/240/120 255/255/0
Texto General Azul Marino 140/240/60 0/64/128
Fig.3.18 Ejemplo de la especificación del uso del color
Información Textual.
La información del proceso es presentada al usuario por medio de varios elementos de los cuales el más comúnmente usado es el texto. Es importante regular el uso de este elemento para informar eficazmente al operador respecto al estado del proceso, por lo que se debe establecer un estándar que rija su utilización. Las características del texto que se deben definir para este fin son las siguientes: el uso de fuentes, el tamaño del texto, la alineación, el espaciamiento, los acrónimos y las abreviaturas.
Específicamente, las directrices que se deben considerar para la definición de las fuentes son las siguientes:
No se deben utilizar más de tres fuentes en la interfaz
No usar más de tres tamaños de la misma fuente
Preferentemente usar fuentes sans serif
El tamaño de la fuente debe ser tal que se pueda leer a distancia por el operador.
Una fuente menor a 8 es difícil de leer
No usar letras mayúsculas en todas las letras del texto, procurar combinarlas con las minúsculas
No utilizar énfasis en el texto (subrayado, itálico, sombreado) salvo en casos especiales
El color del texto debe contrastar con el fondo de la pantalla y debe respetar el código de colores previamente definido
Cuando se usa color en el texto se debe usar en toda la palabra y no solo en ciertos caracteres
Alinear el texto en pantalla: etiquetas a la izquierda, números a la derecha
El punto decimal siempre debe ir alineado
Utilizar el mínimo posible de alineamientos verticales
Espaciar el texto tanto horizontal como verticalmente y así evitar aglutinamientos
Sobretodo cuando se muestra información crítica, esta debe ser espaciada con suficiencia
Fig.3.19 Ejemplo de paleta de fuentes del sistema SCADA comercial Intouch de Wonderware
Como se sugirió al inicio de este párrafo el producto que se debe obtener de este paso de la metodología son los estándares de fuentes, tamaño del texto, los acrónimos y las abreviaturas, así como las directrices que se aplicarán en cuanto a la alineación y el espaciamiento.
Acrónimo Significado
LSH Nivel Alto
LSL Nivel Bajo
PSH Presión Alta o Filtro Sucio
PSL Presión Baja
TSH Temperatura Alta
TSL Temperatura Baja
FSL Flujo Bajo
ZSHH Posición Máxima
HS Paro de Cuerda en Campo SS Sensor de Rotación
ZS Desalineamiento
Tabla 3.1 Ejemplos de Acrónimos basados en el estándar ISA
En el control de procesos industriales es habitual el uso de sensores, válvulas, bombas, motores, controladores. De ahí que sea necesario especificar el estado de cada uno de estos elementos en la interfaz junto a una etiqueta de 16 caracteres máximo. Por ejemplo, se dispone de una bomba identificada como Bomba 440-BO-105 la cual puede tener como etiquetas:
440HISBO105RD (ready)
440HISBO105RM (remoto)
440HISBO105RS (estado en funcionamiento)
En el caso de una válvula con dos solenoides de abrir/cerrar identificada como Válvula 545-FV-7017 puede tener como etiquetas:
545HISFV7017RM (remoto)
545HISFV7017OS (estado de límite abierto)
545HISFV7017CS (estado de límite cerrado)
545HISFV7017OC (control abrir)
545HISFV7017CC (control cerrar)
En el caso de de un lazo de control el controlador automático se identifica como Controlador 440-FIC-7025 y puede tener las siguientes etiquetas
440FIC7025 (controlador de flujo) 440FIT7025 (sensor/transmisor de flujo) 440FV7025 (válvula de control)
de esta forma se asocia el sensor y la válvula al lazo de control y controlador correspondiente.
Estatus de los Equipos y Eventos de Proceso.
En esta fase se debe definir el estándar gráfico de símbolos e íconos que representen el estatus de los diversos equipos de la planta tales como ventiladores, bombas, bandas, válvulas, filtros, etc, así como los cambios de estado digitales (On/Off) de eventos que se requieren representar en las pantallas de proceso. Para este fin es importante recurrir a los estándares locales, nacionales o internacionales de manera que la simbología sea homogénea y fácil de reconocer y diferenciar por el operador.
Al definir estos símbolos e íconos que representen a los equipos y eventos del proceso se recomienda observar las siguientes directrices:
Deben se simples, cerrados y de un tamaño suficientemente visible
Se deben evitar detalles y realismo innecesarios
Utilizar figuras geométricas simples para definir los símbolos e íconos
Preferentemente deben ser enmarcados y delimitados con borde oscuro
Los símbolos e íconos no deben ser ambiguos
Si es el caso, se puede reforzar la señalización del estado del equipo o evento con un texto que también lo indique.
Cuando integramos los símbolos que identifican al equipo con el estatus de colores asociado definido previamente debemos obtener los objetos que representan a los dispositivos de la planta y que informan al operador su estado de manera general (trabajando, parado, en falla, advertencia, etc.).
En esta etapa de la metodología debemos obtener el catálogo de símbolos e íconos que representan cada uno de los tipos genéricos de los dispositivos que se encuentran en la planta y de los eventos discretos (On/Off) asociados al proceso. Es también en esta etapa que podemos iniciar realizando los primeros prototipos de los sinópticos de proceso, tomando en consideración lo que haya sido especificado hasta este momento.
A continuación se muestra un ejemplo de una tabla de símbolos de algunos equipos de proceso comunes y además en el anexo A se muestran ejemplos de simbología de equipos del estándar 5.5 de la ISA.
Símbolo Descripción
Banda Transportadora Ventilador Bomba Hidráulica
Válvula On/Off Tolva Soplador Motor Eléctrico Válvula de Control
Fig.3.20 Ejemplo de la especificación de símbolos de los equipos de proceso
Fig.3.21 Ejemplo de símbolos del sistema SCADA comercial Intouch de Wonderware
Información y Valores de Proceso.
El despliegue de los datos analógicos de proceso es una de las maneras más importantes con las que se informa al operador sobre el estado de la planta, ya sean valores directos del campo o bien procesados por el sistema. La representación en las pantallas de estas variables se lleva a cabo principalmente en dos modalidades: en los gráficos o mímicos de proceso, o bien en tablas y gráficos de tendencias; estos últimos se analizarán en el
siguiente paso de la metodología. El propósito de mostrar estos datos al operador es el de informarlo eficazmente para que logre sus objetivos, lo que significa que debemos visualizar el conjunto de dato mínimo que le muestre el estado actual de la planta y además estos datos deben ser desplegados de tal forma que realmente tengan significado con respecto al proceso. Puede haber datos que informan por si solos, pero hay otros que únicamente tienen significado cuando se comparan o acompañan con otros.
También existen otros que solo vale la pena conocerlos en un contexto o estatus de la planta determinado, como puede ser al arranque de los equipos o cuando rebasan un cierto límite de alarma. Finalmente y como se analizará en la siguiente etapa de esta metodología, hay variables que se deben observar en cuanto a su tendencia en el tiempo junto con otras variables.
El principal problema en el que podemos caer cuando insertamos valores en los mímicos de proceso es el de sobrecargar al operador con una gran cantidad de datos y pero aún desperdigarlos sin sentido. Es por este motivo que primero debemos clasificar los valores, para después decidir como los debemos mostrar al usuario. La clasificación que se propone es la siguiente:
Datos de conducción de una área de la planta
Datos relativos a la seguridad de la planta
Datos relativos a las alarmas de proceso que causan paros de producción
Datos relativos a las alarmas de proceso que NO causan paros de producción
Datos relativos a alarmas de dispositivos
Datos estadísticos del área
Datos estadísticos de los equipos individuales
En algunos casos, por ejemplo, para los valores relativos a alarmas de los dispositivos y en caso de que exista una situación anómala, se puede cambiar el estatus de ese equipo a advertencia y entonces el operador deberá proceder a investigar más a fondo la condición anormal accediendo a la ventana de detalle respectiva.
El segundo paso dentro de esta fase es la de agrupar los valores cuya relación implique que se deban mostrar juntos, por ejemplo,
Grupo 1. Temperaturas de devanados y cojinetes del motor ‘x’
Grupo 2. Vibraciones del ventilador ‘y’
Grupo 3. Producción, descartes y eficiencia del área ‘z’
Es importante notar que los grupos de datos deben contener valores cuya clasificación sea del mismo nivel, esto es, datos de conducción, datos de seguridad, etc, de manera que puedan ser desplegados en un mismo sinóptico, sea general o de detalle, si esto no es así, se debe revisar la clasificación realizada previamente.
Una vez que sabemos que variables deben ser mostradas en que gráficos y además cuales deben ser desplegadas agrupadas con otras, debemos proceder a ubicarlas dentro de los sinópticos de proceso. En términos generales debemos seguir las siguientes directrices que son compatibles con las relativas a la distribución de las pantallas:
Los datos relativos a la seguridad de la instalación debe ubicarse en zonas de mayor visibilidad, esto es, en la parte superior o central de la pantalla
Los datos relativos a la conducción del proceso o a las alarmas que causan paro de la producción se deben situar en una zona cercana a sus equipos respectivos o en zonas que sugieren su instalación física en la planta, pero NO en el área inferior izquierda de la pantalla
Los datos estadísticos de producción se pueden ubicar en zonas de menos visibilidad, como puede tratarse del área inferior de la pantalla
Los demás datos se deben ubicar en las pantallas de detalle y como se sugirió previamente pueden provocar un cambio de estado en los equipos en la pantalla principal, o bien, pueden causar la aparición de una bandera o texto, en caso que el operador deba investigar más a fondo una situación anómala relativa. Sin embargo, este tipo de datos no se debe mostrar permanentemente al usuario.
A continuación se sugieren otras directrices también relativas al despliegue de los valores de la planta:
Respetar y aplicar los estándares previamente definidos respecto al color y la información textual
Evitar el uso de decimales poco significativos
Si es apropiado y da mejor comprensión al operador, usar barras dinámicas horizontales o verticales para mostrar los valores analógicos, además del valor numérico relativo
En caso de utilizar estas barras dinámicas además de etiquetarlas claramente, hay que asegurarse de mostrar su escala
Si se muestran varias barras dinámicas con motivos de comparaciones es importante normalizar las escalas y utilizar diferentes colores para los diversos valores
Es importante que el operador pueda determinar en todo momento las unidades de ingeniería de los datos numéricos pero no necesariamente se deben mostrar siempre
Para resaltar valores se puede aplicar un cambio de color de su fondo o bien enmarcarlo con un borde negro
Otros efectos como el cambio dinámico de tamaño y posición se deben usar en casos muy específicos y esporádicos para evitar sobrecargar al usuario con información
Otras directrices para la creación y visualización de grupos de valores son las siguientes:
Los grupos de datos se deben establecer cuando se requiere mostrar comparaciones, causalidades o integración de los datos
Es recomendable separar y/o enmarcar los grupos de datos para visualizarlos
Cuando existen varias tablas con datos cualitativamente similares, pero aplicadas a diferentes áreas o equipos, se debe mantener el mismo orden dentro de ellas.
Preferentemente agrupar valores en conjuntos de menos de 9 datos
El concepto de cada grupo de datos debe ser claro para el operador, si es necesario se debe etiquetar
Dentro del grupo se debe ordenar los datos por alguno de los siguientes criterios:
Importancia, frecuencia de uso, secuencia, función, tipo o bien alfabéticamente
De esta fase de la metodología debemos obtener la lista clasificada de valores analógicos de la planta y los grupos de datos relacionados. También en este punto debemos empezar a afinar los prototipos iniciados en la fase anterior agregando los datos analógicos a las pantallas.
Fig.3.22 Ejemplo de distribución de mímicos, históricos y grupos de datos relacionados. En algunos casos el mímico y el gráfico de históricos se distribuyen a la izquierda y derecha dentro del Sinóptico. En el ejemplo, tan solo se muestra el mímico, y para acceder al gráfico histórico hay que utilizar los botones del Submenú. En muchas ocasiones el valor analógico se dispone al lado del símbolo gráfico, aunque hay que reconocer que la agrupación de datos asociados al modelo físico-matemático del componente o equipo,
puede facilitar la toma de decisión del operario
Gráficos de Tendencias y Tablas.
Los gráficos de tendencias y las tablas son los principales medios de agrupamiento de las variables para crear esquemas informativos para el usuario. Para crear los grupos de valores que compondrán los diversos gráficos de tendencias es recomendable partir de los definidos en la etapa anterior y de ahí depurarlos, ya sea uniendo varios grupos, o bien creando nuevos. El establecimiento de los grupos de tendencias no elimina ni modifica los definidos en la etapa siete, sino que crea un nuevo catalogo exclusivo para este tipo de gráficos.
Como es común que los sistemas SCADA proporcionen un ambiente específico para las tendencias, debemos decidir si estos grupos deben pertenecer exclusivamente a este
ambiente, o bien si debemos insertarlo también en los sinópticos de proceso. La ventaja de este último enfoque es el de proveer al operador un panorama más completo de la situación de la planta, mostrándole además de los equipos y valores puntuales, los datos que requieren una interpretación en el transcurso del tiempo. Aún tomando esta opción se debe respetar lo dispuesto en el punto precedente respecto a la clasificación de los datos y su despliegue en las pantallas generales y de detalle para no abrumar al usuario con información inútil. Cuando tenemos varios grupos de tendencias es mejor mostrarlos en el ambiente del sistema SCADA respectivo, permitiendo al operador seleccionar cuales de ellos desplegar para su análisis.
Las siguientes directrices se pueden aplicar cuando se especifican los gráficos de tendencias:
No poner más de 9 variables en una sola grafica
Diferenciar los datos con diferentes colores y tipos de línea
Asegurarse que los rangos del grafico sean adecuados para la operación
Mostrar el mínimo y máximo para cada variable
Incrementar las escalas de abajo hacia arriba o de izquierda a derecha
Usar una rejilla tenue (grid) para ayudar al operador.
Las divisiones de la rejilla deben ser comunes tales como 1, 2, 5 o 10 unidades
Permitir al operador visualizar los valores numéricos de los datos en el tiempo
Etiquetar los ejes y puntos graficados
Permitir al operador cambiar el tamaño de la ventana en el tiempo y la fecha de inicio
Permitir al operador quitar temporalmente algunas variables de la tendencia
Las tablas de datos son otros elementos que como ya se mencionó se utilizan para agrupar información relacionada, en los sinópticos se usan principalmente para mostrar resúmenes de diversos tópicos referentes al proceso y su finalidad es la de mostrar un esquema informativo completo al usuario. Las directrices que se pueden aplicar respecto a las tablas de datos son las siguientes:
Es recomendable distinguir las tablas utilizando un color de fondo diverso al de la pantalla
Para separar las celdas usar una rejilla (grid) tenue pero distinguible para el usuario
Titular claramente la tabla
Ordenar las filas y columnas de la tabla por alguno(s) de(l) (los) siguiente(s) criterio(s): Importancia, Frecuencia de uso, Función, Tipo, Tiempo o Alfabéticamente
La ubicación de la tabla debe seguir los criterios de posicionamiento según la importancia de la información
Si la tabla debe contener una gran cantidad de renglones y columnas, es mejor dedicarle una pantalla de detalle en lugar de ponerla junto a los sinópticos de proceso
En resumen, de esta fase de la metodología se deben obtener los grupos de tendencias y la definición de las tablas de datos que serán mostradas al operador. Con ellos se deben
seguir afinando los prototipos de las pantallas de los sinópticos de proceso iniciadas en el paso 7 e iniciar la definición de los prototipos de las pantallas de tendencias.
Fig.3.23 Ejemplo de gráfico de históricos que recoge y agrupa la evolución temporal de las variables asociadas a un reactor químico (temperatura, nivel, cantidad de producto acumulado) junto a la referencia
(setpoint)
Comandos e Ingreso de Datos.
En esta fase de la metodología de la interfaz, se establece la intervención del operador al suministra datos al sistema de manera que este se comporte de acuerdo a sus objetivos.
Normalmente, las operaciones que efectúa el usuario son: ejecutar comandos, seleccionar opciones e ingresar datos de consigna y parámetros del proceso, aparte del reconocimiento de alarmas que será analizado en el punto siguiente. Las características principales que deben tener los comandos son su visibilidad y su facilidad de operación.
Para cumplir con estos dos requisitos es imprescindible que su área de acción en pantalla sea de buen tamaño, perfectamente etiquetada y por ello reconocible fácilmente por el usuario. Cuando el área de acción (que es la zona donde el usuario debe pulsar) es pequeña se tiene el riesgo que el operador encuentre dificultades o inclusive termine pulsando áreas fuera del comando en cuestión. Otra característica importante es la No- modalidad de los comandos, lo cual significa que estos deben tener el mismo significado sin importar el estado actual del sistema. Por ejemplo, si el significado de un comando cambia dependiendo si una secuencia de máquinas esta arrancando o parando, el usuario deberá estar conciente de este hecho para comprender cual será el resultado de su acción. Finalmente, una característica clave de los comandos e ingreso de datos por parte del operador es la retroalimentación, lo cual implica, que el usuario debe recibir una respuesta del sistema (positiva o negativa) inmediatamente después que ha efectuado una acción.
La ubicación de los comandos e ingreso de datos se puede establecer ya sea en pantallas específicamente diseñadas para este fin, pueden ser localizados junto con los sinópticos de proceso, o bien considerando una mezcla de ambos conceptos. Se recomienda ubicar los comandos y el ingreso de datos en los sinópticos de proceso cuando estos son críticos para la operación de la planta o su uso es muy frecuente, de tal manera que el usuario no tenga que estar cambiando pantalla a cada momento. Sin embargo, nuevamente hay que considerar la posibilidad de no saturar la pantalla con datos que no sean esenciales para la consecución de los objetivos del operador.
Es también importante clasificar los tipos de comandos que emiten los operadores de tal suerte que se les asocien objetos estandarizados. Una posible clasificación de los comandos es la siguiente:
Comandos de Arranque y Paro, tanto de áreas completas como de equipos individuales.
Confirmación de Alarmas (Ack)
Selección excluyente de una opción (una sola entre varias opciones)
Selección múltiple No-excluyente (más de una entre varias opciones)
Selección simple (Aceptar o no una opción)
Asociar un objeto típico a cada una de estos comandos ayuda al operador a esquematizar fácilmente sus acciones de forma tal que cuando las ejecute no requiera redescubrir su lógica de funcionamiento.
Algunas directrices para especificar los comandos del operador se mencionan a continuación:
Los comandos deben ser claramente visibles para el operador
Los comandos deben estar claramente etiquetados
El área de acción sobre el comando debe ser suficientemente grande como para que sea fácilmente operado
Los diferentes tipos de comandos deben representarse siempre con los mismos tipos de botones para que el operador los identifique rápidamente
El operador debe ser retroalimentado inmediatamente del resultado de su acción
Los comandos cualitativamente similares deben dar retroalimentación similar
Los comandos que activan una acción crítica o de riesgo deben estar claramente etiquetadas y no deben estar cerca de comandos de uso frecuente
Para el ingreso de datos, se sugiere seguir las directrices que se mencionan a continuación:
Al igual que los comandos, el ingreso de datos debe ser visible, identificable claramente y de tamaño adecuado
El operador debe confirmar con el botón de entrada o con un botón de pantalla antes de aceptar el ingreso de cada dato
A su vez se debe confirmar al operador que el dato ha sido aceptado por la interfaz
Otra modalidad de comunicación con el operador es a través de cajas de diálogos las cuales solicitan datos o respuestas al usuario. Las directrices asociadas a las cajas de diálogo son las siguientes:
Los diálogos se deben mostrar al operador como consecuencia de una acción de él
Los diálogos deben ser concisos y claros.
Los diálogos se deben situar en una parte de la pantalla donde no interfieran con los datos de proceso, esto es, preferentemente en la zona inferior
Solamente cuando el dialogo es de carácter critico se debe mostrar al centro
Los diálogos de confirmación de las acciones del operador se deben mostrar solamente cuando se trate de operaciones críticas y/o irreversibles.
Al igual que las plantillas de los gráficos principales, los diálogos se deben tipificar y estandarizar para que sean fácilmente identificables
El producto que se debe obtener de esta fase de la metodología son los estándares de los botones de comando y selecciones, el estándar de ingreso de datos y las plantillas de los diálogos. Con estas especificaciones en mano es posible iniciar con el desarrollo de los prototipos de las pantallas de comandos y configuración. También en el caso de que se deban agregar comandos, selecciones e ingreso de datos en los sinópticos de proceso cuyo desarrollo ya había iniciado, este es el momento de complementar estos prototipos.
Comando Descripción Retroalimentacion
Comando de Arranque Cambio de color del Boton y/o Texto Comando de Paro Cambio de color del Boton y/o Texto Paro de Emergencia del Área Cambio de color del Boton y Texto
Confirma Alarmas Supresion de señal Auditiva Seleccion Excluyente Visibilidad de un circulo interno Seleccion Independiente Visibilidad de una '√' interna Fig.3.24 Ejemplo de la especificación de comandos del operador
Fig.3.25 Ejemplo de localización de zona en Sinóptico para entrada de comandos por parte del operario.
En algunas ocasiones, dentro del mímico se obtiene una ventana desplegable de los parámetros del controlador (consigna, y parámetros del PID) de manera que la entrada de comandos se produce al lado
de los símbolos
Fig.3.26 Ejemplo de diversas posibilidades de entradas de comandos en objetos del sistema SCADA comercial Intouch
Alarmas.
Las alarmas junto con la representación del estatus de los equipos y de los valores analógicos del sistema constituyen los principales elementos con los que se informa al operador sobre el estado de la planta. Las alarmas son muy importantes ya que alertan al operador sobre las situaciones anómalas que se presentan en el proceso e implican una intervención de el. En caso de que exista una situación informativa que no requiera una intervención del usuario, entonces será definido como un mensaje en vez de una alarma.
Alarmas y mensajes se deben clasificar por prioridades en cuanto a su criticidad:
Críticas: las cuales amenazan la seguridad de la planta y/o que pueden implicar la detención de la producción
Advertencias: las cuales se pueden convertir potencialmente en situaciones críticas después de un tiempo si el evento que originó la advertencia continúa empeorando el estado del equipo. Se puede considerar también una advertencia cuando se presenta una situación que afecta negativamente la conducción óptima de la planta
Mensaje: eventos que conviene transmitir al operador pero no representan una amenaza a la conducción del equipo, a la producción o a la seguridad de la planta
Las directrices que de manera general deben observarse al definir las alarmas son las siguientes:
Los mensajes y las alarmas deben ser congruentes con los estándares de color, fuentes, texto, tamaño, espaciamiento y alineamiento predefinidos
Se debe evitar el exceso de alarmas y mensajes superfluos al operador
En cambio, para constatar el reconocimiento de la situación, el operario debe validar las alarmas criticas (Ack)
El código de colores de alarmas debe complementarse son otros elementos como un icono, la visibilidad de un texto, su posición en pantalla o un sonido
De manera general las directrices que se deben considerar para ubicar la pantalla de alarmas son las siguientes:
La ventana o zona de alarmas debe ser distinguible por el operador y debe estar preferentemente siempre presente y visible
En caso que no puedan estar fijas siempre, se deben poder acceder de manera inmediata o mostrarse automáticamente al presentarse una nueva alarma
Los mensajes en cambio no deben ser mostrados todo el tiempo pero se debe poder acceder a ellos fácilmente
Asimismo la representación de las alarmas y mensajes se deben guiar por las siguientes directrices:
El texto de las alarmas debe mostrar el área/equipo concreto, la condición o parámetro anómalo, la prioridad, además de la hora y fecha del evento
En todo caso el texto debe ser conciso y claro
Las alarmas de mas alta prioridad (critica) deben aparecer en la parte superior de la ventana o zona de alarmas
Es recomendable asociar sonidos a las alarmas que requieren una intervención del operador
Los sonidos mas agudos y de frecuencias altas deben asignarse a alarmas de prioridad mayor ya que llaman mas la atención del operador
Al reconocer la alarma el sonido asociado debe detenerse aun si la situación anómala aun permanece
Las alarmas se deben mostrar agrupadas lógicamente a parte de su prioridad y cronología, ya sea por área, subárea, equipos, etc.
Las alarmas tienen normalmente un componente textual en su ventana y uno grafico en el sinóptico de proceso respectivo
Los cambios de estado en las pantallas de proceso deben corresponder a lo mostrado en la ventana de alarmas, para confirmar al operador lo sucedido además de permitirle visualizarlas con un mejor contexto
No se recomienda el uso de intermitencia (blinking) para mostrar las alarmas ni en la pantalla de proceso ni en la ventana de textos de las mismas salvo en casos excepcionales
El operador debe poder reconocer las alarmas fácilmente y sin tener que desplazarse de su zona actual de trabajo
Resumiendo, en esta etapa se deben establecer las características principales del sistema de alarmas y mensajes al operador, el esquema de sus prioridades, la ubicación del listado de alarmas (si no había sido definida durante la fase de especificación de la distribución de la pantalla) y completar la simbología relativa a la representación de las alarmas y mensajes sobre los sinópticos de proceso. En relación al desarrollo específico de la interfaz, en esta fase se deben finalizar los prototipos de los sinópticos de proceso a parte de definir los prototipos de la ventana del sistema de alarmas.
Fig.3.27 Ejemplo de display de alarmas del sistema SCADA Intouch. Se trata de un ActiveX que permite conocer el tipo de alarmas, el instante en que se produce, si el operario la ha reconocido, los límites de la
alarma (muy baja, baja, alta, muy alta)
Fig.3.28 Ejemplo de ventana emergente faceplate que permite configurar los límites numéricos de alarmas asociadas a una variable del sistema SCADA Intouch.
3.5.2. Evaluación de la Interfaz
Los diez indicadores pueden agruparse en una tabla de forma que el operario encargado de aplicar la guía GEDIS pueda medir cada uno de ellos para obtener un índice global.
Medida del Indicador
Cada uno de los indicadores de la Tabla 2 puede descomponerse en diversos subindicadores. Por ejemplo, el indicador Uso del Color puede detallarse en: visibilidad (3), contraste con el fondo (4), número de colores (4), diferenciabilidad entre colores (3), uso de colores típicos (rojo, verde, amarillo) (2), consistencia (4). Para cada subindicador se recomienda se puntúe numéricamente en una escala de 1 a 5. En este ejemplo el número de subindicadores del indicador Uso del Color es J= 6
J Subind indicador
Valor
J
j
1 _
(1)
El valor medio que se obtiene mediante la fórmula 1 con estos valores es de 2,83. Si se redondea el valor es 3, de manera que al indicador Uso del Color se le asigna el valor 3 en este ejemplo.
Medida de Evaluación Global
Cada uno de los indicadores de la Tabla 2 se mide en una escala de 1 a 5. El experto dispone en este punto de información concreta sobre el indicador, de forma que ya puede valorar las necesidades de mejora. Los valores de los indicadores pueden agruparse de manera que la guía GEDIS ofrezca la evaluación global de la interfaz y pueda ser comparada con otras. En una primera aproximación se ha considerado el valor medio entre indicadores expresado en la fórmula 2. Es decir, a cada indicador se le
asigna un peso idéntico (pi= p2 …=p10= 1) aunque ello permitirá en futuros estudios valorar la importancia de algunos indicadores por encima de otros. La evaluación global se expresa en una escala de 1 a 5. Atendiendo a la complejidad de los sistemas de supervisión industrial y al hecho de que un diseño ineficaz de la interfaz puede provocar el error humano, la evaluación global de una interfaz de supervisión debería situarse en un valor inicial de 3-4 y proponer medidas de mejora para acercarse al 5.
10 1 10
_ 1
i i i
i i
p ind p global
Eval (2)
3.6 Aplicación en planta azucarera
El proceso seguido en esta investigación consiste en aplicar la guía GEDIS al simulador de entrenamiento de operarios del CTA. El trabajo se ha realizado sin la intervención de expertos del CTA, ello significa que en algunos aspectos no se ha podido completar algunos indicadores.
Este simulador es utilizado principalmente como herramienta de capacitación de operadores de este tipo de industrias utilizando un sistema SCADA específicamente diseñado para este objetivo. Analizando casos prácticos como este se puede verificar los conceptos que se han desarrollado en el apartado 3.1 y se puede también valorar su potencialidad. Como se mencionó previamente uno de los objetivos de contar con una metodología sistemática para el desarrollo de interfaces hombre-máquina en ambiente industrial es poder diseñarlas y realizarlas desde su inicio, o sea, desde cero. Sin embargo, el contar con este procedimiento nos permite también evaluar interfaces existentes aplicándole un análisis cognitivo estructurado, pudiendo así emitir juicios y/o recomendaciones respecto a ese producto. Los módulos que serán analizados del simulador dado que son los que se tienen disponibles son los siguientes: Evaporación, Difusión y Calderas. Una aclaración a notar es el hecho de que los comentarios subsecuentes se harán con relación a la operación del proceso y no con respecto a la simulación de fallas por parte del instructor, ya que esta aplicación SCADA tiene esta posibilidad.
A continuación se muestra la tabla con cada uno de los indicadores y la Evaluación Global. En algunos casos es imprescindible la colaboración con el experto del proceso para poder dictaminar un valor numérico concreto.
Elemento Evaluacion Comentarios
1. Arquitectura 5
1.1. Correspondencia con la Planta 5
1.2. Numero de Capas 5
2. Distribución 3
2.1. Consistencia 3 Faltan plantillas de distribucion
2.2. Densidad 3 Alta en los graficos generales
2.3. Simetria y Balance 5
2.4. Flujo de Proceso 3 En general no es claro
3. Navegación 3
3.1 Correspondencia c/arquitectura 5
3.2. Accesibilidad 4 No se sabe que botones usar
3.3. Consistencia 3 Los botones estan dispersos en pantalla
4. Uso del color 3
4.1. Visibilidad 3 Sobretodo en equipos de proceso
4.2. Contraste con el fondo 4
4.3. Numero de colores 4
4.4. Diferenciabilidad entre colores 3 Problemas entre lineas de flujo y equipos 4.5. Uso de colores tipicos(rojo, verde, amarillo) 2 Exceso de uso del color rojo
4.6. Consistencia 4
5. Info. Textual 4
5.1. Numero de fuentes 5
5.2. Numero de tamaños 4
5.3. Visibilidad del texto 3 Sobretodo en valores numericos
5.4. Espaciamiento 5
5.5. Alineacion 5
5.6. Uso del enfasis 4
5.7. Uso de acronimos 4
5.8. Coloración del texto 3 Texto de flujos no codificado con el color
5.9. Consistencia 4
6. Simbolos y representacion de los equipos 4
6.1. Facilidad de reconocimiento 5
6.2. Visibilidad del estado del equipo 3 En algunos casos, no se nota el estado
6.3. Consistencia 5
7. Valores de proceso 3
7.1. Visibilidad 3 Numeros dificiles de ver a distancia
7.2. Ubicación ? Verificar con un experto del proceso
7.3. Distribucion 4
7.4. Agrupación de datos 2 Practicamente no existe
7.5. Consistencia 4
8. Tablas y Grupos de Tendencia 4
8.1. Formato 5
8.2. Visibilidad 5
8.3. Ubicacion 5
8.4. Agrupacion 2 Practicamente no existe
8.5. Flexibilidad de configuracion tendencias 4
8.6. Consistencia 5
9. Comandos e Ingreso de Datos 3
9.1. Visibilidad 2 No se aprecia lo que se puede comandar
9.2. Maniobrabilidad 3 Falta mas area de contacto del comando
9.3. Retroalimentación 3 Falta interactividad
9.4. Consistencia 4
10. Alarmas 3
10.1. Visibilidad de la ventana de alarmas 5 10.2. Accesibilidad de la ventana de alarmas 5 10.3. Ubicacion de la ventana de alarmas 5
10.4. Informatividad de los textos de alarmas 2 Falta mas info. relativa al evento 10.5. Visibilidad de alarmas en sinopticos 3 Exceso de color rojo filtra las indicaciones
10.6. Facilidad de reconocimiento 4
10.7. Consistencia 5
Evaluacion Global 3.5
Tabla.3.2 Evaluación del simulador del CTA mediante la guía GEDIS
A continuación se mostrarán tres ejemplos de los gráficos del simulador modificados a partir de los resultados de aplicar la guía GEDIS. En algunos casos las mejoras requieren la intervención de un experto del proceso que pueda guiar al diseñador de la interfaz en aspectos como la agrupación de valores, las tablas de datos, los valores principales de conducción de la planta, etc.
Los elementos que si fueron modificados son los siguientes:
- Barra de navegación. La barra fue localizada en la misma zona de la pantalla (parte inferior).
- Títulos de pantallas. Fueron ubicados en la misma zona de la pantalla (parte superior central).
- Botones de navegación. Se cambió el color del borde a un color diverso del rojo (azul).
- Coloración de textos estandarizada. El color de los textos se modificó para dar más información al operador:
Blanco : Entrada al proceso Azul : Salida del proceso Amarillo : Flujo interno
- Coloración de valores de proceso estandarizada. El color de algunas variables numéricas se modificó, específicamente las que usaban color rojo se cambiaron a verde.
- Manejo de fuentes y tamaños. Se uniformó la fuente de los textos, el uso de las negritas y el tamaño.
- Tamaño de los caracteres numéricos. Se aumentó el tamaño y el grosor (este último usando negritas) de los valores numéricos para tener una mejor visibilidad.
- Uso de barras dinámicas. Se utilizaron barras dinámicas para representar los niveles de material en tanques, para dar una mejor percepción de su estado al primer vistazo.
- Representación de equipos. Se aumentó el tamaño de algunos equipos (como las bombas) y se utilizaron colores más brillantes para representar que un dispositivo esta trabajando y así dar una mejor visibilidad de su estado. En el gráfico de evaporación se ejemplifica también la posibilidad de rellenar con verde (en este caso) el cuerpo entero de los equipos, como lo es el equipo denominado ‘IB”, para mostrar como sobresale su estado usando el color en elementos de mayor tamaño.
En el caso de la pantalla principal de evaporación se anexo un cuadro resumen del proceso, como ejemplo del uso de esta herramienta para dar información global al operador.
Ahora se mencionan algunos otros puntos específicos que se pueden mejorar con la asesoría de un experto del proceso y una mejor herramienta de diseño:
- El color rojo de los caudales de vapor son todavía muy agresivos y además pueden arruinar el concepto de llamar la atención del operador rápidamente con el uso de este color. Convendría reevaluar su uso y cambiarlo por otro.
- Es importante ubicar correctamente los valores de proceso en los sinópticos generales y los de detalle. Con la ayuda de un experto del proceso sería bueno revisar como han sido distribuidos actualmente y en su caso reubicarlos.
- Otro punto a verificar es el de la densidad de las pantallas, por este motivo se requiere puntualizar el inciso anterior y en su caso suprimir variables de importancia menor de las pantallas generales.
- Se requiere proporcionar al operador información agrupada condensada e índices de operación para darle una mejor panorámica de la planta. Habría que crear grupos y tablas con datos e índices relevantes que cumplan este objetivo. En este punto también se requiere la ayuda de un ingeniero de proceso.
- Igual sucede con los gráficos de tendencia, se requiere crear grupos con variables relacionadas que le den una mejor visión del proceso al operador.
- Otro factor a verificar es el de los comandos del operador. No se identificaron claramente cuales son los comandos disponibles para el manejo de la planta
(arranque/paro/selecciones), por lo que sería conveniente definir un mejor estándar para interactuar con el usuario en este sentido.
- Finalmente, los textos de las alarmas no muestran suficiente información al operador acerca del evento anómalo. Se requiere revisarlos y profundizar la explicación. También sería importante clasificar las alarmas en función de su prioridad, para informar mejor al usuario respecto a la gravedad de la situación.
1 Gráfico de difusión original
2 Gráfico de difusión modificado
3. Gráfico de Evaporación Original
4. Gráfico de Evaporación Modificado
5. Gráfico del Efecto III Original
6. Gráfico del Efecto III Modificado
3.7 Aplicación en campus universitario
A partir de las instalaciones S.A.F. de la Universitat Autònoma de Barcelona, se generó el control y la monitorización mediante el sistema SCADA Intouch. A continuación se comenta la aplicación de la guía GEDIS sobre la interfaz del S.A.F. Se presentan algunos casos abordados por los estudiantes de ingeniería del centro EPSEVG que aplicaron la guía GEDIS sobre la interfaz del S.A.F.
3.7.1 Estudio de casos
Mediante las páginas ofrecidas por la UAB se han investigado y analizado distintos procesos que entran en juego en este sistema como pueden ser el control del tratamiento del agua:
la depuración y desinfección del agua mediante Ozono (O3)
la regulación de variables como cloro
control del pH
A nuestro grupo de prácticas se nos ha asignado analizar y evaluar de manera crítica la aplicación del sistema SCADA para SAF centrándonos básicamente en lo relacionado a comandos e ingreso de datos.
Realmente tenemos que decir, que la valoración en el tema a analizar, no es muy positiva, ya que hemos encontrado varios aspectos a mejorar. Decir también que para el análisis nos hemos guiado de la guía GEDIS, estudiada en clase.
Nos hemos centrado en valorar puntos en relación a ejecutar comandos, seleccionar opciones e ingresar datos de consigna y parámetros del proceso finalizando con el reconocimiento de alarmas.
El primer paso que hemos realizado, es el de entrar y navegar a través de la aplicación para ubicarnos y tener una idea general de la aplicación. En las dos primeras pasadas, que han sido de forma rápida, no nos hemos encontrado con ningún botón que nos sirviera para introducir comandos, por lo que el primer punto que nos gustaría mencionar, sería la falta de visibilidad para el operario.
Analizaremos exhaustivamente las partes donde la aplicación permite al operario introducir datos, ya que nos encontramos con pocos casos.
1º CASO:
En la figura podemos ver la pantalla principal de la aplicación. Observamos (enmarcado en rojo) que el usuario tiene opción de registrarse o salir del registro con los comandos
‘LOG ON’ y ‘LOG OUT’. En nuestra opinión esta información debería de estar más resaltada que las demás opciones, de algún otro color por ejemplo, ya que sino el usuario podría empezar navegando por la aplicación pero sin registrarse, perdiendo así datos ya que al no estar registrado la aplicación no muestra todos los datos de los que dispone, echo que nos ocurrió a nosotros mismo, por ello hablamos de la experiencia propia.
Por otro lado, comentar que el hecho de que el diseñador halla tenido en cuenta que diferentes tipos de usuarios es un punto positivo ya que puede que no les interese que toso el mundo pueda acceder a todos los datos.
Pantalla principal de la aplicación
2º CASO
En la figura vemos la pantalla de control de distintas áreas o zonas exteriores como el rocódromo, el campo de hierba artificial o el frontón. Es visible el desalineamiento de los controles así como la apariencia en general.
Por otro lado es difícil de visualizar cualquier situación de alarmas así como la navegación hasta la correspondiente pantalla de las alarmas, al igual que la dificultad de operación.
No se puede analizar el hecho de que haya o no retroalimentación, ya que estamos trabajando con un simulador y por tanto no podemos introducir datos. En las alarmas, por el contrario (en el siguiente caso está mejor explicado) si que podemos actuar aún trabajando con el simulador y se puede ver claramente que no se hace uso de ningún tipo de retroalimentación, punto cuestionable para una adecuada seguridad.
No pone el nombre de la pantalla donde estamos para podernos ubicar al usuario en la aplicación SCADA.
Pantalla de control de distintos complejos exteriores.
3º CASO
En esta imagen, vemos la pantalla de alarmas, cuya navegación y llegada a ella no ha resultado nada fácil ni intuitiva, característica imprescindible a nuestro juicio para todo sistema de control.
Centrándonos en puntos concretos, llama la atención el hecho de no poder realizar ninguna validación del estado de las alarmas.
Tras investigar la pantalla, se ha encontrado una posible alternativa para realizar la validación de las alarmas aunque con los siguientes puntos a cuestionar:
No es intuitivo.
Difícil de entender para todo el personal (idioma).
Necesidad de un botón más visible y accesible.
Posibilidad de introducir comentarios como ventaja a la hora de su comprensión.
Sistema de validación de alarmas actual.
Creación de comentarios.
4º CASO Campo de hierba:
En este caso, los puntos observados han sido los siguientes:
Mala estructuración del espacio de la pantalla
Mensajes superpuestos
Fotos de mala calidad (reflejos de focos…) y poca visibilidad
No indica al operario en qué lugar está para así poder ubicarse en la misma aplicación SCADA.
Podría haber realimentación en casos muy concretos que requieran un riesgo importante. Ya que si en cada ingresemos datos pusiéramos retroalimentación, el operario podría adquirir una errónea dinámica de clicar dos veces inconscientemente, sin tener en cuenta la responsabilidad que pueda acarreas su acto.
Pantalla de control del campo de hierba.
6º CASO: Indicaciones erróneas y confusas en la navegación.
Por el contrario, y estando al mismo nivel dentro de la organización del sistema SCADA, podemos ver como en la pantalla de Vestuarios – Ventilación el botón de retorno se corresponde al denominado Polideportivo que nos devolvería al menú principal, lo que es algo erróneo y que da pie a posibles confusiones.
Pantallas de control de distintas secciones de la piscina.
Pantalla de control de otra sección de la piscina.
