DISEÑO DE PANTALLA - epsevg.upc.edu

Diseño Industrial

DISEÑO DE PANTALLA

MIPO Máster en Interacción Persona Ordenador

Pere PonsaAntoni Granollers

2/46

Diseño Industrial. Pere Ponsa, Toni Granollers Diseño de pantalla

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.

3/46


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:

4/46


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.

5/46


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

6/46


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

7/46


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ú

8/46


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

9/46


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

10/46


Fondos de Pantallas Item ColorDescripción Matiz/Sat/Lum Rojo/Verde/AzulSinó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 ColorDescripción Matiz/Sat/Lum Rojo/Verde/AzulEquipo Parado Blanco 160/0/240 255/255/255 Equipo Trabajando Verde 80/240/53 0/113/0 Alarmas Item ColorDescripción Matiz/Sat/Lum Rojo/Verde/AzulAlarma 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 ColorDescripción Matiz/Sat/Lum Rojo/Verde/AzulGas 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 ColorDescripción Matiz/Sat/Lum Rojo/Verde/AzulTemperatura 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 ColorDescripción Matiz/Sat/Lum Rojo/Verde/AzulCó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

11/46


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

12/46


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)

13/46


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.

14/46


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

15/46


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:

16/46


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.

17/46


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

18/46


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

19/46


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.

20/46


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

21/46


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

22/46


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

23/46


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

24/46


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)

25/46


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

indicadorValor

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

26/46


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_

ii

iii

p

indpglobalEval

(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.

27/46


Elemento Evaluacion Comentarios1. Arquitectura 5

1.1. Correspondencia con la Planta 51.2. Numero de Capas 5

2. Distribución 32.1. Consistencia 3 Faltan plantillas de distribucion2.2. Densidad 3 Alta en los graficos generales2.3. Simetria y Balance 52.4. Flujo de Proceso 3 En general no es claro

3. Navegación 33.1 Correspondencia c/arquitectura 53.2. Accesibilidad 4 No se sabe que botones usar3.3. Consistencia 3 Los botones estan dispersos en pantalla

4. Uso del color 34.1. Visibilidad 3 Sobretodo en equipos de proceso4.2. Contraste con el fondo 44.3. Numero de colores 44.4. Diferenciabilidad entre colores 3 Problemas entre lineas de flujo y equipos4.5. Uso de colores tipicos(rojo, verde, amarillo) 2 Exceso de uso del color rojo4.6. Consistencia 4

5. Info. Textual 45.1. Numero de fuentes 55.2. Numero de tamaños 45.3. Visibilidad del texto 3 Sobretodo en valores numericos5.4. Espaciamiento 55.5. Alineacion 55.6. Uso del enfasis 45.7. Uso de acronimos 45.8. Coloración del texto 3 Texto de flujos no codificado con el color5.9. Consistencia 4

6. Simbolos y representacion de los equipos 46.1. Facilidad de reconocimiento 56.2. Visibilidad del estado del equipo 3 En algunos casos, no se nota el estado6.3. Consistencia 5

7. Valores de proceso 37.1. Visibilidad 3 Numeros dificiles de ver a distancia7.2. Ubicación ? Verificar con un experto del proceso7.3. Distribucion 47.4. Agrupación de datos 2 Practicamente no existe7.5. Consistencia 4

8. Tablas y Grupos de Tendencia 48.1. Formato 58.2. Visibilidad 58.3. Ubicacion 58.4. Agrupacion 2 Practicamente no existe8.5. Flexibilidad de configuracion tendencias 48.6. Consistencia 5

9. Comandos e Ingreso de Datos 39.1. Visibilidad 2 No se aprecia lo que se puede comandar9.2. Maniobrabilidad 3 Falta mas area de contacto del comando9.3. Retroalimentación 3 Falta interactividad9.4. Consistencia 4

10. Alarmas 310.1. Visibilidad de la ventana de alarmas 510.2. Accesibilidad de la ventana de alarmas 510.3. Ubicacion de la ventana de alarmas 510.4. Informatividad de los textos de alarmas 2 Falta mas info. relativa al evento10.5. Visibilidad de alarmas en sinopticos 3 Exceso de color rojo filtra las indicaciones10.6. Facilidad de reconocimiento 410.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).

28/46


- 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

29/46


