f HMI (Human Machine Interfaz) ~ Ingenieria a nivel industrial

Visita mi canal de youtube

sábado, 18 de marzo de 2017

HMI (Human Machine Interfaz)


La sigla del HMI es la abreviacion del ingles de interfaz hombre maquina. Los sistemas HMI podemos pensarlos como una ventana de un proceso. Esta ventana puede estar en dispositivos especiales como paneles de operador o en una computadora. Los sistemas HMI en computadora se les conoce también como software HMI (en adelante HMI) o de monitoreo y control de supervisión.


      

Tipos de HMI:


- Desarrollos a medida. Se desarrollan en un entorno de programación grafica como VC++,Visual basic, Delphi, java , etc.

- Paquetes enlatados HMI. Son paquetes de software que contemplan la mayoría de las funciones estándares de los sistemas SCADA. Ejemplo son Fix, wincc, wonderware, etc.


Funciones de un software HMI


- Monitoreo.
Es la habilidad de obtener y mostrar datos de la planta en tiempo real . Estos datos se pueden mostrar como números, textos o graficos que permiten una lectura mas fácil de interpretar.

- Supervisión. Esta función permite junto con el monitoreo la posibilidad de ajustar las condiciones de trabajo del proceso directamente desde la computadora.

- Alarmas.
Es la capacidad de reconocer eventos excepcionales dentro del proceso y reportar estos eventos. Las alarmas son reportadas basadas en limites de control prestablecidos.

- Control.
Es la capacidad de aplicar algoritmos que ajustan los valores del proceso y asi mantener estos valores dentro de ciertos limites. Control va mas a ya del control de supervisión removiendo la necesidad de interaccion humana. Sin embargo la aplicación de esta función desde un software corriendo en una pc puede quedar limitada por la confibialidad que quiera obtenerse del sistema.

- Históricos.
Es capacidad de muestrar y almacenar archivos, datos del proceso a una determinada frecuencia . Este almacenamiento de datos es una poderosa herramienta para la optimización y corrección de procesos.

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:






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

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:




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’).
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, RojoVerde, 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.



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.

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.


Fig. Abreviatura de variables de alarmas de interfaces de HMI.


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.





Ejemplo de la especificación de símbolos de los equipos de proceso.




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. 

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.




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



Ejemplo de la especificación de comandos del operador .


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.






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)



Ejemplo de ventana emergente faceplate que permite configurar los límites numéricos de alarmas asociadas a una variable del sistema SCADA Intouch.









0 comentarios:

Publicar un comentario