(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.

30/46


1 Gráfico de difusión original

31/46


2 Gráfico de difusión modificado

32/46


3. Gráfico de Evaporación Original

33/46


4. Gráfico de Evaporación Modificado

34/46


5. Gráfico del Efecto III Original

35/46


6. Gráfico del Efecto III Modificado

36/46


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.

37/46


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

38/46


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.

39/46


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.

40/46


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.

41/46


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.

42/46


3.7.2 Valoración de la interfaz S.A.F. mediante la guía GEDIS Hemos escogido basarnos en la guía GEDIS para realizar la valoración de esta aplicación. ¿Por qué esta guía? No solo porque es la única guía que conocemos la cual tiene en cuenta los aspectos de la ergonomía cognitiva si no que se decide trabajar con ella por la credibilidad de su eficacia, ya que aunque parezca que tiene en cuenta aspectos de sentido común, los diseñadores no son conscientes de estos aspectos hasta que uno los lee. Además de que lo más probable es que un diseñador no tenga conocimientos de cómo el ser humano interpreta y asocia la información, es por ello, que basarnos en la guía GEDIS, será realmente eficaz. Indicador: comandos e ingresos de datos Normalmente, a parte del reconocimiento de alarmas, las operaciones que efectúa el usuario son básicamente ejecutar comandos, seleccionar opciones e ingresar datos de consigna y parámetros del proceso, por ello la importancia de analizar el diseño de cómo esta planteado esta parte del aplicativo. Para cumplir los requisitos mencionados, 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 evitando posibles confusiones o errores por parte del usuario. 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. Finalmente, la guía GEDIS habla de la importancia de la retroalimentación, característica clave de los comandos e ingreso de datos, es decir, el usuario debe recibir una respuesta del sistema (positiva o negativa) inmediatamente después que ha efectuado una acción. Y decimos inmediatamente después, ya que el exceso de tiempo de espera de la retroalimentación, puede hacer que el usuario se distraiga. 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. En este caso por ejemplo, en lugar de tener una pantalla donde el usuario pueda cambiar lo que en ese momento cree oportuno, lo puede realizar donde se encuentran los sinópticos del proceso como vemos en los siguientes ejemplos donde en las figuras siguientes hay opción de controlar la luminosidad de unas áreas concretas.

43/46


cc

Control de focos

Control luces en pista de fútbol

44/46


Control de la caldera modo manual activado

Control de consigna en sala Fitness

45/46


En nuestro caso, nos ha parecido que la aplicación, no permite al usuario intervenir en muchas acciones de control, por ello pensamos que la pantalla no esta saturada en este aspecto, aunque si lo podría estas con exceso de información como lo podemos comprobar en la figura anterior. Por todo esto y lo comentado en la primera parte de esta práctica esta es nuestra evaluación del 1 al 5.

9. Comandos e ingreso de datos

9.1. Visibilidad2 9.2. Maniobrabilidad2 9.3. Retroalimentación2 9.4. Consistencia2

Figura 5. Pantalla de alarmas


46/46

Elemento Evaluación 1. Arquitectura

1.1. Correspondencia con la planta 1.2. Número de capas 1.3. Existencia de mapa

2. Distribución 2.1. Consistencia 2.2. Densidad 2.3. Flujo de proceso

3. Navegación 3.1. Correspondencia c/arquitectura 3.2. Accesibilidad 3.3. Consistencia

4. Uso del Color 4.1. Visibilidad 4.2. Contraste con el fondo 4.3. Número de colores 4.4. Diferenciabilidad entre colores 4.5. Uso de colores típicos (rojo, verde, amarillo) 4.6. Consistencia

5. Info. Textual 5.1. Número de fuentes 5.2. Número de tamaños 5.3. Visibilidad del texto 5.4. Espaciamiento 5.5. Alineación 5.6. Uso de énfasis 5.7. Uso de acrónimos 5.8. Coloración del texto 5.9. Consistencia

6. Símbolos y representación de los equipos 6.1. Facilidad de reconocimiento 6.2. Visibilidad del estado del equipo 6.3. Consistencia

7. Valores de proceso 7.1. Visibilidad 7.2. Ubicación 7.3. Distribución 7.4. Agrupación de datos 7.5. Consistencia

8. Tablas y Grupos de tendencia 8.1. Formato 8.2. Visibilidad 8.3. Ubicación 8.4. Agrupación 8.5. Flexibilidad configuración tendencias 8.6. Consistencia

9. Comandos e ingreso de datos 9.1. Visibilidad 9.2. Maniobrabilidad 9.3. Retroalimentación 9.4. Consistencia

10. Alarmas 10.1. Visibilidad de la ventana de alarmas 10.2. Accesibilidad de la ventana de alarmas 10.3. Ubicación de la ventana de alarmas 10.4. Informatividad de los textos de alarmas 10.5. Visibilidad de alarmas en sinópticos 10.6. Facilidad de reconocimiento 10.7. Consistencia Evaluación global

2 4 1 1 3 3 3 1 2 2 3 2 5 5 5 5 5 5 5 4 5 5 3 3 3 4 4 4 4 3 3 3 3 3 3 2 2 4 3 4 4 4 4 4

4 2 2 2 2 2 3 3 2 4 4 2 2 3

3,1

DISEÑO DE PANTALLA - epsevg.upc.edu

Documents

Transcript of DISEÑO DE PANTALLA - epsevg.upc.edu