cedidet 4 - cenidet.edu.mx · a mis amigos paty y rafa, por su amistad sincera y leal, por...

. . . , . . . . ,, . .

S.E.P. s.E.s.T.. D.G.I.T.

CENTRO NACIONAL DE INVESTiGACION Y

TECNOLÓGICO

cedidet

"SISTEMA MULTIMEDI Y SU APLICACIÓN EN EL

DISEÑO DE INTERFAC 's PARA LA SUPERVISIÓN

Y CONTROL DE PROCESOS1' 4

T E S I S QUE PARA OBTENER EL GRADO DE : M A E S T R O E N C I E N C I A S EN CIENCIAS COMPUTACIONALES P R E S E N T A : MIRIAMZULMASÁNCHEZHERNANDEZ

DIRECTOR@) DE TESIS: Dr. Javier Ortk Hernandez

Dr. Carlos Chavez Mercado

CUERNAVACA MORELOS. AGOSTO 1999

. . . . -- -- .-

Centro Nacional de Investigación y Desarrollo Tecnológico FORMA C3

REVISION DE TESIS

Cuernavaca, Morelos a 2 de Agosto de 1999

M.C. Máximo López Sánchez Presidente de la Academia de Ciencias Computacionales Presente

Nos es grato comunicarle, que conforme a los lineamientos para la obtención del grado de Maestro en Ciencias de este Centro, y después de haber sometido a revisión académica la tesis denominada: Sistema Multimedia y su aplicación en el diseño de interfaces para la supervisión y control de procesos, realizada por la C. Miriam Zulma Sánchez Hernández, y habiendo cumplido con todas las correcciones que le fueron indicadas, acordamos no tener objeción para que se le conceda la autorización de impresión de la tesis.

Sin otro particular, quedamos de usted.

Atentamente

/-- I

M.C. Fe!¡& Alaníz Quezada ' I A

La comisión de revisión de tesis

n

M.C. R'm%ldo Alanís Cantú I

Di. Carlos Chávez Mercado Director de tesis

,/'

i C.C.P. Dr. Javier Ortiz Hernández/Jefe del Departamento de Ciencias Computacionales

INTERIOR INTERNADO PALMIRA SIN. CUERNAVACA. MOR. MEXICO APARTADO POSTAL 5-164 CP 62050. CUERNAVACA. TELS. (73)12 2314,12 7613 .I8 77'41, FAX (73) 12 2434 EMAIL [email protected] cenidet

Centro Nacional de Investigación y FORMA C4

Desarrollo

AUTORIZACION DE IMPRESIÓN DE TESIS

Cuernavaca, Morelos a

C. Miriam Zulma Sánchez Hernández Candidato al grado de Maestro en Ciencias en Ciencias Computacionales Presente

Tecnológico

2 de Agosto de 1999

Después de haber atendido las indicaciones sugeridas por la Comisión Revisora de la Academia de Ciencias Computacionales en relación a su trabajo de tesis: Sistema Multimedia y su aplicación en el diseño de interfaces para la supervisión y control de procesos, me es grato comunicarle, que conforme a los lineamientos establecidos para la obtención del grado de Maestro en Ciencias en este Centro, se le concede-la autorización para que proceda con la impresión de su tesis.

AtentlTgnte

Ortiz Hernández Ciencias Computacionales

INTERIOR INTERNADO PALMIRA SM. CUERNAVACA. MOR. ME%ICO APARTADO POSTAL 5-164 CP 62050, CUERNAVACA. TELS. (73)12 2314.12 7613 ,I8 7741, FAX(73) 12 2434 EMAIL [email protected] cenídet

A Jesucristo, mi Rey y Sahadior- ... Porque todo Go que soy, Go que fíe logrado es

gracíus a tí mí Díos ...

Amímamá ... Por tu ayoyo y a m o r ínconcCicíonal;yor ser

mí mejor- amiga y ía mejm die Iás madres ...i t e quíero ma’!

ma. í s a 6 e G H e r n á d z Q.

N f í o m 6 r e que amo.. . Tor estar a mí hdio e n todo momento,yorque

con tu amor hiciste más fácíGeGcamíno que ha6ía que recorrer. ..¡te a m o mí amor!

Javier Correa íj.

AI Dr. Carlos Chóvez Mercado, por compartir conmigo sus conocimientos y experiencias, por toda su paciencia y amistad desinteresada. Gracias por su interés en cada etapa del trabaio, por su ayuda siempre incondicional ...p or ser mi director de tesis.

AI Dr. Javier Ortíz Hernóndez porque gracias a su interés por los alumnos muchos decidimos continuar con la maestría; por su amabilidad y paciencia durante nuestra estancia en Cenidet. Por el privilegio de ser su tesista.. .

A mis revisores , Reynaldo Alanís, Felipe Alaniz y Max López por sus acertados comentarios.

A mis compañeros y amigos de generación: Eurí, Mario, Wily y Javier, por su amistad y apoyo en esta etapa de mi vida.

A Faby, itzel, Yadira y Rina, por su apoyo en mi estancia en el IIE, por los buenos momentos que pasamos juntas

A mi Iglesia, por sus oraciones durante el desarrollo de mi tesis, por su amor y apoyo, por formar parte de mi familia.

A mi tía Julia por ser siempre un apoyo para mí, porque sé que puedo contar con ella siempre.

A Karlita, porque desde que nació ha sido un motivo más para vivir y superarme..

A mis amigos Paty y Rafa, por su amistad sincera y leal, por compartir conmigo los buenos y malos momentos.

A todos ustedes que forman parte de mi vida ... ¡GRACIAS!

. CONTENIDO

..................................................................................................................................... INTRODUCCION v

CAP-O I: PROBLEMÁTICA EN INTERFACES PARA CONTROL DE PROCESOS 1 . l . Antecedentes ..................................................................................................................... 2

1.3. Solucion propuesta ........................................................................................................... 6 Referencias ................................................................................................................................................ 11

Interaccion hombre-maquina .......................................................................................... 14 Principios generales del diseño de interfaces de usuario ................................................ 15 Factores humanos en el diseño de interfaces .................................................................. 18

. . . 1.2. Descnpcion del problema ................................................................................................. 4 ..

CAPITULO 11: BASES TEÓRICAS PARA EL DISENO DE INTERFACES .. . . 2.1 . 2.2. 2.3.

2.3.1. 2.3.2. 2.3.3. 2.3.4. El sistema motriz ................................................................................................ 23 Diseño de interfaces para control de procesos ................................................................ 24 2.4.1. Manipulación directa como herramienta de diseño y desarrollo de una interfaz hombre-maquina ......................................................................................... 25 Aplicación de características multimedia en interfaces para supervision y control de procesos ................................................................................... 27 2.5.1. Despliegues auditivos ........................................................................................ 29 2.5.2. Principios de diseño para despliegues auditivos ................................................ 31 2.5.3. Señales de advertencia y alarma ........................................................................ 32 Software comercial para control de procesos .................................................................. 34 Simuladores en el entrenamiento de operadores de sistemas para control de procesos .......................................................................................................... 37

Referencias ................................................................................................................................................ 40

CAPITULO IiI: DISEÑO E IMPLEMENTACIÓN

Sistema humano de procesamiento de información ........................................... 18 El sistema perceptivo ....................................... :: ................................................ 20 El sistema cognoscitivo ............... ...................................................................... 21 . .

2.4. . .

2.5. ... . .

2.6. 2.7.

3.1. Análisis del sistema ......................................................................................................... 46 3.1.1. Antecedentes ...................................................................................................... 46 3.1.2. Prototipo del simulador de aula para la Central nucleoeléctrica

de Laguna verde del IIE ..................................................................................... 47 3.1.3. Módulos generales ............................................................................................. 49 3.1.4. Interfaces del sistema ......................................................................................... 51 3.1.5. Planteamiento de objetivos ................................................................................ 60 Especificacion de requenmientos ................................................................................... 60 3.2.1. Requerimientos de hardware y software ............................................................ 60

3.2.1 .I. . Requerimientos de software adicional .... : ....................................... 62 3.2.2. Restricciones del sistema ................................................................................... 63 Diseño del sistema con la incorporación del sonido ....................................................... 64 3.3.1. Arquitectura ....................................................................................................... 64

3.3.1 .I. Arquitectura del módulo de sonido ................................................. 67 3.3.2. Diagrama de eseuctura ...................................................................................... 68 3.3.3. Detalle de módulos ............................................................................................. 70 Implementación del sonido al SimAula .......................................................................... 73

I

. . . . .. 3.2.

. . 3.3.

3.4.

3.4. 1 .

3.4.2. 3.4.3.

Implementación de sonido de retroalimentación en el menú de navegación de los paneles BB09, BBlO y BBl 1 .......................................... 74 Implementación de sonido en la ejecución y control de alarmas ....................... 75 Sonidos ambientales ....... : ................................................................................... 79

......................................................................................................................................... ... Referencia.. '. 81

CAPITULO N: ANÁLISIS, SELECCI~N Y APLICACI~N DEL &TODO DE EVALUACI~N

Objetivo de la evaluacion ................................................................................................ 86 .. 4.1 . Introduccion .................................................................................................................... 84

4.2. 4.3. 4.4.

. . .. .. Alcances de la evaluacion ............................................................................................... 86

Métodos y tecnicas de evaluacion ................................................................................... 87 4.4.1. Evaluaciones basadas sobre usuarios ...................................................... 1 .......... 89 4.4.2. Evaluaciones basadas sobre tareas ..................................................................... 89 Análisis del método de evaluación seleccionado ............................................................ 90 Metodología propuesta de evaluacion ............................................................................. 92 Evaluacion de la interfaz ................................................................................................. 93 4.7.1. Hipótesis de trabajo .......................................... : ................................................. 93 4.7.2. Diseño de un cuestionario para evaluar el grado de presencia de las

hipótesis establecidas ......................................................................................... 94 4.7.3. Diseño experimental .......................................................................................... 94

Referencias ................................................................................................................................................ 98

. . ..

4.5. 4.6. 4.7.

.. ..

RESULTADOS. CONCLUSIONES Y PERSPECTIVAS . . . I . Analisis de resultados ................................................................................................... 100 I1 . Conclusiones ................................................................................................................. 105 111 . Perspectivas .................................................................................................................. 106

Apéndice A

Apéndice B

Apéndice C

ii

LISTA DE FIGURAS

2.1.

3.1.

3.2.

3.3.

3.4.

3.5.

3.6.

3.7.

3.8.

3.9.

Sistema humano de procesamiento de información ...................................... 19

Arquitectura general del Simulador de aula .................................................. 50

Panel BE09 ................................................................................................ 53

Panel BB10 ................................................................................................ 54

Panel BB11 ................................................................................................ 55

Despliegue para visualización del código VASUA .......................................... 57

Despliegue para visualización del código MAAP ............................................ 59

Visión iconográfica del simulador de aula con la incorporación del

módulo de sonido ....................................................................................... 65

Esquema general del módulo de sonido y su implementación

en el sistema ................................................. ; ........................................... 67

Diagrama de estructura del Programa del Simulador de aula ......................... 69

3.10. Diagrama de estructura de los programas fuente (src) de Panelsim ............... 69

3.11. Diagrama de estructura del módulo de sonido para el panel BB09 ................. 70

3.12. Tablero de control de alarmas del panel BB09 .............................................. 76

3.13. Bomba RHR del panel BB09 ........................................................................ 80

3.14. Bomba RHR-A ............................................................................................ 80

5.1. Escala de evaluación con conceptos opuestos (bipolares) .............................. 94

GRÁFICAS

5.1. Resultados de la incorporación de sonido de retroalimentación en el menú de

navegacion de la intevfaaz .......................................................................... 101

Resultados de la incorporación de sonido en el control de alarmas ............... 104

..

5.2.

iii

LISTA DE TABLAS

2.1.

2.2.

2.3.

5.1.

5.2.

5.3.

Capacidades y limitaciones del sistema humano de procesamiento

desde el punto de vista cognoscitivo ............................................................ 21

Capacidades y limitaciones del sistema de procesamiento de

Información del humano y la computadora .................................................. 22

Evaluación de diferentes tipos de alarmas respedo a la

obtención de atención y a la penetración de ruido ........................................ 33 Resultados de la evaluación en la implementación de

sonido en el menú de navegación .............................................................. 102

Valores promedio obtenidos en el análisis situacional

utilizando el escenario VASUA ................................................................... 102

Tempos de respuesta promedio de la evaluación de control de alarmas. ...... 103

iV

IINTRODUCCIÓN En los Últimos tiempos, la aplicación de la computadora como medio de

automatización y presentación de la información, se ha ido incrementando de forma

considerable. Su uso se extiende desde el tradicional almacenamiento y manipulación de

datos y cálculos numéricos, hasta el mejorar la presentación de información para agilizar el

procesamiento de información y la adquisición del conocimiento por parte del usuario.

La especificación, diseño e implementación eficiente de sistemas de representación

M i c a de información (interfaces hombre-máquina) en el desarrollo de software, sea de

aplicación comercial, industrial, científica o educativa es fundamental. El desempeño de un

sistema es percibido, y posteriormente evaluado por el usuario a través de su interfaz. La

importancia de ésta radica principalmente en que es el medio de comunicación entre el

sistema y el usuario; y es a través de ella que el usuario sabe lo que el sistema está haciendo

y qué está sucediendo con la información que está procesando. En general, el usuario se

entera a través de la interfaz de lo que al sistema le es posible o no realizar.

Una aplicación importante de las interfaces se da en el área de control de procesos,

pues de la información que se presente en las interfaces, depende en gran parte la reacción

y acción del operador ante eventos imprevistos en la operación de la planta. Por esto, es

importante que la interfaz encargada de transmitir la información de los procesos de la planta, esté diseñada de tal forma que permita al operador, darse cuenta de manera exacta

del estado actual del proceso cuando ocwan eventos anormales en el mismo, para que

tome las decisiones correctas en el tiempo oportuno.

En la Unidad de Resultados de Energía Nuclear (UREN) del Instituto de

Investigaciones Eléctricas (IIE), surgió la necesidad de diseñar un prototipo de Simulador

de Aula, que tiene por objetivo auxiliar en el entrenamiento de operadores para Centrales

V

Nucleoeléctricas, por medio de interfaces que simulan los paneles de control reales de la

Central Nucleoléctrica de Laguna Verde (CNLV). Dicho simulador consta de diferentes

interfaces que simulan los paneles bb09, bblO y bbl l de la CNLV, así como de una interfaz

que despliega la vasija del reactor con sus diferentes parámetros y gráficas de tendencia.

En la actualidad se ha dado mucho énfasis a la implementación de multimedia en la

presentación de la información, logrando hacer más sencilla y natural la comunicación del

usUano con la computadora.

El objetivo de este trabajo, es la incorporación de sonido en una interfa hombre-

máquina para control de procesos, para analizar los . electos que causa dicha

implementación en los usuarios que la manipulen. Asimismo, evaluar desde el punto de

vista de factores humanos para establecer si interfaces de este tipo, ayudan a mejorar la

comprensión de la información que se despliega en una inter@ para control de procesos.

El contenido de la tesis se resume en:

El capítulo uno presenta el planteamiento del problema y el análisis del mismo.

También se propone una posible solución y su fundamento. En esta primer parte también se

presenta el planteamiento de la hipótesis principal de esta tesis.

El capítulo dos describe brevemente los fundamentos teóricos y conceptuales de

diversos tipos de interfaces, analizando las ventajas y desventajas existentes y su aplicación

para el control de procesos. Aquí también se describe la relación estrecha y la importancia

de incorporar aspectos de factores humanos, en el diseño de interfaces para control de

procesos. Asimismo, en este capítulo se muestran las ventajas y desventajas que tiene el

aplicar aspectos multimedia en este tipo de interfaces.

En el capítulo tres se presentan los criterios considerados para la implementación de

sonido a una interfaz prototipo, asi como la metodología utilizada. Este capítulo también

incluye una introducción a los simuladores utilizados como herramienta de entrenamiento

p m operadores de plantas nucleoeléctricas, tomando como base el simulador de la Central

vi

Nucleoeléctrica de Laguna Verde (CNLV). Asimismo, se hace un análisis del Simulador de

Aula, para entrenamiento de operadores que se está desarrollando en el Departamento de

Energía Nuclear del Instituto de investigaciones Eléctricas (IIE).

El capítulo cuatro trata de los diversos métodos de evaluación que existen, con el

fm de analizarlos y seleccionar el método o técnica más adecuada para aplicarlo al presente

trabajo. Asimismo, se plantea la metodología de evaluación que será aplicada al trabajo

desarrollado.

Por último se presentan los resultados de la evaluación, las conclusiones de este

trabajo, así como una propuesta para trabajos futuros.

vii

CAPíTULO I:

Problemática en interfaces para control de procesos

En este capítulo se analiza el trasfondo de la problemática que se genera al

desarrollar interfaces gráficas para control de procesos. Asimismo se plantea una

propuesta que intenta solucionar en parte dicha problemática, estableciendo una

hipótesis de trabajo la cual se sustentará con los resultados finales de la

investigación.

Capitulo I: Planteamiento del problema

1.1. ANTECEDENTES

D e s d e un punto de vista económico, una de las aplicaciones de mayor impacto de las

interfaces hombre-máquina es en el área de control de procesos. Independientemente del

proceso particular de que se trate - continuo, por lotes, nuclear o químico - en general se trata

de procesos complejos altamente automatizados que requieren de una operación eficaz y

oportuna por parte del operador.

El reto consiste en ofrecer a los operadores los medios que permitan garantizar una mejor comprensión, integración y procesamiento de la información que se está presentando,

para lograr que el funcionamiento y operación de la planta sea en condiciones óptimas de

seguridad. Todo esto con el fin de garantizar la integridad tanto de las personas como de las

instalaciones.

La gran mayoría de los sistemas de producción en la industria de procesos requiere de

operadores humanos para ejecutar tareas de monitoreo, supervisión, control y de toma de

decisiones. El conocimiento de los factores humanos que afectan el desarrollo de estas tareas

juega un papel muy importante en el diseño de las interfaces con la instalación. Muchos

sistemas de despliegues modernos y dispositivos de monitoreo y control usados en sistemas de

supervisión deberían ser diseñados tomando como base datos sobre ingeniería de factores

humanos. Por ejemplo, en el aspecto ergonómico el tamaño de los caracteres alfanuméricos, el

alcance visual, los movimientos de los elementos de control, etc., y en el aspecto cognoscitivo,

la capacidad de memoria, atención, percepción, desempeño, tipos de errores, etc.

Las instalaciones modernas incorporan sistemas que monitorean y evalúan variables

dinámicas con el fin de conocer oportunamente el comportamiento y las condiciones de

funcionamiento del proceso. Esta información se proporciona generalmente al operador

2 Sistema multimedia y su aplicación en el diseño de interfaces para la supervisión y control de procesos

Capítulo I: Planteamiento del problema

mediante despliegues gráficos que muestran el estado de la instalación y su comportamiento,

con el fin de facilitarle la identificación de problemas que pueden presentarse en la planta. Sin

embargo, es imposible predecir la ocurrencia de la totalidad de eventos y las consecuencias que

pueden tener en el producto o proceso. Es en este tipo de situaciones en donde los operadores

juegan un papel esencial y donde un pobre diseño de las interfaces puede inhibir seriamente su

capacidad de enfrentarse con tales imprevistos.

En el área nuclear en donde se tienen las máximas medidas de seguridad y se cuida

mucho de la integridad tanto del operador como de las instalaciones, se generó uno de los

accidentes más relevantes en cuanto al diseño de interfaces. Este accidente es el ocunido en los

Estados Unidos en la planta nuclear de Tres Millas, Unidad 2 (TMI2)[1]; en donde una falla no

examinada del equipo ocasionó confusión entre los operadores propiciando que un incidente

insignificante aumentara potencialmente hasta convertirse en un accidente de gran magnitud

provocando daños severos al reactor. El reporte de la comisión presidencial de ese país,

encargada de analizar el accidente TMI2, señaló algunos factores que habían contribuido

significativamente a la confusión del operador:

a) Entrenamiento deficiente de los operadores. Aunque su entrenamiento incluía

accidentes serios, la combinación de falla del equipo con la presentación confusa de

resultados que se observó en la interfm, dejaron incapaces a los operadores para

enfrentarse con una situación como la que se presentó.

b) Los procedimientos de operación que se aplicaron a este accidente fueron muy

confusos.

c) Este tipo de fallas no habían sido analizadas ni consideradas en los accidentes

estudiados.

Como se ha podido observar, uno de los problemas en interfaces para control de

procesos es la deficiencia en el diseño, ya que de ello depende en gran parte el nivel de

comprensión que tenga el operador de la información que se está presentando, y por


CapiNlO I: Planteamiento del problema

consecuencia de lo oportuna que sea su intervención cuando sucede un evento anormal en la

planta.

A pesar de que actualmente las interfaces han mejorado considerablemente, el trabajo

de los operadores también se ha incrementado en complejidad. Hoy en día los operadores

requieren de interfaces que les permitan un nivel de visión más amplio de los procesos, así

como de una presentación de la información en forma clara, concisa y oportuna. Además de 10

anterior, es indispensable una capacitación más eficiente que les permita operar la planta con

mayor seguridad en condiciones normales, anormales y críticas.

Todo esto lleva a proponer el diseño de una inter$¿ que presente la información ai

operador de la manera más sencilla y clara que sea posible, implementundo características

multimedia, de tal forma que la interfaz logre captar su atención en situaciones de alarma y le

permita tomar decisiones adecuadas y oportunas en situaciones severas de degradación del

estado del proceso.

1.2. DESCRIPCI~N DEL PROBLEMA Según Alty [Z], las interfaces tradicionales" han mostrado serias limitaciones en el

ambiente de control de procesos, tanto con respecto a la captura de atención como con el

despliegue efectivo de la información. Es decir, es en este tipo de ambientes donde existen

eventos inesperados en tiempo real y en donde las decisiones se tienen que tomar en forma

oportuna y precisa. Una interfaz con limitaciones en la presentación de información es de

graves consecuencias en la operación de la planta, pues se requiere que el operador reciba la

mayor información posible de lo que sucede con el proceso de manera clara y sencilla para que

pueda tomar la decisión correcta y realizar las acciones que se requieran oportunamente. Sin embargo, toda técnica de presentación debe considerar las limitaciones y capacidades del ser

a Interfaces tradicionales se refiere a aquellas que utilizan generalmente solo un medio para transmitir la información, ya sea el textual o el gráfico. Esto es, su forma de interacniar con el usuario es simple, utiliza menús o el ratón pan seleccionar su información. No incluye la manipulación directa, sonido, animaciones, ni video.

4

Sistema multimedia y su aplicación en el diseiio de interfaces para la supervisión y control de procesos


humano para procesar la información. Un ejemplo de dicha capacidad es el uso de múltiples

medios para evaluar y comunicarse con el medio exterior; mientras que una limitación sena la

incapacidad de retener 7 s items de información en memoria de corto plazo [3].

Según Norman [4], el ambiente deseado en una interfaz no debe presentar ningún

obstácuio para que los usuarios puedan ejecutar sus tareas; esto es, que la información que

presente la interfaz sea total y absolutamente clara para el usuario, y que su manipulación sea

lo más sencilla y directa posible.

Por ejemplo, la información que se presenta en las interfaces generalmente es

desplegada en forma gráfica y, en ocasiones, aunque dicha información poco después de que

fue mostrada ya es irrelevante u obsoleta, permanece en pantalla ocasionando que el despliegue

tenga información amontonada. La consecuencia es una carga cognoscitiva para el operador lo

que dificulta la atención y la comprensión del proceso bajo control.

Considerando todo lo antenor, una de las aplicaciones que tiene la característica de

centrar su diseño en las capacidades y limitaciones del usuario en cuanto a comprensión de

información, es el diseño de interfaces multimedia. Por tanto, este trabajo de tesis plantea la

incorporación de sonido en una interfaz para control de procesos con el fin de mejorar la

comprensión de la información que se transmite a los usuarios de este tipo de sistemas, asi

como mejorar SU tiempo de respuesta ante eventos inesperados en la operación del proceso.

5 Sistema multimedia y su aplicación en el diseno de interfaces para la supervisión y control de procesos

1.3. SOLUCIÓN PROPUESTA

La tecnología multimedia toma en cuenta las capacidades y limitaciones de la

comunicación humana, y además toma en cuenta las limitaciones para interactuar con sistemas

artificiales. En este sentido, las Interfaces Multimedia son aquéllas que utilizan diferentes

medios (como texto, gráfícas, voz, sonido y video) para transmitir la información y establecer

una comunicación más natural y sencilla entre los seres humanos y los sistemas de cómputo.

Esto Ileva al planteamiento de la siguiente hipótesis: las interfaces multimedia, cuando están

bien diseñadas, ayudan a los operadores responsables del control de procesos a reducir su

carga cognoscitiva al estar frente a un sistema que despliega información y que requiere de

toda su atención y de una manipulación cuidadosa de los datos.

Alty[2], en su investigación sobre diseño de interfaces multimedia, trata de responder a

una pregunta clave en este tipo de aplicación: cuándo usar qué medio y en qué combinación,

para Zograr el máximo efecto. Aunque aún no hay respuestas defhtivas acerca de este punto,

existen algunos resultados de investigación al respecto [S, 61.

Según Alty [2] algunos medios son mejores que otros para transmitir cierta clase de

información dependiendo de las circunstancias en que se ejecuten las tareas. Esto es, que para

algunos usuarios en algunas circunstancias la información es mejor asimilada a través de un

canal que al utilizar otro. En cuanto esto, Deathersage[q realizó investigaciones que se

resumen en la tabla 1.



Tabla 1. Aspectos importantes a considerar para la selección del formato de presentación de la

información. (Según Deathersage)

I 2. El mensaje es corto 12. El mensaje es largo

3. El mensaje no será mencionado después

4. El mensaje trata con eventos en tiempo

3. El mensaje será mencionado después

4. El mensaje se enfrenta con asignación df

espacio

5. El mensaje no requiere acción inmediata 5. El mensaje exige acción inmediata I

6. El sistema visual de la persona está 6. El sistema auditivo de la persona esti

sobrecargado sobrecargado.

7. El lugar de recepción es demasiado 7. El lugar de recepción es demasiadc

brillante o una adaptación de oscuridad es ruidoso.

necesaria.

8. El trabajo de la persona requiere que 8. El trabajo de la persona le permitf

cambie de lugar continuamente. quedarse en una sola posición.

Referente a medios visuales y auditivos, diferentes mensajes visuales pueden ser

desplegados a la vez y usualmente están disponibles para un segundo vistazo, aunque para esto

se tiene que mirar en la dirección apropiada. En cuanto al sonido, la mayoría de las ocasiones

no es necesario mirar de donde proviene el sonido para oírlo e interpretarlo, aunque en algunas

circunstancias como en la detección de alarmas, sí es necesario localizar el origen del sonido

para determinar qué tipo de alarma sucedió y tomar las acciones pertinentes. Por io general un

sonido puede ser oído desde muchos lugares durante cierto tiempo, mientras que un objeto

visual puede ser visto en un solo lugar durante mucho tiempo.

I

Sistema multimedia y su aplicación en el diseño de interfaces para la supervisión y control de procesos


Mountford [SI establece dos razones por las cuales es atractivo utilizar el sonidob para

complementar la información que proporcionan los sistemas:

a) Cuando se implementa sonido en el sistema se aumenta la comunicación que

transmite la interfaz al usuario, ya que además de presentarla grificamente, la

presenta auditivamente y así alerta al usuario de que algo está sucediendo. Esto está

sujeto al ambiente en el que se desarrollen las tareas del usuario, pues en ocasiones

existe ruido o interferencia para el sonido.

b) Muchas veces la información transmitida a través del sonido complementa la

información que está visualmente disponible; de tal forma que el sonido puede

proporcionar un significado para desplegar información que en ocasiones es difícil

de visualizar, especialmente cuando tenemos exceso de despliegues gráficos en

pantalla o simplemente requerimos de todo el espacio del monitor para desplegar

información gráfica.

Un ejemplo sencillo de la utilidad del sonido en las interfaces tradicionales es en la

aplicación de un trasfondo de sonido en la herramienta de impresión. Cuando se inicia un

trabajo de impresión, un sonido bajo y uniforme informará que el trabajo ya está siendo

procesado e impreso. Mientras se continúan realizando otros trabajos, el sonido puede ser

modificado para indicar la rapidez de impresión, la falta de papel en la impresora, si existe

algún problema para la impresión; y finalmente, señalar cuando termina la impresión. Utilizar

el sonido en esta forma puede proporcionar información acerca de muchos procesos sin

desordenar la pantalla. Los sonidos informativos (como en el ejemplo anterior), necesitan

ser particularmente evidentes o que interfieran con el usuario. Las interfaces con

implementación de sonido' bien diseñadas debenan formar una extensión natural de los

bEn este documento el término sonido se refiere al audio no hablado. Con respecto al audio de voz sintetizada, se utilizarh el término simple de voz Generalmente son conocidas como interfaces auditivas.


ambientes de interfaces gráficas existentes, empleando sonidos que sean distinguibles, sin ser

sorpresivos o distrayentes.

En conclusión, los sonidos pueden ser usados para desplegar el estado de procesos en

ambientes multitareas. Pueden ser usados para transmitir información acerca de eventos

discretos en la computadora, tal como la llegada de un correo o problemas con alguna conexión

de un dispositivo. Lo mismo que la voz puede reducir la necesidad de entradas manuales, así el

sonido puede reducir o complementar la necesidad de salidas gráficas.

Sin embargo, a pesar de todas las ventajas anteriormente expuestas, también existen

desventajas que hay que considerar seriamente.

Las interfaces con sonido pobremente diseñadas pueden ser molestas o inútiles. Un

ejemplo de esto es cuando los usuarios que trabajan en ambientes de ruido o aquéllos con

deficiencias de oído encuentran dificil obtener información del sonido. Además la naturaleza

transitoria de los mensajes de audio puede originar una carga de memoria excesiva sobre los

usuarios, además de quizás distraer a otros usuarios cercanos. Por supuesto, los audífonos

pueden ayudar a evitar los problemas de molestar a gente que esté cerca, y permitir el uso de

sonidos aún en ambientes de ruido; sin embargo, los sonidos deberían, en la medida de lo

posible, ser diseñados para no obstaculizar la transmisión de la información, así que los

audífonos idealmente no debieran ser necesarios.

Muchos sonidos son dificiles de distinguir y recordar, aunque también las pantallas

gráficas desordenadas son dificiles de examinar. La habilidad para utilizar interfaces auditivas

será limitada por discapacidades del oído, pero así también la habilidad para usar despliegues

visuales está limitada por problemas en la vista.

9 Sistema multimedia y su aplicación en el diseño de interfaces para la supervisión y concol de procesos

En la presente tesis se analizarán con detalle las características de las interfaces

grá$cas con aspectos multimedia, específicamente las que incorporan audio. De manera que

sea posible establecer sus ventajas y sus desventajas en el área de control de procesos.

El presente trabajo se apoyará en un prototipo de un simulador de aula para la Planta

Nucleoeléctrica de Laguna Verde desarrollado en la Unidad de Energía NuclearVEN) del IIE

[9], con la Jinalidad de evaluar y en su caso validar modificaciones propuestas en la interjaz

de usuario, con respecto a la incorporacidn de aspectos multimedia.

io



BIBLIOGRAFIA:

[I] Report of the President’s Commission On-“The Accident at Three Mile Island

The need for change: the legacy of TMi”. October 1979, Washington, D.C.

pp. 9-11.

[Z] Alty J. L., Bergan M. (1992) “Guidelines for Multimedia Interface Design in a Process

Control Application” Int. Cod. On Design and Sefety of Nuclear Reactors ANP ‘92 Vol. 4,

Atomic Energy Society of Japan.

[3] Miller G., (1956)“The Magical Number Seven Plus o Minus Two: Some Limits on our

Capacity for Processing Information”, Psycological Review, Vol 63, pp. 83-97.

141 D. A. Norman and S . W. Draper, (1987) “Direct Manipulation Interfaces” In User

Centered System Design: New Perspectives on Human-Computer Interaction. Eds. Hillsdale,

NJ:Lawrence Erlbaum Associates, 1988, pp. 87-124.

[SI Edwards A.D.N., (1990), Multi-what?, Position Paper, CHI’90 Workshop on Multi-media

and Multi-modal Interface Design.

[6] Sutcliffe Alistair, Faraday Peter, (1 994), “Systematic Design for Task Related Multimedia

Iníerfaces”, Proc. Infonnation and Software Technology, Vol 36 Number 4, pp. 225-234.

(71 Deatherage, B. H. (1972). “Auditory and others Sensory Forms of Information

Presentation”. In H.P. Van Cott and R. G. W a d e (eds.), Human engineering guide to

equipment design. Washington : Government Printing Office


9 9 - 0 5 8 7


(81 Mountford S. H. and William W. Gaver (1 990). “Talking and Listening io Computers. The

Art of human-computer Interface Design”, edited by Brenda Laurel. Pp. 319-334.

191 Chávez M. Carlos, et al. (1997) Informe Técnico Final del Simulador de Aula (Prototipo)

para operación y análisis de procesos nucleares de centrales Nucleoeléctricas. Unidad de

Energía Nuclear. Instituto de investigaciones Eléctricas, Morelos, México.

12

Sistema multimedia y su aplicación en el diseño de interfaces para la supervisi6n y control de procesos

CAPITULO II: Bases teóricas para el

diseño de interfaces

En este capítulo se recomiendan algunos principios y guías generales

para el diseño de una Interfaz. Así mismo, se analiza el sistema humano

de procesamiento de información como factor importante en el diseño de

interfaces. También se exponen las posibles aplicaciones de

características multimedia en interfaces para control de procesos.

Capítulo 11: Bases Teóricas para el diseño de Interfaces

2.1. INTERACCIÓN HOMBRE-MÁQUINA Cuando conversamos con otra persona utilizamos diversos medios para interactuar con

ella; esta facilidad de diálogo está restringida cuando un usuario trata de interactuar con una

máquina.

El diálogo que se lleva a cabo entre el usuario y la computadora se realiza mediante la

presentación de información que se despliega en el monitor y las acciones correspondientes que

toma el usuario con respecto a esta presentación. La computadora se comunica con el usuario

mediante despliegues sujetos a interpretación, mientras que la acción que realiza el usuario le

permite comunicarse con la aplicación de acciones efectuadas en dispositivos de interacción

(ratón, teclado, lapiz óptico, etc.). [l]. El medio a través del cual 5e establece una comunicación

entre la computadora y el usuario se denomina interfaz.

La computadora utiliza diversas formas de presentación para desplegar datos que

proporcionen un contexto de interacción al usuario, dando la pauta para que éste realice ciertas

acciones en respuesta a la interpretación de los datos.

La calidad de una interfaz desde el punto de vista del usuario depende de cómo se

presenta la información, de su organización y de las acciones que se pueden realizar para

obtener ciertos resultados.

Gouid y Lewis (21 establecen 4 factores críticos que necesitan ser considerados para el

desarrollo y evaluación de un sistema computacional:

4 enfoque centrado en usuarios

+ diseño interactivo

4 evaluaciones empíricas

4 diseño iierativo.

14


Capímlo I 1 Bases Teóricas para el diseño de Interfaces

El enfoque centrado en el usuario significa que el personal de diseño debe interactuar

de manera directa con los usuarios que van a utilizar el sistema en el CUTSO del proceso de

diseño. Se sugiere que la interfaz debe ser el primer componente desanollado del futuro

sistema. El diseño inferactivo involucra la inclusión de usuarios tipicos quienes vendrán a ser

miembros del equipo de diseño, al menos por un corto tiempo al inicio del ciclo de diseño. La

evaluación empírica incluye tanto la evaluación del aprendizaje y la usabilidad" de una interfaz,

como conducir estudios empíricos y experimentales del sistema en todo el proceso de

desarrollo. Finalmente, el diseño iferafivo involucra la incorporación de los resultados de

pruebas de desempeño dentro de la siguiente versión del sistema.

El manejo del diálogo hombre-máquina es esencial para el adecuado procesamiento de

información y para el buen desempeño de los usuarios de las computadoras que trabajan en

tiempo real. A continuación se presentan algunos principios de diseño para desarrollar y

diseñar sistemas de interfaces hombre-máquina.

2.2. PRINCIPIOS GENERALES DE DISEÑO DE INTERFAZ DE

USUARIO Desde hace ya varios años se han establecido guías y principios para el buen diseño de

interfaces de usuario. Engel y Granda [3] proporcionan la primera guía para diseño de

interfaces. Hendricks, Kilduff, Brooks, Marshak y Doyle [4] tratan una variedad de ejemplos

sobre el diseño de sistemas y proporcionan sugerencias para el diseño de interfaces. En la

corporación MITRE, Smith y Mosier (51 han publicado varias guías para el diseño de

interfaces, las cuales se han venido actualizando con el fin de mejorar el diseño. Los siguientes

principios son las Características generales que cualquier interfaz debena de tener, por lo que se

deben aplicar en todos los aspectos de diseño[5-7].

a Usabilidad es el grado de facilidad de manipulación de un sistema. 15

Sistema multimedia y su aplicación en e l disefío de interfaces para la supervisión y control de procesos

Capítuio 11: Bases Teóricas para el diseño de Interfaces

a) Compatibilidad del usuario

El principio fundamental, del cual se derivan todos los demás, es conocer al usuario.

Los diseñadores deben tener conocimiento sobre los alcances y limitaciones de la mente

humana; así como también conocer particularidades del usuario y los detalles de su trabajo.

Quizá la actitud más segura para un diseñador, es asumir que los usuarios son diferentes tanto

del diseñador mismo como de otros usuarios.

b) Compatibilidad de[ producto

Al diseñar un nuevo sistema, la hterfaz generalmente es mejor que la del sistema

anterior, pero se debe tener cuidado de que sea compatible con los sistemas anteriores en

cuanto al diseño de su interfaz, para explotar lo que el us&o ya conoce y minimizar la

necesidad de nuevo aprendizaje. La compatibilidad a través de los sistemas puede reducir

tanto el tiempo de aprendizaje como los errores.

c) Conshtencia

A menudo hay operaciones similares en diferentes partes de una aplicación o en

diferentes aplicaciones de un sistema. Estas operaciones deberían tener interfaces que sean

similares, o la misma si fuera posible. La gente asimila en forma natural la consistencia

y razona por analogía.

d) Fanuliaridad

Otra característica que puede facilitar grandemente el aprendizaje de una nueva interfaz,

es la familiaridad. Pueden ser incorporados conceptos y terminología con los que el usuario ya

está familiarizado.

e) Manipulación directa I

Una interfaz de manipulación directa, es una en la cual los usuarios directamente

ejecutan acciones sobre objetos visibles. Esto hace que la interfaz sea fácil de aprender y muy

16

Sistema multimedia y su aplicación en el diseño de interfaces para la supewisi6n y control de procesos

Capihdo 11: Bases Teóricas para el diseño de Interfaces

poderosa, aunque también tiene limitaciones, pues la exactitud de la manipulación se deja en la

habilidad que tenga el usuario con el uso del mouse u otros dispositivos de interacción.

fl Control

Los usuarios requieren sentir una sensación de mando y control sobre cualquier

herramienta que esté a su disposición. Los usuarios tendrán una sensación de mando si la

interfaz es simple, predecible y consistente.

g) Disponibilidad

Este principio establece “Lo que ves, es lo que obtienes”. Esto se refiere al grado de

correspondencia uno a uno, entre la infonnación desplegada en la pantalla y las acciones

disponibles por el usuario.

h) Flexibilidad

La flexibilidad en un sistema, permite adaptar y controlar variaciones de las habilidades

y preferencias de un usuario. Éste debería ser capaz de obtener información del despliegue en

la forma más conveniente para la tarea en que esté trabajando.

i) Retroalimentación

La computadora debe siempre responder inmediatamente a la acción del usuario. Ya

que lo que hace internamente la computadora es invisible al usuario, para éste es imposible

saber cuanto tiempo tardará el sistema en completar una tarea; así que cuando el tiempo de

espera sea inevitable, se debe informar al usuario el estado del progreso de la tarea.

.í) Robustez

Un sistema debe tolerar errores humanos comunes e inevitables, esto es, hacer sentir al

usuario que el sistema es lo suficientemente robusto para manejar cualquier clase de acciones,

incluyendo los errores.

17

Sistema multimedia y su aplicaci6n en el diseño de interfaces para la supervisión y control de procesos

Capitulo 11: Bases Teóricas para el diseño de Interfaces

k) Protección

El usuario de6e también estar protegido contra sus propios errores. La gente comete

errores cuando trabaja rápidamente o bajo presión. Esto debe ser tomado en cuenta para

proteger ai usuario en contra de errores que se cometen por descuido u omisión mediante

mensajes de confirmación y acciones de recobro.

r) Fkcil de aprender - fdcil de usar

Los sistemas deben ser fáciles de aprender para el novato, así como eficientes y fáciles

de usar para el experto. Muchos de los principios anteriores contribuyen ai logro de este fin.

2.3. FACTORES HUMANOS EN EL DISEÑO DE INTERFACES Para lograr el desarrollo de una interfaz que cumpla con el objetivo de transmitir la

información en forma clara, sencilla y precisa ai usuario que la está manipulando, es necesario

tomar en cuenta factores humanos como: memoria, percepción visual, representación del

conocimiento, pensamiento, razonamiento y construcción de diálogos. Por tanto, es necesario

analizar algunas características en la forma de procesamiento de información del ser humano,

para conocer sus alcances y limitaciones en cuanto a la comprensión de la información que

recibe a través de una interfaz.

2.3.1. Sistema humano de procesamiento de información La capacidad de procesamiento de hfomación de la mente humana, es deteminante en

la ejecución de tareas del usuario. Entender cómo piensa la gente, razona, aprende y comunica

es esencial para diseñar sistemas interactivos que faciliten las tareas cognoscitivas.

18

Sistema multimedia y su aplicación en el diseño de interfáces para la supervisión y control de procesos

Capítulo I 1 Bases Teóricas para el diseño de Interfaces

Mayhew 161 establece un modelo de procesamiento de información del ser humano, el

cual presenta tres tipos de memona: memoria de corto plazo, memoria de largo plazo y la

memoria de plazo intermedio.

La memoria de corto plazo también es llamada memoria de trabajo, y es donde el

pensamiento consciente ocurre. Aquí se ejecutan cálculos, se interpretan datos nuevos y se

organiza la información para resolver problemas. La memoria permanente es la memoria de

largo plazo. Aquí se recuerda cada evento sucedido y se registra toda información y habilidad

que hemos aprendido. La memoria de plazo intermedio es la parte de nuestro sistema de

memoria que mantiene registro continuo de los procesos involucrados durante la solución de

problemas y toma de decisiones.

Según Card [SI, el sistema de procesamiento humano se divide en tres subsistemas

principales: el sistema perceptivo, el sistema cognoscitivo y el sistema motriz. La figura 2.1.

ilustra el caso.

Fig.

c PROCESADOR MOTRIZ

2.1. Sistema humano de procesamienio de información según Card [SI.

19



En los siguientes puntos se analiza cada uno de los subsistemas del sistema de

procesamiento humano, tratando de ejemplificar las implicaciones de cada uno para el diseño

de interfaces.

2.3.2 El sistema perceptivo. El sistema perceptivo del ser humano transporta estímulos del mundo físico que han

sido detectados por el cuerpo, a través del sistema sensorial. Dichos estímulos, son

transformados en representaciones internas de la mente para continuar con la siguiente etapa

del sistema de procesamiento humano de información.

La primera información que entra al sistema humano es a través de los órganos

sensoriales (ojos, oídos, olfato, tacto y gusto), esta información se guarda en un centro de

almacenamiento sensorial, el cual tiene como propósito guardar una imagen fija del mundo

externo por tiempo suficiente para algún análisis posterior [6]. Esto es especialmente

importante con señales auditivas (sonidos, voz), porque éstas son fiecuentemente de muy corta

duración. También es importante para señales visuales porque ellas no siempre permanecen en

nuestra línea de visión para poder estudiarlas.

Aunque hay algunas evidencias para almacenamiento sensorial del tacto y del olfato,

los dos mecanismos de almacenamiento sensorio que se conocen más, son aquellos que se

asocian con el sistema visual, llamado almacenamiento icónico, y el sistema auditivo, llamado

almacenamiento ecóico 191.

Si un estímulo visual es reflejado muy brevemente sobre una pantalla, el

almacenamiento icónico guarda la imagen por un corto tiempo, permitiendo más tarde el

procesamiento de la imagen. El mismo tipo de fenómeno ocurre con la información auditiva en

el almacenamiento ecóico. El almacenamiento icónico generalmente dura menos de 1 segundo,

mientras que el almacenamiento ecóico puede durar unos pocos segundos antes que la .In

~~



representación se desvanezca. En esencia el almacenamiento sensorial es relativamente

automático y es poco lo que se puede hacer para incrementar la longitud de la representación

sensorial.

2.3.3. El sistema cognoscitivo Desde las tareas más simples hasta las más complejas, el sistema cognoscitivo sirve

para conectar las entradas de datos desde el sistema perceptual hasta las salidas conectas al

sistema motriz Ill].

El sistema humano de procesamiento de información tiene ciertas características que

afectan la forma de procesar la información. En esta sección se analizan las capacidades y

limitaciones que tienen la memoria de largo y corto plazo y que afectan el sistema de

procesamiento en su parte cognoscitivu.

Las principales capacidades y limitaciones del sistema humano de procesamiento se

resumen en la tabla 2.1.

Tabla 21. Capacidades y limitaciones del sistema humano de procesamiento desde el punto de vista

cognoscitivo. 141

plazo. plazo

Gran aptitud para el aprendizaje Procesamiento propenso al error.

..mem5rii7de- - .. &go. .. . 1 . .;.&;,.-. ;.,%y.)

: ,I ' *-,' :I 1 . . . . ~ . . . . f . '

mecaukmo-de atención.,, ',

, ; :." .. li ", ., .-i..;,.. . . 0'

.;. .* . . . . ' , ...?,. I ; . :* 1 . . ' , . . . .. -..----..-.*-A. ...

- < ,

Poderoso patrón de reconocimiento. Procesamiento muy bajo.

21



Podemos comparar las capacidades y limitaciones relativas del sistema humano de

procesamiento con los del sistema de procesamiento de información de la computadora, y notar

algunos aspectos interesantes: las capacidades del sistema humano (aptitud de aprendizaje,

duración de memoria de largo plazo, poderoso patrón de reconocimiento) tienden a ser las

debilidades de la computadora, y las limitaciones del sistema humano (breve duración en SU

memoria de corto plazo, procesamiento bajo y propenso al error), tienden a ser la i capacidades

de la computadora. [6]

ES muy importante considerar este tipo de aspectos al diseñar una interfw ya que el

diseñador debe asignar tareas al usuario y a la computadora dependiendo de io que ellos hacen

mejor. Por ejemplo, el usuario debería ser el indicado para tomar decisiones complejas basadas

en análisis hewísticos de datos, y no debiera ser requerido para hacer cálculos mentales

complejos y transformaciones de datos, mientras que no debiera esperarse que la computadora

realice análisis intuitivos. Estos aspectos se sumarizan en la tabla 2.2.

Tabla 2.2. Capacidades y limitaciones del sistema de procesamiento de información del humano y de

la computadora[ó]

Procesamiento muy r4pido

Procesamiento libre de errores

Acceso confiable de memoria

Aprendizaje reducido

Bajo nivel en la integración de datos.

22



2.3.4. El sistema motriz El resultado del sistema de procesamiento de datos es siempre una función motriz, ya

sea un movimiento, una expresión de voz o un sonido. El sistema motriz consiste de un gran

número de músculos que son controlados y coordinados por un complejo sistema nervioso

altamente interconectado [lo].

Se cree que el pensamiento es transformado en acciones a través de una serie de

discretos micromovimientos en el cuerpo humano. Diferentes conjuntos de músculos son

involucrados en movimientos motrices amplios (por ejemplo, el movimiento de la mano del

teclado ai mouse), o en movimientos motrices más minuciosos (por ejemplo, posicionar el

mouse en un objeto o escribir).

Los movimientos motrices importantes en el diseño de una interfaz incluyen la cabeza,

los ojos, brazos, mano y movimientos de los dedos. El diseñador debe tratar de minimizar los

movimientos motrices extensos pues llegan a ser fatigantes, además las transiciones de

movimientos extensos a movimientos minuciosos requieren mucha concentración [6] .

Los movimientos de los ojos deben ser minimizados para incrementar la ejecución y

minimizar la fatiga. Por ejemplo, las pantallas pueden ser planeadas para minimizar la revisión

y búsqueda, y con esto reducir los movimientos de los ojos de la pantalla al teclado.

Es importante considerar el sistema motriz en el diseño de la interfaz para que el

usuario tenga una óptima ejecución de sus tareas y no se fatigue durante su realización, y por lo

tanto sean mínimos los errores que se puedan cometer debido al cansancio fisico.



2.4. DISEÑO DE INTERFACES PARA CONTROL DE PROCESOS El lograr una mejor comunicación entre el ser humano y la computadora es el principal

objetivo de una interfaz. Hoy en día las interfaces gráficas son la manera más común para

establecer la interacción hombre-máquina.

Sin embargo, cuando se analiza el uso actual de sistemas de interfaces, se encuentra que

muchos sistemas computarizados actúan como registradores pasivos de datos y no como un

componente activo de la tarea a realizar por el usuario. Los sistemas registran io que el

operador está haciendo, pero el diseño no asume ningún papel activo en controlar los procesos

o acciones del usuario.

Por otra parte, en ambientes de control de procesos, el elemento de tiempo real y

dinámico hace los sistemas más complejos y generalmente más automatizados, lo que provoca

fallas en la ejecución humana, no sólo del usuario al interpretar mal la información, sino en los

diseñadores de la interfaz al no tomar en cuenta factores humanos para un mejor desempeño

del sistema.

Según Rasmussen 1121 los accidentes no son causados por error del usuario únicamente.

Los errores humanos pueden ser divididos en dos clases: errores activos y errores pasivos. Un

error activo es aquél cometido por un usuario al estar frente al sistema; mientras los errores

pasivos son errores en el diseño o construcción del sistema. Tales errores pueden quedar sin ser

detectados por un largo tiempo, hasta que un conjunto peculiar de circunstancias cause un

mayor incidente. Según Rasmussen los errores pasivos son más comunes y además son la

principal causa de los errores activos.

El saber transmitir y recibir datos por medio de una interfaz puede ser caracterizado

como un problema de diálogob o de comunicación. El manejo apropiado del diálogo hombre-

máquina es esencial para aumentar la capacidad de toma de decisiones de los usuarios de

Un dialogo es una secuencia de interacciones entre el operador y el sistema para lograr un objetivo. Por ejemplo, el dialogo a seguir para imprimir un archivo.

24

Sistema multimedia y su aplicación en el diseno de interfaces para la supervisión y control de procesos


computadoras que trabajan en tiempo real. Sin embargo, los diálogos que se presentan

actualmente en las interfaces frecuentemente son considerados por los operadores inflexibles e

inestructurados. 1131

2.4.1. Manipulación Directa como herramienta de diseño y desarrollo

de una Interfaz hombre-máquina. En contraste con lo establecido en el punto anterior, la utilización del modelo de

manipulación directa, permite el diseño de interfaces gráficas fáciles de usar, ayudando a que

la tarea del operador se efectúe de una manera más eficiente.

Las interfaces que utilizan manipulación directa permiten, como su nombre lo indica,

manipulan directamente objetos gráficos (iconos) que representan sistemas, comandos,

procesos o parámetros de proceso.

Shneiderman [14, 151 define el modelo de manipulación directa como un método

aplicable a interfaces de usuario que contengan las siguientes características:

a) Representación visual continua de los objetos de interés.

b) Acciones físicas en la interfaz o manipulación de botones etiquetados que

simulen la acción real del sistema; en lugar de una sintaxis compleja y

comandos escritos.

C) Operaciones reversibles rápidas cuyo efecto en el objeto de interés sea

inmediatamente visible.

Una de las principales premisas de la manipulación directa es que mientras más directa

y natural sea la sensación de controlar la interfaz gráfica, más efectivo será el uso de la misma.

En un experimento desarrollado por Shneiderman y Margono 1161, se realizó una comparación

en la ejecución de tareas en un archivo entre un sistema que usa lenguaje de comandos y un

25

Sistema multimedia y su aplicación en el diseño de interfaces para la supervisión y contml de procesos

Capítulo 11: Bases Te6ncas para el diseño de Interfaces

sistema con manipulación directa. Treinta sujetos inexpertos aprendieron a utilizar el sistema

ejecutando las tareas que se les asignaron. Los resultados mostraron que la manipulación

directa fue superior en cuanto al aprendizaje y al tiempo para completar las tareas. De acuerdo

a los autores del experimento, esto fue debido a que hubo menor carga de memoria y a la

facilidad y manejo eficiente del mouse.

Actualmente las interfaces con manipulación directa están siendo utilizadas cada más

en el área de control de procesos. Estas interfaces están cambiando y mejorando el diseño

tradicional de cuartos de control para procesos. Esto es, en vez de supervisar grandes tableros

con medidores, alarmas y controles, el operador puede maniphar la planta a través de diversas

pantallas que han sido colocadas hábilmente para un mejor control y supervisión de los

procesos.

En el sector nuclear,gor ejemplo, en la tercera generación de reactores Kashiwazaky-

Kariwa [I71 incluye una sala de control altamente automatizada, en donde las operaciones de

control se realizan mediante la utilización de pantallas sensibles al tacto bajo un arreglo

jerárquico de despliegues gráficos y paneles de alarmas, digitalizando la instrumentación y los

sistemas de control, incluyendo los sistemas de seguridad. Por su parte, Beltrachi [IS] discute

la implementación de una interfaz con manipulación directa para el control del reactor basada

en iconos que representen los procesos del sistema. Propone el diseño de una consola

compuesta por catorce pantallas, algunas sensibles al tacto y otras manipuladas por teclado y

ratón. De la misma forma, Chávez [IS] propone una interfaz avanzada con pantallas sensibles

al tacto que desplieguen paneles simplificados para el control de una planta nuclear.

Sin embargo, a pesar de las grandes ventajas que ofrecen las interfaces de manipulación

directa en el control de procesos, se propone mejorar aún más la comunicación en este tipo de

ambientes tratando de ofrecer diversos medios para transmitir la información; esto es,

implementar caractensticas multimedia a las interfaces para control de procesos.


Capítulo 11: Bases Te6ricas para el diseño de Interfaces

2.5 APUCACI~N DE CARACTEI~STICAS MULTIMEDIA EN

INTERFACES PARA SUPERVISI~N Y CONTROL DE

PROCESOS Se ha comprobado que la gente se comunica más efectivamente a través de múltiples

canales', como la vista, el oído y el tacto; además de gestos y otros movimientos del cuerpo que

usualmente acompañan la voz (11. Esta comunicación eficiente y familiar al usuario, es la que

se pretende lograr con las interfaces multimedia, ya que además de cumplir el requisito de

permitir la comunicación hombre-máquina, trata de que ésta sea más natural, sencilla y fácil de

comprender a través de utilizar diversos medios (animación, sonido, texto y video) para

transmitir la información.

Sin embargo aplicar estas características de comunicación en una interfaz para control

de procesos es bastante complejo. James Alty añrma que: "el problema principal que se

presenta en el control de procesos es SU naturaleza no determinística, ya que no se puede

predecir exactamente el estado futuro del proceso o su reacción a ciertos eventos, por tanto,

tampoco se puede saber el requerimiento actual del medio por el cual se va a transmitir la

información. Esto quiere decir, que existe la factibilidad de tener súbitamente peticiones

simultáneas para el uso del mismo medio, por diferentes tareas de igual importancia" [20, pg

43-21, En este tipo de situaciones, es donde existen senas limitaciones en la aplicación de las

actuales interfaces gráficas, ya que el despliegue textual y gráfico muchas veces no es

suficiente para proporcionar toda la información que necesita el operador en un instante dado.

El ambiente de control de procesos demanda requerimientos específicos de un sistema

de presentación multimedia:

Canal es ei sentido humano para percibir y comunicar información. por ejemplo: el olfato, el gusto, oído, vista y tacto. Actualmente s610 los canales d e la vista, el oído y el tacto están disponibles para las interfaces hombre-máquina.



El operador puede estar ocupado en muchas tareas distintas simultáneamente, por ejemplo,

monitoreo, localización de alarmas, etc.

Nuevas tareas y por lo tanto interacciones, pueden ser fomentadas en cualquier momento

por otro sistema u operador.

El estado del proceso puede ser extremadamente dinámico, de tal forma que la información

puede necesitar ser presentada rápidamente y en una forma que sea fácilmente entendida

por el operador.

e

e

En la aplicación de multimedia en el área de control de procesos, surge una pregunta

importante, ¿qué medio utilizar y en qué combinación para lograr el máximo efecto?. Aunque

no hay respuestas definitivas, existen diversas investigaciones ai respecto, una de ellas es la de

Deatherage [21] sobre cuándo utilizar sonido, que ya se presentó anteriormente. También

Beagles-Roos, 1221 ha encontrado que los medios auditivos hacen sobresaliente el diáiogo, ya

que estimula la imaginación; y en algunas circunstancias su combinación con el medio visual

es más efectiva que el sonido solo. Asimismo Rewey 1231 establece que los diagramas son

mejores para transmitir ideas y que el texto es mejor para el detalle. Marmollin, 1241 en SUS

investigaciones sobre como identificar cuándo es apropiado utilizar diferentes medios,

establece que una representación que permite exploración es mejor cuando un problema es

nuevo para el usuario, mientras que, cuando el usuario tiene mucha experiencia, es mejor la

forma textual. Sin embargo él afirma que entre las dos, la visual es preferida por los usuarios.

Es usual pensar que el canal visual siempre domina sobre el canal auditivo, pero no

siempre es éste el caso. Edwards, [25] desarrolló interfaces auditivas para usuarios

discapacitados. Su procesador de palabras contiene el audio equivalente a menús, ventanas,

barras de desplazamiento, etc. y puede ser operado por medio de un mouse utilizando

retroalimentación auditiva. Él. señala que la memona de corto plazo es mucho más importante

en interacción auditiva que en una interacción visual.

28

Sistema multimedia y su aplicación en el diseño de interfaces para la supervisión y conlrol de procesos


Un proyecto importante en esta área es el PROYECTO PROMISE [26] (Process

Operators Multimedia Intelligent Support Environment) cuyo objetivo es el diseño,

construcción y evaluación de un conjunto de herramientas multimedia para: "Mejorar las

interfaces de usuario para sistemas expertos de asesoría y diagnóstico que es usado por

operadores en ambientes de control de procesos"

El sistema PROMISE es multimedia ya que soporta muchas formas de comunicar la

información, y es multimodal porque soporta muchos estilos de interacción. El sistema cuenta

con las siguientes opciones multimedia:

Texto, graficos y salida de sonido.

Salida de video

Animación bidimensional y tridimensional.

Audio y vídeo inmediatos.

Salida de lenguaje natural

Entrada de datos con texto y mouse

El proyecto PROMISE fue implantado en dos distintos tipos de ambientes: una planta

nuclear y una planta química. Estas dos plantas fueron seleccionadas deliberadamente por los

diferentes tipos de ambientes que ofrecen. El trabajo en la planta nuclear es llevado a cabo en el

simulador de la planta. El trabajo en la planta química es llevado a cabo en la sala de control de

la misma. En el caso particular del simulador, éste permite crear deliberadamente situaciones

de error y expiorar la importancia de diferentes medios para asistir a operadores que tratan con

diversos tipos de situaciones.

2.5.1. Despliegues auditivos (Interfaces con sonido) La naturaleza del sentido auditivo ofrece ciertas ventajas únicas para presentar

información, en contraste con el modo visual. Un conjunto de comparaciones de estos dos

29

Sistema multimedia y su aplicacion en el diseño de interfaces para la supervisión y control de procesos

Capítulo 11: Bases Teóricas para el diseño de interfaces

sentidos fue dado anteriormente, (ver tabla 1.1) de las cuales es posible identificar ciertos tipos

de circunstancias en que los despliegues auditivos pueden ser preferidos a los despliegues

visuales:

Cuando el origen de la señal es un sonido mismo @or ejemplo, alarmas).

Cuando el mensaje es simple y corto.

Cuando el mensaje no será referido después.

Cuando el mensaje se enfrenta con eventos en tiempo (cuando se requiere de una acción

inmediata).

Cuando son activadas alarmas o cuando el mensaje llama a una acción inmediata.

Cuando cambia continuamente la información que es presentada.

Cuando el sistema visual está sobrecargado.

Cuando canales de voz son empleados.

Cuando la iluminación limita el uso de la vista.

Cuando el usuario se mueve de un lugar a otro.

Cuando es requerida una respuesta verbal.

En las guías anteriores se debe hacer una mención particular de la deseabilidad de

restringir mensajes auditivos a aquéllos que son cortos y simples (excepto en el caso de voz),

ya que la gente no conserva.muy bien en su memoria los mensajes complejos.

Podemos considerar cuatro tipos de funciones humanas, o tareas inyolucradas en la

recepción de señales auditivas [27]:

I) Detección. Determinar si una señal dada está presente, tal como una señal de alarma.

2) Discriminación relativa. Diferenciando entre dos o más señales presentadas muy juntas.

3) Identificación absoluta. Identificando una señal particular de alguna clase, cuando sólo una

es presentada.

4) Localización. Determinar la dirección desde la cual la señal está llegando.

30


Capiíulo 11: Bases Teóricas para el diseño de Interfaces

A continuación se proponen algunas guías sobre el diseño de interfaces con sonido que

se recomienda seguir para mejorar la eficiencia de este tipo de despliegues.

2.5.2. Principios de diseño para despliegues auditivos Como en otras áreas de ingenieria de factores humanos, las guías y principios sobre

despliegues auditivos son aceptados con ciertas reservas, debido a que no siempre son válidas

para todo tipo de ambientes y situaciones, y algunas circunstancias específicas pueden ser

argumentadas para contradecirlas. Con tales reservas en mente, existen algunas g~.Úas para el

uso de despliegues auditivos (271. Éstas generalmente son el resultado de investigación y

experiencia, otras han sido extraídas del trabajo de Mudd [28] y Licklider 1291.

Princivios generales

a) Compatibilidad Hasta donde sea posible, la selección de las señales debe explotar io ya

aprendido por los usuarios del sistema.

b) Aproximación. Cuando una información compleja es presentada, la señal debe ser de tal

forma que atraiga la atención para poder identificar el tipo de información que se está

presentando de forma precisa.

c) Disociabilidad Las señales auditivas deberían ser fácilmente discemibles de otra entrada

de audio (incluyendo el ruido). Por ejemplo, si una persona está oyendo al mismo tiempo

dos o más canales, las frecuencias de los canales deben ser diferentes.

d) Parsimonia. Las señales auditivas no deben proporcionar m b información que la

necesaria.

e) Invariabilidad. La misma señal debe ser asignada a la misma información en todos los

tiempos.

d2 Principios para la uresentación:

a) Evitar extremos de dimensiones auditivas. Señales de alta densidad, pueden causar un

sobresalto en la respuesta e interrumpir la ejecución.



b) Establecer intensidades relativas al nivel de ruido del ambiente. El nivel de intensidad

debe ser asignado de tal forma que no sea encubierto por el nivel de ruido del ambiente.

c) Usar señales variables o interruptoras. Mientras sea posible, evitar establecer señales

constantes, y en lugar de esto usar señales variables o de interrupción. Esto tenderá a

minimizar la adaptación perceptiva.

d) No sobrecargar el canal auditivo. Sólo pocas señales auditivas deben ser usadas en alguna

circunstancia dada, ya que muchas señales pueden confundir y sobrecargar al operador.

(Por ejemplo, en el accidente nuclear de Three Mile Island, más de 60 señales auditivas de

alerta fueron activadas).

Princiuios para la instalación de desvliepues auditivos:

a) Probar las señales que serán usadas. Las pruebas deben ser hechas con un ejemplo

representativo de la población de usuarios que las van a utilizar, para estar seguros de que

las señales puedan ser detectadas e identificadas por ellos.

b) Evitar conflictos con sefiales previamente usadas. Las señales que hayan sido

recientemente instaladas no deben contradecir el significado de las señales existentes o las

de los sistemas anteriores.

c) Facilitar cambios de despliegues previos. Cuando las señales auditivas reemplazan

algunos modos de presentación @or ejemplo, el visual), es preferible que se continúe con

ambos modos para ayudar a la gente que se está acostumbrando a las nuevas señales

auditivas.

2.5.3. Señales de advertencia y alarmas Las características únicas de los sistemas auditivos hacen que los despliegues con

sonido sean especialmente útiles para señales de advertencia y alarmas. Cada uno de los

diferentes tipos de dispositivos disponibles tiene sus características individuales y sus

32



correspondientes ventajas y limitaciones. Un resumen de estas características se presenta en la

Tabla 2.3.

Tabla 2.3. Evaluación de dgerentes tipos de alarmas respecto a la obtencwn de atención y a la

penetraeón de ruido. .Deafherage (1972, Tabla 4-2) 1211

Según Adams y Trucks [30] el tiempo de reacción disminuye cuando la intensidad de la

señal se incrementa; por io que cada señal de alarma debe estar diseñada en forma específica

con intensidad adecuada para evitar el incremento en el tiempo de reacción.

En la selección o diseño de señales de alarma, las siguientes recomendaciones generales

de diseño han sido propuestas por Deatherage [21] y Mudd [28]:

Usar frecuencias entre 200 y 5000 Hz, preferiblemente entre 500 y 3000 Hz, porque el oído

es más sensible en este rango intermedio.

33 Sistema multimedia y su aplicación en el diseilo de interfaces para la supervisión y control de procesos


Usar frecuencias abajo de 1000 Hz cuando las señales tengan que propagarse a grandes

distancias (más de 304 metros), porque altas frecuencias no se propagan muy lejos.

Usar una señal modulada (1 a 8 beeps por segundo), ya que la diferencia de éstos con

sonidos normales es suficiente para demandar atención.

Usar sefiales con frecuencias distintas de aquéllas que predominan sobre algún ruido de

fondo, para minimizar el ocultamiento de señales que se puede provocar.

Si diferentes señales de alarma son usadas para representar diferentes condiciones que

requieren diferentes respuestas, cada una deberá ser discriminable de las otras, utilizando

señales de intensidad moderada.

Mientras sea posible, usar un sistema de comunicación distinto para alarmas, tal como

altavoces, bocinas, u otros dispositivos que no sean usados para otros propósitos.

2.6. SOFWARE COMERCIAL PARA CONTROL DE PROCESOS

El software juega un papel vital en el desarrollo de sistemas de control de instrumentos

y/o procesos, y en la automatización de la adquisición de datos. El software que se usa en el

campo de supervisión y control de procesos, posee un amplio rango de funciones, desde

manejadores de dispositivos para controlar un hardware especifico, hasta paquetes de software

de aplicación para desarrollar sistemas completos. Los paquetes de software de aplicación

proporcionan herramientas para instrumentos de control, adquisición, análisis y presentación de

datos; permitiendo reducir el tiempo de desarrollo del sistema y hacer más fácil su

mantenimiento.

Actualmente existe mucho software de aplicacion que sólo se enfoca a una de las partes

de desarrollo de un sistema de control de procesos (ya sea adquisición de datos, análisis de

datos o presentación de los datos), aunque generalmente solo se utiliza para aplicaciones

específicas.


Capíiulo 11: Bases Teóricas para el diseño de Interfaces

Existen dos compañías que se distinguen por sus productos enfocados a solucionar un

amplio rango de problemáticas en el área de control de procesos, adquisición de datos, andisis

y presentación de los mismos: National Instruments y Intellution.

National Instruments cuenta con dos paquetes que se distinguen por su flexibilidad y

por abarcar todos los elementos de un sistema de este tipo: LabView y Labwindows.

LabView:

Puede correr en plataformas windows, macintosh y sun. Es un sistema de programación

gráfica para instrumentación, que pueden utilizar tanto programadores inexpertos como

avanzados. Tiene capacidad para manejar multitarea, crear múltiples ventanas y correr en red.

También incluye capacidad de intercambio de datos dinámico (DDE) en platafoma Windows,

capacidad de TCPAP para plataforma Sun, y comunicación Interaplicación (LAC) para

platafoma macintosh.

Para la presentación de los datos se construyen interfaces gráficas, ensamblando

gráfkamente módulos de software llamados instrumentos virtuales (VIS).

Labwindows:

Puede ejecutarse bajo DOS y NEC. Los programas que se desarrollan en este software

bajo ambiente DOS son construidos bajo programación Basic y Microsoft C; por tanto, es ideal

para programadores intermedio-avanzado de Basic y programadores de C. Los programas

desarrollados en Labwindows no están limitados en memoria, pues es un sistema abierto,

además se pueden incluir las librenas necesarias para tus necesidades específicas. Labwindows

también corre en series de computadoras NEC PC-9800. Estas computadoras son las más

populares en Japón que corren bajo DOS y son usadas en aplicaciones científicas y de

ingeniería. Los lenguajes de programación utilizados son QBasic y C. También incluye

caracteres japoneses y manejadores de dispositivos de manufactura japonesa.



Por otra parte, la compaii’a Intellution ofrece el software FLY (Fuliy-Integrated

Control System) que incluye las siguientes características:

- Monitoreo y control supervisono de procesos en tiempo real.

- Alarmas y manejo de alarmas

- Gráficas de tendencia históricas

- Fácil sistema de expansión

- Manejoenred

El FIX se divide en varios sub-móduios de software que pueden utilizarse de forma

independiente:

FIX MMi (Man-Machine Interface) para windows, es el software encargado de desmollar la

interfaz del sistema, utilizando librerías gráficas que contienen más de 150 instrumentos

básicos en este tipo de aplicaciones. La interface permite animación básica.

FIX DMACS es un software que corre bajo plataforma windows y realiza las mismas

funciones que FIX MMI, adicionando el trabajo en red.

Plant TV es una herramienta que permite ver la información importante de manufactura en una

simple aplicación de windows. Incluye el manejo de datos en base de datos relacionales.

FIX BOS (Batch Operations Supervisor) es el software encargado de automatizar las

operaciones por lotes y dar información específica al supervisor de estas operaciones.

36 Sistema multimedia y su aplicación en el diseño de interfaces para la supervisión y conírol de procesos


2.7. SIMULADORES EN EL ENTRENAMIENTO DE OPERADORES DE SISTEMAS PARA CONTROL DE PROCESOS.

El objetivo de un entrenamiento sistemático es asegurar que habilidades específicas,

trabajos o procedimientos sean aprendidos. La tarea del instructor es asegurar que el material y

comportamiento aprendido por el operador es apropiado para el trabajo, asegurar que el

proceso de aprendizaje es conducido eficientemente, y asegurar que lo que es aprendido

durante las sesiones de entrenamiento se transfiere satisfactoriamente al ambiente de

trabajo 1341.

El entrenamiento es uno de los factores m h importantes en el buen desempeño del

personal de operación de un sistema de control de procesos, por lo que los simuladores

adquieren gran importancia, ya que permiten el adiestramiento del personal a bajo costo y con

altos niveles de calidad y eficiencia.

La principal función de los simuladores es permitir la práctica exhaustiva de acciones

operativas incluidas en los procedimientos en planta, tanto en situación normal, como en

anormal y en emergencia.

Sin embargo, a pesar de que los simuladores fueron creados para mejorar el desempeño

de los operadores en el manejo de la planta, también presentan desventajas. Una de las

principales desventajas es el grado de fidelidad en el funcionamiento del simulador de

entrenamiento respecto a la planta real. Ai proporcionar menos detalles que el cuarto de control

provoca que el operador adquiera hábitos indeseables, como volverse tolerante con las fallas,

ignorar indicadores de alerta, o tener diferente desempeño en una sesión de entrenamiento que

en una sesión de trabajo. Por tanto, se han establecido tres requisitos primordiales para el

diseño de simuladores [35]:


Capitulo 11. Bases Teóricas para el diseño de Interfaces

11 Alta fidelidad: La fidelidad fisica es la medición del grado de similitud entre el simulador y la

unidad referida con respecto al equipo y al código de simulación. I \

Alta flexibilidad: Para realizar entrenamientos con múltiples propósitos, se debe facilitar la

reorganización de los instrumentos y el intercambio de los módulos.

Alta modularidad: Permite añadir, eliminar o modificar módulos del sistema sin alkerar el

diseño básico.

I1

11

Generalmente los procedimientos empleados en los simuladores son los mismos' que en

la planta, sin embargo existen algunas diferencias considerables. Los simuladores deben

permitir entre otras funciones 1361: 9 Pausa 'I

11 9 Retroceso.

9 Repetición. 11 > Graficación

9 Reinicialización 'I

9 Mal funcionamientos

> Ejecución en tiempo real I/

9 Ejecución más lenta que en tiempo real

9 Ejecución más rápida que en tiempo real

9 Operación normal y en estado estacionatio

9 Registro de acciones, estados operacionales y fallas

I/

Durante el periodo de entrenamiento generalmente se aplica una preparación teórica en

aula combinada con sesiones prácticas en el simulador. Un periodo de entrenamiento debe '1

cubrir operación normal, anormal y de emergencia. I

1 Además de emular el comportamiento de la planta, algunos de los simuladores también

reproducen condiciones ambientales, tales como: sonidos asociados con el füncionyiento o

~~ ~~ ~

Sistema multimedia y su aplicación en el diseño de interfaces para la supervision y control de procesos ll

Capítulo 11: Bases Te6ncas para el diseño de Interfaces

disparo de un equipo y apertura de válvulas de alivio y de seguridad, alarmas de fuego, luces

normales y de emergencia. La simulación de condiciones ambientales es importante porque

éstas afectan el desempeño de operadores.

OBJETIVO DE LOS SIMULADORES PARA ENTRENAMIENTO

El objetivo principal de proporcionar entrenamiento a los operadores es desarrollar en

ellos habilidades y conocimientos específicos sobre el manejo y operación de la planta. A

continuación se listan los aspectos más importantes [35]:

Habilidades:

9 Diagnóstico de eventos.

P Intercambio de información.

9 Selección y uso de procedimientos de la planta.

9 Tomar el control de sistemas automáticos si es requerido.

9 Interpretar, verificar y dar prioridad a las alarmas y anunciadores.

9 Localización y manipulación de controles, verificación de respuestas.

9 Interpretación de las respuestas del sistema y predicción de los efectos en la planta.

Conocimientos:

9 Especificaciones técnicas.

9 Respuesta integrada de la planta.

9 Procedimiento del plan de emergencia

P Procedimientos de operación de la planta.

9 Procedimientos de operación en emergencia.

Además de servir como herramienta de entrenamiento, los simuladores representan

una excelente herramienta para la investigación de factores humanos, principios básicos de

diseño de interfnz hombre-máquina y estudios de desempeño y confiabilidad humana.

39


Capítulo 11: Bases Teóricas para el diseño de interfaces

REFERENCIAS:

1

[l] Mark T. Maybury (I 993). “Intelligent Multimedia Interfaz: Automated Presentation

Design”, Chapter I: Intelligent Multimedia Presentation Systems, American Association form

Artificial Intelligence, pp. 1-8.

’ \

[2] Gouid J. D.,Lewis C.,(1983). Designing for usability -key principles and what designers

think. Human factors in computing systems, pp. 50-53. New York: Association for Computing

Machinery.

I‘

11

I

[3] Engel, S.E., Granda, R.E. (1975). “Guidelines for maddisplay Interfaces”. IBM Technical

Report, Poughkeepsie N. Y. I1

[4] Hendricksm, D., Kilduff, P., Brooks, P., Marshak, R., Doyle, B. (1986). “Human \

Engineering Guidelines for Management Information Systems”. U.S. Army. Human

Engineering Laboratory, Aberdeen Proving Ground Maryland. ‘1

IS] Smith, Sid L. and Mosier, Jane N., (1986). “Guidelines for Designing User Interface

Software”, Report ESD-TR-86-278, Electronic Systems Division the MITRE Corporation,

Bedford. Available from National Technical Information Service, Springfield, VA. I(

161 Mayhew Deborah J. (1992). “Principles and Guidelines in Software User Interface Desi&.

Prentice Hail Englewood Cliffs, New Jersey, pp.8-29.

II

[7] Gould Jhon D. (1988). “How to Design Usable Systems”, IBM Research Center-

Hawthorne, New York, Chapter 3 5 : En Handbook of Human-Computer Interaction, Science

Publishers B.V. (North-Holland) pp. 757-785. ‘i

\

p Sistema multimedia y su aplicación en el diseño de interfaces para la supervisión y control de procesos

Capiíulo 11: Bases Teóricas para el diseño de Interfaces /!

[SI Card Stuart (1981). “The Model Human Processor: A Model for Making Engineering

Calculations of Human Performance”, Proceedings of the Human Factors Sociev 25”. Anual 11

Meeting, pp. 301-305. 11

I

[9] Card Stuart K., Moran P. Thomas, Newel1 Allen, (1983), “The Psychology of Human-

Computer Interaction”. Hillsdale, New Jersey London, pp. 23-44. 11

[lo] Rasmussen Jens (1986). “Information Processing and Human-Machine Interaction an

approach to cognitive engineering”, Vol. 12,Riso National Laboratory Roskilde, Denmark.

North-Holland Series in SYSTEM SCIENCE AND ENGINEERING, Andrew P. Sage, Editor. I1

I Pp. 71-85.

[ill Wickens Christopher D. (1984). “Engineering Psychology and Human Performance”,

Scott, Foresman and Company, London. i

I121 Rasmussen, J., (1980). “What Can be Learned from Human Error Reports?”, Changes in

Working Lile, eds. K . Duncan, M. Gruneberg & D. Wallis, Jhon Wiley &Sons, London,

[13] Ally, J. L., Elzer, P., Holst, O., Johnnsen, G., andSuvos: S., (1985). “Literature and User

Survey of Issues Related to Man-Machine Interfaces for Supervision and Control Systems”,

ESPRIT P600, Scottish HCI Centre Report No. AMU860301S, Scottish HCI Centre, George

House, George Square, Glasgow, Scotland, I985.

1141 Shneiderman, B., (1982). “The Future of Interactive Systems and the Emergence of Diyct

Manipulation”. Behavior and information Technology, Vol. 1, pp. 237-256.

[is] Shneiderman, B., (1983). “Direct Manipulation: A Step beyond Programming

Languages”. IEEE Computer, Vol. 16, pp. 51-69. I

U 41

Sistema multimedia y su aplicación en el diseño de interfaces para la supervisión y control de procesos ’

I

Capiíulo 11. Bases Teóricas para el diseño de Interfaces I

[16] Shneiderman, B., an4Margono, S., (1987). “A Study of File Manipulation by Novices

Using Command vs. Direct Manipulation”. Proceedings of 26th Annual Technical Symposium

of the Washington, D. C. Chapter of the ACM, Gathersburg, MD: National Bureau of

Standards.

[17] Kashiwazaki-Kariwa (1996). “ABWR Type Control Room Panel Development of Third

Generation Control Panels”. Electric Power Company Nuclear Power Plant Construction. !

11

[18] Beltrachi, E. L., (1990) “A Direct Manipulation System-Process Interface”. Topical

Meeting on Advances in Human Factors Research on ManlComputer Interactions (Meeting

Proceedings), Nashville, Tennessee. American Nuclear Society. Pp. 286-291.

11

[I91 Chávez, C., Golberg, J. H. and Edwards, R. M., (1991). “A Human Factors Evaluation ofa

Highly Automated Nuclear Power Plant”. Ai 91, Frontiers in Innovative Computing f i r the

Nuclear Industry (Meeting Proceedings), Jackson, Wyoming. American Nuclear Society. Pp. 403-41 1.

[20] Alty, J.L., and Bergan M., (1992). “Guidelines for Multi-Media Interface Designkin a

Process Control Aplication”. Int. Con$ On Design and Safety ofNuclear Reactors, ANP 1992

Vol. 4 Atomic Energy Society of Japan.Pag. 43,l-7 11

\

[21] Deatherage, B. H. (1972). “Auditory and other sensory forms of information

presentation”. In H.P. Van Coti and R. G. Kinkade (eds.),Human engineering guide to

equipment design. Washington: Government Printing Office.

I

I

[22] J. Beagles-Roos, (September 1985). “Specific Impact of Radio and Television on Adult

Story Cornprehension”, Presented at a meeting of the Amencan Psichological Association, Los

Angeles. I

42

, Sistema multimedia y su aplicacion en el diseno de interfaces para la supervision y conwoi de procesos

‘I

!i Capítulo 11: Bases Teóricas para el diseño de Interfaces

(23) Rewey, K. L, Dansereau, D. F., Skaggs, L. P., Hall, R. H. & Pitre., U. (1989), “Effects of

Scripted Cooperation and Knowledge Maps on the processing of Technical Material”,”Journal

of Educational Psychologv Vol. 81, pp. 604-609. I!

[24] Marmollin, (1991). “Multimedia from the perspectives of Psychology”. Proceedings of the

Eurographics Workshop on Multimedia. Stockholm.

[25] Edwards, A. D. N., and I.J. Pitt, (1988). “Adapting the MacIntosh and other Graphical

User Interfaces for Blind Users”. Special Edition of Info Visie Magazine Vol. 4, No. 3.

(261 Alty J. L., and McCartney, C. D., (1992). “Managing Multimedia Resources in Process

Control: Problems and Solutions”. Multimedia: Systems, Interactions and Applications, (L.

Kjelldahl de.), pp. 293-306, Springer-Verlag, Berlín.

II

I1

(271 Sanders S. Mark, and McCormick J. Ernest, (1997). Human Factors in Engineering and

Design. McGraw-Hill Book Company, pp. 154-155.

(28) Mudd, S. A,, (1961). ‘The scaling and experimental investigation of four dimensions of

pure tone and their use in an audio-visual monitoring problem”. Thesis, Lafayette, Pdrdue

University.

[29] Lickiider, J. C . R., (1961). “Audio warning signals for Air Force systems” (TR 60-814).

USAF, Wright Air Development Division, Wright Patterson Air Force Base. I d

[30] Adams, S., and Trucks, L. (1976). “A procedure for evaluating auditory warning signals”.

Proceedings of the 6th Congress of the International Ergonomics Association and Technical

Program for the 20th Annual Meeting of the Human Factors Society. Santa Mónica, CA:

Human Factors Society.

43 ~ ~~ ~~~

Sistema multimedia y su aplicación en el diseño de interfaces para la supervisión y cona01 de procesos ,,

Capítulo 11: Bases Te6ricas para el diseño de Interfaces

I

[31] National Instruments, “IEEE 488 and VXIbus Control, Data Acquisition and Analysis”,

1993. ) ‘I t

1321 http://www/natinst.com

(331 http://www3.ios.com/-abci/intellut.html

(341 Holding D. H. “Concepts of training, Department of Psichology University of Louisville”.

Handbook ofHuman Factors edit. Gavriel Salvendy, pp. 939. I

I [35] “Role of simulators in operator training task 5”. OECD/NENCSNI/Principal working

group No. 1 Expanded task force on human factors. Part 2. Simulator fidelity issues.

(361 ANSUANS 3..5-1993. “American National Standard for Nuclear Power Plant Simulator

for use in operator training and examination ANS”. La Grande Park, Illinois, 1993.


http://www/natinst.com

http://www3.ios.com/-abci/intellut.html

,Capítulo 111:

Diseño e Implementación

En este capítulo se analiza la problemática del simulador réplica de la

Central Nucleoeléctrica de Laguna Verde (CNLV) como antecedente al presente

trabajo. También se expone la arquitectura del simulador de aula (SimAula) del

Laboratorio de Seguridad Nuclear (LSN) y las'implementaciones de sonido que

se hicieron con el fin de mejorar la interiaz de dicho simulador, objeto de este

proyecto. Se presenta el diseiio y la implementación de las alarmas en los

paneles de control BB09, BBIO y 6 6 1 1 del SimAula, los cuales son una

representación virtual réplica de los tableros de la sala de control de la Unidad I

de la CNLV; asimismo, se muestran las implementaciones de sonido sa los

despliegues gráficos de los códigos MAAP y VASIJA (que forman también,parte

esencial del Simulador de Aula).

Capítulo 111: Diseño e Implementation

3.1. ANÁLISIS DEL SISTEMA En este punto se anaiiza el porqué de este trabajo, examinando el sistema que

sirvió de base para el presente trabajo, sus características y sus deficiencias. Asimismo, se

plantean los objetivos que persigue este trabajo al implementar sonido al sistema actual.

3.1.1. Antecedentes Simulador réplica de la Central Nucleoeléctrica de Laguna Verde (CNLV).

El simulador de alcance total para el adiestramiento de operadores de la Central

Nucleoeléctrica de Laguna Verde (CNLV) fue diseñado, construido y puesto en operación

por el Instituto de Investigaciones Eléctricas (HE) en 1991, habiendo participado personal

de los Departamentos de Simulación, Energía Nuclear, Electrónica, comunicacioes y de

Instrumentación y control.

Este simulador está integrado por tableros de instrumentos idénticos ai cuarto de control

de la CNLV, así como por equipos y programas de cómputo que reproducen fielmente la

operación del mismo y los efectos de las diversas acciones y maniobras de control que

deben efectuar los operadores.

Algunas de las ventajas que se obtuvieron con el desarrollo de este simulador son:

a) Los operadores ejercitan las acciones y maniobras de control en una ampiia gama de

condiciones de operación normales y de emergencia.

b) El adiestramiento se realiza en un cuarto de control idéntico ai de la central.

c) Se ahorran divisas ai no tener que enviar a los operadores a adiestrarse al extranjero en

simuladores genéricos que no tienen el mismo alcance ni la misma disposición de los

instrumentos.

d) Es posible actualizar los escenarios de adiestramiento para incorporar las mejoras

continuas que se realizan en los procedimientos de operación de emergencia y las

actualizaciones de la propia planta.

46 Sistema multimedia y su aplicación en el diseño de interfaces para la supervision y control de procesos

Capítulo 111: Diseño e Implementación

El simulador desarrollado cumple con todos los requerimientos estipulados por la

Comisión Nacional de Seguridad Nuclear y Salvaguardias (CNSNS) y en particular con los

determinados por la norma ANSVANS-3 de 1985, en la cual se basan la mayor parte de los

siinuladores existentes.

Problemas con el simulador actual de la CNLV

A pesar de que el simulador de entrenamiento actual de la CNLV es capaz de reproducir

completamente una gran variedad de escenarios operacionales bajo condiciones de operación

normal, anormal y de emergencia, éste no fue diseñado para reproducir escenarios bajo

condiciones extremas tales como transitorios severos y secuencia de accidentes.

El objetivo básico de un simulador de entrenamiento, como el que se utiliza en la

CNLV es el de entrenar ai personal de operación en el seguimiento de procedimientos de

operación bajo un esquema fiel, tanto físico como funcional considerando la ejecución en

tiempo real. Por tanto, un simulador réplica resulta inadecuado para permitir al operador

efectuar un anáiisis detallado y más profundo, para lograr un entendimiento completo de la

dinámica del proceso o procesos simulados y de sus interacciones.

3.1.2. Prototipo del simulador de aula para la Central Nucleoelédrica de Laguna Verde del IIE

Entre los principales objetivos de la Unidad de Resultados de Energía Nuclear (UREN)

del Instituto de Investigaciones Eléctricas (IIE), está el desarrollo del Laboratorio de Seguridad

Nuclear (LSN). El LSN representa un esfuerzo multidisciplinario para integrar la experiencia y

desarrollo tecnológico acumulados por más de una década en la UREN con ayuda técnica y

financiera de diversos organismos tales como el Organismo Internacional de Energía Atómica

(OIEA), el Electrical Power Research Institute (EPR-) y la comisión Federal de Electricidad

(CFE) entre otros[5].

47 Sistema multimedia y su aplicacih en el diserio de interfaces para la supervisión y conaol de procesos

Capítulo 111: Diseño e Implemeniaci6n

El principal componente del Laboratorio de Seguridad Nuclear es el sirnulador de aula

(Sidula), cuyo propósito primordial es ser utilizado como una herramienta de análisis para un

entrenamiento más eficiente y completo del personal de operación de la CNLV. El principal

objetivo al desarrollar el simulador de aula, es desarrollar un sistema de cómputo modular,

robusto, y reconfigurable, que permita la simulación del funcionamiento de los principales

sistemas de la CNLV, así como la representación virtual mediante gráficos por computadora,

de paneles de control correspondientes a estos sistemas.

I1

I/

I1

I1

I/

El simulador de aula se diseñó e implementó como un sistema de computadoras

intercomunicadas entre sí, controladas por una interfaz gráfica la cual permite la representación

virtual y emulación de paneles de control e instrumentación asociada, así como la exhibihn de

diversos despliegues gáfkos de información.

11

11

Códigos nucleares en el simulador de aula

La simulación de los procesos nucleares en el SimAula se realiza mediante códigos

nucleares especializados que permiten la simulación y un análisis muy preciso del desarrollo de

los procesos en condiciones de operación normal, eventos transitorios y secuencia de

accidentes severos. ll

Actualmente el prototipo del Simulador de Aula de la UREN incluye versiones I\

interactivas de los códigos VASIJA Y MAAF’.

El código de VASIJA 191, resuelve sistemas de ecuaciones diferenciales que resultan de

efectuar balances de masa, energía y momento en ciertos volúmenes de control, además de

cinética puntual. Puede ser utilizado para simular transitonos operacionales bajo operación

normal del reactor y algunas situaciones especiales anormales que no incluyan grahdes

pérdidas de reiiigerante. Este código ha sido probado para transitorios por disparo de luna

bomba de recirculación y por falla del controlador de agua de alimentación. También se pueden

simular con bastante precisión otros transitorios causados por disminuciones de presión ildel

ll

48 I/

Sistema multimedia y su aplicación en el diseiio de interfaces para la supervisión y control de procesos ,,

i!


regulador, incrementos o disminuciones'en el flujo del refiigerante y aumentos o disminuciones

de temperatura del moderador debido a diversas fallas de los sistemas involucrados.

I!

I1

El código MAAP (Modular Accident Analysis Program) [SI fue desarrollado

originalmente como parte del programa Industry Degraded Core Rulemarking orientado a la

fenomenologia de escenarios de accidentes que podrían dañar ai núcleo. Actualmente, el

Electrical Power Research Znsrifufe (EPiü) tiene la responsabilidad de mantener y mejorar el

código MAAP por medio de un grupo activo de usuarios del mismo. Su principal objetivo es

asegurar que el código sea una herramienta confable para su uso en la realización de

Evaluaciones Individuales de Planta (EIP), ejercicios de planes de emergencia y en la revisión

de la efectividad de procedimientos de emergencia.

I1

1

I

11

Existen tres categorías de accidentes que pueden ser analizados con W: accidentes 1)

de pérdida de refiigerante (LOCAS), LOCAs pequeños y eventos transitorios.

A continuación se hace un breve análisis de la arquitectura general del sistemalen el

momento en que fue adoptada para realizar el presente trabajo experimental.

I1

3.1.3. MODULOS GENERALES DEL SISTEMA' 1

El simulador de aula ha sido implantado como un sistema multi-computadoras,

reconfgurable y modular. El uso de varias computadoras pemite ejecutar en paralelo diversos

modelos de simulación sin comprometer la adquisición de datos y el control en tiempo red. La

reconfigurabilidad ofrece mayor flexibilidad en el acceso, despliegue y optimización de los

11

parámetros de la consola de control, y la modularidad facilita que un componente o 81

' El Simulador de Aula prototipo, desde su concepción hace más de tres años, ha sido sujeto a diversas modificaciones tendientes a aumentar y mejorar su funcionalidad. La descnpcibn del sistema en esta sección corresponde al estado del sistema en el momento de ser adoptado como plataforma experimental para la incorporaci6n de aspectos multimedia, objeto del presente trabajo de tesis. ~

49 S i e m a multimedia y su aplicación en el disefio de interfaces para la supervisión y control de procesos I'

!I

Capitulo 111: Diseño e Implementación

componentes sean agregados, eliminados o modificados sin afectar el resto de los componentes

o al sistema mismo[5].

Existen cuatro módulos principales(51:

I.

I1

III.

N

E1 módulo de los paneles de control.

El módulo de simulación de la planta.

El módulo de monitoreo de parimetros.

El módulo de visualización. 1,

'I

Estos módulos y sus inkeracciones junto con el módulo de comunicación, se encuentran I1

representados en la figura 3.1. que se presenta a continuación.

I1 Módulo de paneles

de control I!

compartida

Sección

monitoreo de visualización

parámetros

FIG. 3.1. Arquitectura general del simulador de aula[S]

La dinámica para la simulación de los diversos paneles de control es controlada por el

módulo de paneles de control. En su modo de operación normal, el proceso del panel de 11


Capítulo 111: Diseño e Impiementación

control provee parámetros de salida de controladores manuales o automáticos al módiilo de

simulación de la planta, vía la memoria compartida de la consola de control, mientras que

recibe los parámetros de salida, del módulo de simulación de la planta a través del segmento de

memoria compartida de simulación de la planta.

d

I

I\

El módulo de simulación de la planta está compuesto por diferentes módulos de

acuerdo a los diferentes modos de operación del sistema. Para los modos de análisis de

transitorios y accidentes severos, el módulo de simulación de la planta se respalda mediante los

códigos VASIJA y MAAF', respectivamente.

11

Por medio de sus correspondientes segmentos de memoria compartida, ambos módulos,

el de paneles de control y el de simulación de la planta, se comunican con el módulo de

monitoreo de p d e t r o s de la planta ylo el módulo de visualización de la planta. Los módulos

de monitoreo de parámetros de la planta y el de visualización reciben datos de entrada a través

de sus respectivos segmentos de memoria compartida. Estos dos módulos también tienen la

capacidad de enviar parámetros de control vía sus segmentos de salida de memoria compartida.

El módulo de moniroreo deparámefros es usado para monitorear y controlar los parámetros'be

seguridad de la planta (módulo SEPS), mientras que el módulo de visualización se usa paraja

visualización y control de componentes y sistemas durante secuencias de accidentes severos

I1

I(

(módulo W).

3.1.4. INTERFACES DEL SISTEMA Uno de los principales componentes del sistema es la interfaz hombre-máquina, con 1; I

cual el usuario del sistema interactúa vía manipulación directa con los objetos gráficos que

representan fielmente la instnimentación de monitoreo y control. Asimismo, la interfaz permite

al usuario navegar a través de los diversos despliegues involucrados de una forma sencilla:

interactiva y amigable. I/

51 I Sistema multimedia y su aplicación en el diseño de interfaces para la supervisión y control de procesos

Capítulo I11 Diseño e hplementación

La interfaz del operador está compuesta de tres interfaces gráficas, la interfuide los

paneles de control, la interfaz de los parámetros de seguridad de la planta y la intedaz de

visualización.

I

I'

!!

,I Las interfaces de los paneles de control son del tipo de manipulación directa que

simulan los paneles de control. Proporcionan una representación virtual de los instrumentos y

controles cuya funcionalidad es similar a los del simulador réplica actual. Por medio 'be la

manipulación directa, el sistema permite al operador visualizar y manipular la instrumentación

vía interacción con el ratón o mediante pantallas sensibles al tacto (touch-screen).

It

!,

Actualmente el sistema contiene una representación completa de los paneles BB'-09,

BB-IO y BB-11 de la CNLV. Las figuras 3.2,3.3 y 3.4 nos muestran las interfaces que simulan

dichos paneles de control.

I\

!I

I,

'1

Estos paneles contienen la instrumentación asociada a los sistemas de refrigeración#, de

emergencia, agua de servicio nuclear, recirculación e instrumentación y control nuclear. Los

despliegues gráficos que representan los paneles de control se han diseñado para que tengan

una alta similitud con los paneles del simulador de entrenamiento actual, pero tratando "de

evitar un realismo excesivo e innecesario que' podría crear un ambiente complejo para ,!el

operador.

¡I

,I

!/

Los despliegues del módulo de los paneles de control permiten manipular algunos

parámetros del módulo de simulación de la planta para la reproducción de diferentes escenarios

operacionales. También permiten el monitoreo de parhetros críticos mediante instrumentos de

medición e informativos. La interacción con los despliegues recrea la manipulación en uh tablero real de la planta. '-

!I

52 Sistema multimedia y su aplicacion en el diseño de interfaces para la supervision y conuol de procesos

I ff

Fig. 3.3. Panel de conirol BBlO


La interfaz de los paneles de control está dividida en tres áreas: en la parte superior

de la pantalla se encuentran el área de menús con diferentes opciones para el manejo de

archivos, acceso a la información suplementaria y control de subprocesos. El área central es

donde se despliegan los paneles de control y finalmente, en la parte inferior de la interfd se

localiza el área dedicada al control de la visualización de los despliegues (menú :de

navegación).

La intetfaz de los pardmetros de seguridad de la pianta es una copia simplificada

de algunos despliegues del SEPS (Sistema de Exhibición de Parámetros de Seguridad) de 'la

CNLV. Esta copia contiene solamente los despliegues relacionados con los actuales

procesos simulados, entre ellos están los diagramas mimicos de los sistemas de

refrigeración de emergencia, despliegues de gráficas de tendencia y gráficas parátnetro vs.

parámetro.

I

11

/ /

La Zntetfuz de visuulización es muy similar en concepto y equivalente en

funcionalidad a la interfaz del control de proceso. La diferencia es que esta interfaz permite

el acceso a un conjunto de despliegues gráficos que representan la vasija del reactor, los

sistemas de refrigeración de emergencia y la contención primaría. Estos despliegues han

sido construidos para la animación y visualización de eventos transitorios (visualización del

código VASIJA) y para visualización de accidentes severos (visualización del código'

I

I1

I/

La figura 3.5. muestra el despliegue principal de visualización del código VASIJA,,,

el cual es una representación gráfica de la vasija del reactor. Incluye el sistema de agua de I

alimentación, sistema de recirculación, flujo de vapor a la turbina, bombas de sistemas de

refrigeración de emergencia y válvulas principales. El despliegue además contiene diversos

componentes gráficos para el monitoreo de parámetros principales (posición de válvulas, '

flujos, nivel, potencia, etc.) así como componentes de control (controladores, disparo de It

11

bombas y puntos de ajuste). I/

I1

56 1



La interfaz hombre-máquina para la visualización del código VASIJA es del tipo

manipulación directa mediante la cual es posible controlar el proceso de simulación (código

VASIJA) interactuando directamente sobre los principales componentes gráficos mediahe

el ratón o en pantallas sensiblesal tacto. I1

Adicionalmente se tiene un despliegue para gráficas de tendencia, el cual contiene

19 de la principales variables en'forma parametrizada, necesarias para un análisis adecuado

de los principales eventos.

La kterfaz hombre-máquina para la visualización del código VASIJA contiene

menú de opciones de control, mediante el cual es posible seleccionar un evento transitonh

entre una lista preestablecida, así como efectuar el paro/arranque de la simulación, pausa, II

I /

restablecer y salida. 11

Finalmente, el despliegue cuenta con un anunciador de las principales alarmas para

alertar ai usuario sobre el desarrollo de cualquier evento transitorio.

En cuanto ai despliegue de visualización del código MAAP IS], es una'

representación gráfica de la vasija del reactor, núcleo y principales componentes, sistemas''

de refrigeración de emergencia y contención primaria. El despliegue está orientado a

proporcionar una animación completa de sistemas, componentes y parámetros para la 11

visualización, control y principalmente el análisis de secuencia de accidentes severos vía

interacción en línea y fuera de línea (mediante archivos de datos de salida) con el código ,/

w.

ll

11

58 : Sistema multimedia y su aplicación en el diseño de interfaces para la supervisión y control de procesos

t

I

V -- o

I

Capítulo 111 Diseño e hplementación 1)

3.1.5. Planteamiento de Objetivos II

El objetivo principal de añadir sonido al sistema es lograr una mayor fidelidad y

aumentar la comprensión del operador en las acciones y procesos involucrados, así como

aumentar su estado de alerta.

11

I

11

En el presente trabajo se plantea una implementación de sonido en tres difereptes

modalidades: retroalimentación, ambiental y en alarmas.

2.4.3.2. ESPECIFICACI~N DE REQUERIMIENTOS I Los requerimientos definen con precisión las caractensticas del sistema a desarrollar y /I

establecen los alcances del mismo, sirven de base para el diseño del sistema, de referencia para

las pruebas del producto final y de fuente principal de información para utilizar el producto de

programación. I1

3.2.1. Requerimientos de hardware y software 11

Para el desarrollo del presente trabajo (implernentación de sonido en las interfaces del

prototipo del simulador de aula) se requiere el siguiente hardware: 11

a) Una Alphastation 200 4/166 con vídeo básico y vídeo JPEG.

b) UM Ahastation 500/333 con vídeo básico y video JPEG.

C) Tarjeta de sonido Alphastation

d) Un amplificador de sonido

e) Bocinas

9 Micrófono

81

En cuánto al software, la implementación de sonido requiere el software MuZtimediu

Services v2.2. for Digital ünix, el cual incluye capacidades de audio y vídeo para estaciones de i I/

60 ! Sistema multimedia y su aplicación en el disefío de interfaces para la supervisión y control de procesos

Capítulo 111: Diseño e implementación

trabajo digital, y proporciona una libre+a I completa de programación para desarrollar nuevas aplicaciones multimedia. 1G

El paquete Multimedia Services está constituido por dos componentes: 1)

Runtime, que habilita el uso de aplicaciones de audio y video sobre estaciones de trabajo.

Herramientas de desarrollo de aplicaciones (Software Development Kit, SDK)

Las principales caractensticas del Runtime incluyen:

1) Un conjunto de programas de utilenas multimedia:

DecSound-Registrador de Audio, playback y una utilería para edición de sonid8.

AlphaVCR-Registrador de video y una utilería de playback soportando formatos

de PEG, AVI y MPEG.

Audiocontrol- Utilena de selección y control del dispositivo de Audio.

VideoOdyssey-una utilena de protector de pantalla en video (vídeo screen saver).

2) Soporte para varios formatos de datos y archivos multimedia:

+ WAV : IMA ADPCMM, G.711 u-law, 8/16 bits lineales.

t Sun AU u-law

t AV1

t Vídeoh4PEG

+ AudioMPEG

El software para desarrollo de aplicaciones (SDK) proporciona la interfaz de

programación para incorporar las funciones de audio y vídeo dentro de las aplicaciones. Este

incluye:

1) Una interfa de grabación y playback de audio en forma de onda (WAV), proporcionando:\

'!

;I + Una interfaz de dispositivo independiente para el hardware de audio.

+ Funciones de grabación, playback y control de audio.

+ Funciones de configuración, abrir y cerrar el dispositivo. I1

1) 61


I)

t i


2) Compresión y descompresión de audio

t Funciones de compresión y descompresión IMA ADPCM.

3) Captura de vídeo

t Funciones de configuración, abrir y cerrar el dispositivo.

t Funciones de selección del formato.

4) Compresión, descompresión y presentación del vídeo.

t Funciones de compresión y descompresión

t Funciones de control de presentación (brillo, contraste, saturación y nitidez) ( 8

5) Salida de vídeo

t Funciones para mandar datos (incluyendo gráficos, vídeo y texto) hacia un

dispositivo de salida de vídeo tal como un VCR o un monitor de televisión. /I

I 6) Archivos I/O Multimedia

t Funciones para crear, leer y escribir archivos en disco que almacenen datos de audio

en formato WAV y MPEG, además de datos audio+vídeo en archivos con format&

AV1 y MPEG. ll

,I

7) Ejemplos de código fuente p a a algunas de las funciones listadas arriba.

3.2.1.1. Requerimientos de software adicional Además del software de multimedia para estaciones de trabajo, fue indispensable contar

11

con el siguiente software:

a) Digital UNIX v3.2 o supenor (Sistema Operativo)

b)

1,

!

Digital UNIX C Developer's v1.3 o superior

62' Sistema multimedia y su aplicación en el diseño de interfaces para la supervisión y control de procesos ,

,t


3.2.2. Restricciones del sistema 1

I

. El Simulador de Aula podrá ser ejecutado en una estación de trabajo Digital que*

contenga el software básico del sistema : C para Unix, Data Views y las

. herramientas básicas del software Multimedia Services for Digital Unix.

. 1. Retroalimentación al operador.

El sonido implementado al Simulador de Aula será en tres modalidades: 11

El objetivo del sonido en el menú de navegación es proporcionar

retroalimentación en las acciones que ejecuta el operador. Esto es, que el operador al

realizar una tarea utilizando el menú de navegación(hacer un zoom de acercamiento o

alejamiento, deshacer una acción, etc), reciba confimación sonora de que la acción ya

fue aceptada por el sistema; o viceversa, cuando ha ejecutado una acción errónea se de

cuenta inmediatamente al escuchar un sonido que marca un error.

I \

\

,I

'I

I1

Todos los botones de control del menú de navegación tienen dos sonidos. el'de

aceptación del sistema (ding.wav), que se da cuando el sistema detecta una acción y es

posible realizarla; y el de error (error.wav) que ocurre cuando el usuario realiza una

acción imposible de realizar por el sistema (por ejemplo, hacer un zoom de

acercamiento cuando la imagen ya dio el máximo acercamiento posible, querer ver una

zona demasiado pequeña en la pantalla, etc.).

11

11

11

I

I1

2. Sonido ambiental en instrumentos de control.

Un sonido ambiental es aquél que trata de reproducir fielmente el sonido de un

objeto o evento del mundo red. Uno de los objetivos al implementar sonidos

ambientales en interfaces es hacer la interfaz más familiar ai usuario, de tal forma que

sienta que está en íntimo contacto con los procesos que está monitoreando.

I(

11

3. Sonido en la detección de alarmas.

El sonido en alarmas contempla lo siguiente:

63 Sistema multimedia y su aplicación en el disefio de interfaces para la supervisión y control de procesos Ir


a) La llegada de una señal de alarma sera indicada en el tablero de alarmas por un parpadeo de

color rojo, además de un sonido que solo podrá ser silenciado por medio del tableio de

control de alarmas.

b) El tablero de control de a l m a s está diseñada para realizar cuatro acciones: Silencih el

sonido, Reconocer la a l m a (quitar el parpadeo rojo del tablero de alarmas), R e s t a d la

alarma (Poner en su valor inicial todas las variables relacionadas con la alarma que hhbía

sucedido) y Probar las alarmas (el tablero de alarmas se pone de color rojo y el sonido

asignado a las alarmas se oye por un lapso corto de tiempo).

3.3. DISEÑO DEL SISTEMA CON LA INCORPORACI~N DE

'I

I/

SONIDO. Siguiendo los principios de Ingeniena de Software, es ideal que previo a la etapa de

diseño se tenga una visión clara de los requerimientos del sistema, y que se documente la

especificación de dichos requerimientos. Hasta el momento se conoce el problema y 1;s

objetivos, así como los requerimientos del sistema. En este punto se explica en detalle la forma

en que se diseñó la estructura de la implementación de sonido en el sistema.

11

I

'I

La fase de diseño se divide en tres etapas:

a) Arquitectura

b) Diagrama de estructura

c) Detalle de módulos

ii

3.3.1. Arquitectura Para el diseño de la arquitectura de un sistema de programas se procede, en primed

instancia, a dividir el sistema en subsistemas (y posiblemente estos subsistemas dividirlos a su

vez, en partes funcionalmente más manejables).

64, Sistema multimedia y su aplicación en el diseño de interfaces para la supervisión y control de procesos

18


La arquitectura del simulador de aula altamente modular, permitió la incorporación de

La figura 3.7. presenta .una visión iconográfica del simulador de auia con la

sonido de una manera sencilla y directa.

implementación del módulo de sonido.

Figura

a Suriión global de nunotia

D ~COMUMCACION 1

+ 4

Visión iconográfica del simulador de aula con la incorporación del módulo de sor



Cómo se puede observar en la figura antenor, se tienen nodos (seMdores) '1

independientes para ejecutar en su totalidad el Simulador de Aula. El nodo O es el que contiene

el proceso de simulación del código MAAP; y mediante protocolos de comunicación manda las

señales (valores) ai nodo que se encarga de visualizar este proceso de simulación. El nodo

DENOl a su vez, hace un proceso similar con el código de VASIJA. ;I

El nodo lsnOl contiene todos los despliegues visuales del Simulador de Aula, este nodo

recibe las señales Correspondientes del nodo O y el nodo DENOl para desplegar tanto' las

gráficas de tendencia de MAAP y VASIJA, como la simulación de los paneles de control

bb09, bblO y bbll; y los despliegues de MAAF' y VASIJA. En este nodo es dónde también se

encuentra la implementación de sonido. I!

El módulo de sonido interactúa con el despliegue de los paneles de control y en' el

despliegue de VASIJA. \

81

Ejecución del sistema

El simulador de Aula tiene que ejecutarse de la siguiente manera:

A) Para los Paneles de control y el despliegue del código MAAP :

1. En el nodo O se tiene introducir la siguiente instrucción:

@maapview

2. En el nodo IsnOl, en el subdirectono /discol/simaula/maapsim/

csh -x maapview.com

3. En el nodo IsnOl, en el sudirectono /discol/simaula/panelsimsd

csh -x panelsimsd.com

B) Para el despliegue del código de VASIJA

1. En el nodo DEN01 se tiene que introducir la siguiente instrucción:

@vassim

2. En el nodo IsnOl, en el subdirectono /discol/simaula/vassimsd

csh -x vassimsd.com

II

66 ,I Sistema multimedia y su aplicación en el diseno de interfaces para la supervisión y control de procesos

http://maapview.com

http://panelsimsd.com

http://vassimsd.com


3.3.1.1. Arquitectura del módulo de sonido El sonido adicionado al sistema contempla tres modalidades:

Retroalimentación a las acciones del operador en el menú de navegación de los

paneles BB-09, BB-IO y BB-I 1 ; así como en los botones de control del despliegue

del código VASIJA.

Sonido en el tablero de alarmas del panel BB-09 y en el anunciador de alarmas del

despliegue del código VASIJA.

Sonido ambiental en instrumentación de control para accionar componentes yío sistemas 'I

En el siguiente esquema se puede observar en forma general el módulo de sonido: 11

I1

MODULO DE SONIDO

Figura 3.8. Esquema general del módulo de sonido y su implemeniación en el &tema I/


1


Selección de sonidos para los despliegues del sistema

En la selección de sonidos se realizó primero una recopilación de sonidos WAV que

pudieran servir para la implementación en el sistema. Inicialmente se implementaron los

sonidos de I :

ding.wav : Para el menú de navegación.

error.wav : Para el menú de navegación.

alarmal.wav

alarma2.wav : Para el anunciador de alarmas del despliegue del código VASIJA. ,,

ll

!t

11

: Para el tablero de alarmas del panel BBO9, BB-IO y BB-11.

click.wav : Para el accionar de manijas del panel BB-09, BB-IO y BB-11. .I

mecha.wav : Para iniciar el sistema. IL

baby.wav : Para finalizar el sistema.

Todos los sonidos anteriores tuvieron que ser reeditados mediante la herramienta

DecSound para lograr un sonido más real y con un volumen adecuado.

Los sonidos de las alarmas fueron reemplazados por los sonidos originales de las

alarmas que se generan en los paneles de control BB-09, BB-10 y BB-11; así como la alarma

del despliegue del código VASIJA de la Unidad 1 de la CNLV. i

11

I1

3.3.2. Diagrama de Estructura La estruchira del sistema está basada principalmente en la subdivisión jerárquica y

funcional de sus programas. Como se puede observar en la figura 3.9 el Simulador de Aula

tiene tres módulos principales: Maapsim, Vassimsd yPanelsimsd. Estos módulos a su ve;, I

están subdivididos en tres sub-módulos que contienen los programas principales del Simulador.

I

1)

2 1 ' Algunos sonidos se obtuvieron del sisiema Windows95 y oircn fueron grabados especialmente para esta aplicación

68 Sistema multimedia y su aplicación en el diseño de interfaces para la SUpeNiSi6n y control de procesos


Fig. 3.9 Diagrama de estructura del Programa del Simulador de Aula 1

1

El módulo de sonido está implementado dentro de los sub-módulos src (que contiene

los programas ejecutables del sistema) y .dentro de duros (que contiene todos los valores

iniciales de los objetos y las almas del sistema). La estructura del módulo src que incluye el

módulo de sonido del Punelsirnsd se muestra a continuación:

I I/

I1

11

/

bb09view. c bb09view.h -

Rutinas para desplegar Módulos de sonido**

la interface, obtener y

escribir valores en la

memoria compartida, etc.

Fig. 3.10. Dingrama de estructura de los programas fuenie (src) de-Panelsimsd

El módulo de sonido contiene instrucciones de ejecución de sonido en vanas partes del

programa bb09-view.c, para realizar todas los sonidos de retroalimentación pertinentes al I!

panel de navegación de la interface. Además contiene las subrutinas de sonido y control d?

I/

69 Sistema multimedia y su aplicación en el diseño de interfaces para la supervisión y MnUOI de procesos

SI


alarmas que manipulan los accesos a memoria compartida en dónde llegan las señales (valores) 11

de alarma. 1/

Alarma - sonido0 Restablece-alarma() Botónqruebao Parpadeo - alarma()

Figura 3.11. Diagrama de estructura del módulo a2 Sonido para elpanel bb09.

3.3.3. Detalle de módulos Como fue descrito en el punto anterior, el Simulador de Aula está subdividido en ves

componentes principales: Maapsim, Vassimsd y Panelsimsd. Éstos a su vez, están divididos en

src, datos y view.

m.

11

Contiene todos los archivos fuente y ejecutables del módulo en cuestión (paneles

control, código maap o código vasija). También incluye todos los archivos cabecera (*.h). ,!

&. 1

I

Contiene los archivos tipo texto que son la entrada básica de los programas ejecutables;

es decir, contiene todos los valores iniciales del sistema, y es aquí dónde se declaran todos los

objetos desplegados en la interface junto con sus valores iniciales.

Contiene todos los despliegues gráficos y objetos de la interface, hechos en el software de Dataviews (herramienta gráfica utilizada en el desarrollo del Simulador de Aula). 1)

70 Sistema multimedia y su .aplicación en el diseño de interfaces para la supervisión y control de procesos

.-

!I

Capitulo 111: Diseño e Implemehción

Para desarrollar el módulo de sonido para las alarmas del panel BB-O9 se hivieron que I

incorporar instrucciones y declaraciones correspondientes en los siguientes archivos: 14

bb09intobj.dat. Este archivo contienen toda la información relacionada con los objetos

gr%cos del panel bb-09 que permiten una interacción con el usuario. Aquí se encuentrah los

botones de control de alarmas y las palancas. La información contenida en este archivo de

datos es secuencial y corresponde a: 11

+ índice (es secuencial)

+ nombre del objeto giiifico

+ número de variables asociadas

+ tipo (objeto o gráfico)

+ contador (sin uso actual)

+ referencia (sin USO actual)

+ segmento de memoria compartida ai que pertenece.

+ canal de memoria compartida

+ valorinicial ‘I

@ bb09obj.dat. Este archivo contiene la información de los objetos &cos del panel BB-O9

que no requieren de una interacción con el usuario. Aquí se encuentran los datos referentes1 I a

las alarmas. La información contenida en este archivo es secuencial y es similar a la contenida

en el archivo bb09intobj.dat. NI

II a bb09-eva1.c. Este archivo es el encargado de recibir datos del código principal

(bb09view.c) para evaluar los cambios que se hayan generado en los objetos gráficos y

escribirlos en la memoria compartida. Esto lo hace a traves de un procedimiento llamado

shm-wrife el cual recibe como parámetros el canal de memoria del objeto a modificar, SU /I

nuevo valor, y el tipo de dato del valor. Por ejemplo:

I,

shm-write (300, 0.5, “f)

El ejemplo se refiere ai canal 300 con valor inicial de 0.5 que es de tipo “float”.

71 Sistema multimedia y su aplicación en el diseño de interfaces para la supervisión y control de procesos 8 ,

Capitulo 111 Diseño e Implementación

bb09view.c: Este archivo contiene el código principal de despliegue del panel BB-09.

Contiene todas las subrutinas en Dataviews que generan los despliegues, así como el control de

éstas a través de subrutinas que manipulan los accesos a la memoria compartida. En este

código se incorporó el módulo de sonido, el cual consta de las siguientes subrutinas:

1

11

I1

II

I1

&Alarma-sonido(). Este procedimiento, monitorea las señales de alarma en los

canales correspondientes. Si una alarma se genera, ejecuta un sonido de alerta contiFuo;

asimismo, checa la condición del botón de control Silenciar alarma, pues si éste se

activa, se deshabilita el sonido.

,/

I

I

&Restablece-alarma@ La función principal de esta subrutina es restablecer ,!as

alarmas generadas; así como todas las banderas que se activaron cuando se dio esta

situación de alerta. También se habilitan todos los botones que fueron desactivados con

la alarma.

,I

&BotónqruebaO. Este procedimiento checa que todas las señales de alarma del

tablero se prendan, es decir, tengan la capacidad de encenderse (o cambiar al color

rojo). Este procedimiento activa y desactiva el botón de prueba. 51

I1

&Parpadeo-alarma(). Este procedimiento hace la función del botón de reconocer, ya

que sólo habiliMdeshabilita el parpadeo de la alarma generada. Esto es, cuando de

detecte que el botón de reconocer se activa, automáticamente el parpadeo de

deshabilita, y la alarma deja de parpadear para quedar en un color fijo. El botón se

vuelve a activar cuando se restablece la alarma.

! 72

Sistema multimedia y su aplicación en el diseño de interfaces para la supervisión y conbol de procesos

/I I1


Algoritmo en el código del despliegue de VASIJA:

vez que se genera una alarma. En este mismo algoritmo se restablece el sonido para aquéllas \I

11

6 sonidoo. Este procedimiento detecta las señales de alarma y ejecutar un sonido kada

alarmas que ya se hayan desactivado; asimismo se vuelven a habilitar todas las banderas que se

Cabe notar que el algoritmo es diferente al desarrollado para el panel de control bb09, pues el

sonido de alarma que se genera en el despliegue de código VASIJA se ejecuta una sola vez

cuando se detecta la alarma. En cambio, el sonido generado en el panel bb09 cuando se da una

señal de alarma, se está ejecutando mientras dura la señal de alarma, es decir no se calla el

sonido hasta que el operador silencie la alarma por medio de los botones de control, o cuando

se restablezca la a l m a y por ende el sonido.

prendieron cuando se genero la alarma. 11

l j

I!

II

I

2.5.3.4. IMPLEMENTACI~N DEL SONIDO AL SIMAULA Para lograr la implementación del sonido en el sistema se utilizó la instrucción $e

mme-ivp - oudiojdoy, que se encuentra entre las funciones que ofrece el software Services

Muliimedia que se instaló para desarrollar el módulo de sonido. La función principal de eye

manejador de sonidos es leer archivos WAV y reproducirlos en algún dispositivo de salida pTa

formatos WAV. 1

II

El formato de la instrucción mme-ivp-audioqlay es el siguiente: 1

mme-ivp-audioglay <# drsposrtwo disponible p/ archivos WAE- <Archivo WA E-

El número del dispositivo disponible para reproducir archivos WAV generalmente es el

O o 1. El archivo WAV debe localizarse en el directorio donde se ejecuta el sistema, de no ser It

así, debe especificarse la ruta en donde se localiza el archivo. II

Para el desarrollo del módulo de sonido se implementaron los siguientes algoritmos:

73 Sistema multimedia y su aplicacián en el diseño de interfaces para la supervisión y control de procesos I!

'1

Capítulo 111 Diseño e implementación

a) Algoritmos para la ejecución y control de alarmas del panel BB-09.

b) Instrucciones de sonido para el menú de navegación de los paneles BB-09, BB 1 O y BBi 1.

C) Instrucciones de sonido para reproducir sonidos en las manijas de control del panel "

BB-09.

d) Un algoritmo para la ejecución de alarmas del despliegue del código vasija.

Los algontmos para implementar el sonido fueron escritos en lenguaje C para ünix, y

adicionados al código del módulo correspondiente del sistema. Además de los algoritmosj se

tuvieron que hacer modificaciones en la memoria compartida del sistema creando nuevos

canales de comunicación para los botones de control de alarmas. Así como algunas

modificaciones en la defuición de los objetos de despliegue diseñados previamente en' el

ambiente Data Views.

I(

3.4.1. Implementación de sonido de retroalimentación en el menú de

navegación de los paneles bb-09, bblO y b b l l Los sonidos seleccionados para el menú de navegación fueron reeditados con el

software Decsound para lograr en ellos el efecto y el volumen deseados, tomando en

consideración las recomendaciones analizadas en el capitulo anterior. 1

Para incorporar el sonido en el panel de navegación se insertó la línea de ejecución de

sonido (mme-ivp-audioglay0) dentro de los procedimientos pertinentes en el archivo bb09view.c. I!

Se incorporaron dos sonidos, acción-bien y acción-mal. El sonido de acción-bien solo

se ejecuta si el procedimiento ya obtuvo la entrada correcta del sistema (una acción correcta del

operador en el panel de navegación). Si el sistema no reconoce la acción ejecutada por el

operador en el menú de navegación, hará sonar el sonido de acción-mal.

Ejemplo: Adición de sonido en el botón de ZoomTo en el bb09view.c

,t 74


II

Capítulo 111: Diseño e Implementaci6n

/*Procedimiento de la función ZoomTo delpanel de navegación */

VOID ZoomTo 0

OBJECT location; RECTANGLE Zoom Vp; location = GetlocationinDrawport;

cpybuf(&ZoomVp.ll, VoloWcpGet(location), sizeof(POiNT); location = GetlocationInDrawpon;

cpybuf(&ZoomVp.ur, VoloWcpGet(location), sizeof(P0iNT); mensaje(o1d-msg); VouVpSort(&ZoomVp); if((ZoomVp.ur.x - Zoom.Vp.11.~)>300 (1 (Z0omVp.ur.y - Zoom.Vp.ll.y)>300 { SON-BIEN; /*Sonido que indica que la acción del operador es correcta*/ TdpZoomTo(disp 1 .drawport, &ZoomVp);

Wpt-centes.x = DIV--2(ZoomVp.ii.x + ZoomVp.ur.x);

Wpt-center.y = DI--Z(ZoomVp.ii.y + ZoomVp.ur.y);

TdpDraw(displ1 .drawport);)

else { SON-MAL; /*Sonido que indica una acción inválida para el sistema*/

mensaje(“2ona demasiado pequeña para un Zoom}

{

(“Seleccione primer esquina del área deseada”);

(“Seleccione esquina opuesta del Area deseada”);

3.4.2. Implementación de sonido en la ejecución y control de alarmas I

I\ A\ Caso 1: Panel bb09 Este panel se modificó para incorporar un sistema de alarmas para cubrir los siguientes

eventos:

a) HPCSActuado

B) HPCS Vasija Reactor Bajo Nivel Agua

C) HPCS Pozo Seco Alta Presión.

l l

Cada vez que el sistema detecta que una de estas tres alarmas ocurre, en el tablero se

enciende de rojo parpadeante la casilla del tablero correspondiente a la alarma, además de que


Capítulo 111 Diseño e Implemenpción

se genera un sonido de alerta similar al que se genera en la CNLV. Para controlar las a l m a s

se tiene un grupo de botones que realizan io siguiente: I

!

Silenciar. Este botón apaga el sonido de la alarma.

Reconocer. Tiene como función quitar el parpadeo de la alarma, indicando así que el

operador ya reconoció la alarma.

Restablecer. Su función es restablecer por completo la alarma, es decir, apagar la a l a h a

del tablero (se quita el color rojo y vuelve a su estado normal), una vez que el operador ha

realizado acciones pertinentes para corregir el problema.

Prueba. Este botón tiene como objetivo probar si las señales de alarma funcionan

correctamente. 1

3.12. Tablero de control de alarmas delpanel BB-09.

I

Estos botones de control fueron implementados de la siguiente forma:

A) Primero se revisó el diseño de los botones de control en el software de Data Views, para

asignarles valores lógicos a los estados de la dinámica de oprimidsoltar el botón. Cuando el

botón se presiona toma el valor de 1 y cuando se vuelve a oprimir para desactivarlo está

con valor O.

'I

I1

76' Sistema multimedia y su aplicación en el diseño de interfaces para la supervisión y control de procesos

I'

11

1

ii Capitulo 111: Diseño e hplementación

B) Se asignó un canal de comunicación en la memoria compartida para asociarla a la señal (o

si una alarma se genera todos los botones tengan el valor lógico de O en espera de alguna

acción por parte del operador.

C ) Si la función es silenciar, al ser presionado el botón correspondiente toma el valor de 1 [ y el

sonido se silencia (desactiva). Cabe señalar que las señales de alarma que MAAP manda

son valores lógicos de O y 1. O en ausencia de alarma y 1 si está presente.

s e a e s ) de alarma que M W manda al módulo de panel de control. Esto de tal forma, I que

,\

D) Si el objetivo es reconocer la alarma, se accesa al canal de memoria donde están guardados

los valores del botón y se desactiva el atributo de parpadeo.

E) Si lo que se quiere es resfabíecer la alarma, entonces los pasos a seguir son: una vez

detectado que el botón de restablecer está activado, se verifica que la alarma siga encendida, y

se accesa a los canales de memoria donde se guardan todos los valores que generó dicha

a l m a para reiniciarlos al valor lógico de O (que es el valor en que se inicializan todas las 11

alarmas). I

Si se quiere realizar la prueba de las alarmas, se accesa al canal de memona del botón be

prueba. Todas las alarmas se encienden en color rojo al oprimir el botón de prueba y cuando

éste se libera (en la simulación, hay que volverlo a oprimir para liberarlo), las alarmas vuelven 1

a su estado normal. I1

Para que los instrumentos envíen o reciban información del módulo de simulación, se

asignan canales de memoria compartida. En otras palabras, un canal de memoria compartida es

una localidad de memoria a la que tienen acceso concurrentemente tanto el módulo de control

como el de simulación. Un instrumento puede usar más de un canal de memoria compartida de

acuerdo a su tipo de interacción, que puede ser de entrada o de salida.

II

Los nombres y canales de memoria asignados a las a l m a s y a los botones de control

I8 de alarmas son los siguientes:

771 Sistema multimedia y su aplicación en el disñio de interfaces para la supervisión y control de procesos

Capítulo 111: Diseño e Implementacion

Nombre en código Canal de memoria compartida

0 Botón de silenciar

6 Botón de reconocer

sil - sonido - btn

Reconocer bm

Restablecer btn

Prueba - btn

hpcs - - act aim

-

0 Both de restablecer - 0 Botón de prueba

6 Alarma HPCS actuado

0 Alarma HPCS vasija

hpcs bajo nvl alm Reactor bajo nivel agua - - -

Q Alarma HPCS pozo seco

alta presión hpcs - aliapr-alm

B) Caso 2: DesDlieme del códieo vasiia

canal 342

canal 344

canal 343

canal 345

canal 42 il

canal 32

canal 33

En el escenario de VASIJA también se implementó el sonido para las alarmas. El

despliegue consta de 20 alarmas cuya señal se recibe en los siguientes canales de la rnemoAa

compartida: 11

Alarma

Disparo AA

Disparo BBA 1 RRC

Disparo BBA 2 RRC

Transf. Baja BBA 1 RRC

Transf. Baja BBA 2 RRC SCRAM Alto flujo Neutrónico

Disparo Turbina

Aislamiento

Nivel 8

Nivel 4

Canal

1 O0 101

102

103

104

105

106

107

1 O8

1 o9 110

78' Sistema multimedia y su aplicación en el diseiio de interfaces para la supervisión y control de procesos ,

Nivel 3

Nivel 2

AA menor a 30%

Bypass abierto

-

114

111

112

113


Para accesar al canai de memoria compartida en donde llegan las señales de alerta, se 11 tiene un apuntador llamado vusqtr->chan-vul[ <canal de memoria>] el cual permite accesar

al valor que tiene determinado canal de memoria. I1

11 Existen 5 almas que aún no han sido definidas para algún evento crítico, sin embafgo

ya están listas para activarse con el sonido. Los canales que se les han asignado en la mem9ria

compartida son del 1 15 al 1 19 con valor inicial de O.

En el despliegue del código VASIJA también se implementó el sonido $e

retroalimentación en los botones de control (controladores, disparos de bomba y puntos de

ajuste), utilizando la instrucción de me-ivp-audioqlayo descrita en el punto 3.4. !I

'!

3.4.3. Sonidos ambientales 11

Ai implementar sonido en el prototipo del simulador de aula se incluyó un sonido de

manija para emular el que emite una manija real ai girar para abrirse o cerrarse. Esta

incorporación de sonido se hizo reeditando el archivo clickwav, dándole el volumen adecuado

para mejorar su efecto. Esto se realizó en las palancas del panel BB-09, las cuales se describen a continuación: !I

Nombrflanel BE09 Nombre /código Canal de Memoria

Bomba RHR A bba-rhr-aqal 315 I

Bomba RHR C bba-rhr-cqal 313 I1

79'

Bomba RHR B bba-rhr-bjal 314

Motor Bomba HPCS mtr-bba-hpcsqal 300

Sistema multimedia y su aplicación en el disefio de interfaces para la supervisión y control de procesos ,~

Capitulo 111 Diseño e Implementación 11

Ji En este tipo de palancas, se tienen tres estados: paro (para el funcionamiento de la

bomba asignada a la palanca), auto (está en posición neutral) y arranque @one en

funcionamiento la bomba asignada a la palanca). Por lo tanto, toman tres valores, O (paro): 0.5

(auto) y 1 (arranque). En el programa auxiliar bb09yos.c, que detecta en qué posición se

encuentra la manija para regresarla a su posición inicial (funciona como resorte),, se

implementó el sonido, para que cada vez que las palancas sean manipuladas (cambien, de

posición) se ejecute el sonido de click.

'I

'I

Algunas de las palancas que cuentan con sonido ambiental se muestran en las siguientes

figuras:

Figura 3.13. Bomba RHR B delpanel BB-O9 Figura 3.14. Bomba RHR A

Cómo ya se ha mencionado, este proyecto está sujeto a constantes mejoras, por lo que li

el presente trabajo constituye una base para continuar o no, la implementación de

Características multimedia @or ejemplo, más sonidos, video, etc) en la interface. Esto en base a ,

los resultados obtenidos en la evaluación hecha posteriormente al sistema.

80 I Sistema multimedia y su aplicación en el diseño de interfaces para la supervision y control de procesos 11

88

Capítulo 111: Diseño e implemepción

REFERENCIAS:

[l] Holding D. H. “Concepts of training, Department of Psichology University of Louisville’’.

Handbook of Human Factors edit. Gavriel Salvendy, pp. 939. I1

[2] “Role of simulators in operator training task 5”. OECD/NEAíCSNIPnncipal working

group No. 1 Expanded task force on human factors. Part 2. Simulator fidelity issues.

[3] ANSUANS 3..5-1993. “American National Standard for Nuclear Power Plant Simulator‘ for

use in operator training and examination ANS”. La Grande Park, Illinois, 1993. II

I

II

[4] Barrero Pérez, Luis, “Descripción general del simulador de la Central Laguna Verde”.

Boletín IIE, número especial, marzo/abnl 1992, México D. F. I

II

[SI Chávez M., Carlos, et al (1997). Informe técnico final, ”Simulador de aula (prototipo) p y a

operación y análisis de procesos nucleares de centrales nucleo-eléctricas”. Unidad de Energía

Nuclear. IIE, Cuemavaca Morelos.

[6] Zayas Pérez Benjamín E., Caves M. Carlos (1997). “Interfaz gráfica Hombre-M@U’:a

avanzada para un simulador de procesos nucleares para entrenamiento en aula”. IIE, Unidad de

Energía Nuclear. México Nuclear, Sociedad Nuclear Mexicana, México, D.F., Año 2 No. 5,

abril-junio 1996. Pp. 8-16. 1

11

11

[7] Valdés Parra, Jacinto J. y Ocampo Mamilla, Héctor,(1995). “Incorporación de los códigos

MAAP y VASIJA en el prototipo de simulador de aula desarrollado por la UREN-IIE, Cuemavaca Morelos, 1995. I

[8] Valdés Parra, Jacinto J.,(1997). “Incorporación del código MAAF’ en el prototipo del

simulador de aula”. Informe Técnico Final, Instituto de investigaciones Eléctricas, División de II 11

81 Sistema multimedia y su aplicación en el diseño de interfaces para la supervisión y control de procesos II

Capitulo 111: Diseno e Implemeniación

I1 Energías Alternas, Unidad de Resultados de Energía Nuclear, Cuemavaca Morelos, marzo

1997. 11

[9] Ramos Pablos J.C. (1991), “Simulación en Tiempo Red de la Termohidráulica de un I1

Reactor de Agua Hirviente”, Tesis de Maestría Cuernavaca Morelos, ESFM-IPN, diciembre

1991. , \

82’ Sistema multimedia y su aplicación en el diseño de interfaces para la supervisión y control de procesos

11

Capítulo IV': 18

Análisis, selección y aplicación del método de

eva I uaci ó n

11

En este capítulo se analizan algunos aspectos que se deben tomar en1

cuenta para la evaluación de una interfaz hombre-máquina. También se analizan"

los métodos de evaluación más comúnmente usados resaltando sus posibles ,, aplicaciones; asimismo, se presenta el método de evaluación que se utilizó l~

para la evaluación de este proyecto, analizando los aspectos que se I'

consideraron para su selección.

II

I

'- CaPhdO I v Análisis, seiecci6n y aplicación del método de eialuaci6n //

4.1. INTRODUCCI~N

La evaluación, en el contexto de desarrollo de un sistema, ha sido definida c&o la

medición de las partes de un sistema (hardware, s o h a r e y personal), para verificar que éstos

harán 10 que se espera que hagan con la eficiencia que se desea[l]. El resultado de una

evaluación de software, debe proporcionar un esquema que represente la facilidad o dificultad,

que tengan los usuarios al llevar a cabo las tareas deseadas. Actualmente, cada decisión que se

toma durante el diseño de un sistema, incluye algún criterio de evaluación, tal cómo decidir si

es mejor usar una señal visual o una señal auditiva.

I/

I1

11

En cuanto a la evaluación de factores humanos, 'consiste en examinar las partes,del

sistema para asegurar que sean correctos los atributos que se han implicado para la ejecución

humana[Z]. La evaluación de algunos elementos en términos de consideraciones de factqres

humanos, debena ser llevada a cabo sistematicamente, de la misma manera que iiun

experimento. Sin embargo, en muchas ocasiones, los procedimientos de evaluación dejan

mucho que desear en términos de procedimientos aceptables. II

Muchos de los problemas a que se enfrentan los responsables de la evaluación 'he I/

factores humanos, se presentan en situaciones operacionaies reales o en situaciones que se

aproximan a condiciones operacionales. A pesar de que mucha de la investigación en cuanto' 11 a datos y principios de factores humanos, se desarrolla en laboratorio, I DeGreene [3] señala que ?I

laboratorio más adecuado para investigación de factores humanos debena ser el mundo real.

Esto es necesario para que en la evaluación y prueba final del sistema, éste sea usado por la 11

gente que realmente lo requiere.

1

84 Sistema multimedia y su aplicación en el diseño de interfaces para la,supervisión y control de procesos

Capítulo Pi: Análisis, selección y aplicación del metodo de evaluaci6n

Sin embargo, los problemas involucrados en la evaluación en el mundo real, usdmente

son mucho mas COmPkjOS que aquéllos que se realizan en el laboratorio. En el diseño de

y procedimientos de evaluación se deben considerar tres factores: usuarios de prueba, criterios 11

procedimientos experimentales[2].

USUARIOS DE PRUEBA. La evaluación debe ser llevada a cabo con los mismos tipos

de individuos que usarán el sistema en cuestión, tal como pilotos entrenados, person& con

licencias de manejo, personal de industrias de montajes, personas impedidas, o el público en

general.

/I

1,

CRITERIOS. Un criterio (variable dependiente) debena ser relevante al uso operacional

del elemento en cuestión, y dependiendo del elemento &:pueden incluir ejecución del trabFjo,

efectos psicológicos, accidentes, efectos de interrupción o paro, tiempo de aprendizaje,

SatkfacciOn del trabajo, actitudes y opiniones, y consideraciones económicas, por mencionar

unas pocas. El uso' de múltiples criterios es caractenstico en la investigación de una evaluación.

Raramente, un simple criterio es base suficiente para una evaluación.

11

il

11

/I

1,

CONTROLES Y PROCEDIMIENTOS EXPERIMENTALES. El problema de llevak a

cabo procedimientos experimentales -incluyendo controles adecuados- es mucho mayor eni el

mundo real que en un laboratorio. Johnson y Baker 14) señalan que en muchos campos tie estudio no es posible duplicar el ambiente estudiado, y no siempre pueden ser usados gnipos be ll

control, por lo que el ambiente físico no puede ser completamente controlado. Reconociendo

esto y otras limitaciones de evaluación en circunstancias del mundo real, el investigador debe

hacer un esfuerzo para seguir procedimientos experimentales apropiados.

11

,I

Según los principios propuestos por Senach IS], el primer elemento que hay que

determinar es el objetivo de la evaluación, para después ,identificar las dimensiones de la

evaluación y continuar con el análisis de métodos de evaluación. Por último se debe definir la

85 Sistema multimedia y su aplicación en el diseño de interfaces para la supervisión y conwol de procesos

Capitulo IV: Análisis, selección y aplicación del método de evaluación IJ

81

modalidad o el método de evaluación que se va a aplicar al sistema. De acuerdo con lo Atenor.

a continuación se expone el objetivo de la evaluación del proyecto.

4.2. OBJETIVO DE LA EVALUACIÓN DEL! PROYECTO 'I

La presente investigación trata de probar si la implementación de caractensticas

multimedia ayuda o no a mejorar la comprensión de la información que se transmite a un

operador mediante interfaces para control de procesos. IEspecíficamente, en este trabaj y, la

adición de sonido en alarmas, sonidos de retroalimentación en menús de navegación, y sonidos

ambientales en los paneles de control de un prototipo de un simulador de aula para una central

nucleoeléctrica.

,I

11 I

El objetivo principal de evaluar el proyecto es comprobar si la hipótesis hecha ai

principio del trabajo es verdadera o falsa; con esto se fundamentarán las conclusiones de la tesis

y se pondrán de manifiesto las ventajas ylo desventajas que se generan ai añadir características I/

multimedia a interfaces para control de procesos.

I1

4.3. ALCANCES DE LA EVALUACI~N

Este trabajo contempla la aplicación de una metodología de evaluación que se basa en

evaluar los principios o características que desde el punto de vista de los factores humands

deben contener los productos para satisfacer las necesidades y expectativas de los usuarios.

Dicha metodología utiliza un cuestionario y un experimento que se aplica a los usuarios en dos

sesiones distintas. La evaluación contempla algunos aspectos de diseño pero se enfoca en los I

aspectos relevantes que son de interés para este trabajo de tesis.

I,

86 Sistema multimedia y su aplicación en el diseño de interfaces para lasupervisión y control de procesos ,

Capítulo IV: Análisis; selección y aplicación del método de evaluación

Debido al tiempo que consume este tipo de evaluación, únicamente se evaluaron diez

usuarios, esperando obtener con esto resultados adecuados; ya que se hizo una selección

cuidadosa de ellos, tratando de que todos cumplieran con un perfil determinado para tener una

población de evaluadores uniforme.

,!

Continuando con los principios propuestos por Bernard Senach [SI, se analizan albunos

de los métodos de evaluación que generalmente se utilizan en el diseño y desarrollo de

interfaces hombre-máquina.

11

4.4. MRODOS Y TÉCNICAS DE EVALUACIÓN

Actualmente existen muchas técnicas y métodos para la evaluación de un diseño; de

interfaz de usuario, y su relación con el proceso de diseño del software. John Karat [6] nos

presenta las técnicas divididas en dos categorías: aquéllas que son basadas en observaciones ,de

individuos que usan un sistema real o prototipo (evaluaciones basadas en el usuario): y

aquéllas que son basadas en un análisis de la tarea que es ejecutada (evaluaciones basadas in

La tabla 4.1 resume algunas de las técnicas que se utilizan en la evaluacion,

proporcionando una indicación general de dónde puede ser utilizada cada una en el diseño de

un proyecto. Dependiendo del tipo de información que proporcione la interfaz de usuanÓ,

algunas técnicas son más útiles en ciertos procedimientos de diseño que en otros.

ll

I\

fareas). li


Capítulo I V Análisis, selección y aplicación del método de evaluación

Tabla 4.1. Resumen de los méiodos de evaluación y su IISO)~].

1 ,B /cuestionario Respuesta subjetiva a una 1' En cualquier momento del ciclo, \

S U

a

pregunta planteada. Es . cuando pueden ser planteadas

mejor con preguntas preguntas claras.

específicas. !

- E

a 1.

b a

a d

V

S

a S

e n

t a r e a S

-

, Experimentos Medidas específicas en un Para pruebas específicas de ¡,

1 controlados. escenario controlado. alternativas principales o

!I ~ hipótesis.

I I,

I1 Análisis fonnai Predicciones de Usar en lugares de prueba del 1

comportamiento de un usuario para facilitar el uso de ,j

usuario experto. predicciones.


Capítulo IV: Análisis, selección y aplicación del método de e4aluacion I!

', 4.4.1. Evaluaciones basadas en usuarios, II

Hay varias técnicas que pueden ser utilizadas para obtener información de usuarios de

sistemas. El tipo de evaluación que. es apropiado depende del tiempo en que la evaluación es

llevada a cabo y del uso que se le vaya a dar'a la información recolectada. Las evaldciones

conducidas durante el desarrollo del sistema se hacen generalmente para obtener información

sobre mejoras en el diseño existente. En estos casos, la, información muy específica acerca de

los detalles de la interfaz es de mayor utilidad. Esta clase de información puede ser obtedda en

reportes verbales y pruebas directas a interfaces alternativas. Las evaluaciones conducidas en

sistemas terminados están a menudo menos interesadas en información acerca de detalles

específicos y buscan información de una naturaieza más general (tal como cuáles de los

productos son más fáciles de aprender a usar o cuáles son más efectivos en llevar a cabo ciertas

tareas de trabajo). Las encuestas y los cuestionarios, y en general estudios descriptivos, son a

I1

./

\I

'I

I\

menudo las técnicas de evaluación seleccionadas.

4.4.2. Evaluaciones basadas en tareas Hay diversas técnicas que no necesariamente involucran la prueba u observación' de

usuarios potenciales para obtener información. Éstas son basadas generalmente sobre'lun

análisis de las necesidades que tiene alguien que usa el sistema en cuestión (una formallde

análisis de tareas). Los métodos incluyen desde revisiones informales del diseño, hasta análisis

formales como el análisis GOMS (Goals, Operators, Met I id , and Selection Rules) de CAd,

Moran y Newell [7], o el análisis de sistemas de producción'de Kieras y Polson [SI.

II

I¡

La mayona de las técnicas formales, actualmente contienen modelos simplificados del 1

operador humano y por tanto, constituyen teorías de desempeño humano.

89 Sistema multimedia y su aplicación en el diseño de interfaces para la supervisión y control de procesos ,

Capitulo iV: Anhlisis, selección y aplicacion del método de evaluación

4.5. ANÁLISIS DEL MÉTODO DE EVALUACI~N SELECCIONADO

I1 Generalmente existen dos razones principales p&a la evaluación de un sistema: la

primera es ayudar en las decisiones de diseño, y la segunda es la medición de la calidad del

diseño. La diferencia estriba en saber si uno está evaluando para obtener nueva información

acerca de posibles alternativas de desarrollo del sistema, o se está evaluando para obtener un

reporte sobre el valor de algunos aspectos del diseño. ‘Los métodos de evaluación cubien un

rango amplio de técnicas y de necesidades.

1)

I\

,L

Una de las técnicas de evaluación m b utilizadas para evaluar un sistema es mila de

experimentos controlados. Las evaluaciones a través de experimentos controlados son

diseñadas para recolectar mediciones objetivas tales como tiempo para completar una &ea, o

respuestas correctas o número de errores, las cuales son comúnmente usadas en evaluaciones de

sistemas. Aunque este tipo de evaluación es muy eficaz p&a obtener resultados objetivos, no se

aplicó en este trabajo debido a que la interface está en v a “fase evolutiva constante” y por

tanto, se requería solamente de evidencias para sustentar la hipótesis planteada en el inicio de la

investigación, y así obtener bases sólidas para implementar aspectos multimedia en el

Simulador de Aula.

11

il

‘I

!4

h

Debido a las caractensticas del proyecto y al objetivo de la evaluación misma, se eligió

utilizar la técnica de cuestionarios combinada con una evaluación dinámica de la interface. Esto

se decidió debido a que, como se ha dicho anteriormente, en ocasiones es imposible realizar

evaluaciones en un ambiente real y totalmente controlado, por lo que se tiene que realim,\la

evaluación en laboratorio y con limitantes de evaluación que a veces resultan inesperadas.

I

li

Estas dos técnicas s e r b explicadas a continuación: ,


- -

'I

11

I1 Capítulo IV: Análisis, selección y aplicación del método de evaluación

En la técnica de Cuestionarios, las preguntas pueden ser totalmente genedes o, muy

específicas en cuanto a detalles que la evaluación ibusque direccionar, o muy abiertas

requiriendo comentarios del sistema. I! I1

Las respuestas pueden ser limitadas, (por ejemplo, marcar un cuadro en alguna e s d a ) o

pueden ser de forma libre. 11

I!

En muchos aspectos los cuestionarios proporcionan el método más fácil y henos

costoso para obtener datos de medición sobre un sistema; S i embargo se debe tener siempre

presente que lo que se obtiene de los cuestionarios son simples puntos de vista. La utiiiúud de

'1

'I

la evaluación estará en la correctu interpretación de los resultados.

'1

I1 I1

Por otra parte, la evaluación dinámica de la interface inicia con el planteamiento de una

pregunta, la cual es comúnmente de naturaieza comparativa (Les un sistema A mejor que el

sistema B en alguna medida?), pero puede tener muchas otras formas(jen que grado es más

fácil aprender un segundo sistema, una vez que ya conoces un sistema similar?). Las

mediciones objetivas están ya determinadas, así que medidas que puedan ser recolectadas en

alguna prueba (ial como tiempo para completar una tarea), pueden ser relacionadas a elementos

clave de la pregunta (íai como si es fácil de usar). En general las técnicas difieren muy poco de

aquéllas usadas en otras keas de factores humanos (o en ciencia en general). Si una pregunta

I

II t

11

11 I

I)

i

II I

puede establecerse claramente, una evaluación experimental para obtener datos empíricos

puede diseñarse como un conductor para responderla. I1

Con una pregunta clara en mente y un plan para cómo serán recolectadas las

mediciones; el segundo paso es encontrar sujetos para la pmeba y coleccionar los datos. LLa guía

general establece que hay que probar usuarios representativos, una situación que es a menudo

dificil de resolver con el conjunto de sujetos disponibles, ya que el objetivo debe ser obtener 11

I /I

, I 91 Sistema multimedia y su aplicación en el diseño de interfaces para la supervisión y control de procesos

'I

Capitulo IV: Análisis, selección y aplicación del mktodo de evaluación

datos de evaluación que reflejen tan cercanamente como sea posible la situación reh y el

ambiente de prueba, por io que la gente debe ser cuidadosamente seleccionada.

I1 Hay por supuesto costos a ser considerados; como es el tiempo consumido en la

evaluación, la disponibilidad de usuarios con características específicas para este tipo de

evaluación, un ambiente de control más específico, etc. En general se requiere delmucho

tiempo y recursos (tanto humanos como materiales) para conducir un buen trabajo

experimental.

I

4.6. METODOLOGÍA PROPUESTA PARA LA EVALUACI~N Tomando en cuenta que los factores humdos en el área de computacióh están

relacionados principalmente con la interacción entre I el hombre y la computadora (interfaz

hombre-máquina) y que la calidad de ésta depende de su capacidad para satisfacer un conjunto

predefinido de requerimientos del usuario, se propone una metodología de evaluación que

dmensione el grado de satisfacción del usuario contrariamente a lo convencional, dbnde se

11 t

evalúa el objeto de interés, esto es, la interfaz. I1

La dificultad al evaluar si una interfaz tiene o no las características deseadas por el

usuario, es que la mayoría de los resultados resultan ser subjetivos, por lo que el método que se

presenta en este trabajo sirve para evaluar la presencia de factores humanos en la interfaz,

considerando siempre que el usuario percibe al sistema básicamente a través de su interfaz.

I1

i /I La metodología de evaluación que se propone aplicar en este trabajo de tesis consiste

Establecer un conjunto de hipótesis. Cada una de las hipótesis está rel&ionada

con una de las cafactensticas que se desea evaluar.

en lo siguiente:

PASO 1: II

, ii

~

Sistema multimedia y su aplicación en el diseño de interfaces para la supervisión y control de procesos '1

Capitulo I V Análisis, selección y aplicación del método de evaluación

Diseñar un mecanismo (cuestionario) para evaluar estadísticamente el grado de

presencia de las hipótesis establecidas.

Diseñar un experimento y aplicar el cuestionario diseñado.

Procesar los datos obtenidos en el !experimento, obtener y analihr las

I\

PASO 2:

!I

PASO 3:

PASO 4:

evidencias. (1

i

4.7. EVALUACI~N DE LA INTERFAZ II

En esta sección se presenta la planeación y realización de las evaluaciones efectuadas al

sistema, utilizando la metodología antes planteada con el fin de obtener y presentar resultados

que fundamenten la aceptación o rechazo de la hipótesis planteada al inicio de este trabajo. A

continuación se detallan cada uno de los pasos que se siguieron para aplicar dicha metodología

de evaluación

h

I1

4.7.1. Hipótesis de trabajo A partir de un conjunto de características deseadas para el buen desempeño de la

a) “Una interfaz para control de procesos con sonido de retroalimentación en su me& de

navegación, facilitará y mejorará la comprensión y el uso de los controles que el usUano

tiene que manipular en la interfaz”.

I interfaz se establecieron hipótesis que permiten fundamen& los resultados de la investigación.

11 b) “Una interfaz para control de procesos que incluye sonido para indicar el disparo de sus

alarmas, permitirá al usuario tomar decisiones más oportunas”.

c) “El sonido ambiental en los controles que se simulan en una interfaz para control de

procesos, ayudará a que el usuario tenga una percepción más realista del sistema que se

esta simulando, aumentando con esto la sensación d& control sobre la misma”.

I

I\

14 I

I‘ 93 ,, Sistema multimedia y su aplicación en el diseño de interfaces para la supervisión y control de procesos

Capitulo IV: Análisis, selección y aplicación del método de ehuación

!!

4.7.2. Diseño de un cuestionario para evaluar el grado de presencia de I1

\

las hipótesis establecidas Para cada una de las hipótesis defindas en el paso anterior, se definieron un conjunto de

preguntas. Cada una de las preguntas fueron diseñadas para que su respuesta refleje el grado de

presencia de la característica deseada que está relacionada con la hipótesis en cuestión. Cada

pregunta tiene asociadas siete posibles respuestas que corresponden a una escala semántica

diferencial regresiva de 7 puntos, acotada a cada extremo por adjetivos bipolares (SIEMPRE-

NUNCA), como se muestra en la figura 5.1.

II

i! !I

I¡

!

5 'I 2 1 ,I 7 6 5 4 3 ,I

SIEMPRE NUNCA

:concepto 1) (concepto 2)

7 6 5 4 3 2

muy rara vez 1

(le da igual) \I Neutral

A veces I Regular i

:o 1 se cumple I1

Figura 5.1. Escala de evaluación con conceptos opuestos(bipo1bes) /I

'1 4.7.3. Diseño experimental

I! El diseño experimental para la evaluación dinhica de la interfaz consistió en:

I1

A) Establecer requerimientos

B) i6 Especificar las pruebas y aplicarlas.

x 94

Sistema multimedia y su aplicación en el diseño de interfaces paraja supervisión y control de procesos I!

!

14

Capitulo I V Análisisj selection y aplicacion del método de evaluación

A) Establecer los requerimientos del experimento: se definió el perfil llde los

participantes, el número y el método de selección. I

(a) Perjil de los participantes

Los sujetos que participaron en la evaluación dinámica del sistema satisfacieron

un perfil definido con las siguientes caractensticas. 11

J Conocimiento básico sobre diseño y construcción de interfaces gráficas.

J Conocimientos sobre control y monitoreo de procesos

J Formación profesional compatible con alguna de las áreas relacionadas con el I'

presente trabajo.

(b) Número de participantes

La evaluación debe ser aplicada a un grupo de 10 sujetos que cumplan cin los

requisitos que se establecieron para los participantes. El origen de los participantes

comprendió el Instituto de Investigaciones Eléctricas (HE) y el Centro Nacional de

li

I/

Investigación y Desarrollo (CENIDET).

(c) Mktodo de selección de los participantes

Los participantes deben ser seleccionados bajo el perfil establecido

anteriormente, además de esto, se determinó que los sujetos no hubiesen visto ni

manejado anteriormente el sistema a evaluar. Por último, debe tomarse en cuenta su

disponibilidad de tiempo para la evaluación, pues se requiere su asistencia en dos

sesiones en diferentes tiempos.

I1

11

I)

I'

I \

B) Especificar la prueba: Se definieron alcances, lugar y duración de las sesiones con la

participación de x sujetos en pruebas piloto. Las respuestas del cuestionario se complementarán

con los comentarios de los participantes.

ll

11

95 Sistema multimedia y su aplicación en el diseño de interfaces para la supervision y control de procesos '

% 1

Capitulo IV: Análisis, selección y aplicación del método de evaluación

A): I

p Evaluación del menú de navegación

> Evaluación de manejo y control de alarmas.

La evaluación del menú de navegación, consistió de un escenario simulado donde se

representa un panel de control con objetos gráficos manipulables para la ejecución de diversas

funciones de control de la interfaz. El objetivo de esta evaluación consistió en determinar si el

sonido de retroalimentación implementado en el menú de navegación, simplifica el manejo de

la interfaz en cuanto a su comprensión y facilidad de USO. Para esto, se asignó al usuario una

lista de tareas a realizar utilizando el menú de navegación de la interfaz. Al final de esta prueba

se aplicará un cuestionario con preguntas cerradas y abiertas.

Para la evaluación de andisis situacional se preparó una sesión de sim4ación

predefinida del escenario VASIJA en la cual suceden eventos repentinos, como el cambio de

valores en parámetros importantes en la interfaz, que ocasionan la ocurrencia de alarmas y

eventos transitorios. En esta sesión la tarea del usuario consistió en la observación cuidadosa

del escenario, de tal forma que pueda percibir la severidad de la situación que se está

presentando y predecir el curso del evento o eventos ocurridos. Al final de esta prueba se aplicó I I1

un cuestionario. ! P

I I I 1 .

!I Por último, en la evaluación de manejo y contrhl de alarmas, se presentó un escenano

simulado con tres pantallas, en una se presenta el tablero anunciador de a l m a s , en otra una 11 11

96 NI

Sistema multimedia y su aplicación en el diseño de 'interfaces para la supervisión y control de procesos ' t

I

Capitulo IV: Análisis, selección y aplicación del método de evaluación

gráfica que despliega valores que representan el estado del proceso; y en la última pantalla se

presentó una palanca que controla las alarmas que se generan durante la sesión. En esta prueba

se simularon alarmas en el tablero y se hicieron modificaciones al programa principal para que

la palanca de control de alarmas apague las alarmas que se generen durante la sesión. Asimismo

se realizó un programa que simula la ocurrencia de alarmas en la interfa y otro programa que

registra en un archivo de datos el momento en que se disparan las alarmas y el momento en que

el evaluador las detecta ejerciendo acción sobre ellas.

11

I1 1

li

/I

i

La tarea del evaluador en esta prueba fue el monitoreo de los procesos de la interfq

registrando en una bitácora los valores que registra la gráfica; al mismo tiempo el usuario debía

estar pendiente de las alarmas que se disparan durante la sesión y ejercer acciones de

reconocimiento y control mediante la manipulación de la palanca de control. En esta prueba no

se llena un cuestionario, pues se obtiene un archivo de datos que registra los tiempos en que se

disparan las alarmas y el tiempo en que el u s d o realiza alguna acción en la interfaz.

11

11

/I

I

Las sesiones de evaluación se realizaron en las instalaciones del Instituto de

Investigaciones Eléctricas, en el laboratorio de automatización y control de procesos. En este

trabajo no se consideraron usuarios potenciales reales, ahque se considera hacerlo en el futuro. u '1

Las sesiones tendrán una duración de 30 a 40 minutos, en cada una de ellas deben

llevarse a cabo las tres evaluaciones antes descritas. Cada participante evaluador debe asistir a

dos sesiones diferentes separadas por un lapso de tiemEo de dos días, con el fin de que el

evaluador no tenga tan reciente en su memoria la sesión pasada y pueda establecer diferencias

entre las dos sesiones sin que afecte la predisposición que pudiese darse al haber manipulado ya

la interíaz bajo ciertas condiciones.

I1

Ejemplo de los cuestionarios resueltos y de los larchivos de datos grabados en'llas

sesiones de evaluación, se presentan al final de este trabajo en el apéndice B.

I\

I 97 I1 Sistema multimedia y su aplicación en el diseño de interfaces para la supervisión y control de procesos

I

I\ Capitulo IV: Análisis, selección y aplicación del método de evaluación

REFERENCIAS:

[l] Meister, D. and Rabideau, G. F. (1965). Human Factors evaluation in systems development.

New York: Wiley. Pág. 13. !

[2] Sanders Mark S., McCormick Ernest J. (1987). Human Factors in Engineering and Design.

Sixth Edition, McGraw-Hill Book Company. Pp. 538-539. It

U

[3] DeGreene, K. B. (1977). “Has Human factors come of age?” Proceedings of the Human Factors Society. Santa Mónica, CA: Human Factors Society. Pp.457-461.

t

[4] Johnson, E. M., and Baker, J. D. (1974). “Field testidg: The delicate compromise”. H&an

Factors, Vol. 16, Nun. 3. Pp. 203-214.

18

[S] Senach Bernard (1 993). “L’Évaluation Ergonomique Des Interfaces Home-Machine”.

L ’ergonomie Duns La Conception des projets Informatiques. Direction de. Jean-Claude

Sperandio Ire. Edition, OCTARES Editions. Todouse-France. Pp. 75-103.

II

I1

I’

[6] Karat John (1988). “Software Evaluation Methodologies”, IBM Corporation, Austin Texas.

Handbook of Human-Computer Interaction. M. Helander(ed). Elsevier Science Publisher B. V. ,I

I 11 (North-Holland), pp. 445-446.

I¡ I

[7] Card, S. K., Moran, T. P., & Neweil, Aa. (1983). The Psychology of Human Computer

Inreraction. Hillsdale, New Jersey: Erlbaum. I

II [S] Kieras, D. E., & Polson, P. G. (1985). “An approach to the formal analysis of user

complexity”. International Journal of Man Machine Studies, Vol. 22, pp. 365-394. I

YO

Sistema multimedia y su aplicación en el diseño de interfaces para la supervisión y control de procesos I

‘I

Res I u I tad ols,

conclusiones! y

perspectivas

En esta sección se presenta un análisis de los resultados obtenidos en cada

una de las pruebas hechas al sistema para establecer la afirmación o rechazo de

la hipótesis planteada al inicio de la investigación. Asimismo, se plantean las

conclusiones que se obtuvieron en el presente trabajo y las perspectivas para

investigaciones posteriores.

l 11

II

I

Resultados, conclusiones y perspectivas

I. ANÁLISIS DE RESULTADOS De acuerdo al proceso de los datos obtenidos en las diferentes evaluaciones

aplicadas a los 1 O participantes en la evaluación dinámica de la interfq se obtuvieron los

siguientes resultados.

(1

11

Evaluación de la incorporación de sonido en el menú de navegación: I'

Las respuestas de los cuestionarios aplicados al !.finalizar la prueba correspondiehte de

cada sesión se evaluaron de acuerdo a la escala establecida (Fig. 5.1). Sumando el valor de

cada pregunta (diez por cada cuestionario), se obtierik el resultado de cada participante y al

final se obtiene un promedio general de la población evaluada..

I/

I!

11

T.

14

Los valores asignados en la escala de los cuestionarios describen el grado de

satisfacción en el uso de la interfaz durante la evkación. Un valor neutral (4) indica

indiferencia por el sonido en la interfaz. 'I

I1

Tomando los valores asignados a la escala aplicada en el cuestionario! se

contabilizaron las respuestas y se encontró que el 90% de los participantes en la evaluación

encontraron la interfaz más fácil de usar y más sencilla de manipular cuando tenía sonido y

al 10% le fue indiferente el sonido. b

!I

La gráfica 5.1. muestra los resultados de cada sujeto en cuanto a sus preferencid en :I

la interfaz conísin sonido. ,


/I

I1 Resultados, conclusiones y perspectivas

Efectos de la implementación de sonido de retroalimentación en la in t e if a c e

Grado de satisfacción ( W i m o 70)

Gráfica 5.1. Resultados de la incorporación de sonido de retroalimentación en el mend de navegación de la interfm

Todos los participantes manifestaron a través del cuestionario, que el sonido de

retroalimentación ayudó a percibir los errores que se cometen al manipular la interfaz, y

asimismo, manifestaron que es indispensable saber en todo momento si las acciones

realizadas por el usuario son o no aceptadas por el $sterna, y si éstas se realizaron de forma

incorrecta es importante que la interfaz lo indique.

I

11 . 11 'I

El 90% de los usuarios manifestó un mayor control de la interfaz cuando ésta

incorpora sonido de retroalimentación en el menú de navegación.

En términos generales, el valor promedio obtenido indica que la interfaz con sonido

satisface más a los usuarios en cuanto a facilidad de uso y sencillez en la comprensión y desarrollo de las tareas, que la interfaz que carece de sonido en el menú de navegación. La

tabla 5.1. muestra el valor promedio obtenido en la evaluación. 1

11

'I ll 101 'i

Sistema multimedia y su aplicación en el diseño de interfaces para la supervisión y control de procesos I'

Resultados, conclusiones y perspectivas 1

I /I

Tabla 5.1. Resultados de la evaluación en la implementación de sonido en el menú de navegación.

Con sonido 6.54 '1

Si tomamos en cuenta la escala utilizada, el valor de 6.54 es muy cercano al

concepto de SIEMPRE que representa el mayor grado de satisfacción al utilizar la interfaz,

por lo que se deduce que el sonido en el menú de navegación de la interfaz ayudó a que el

usuario sintiera un mayor control de la interfaz pxr lo que le fue más fácil desarrollar sus

tareas en ella. En cuánto al valor 5.36 que se obtiene al evaluar la interfaz sin sonido,

muestra que aunque la interfaz gráfica ayuda, no fue suficiente para que el usuario realizara

con seguridad sus tareas.

I

'I '1

l '11 Evaluación del análisis situacional

La tabla 5.2. presenta los valores promedio obtenidos basándose en las respuestas de los

cuestionarios suministrados al. finalizar la prueba de análisis situacional. Estos valores

pueden ser tomados como un índice de representatividad con la que el usuario percibió la

severidad y realismo del escenario presentado.

i.

i I i Tabla 5.2. Valores promedio obtenidos en el análisis situacional utilizando el escenario

VASIJA.

Como se puede observar en la tabla 5.2, el sonido en la interfaz mejoró el proceso de

percepción de las situaciones anormales que se presentaron durante la operación.


;I

,I

Resultados, conclusiones y perspectivas ,I

Asimismo, permitió al operador estar más consciente de los eventos que ocurrin y por

tanto, es de suponerse que la toma de decisiones será más oportuna que en la interfaz que

carece de sonido.

I1

I :

En esta evaluación se obtuvo que todos,,los sujetos que utilizaron la ihterfaz,

consideraron indispensable el sonido para poder detectar anomalías en el monitoreo de

procesos, ya que es muy dificil dar seguimiento a todas las variables del proceso y detectar

cuando una de ellas varía en forma significativa requiriendo atención inmediata. l.

,

Evaluación del control de alarmas.

En esta evaluación no se aplicaron cuestionarios a los participantes, p u p se

desarrollaron programas para registrar el momento en que se generaban las alarmas y el

tiempo en que el operador de la interfaz "respondía" realizando alguna acción; esto es,

registraban el tiempo de respuesta del usuario. El objetivo de esta evaluación fue establecer

si el sonido en la interfaz que controla y despliega alarmas (control de procesos) era de

11

I1

I1

alguna utilidad. li

El tiempo de respuesta promedio que se obtuvo en esta evaluación se muestra en

la tabla 5.3: Tabla 5.3. Tiempos de respuesta promedio de la evaluación de control de alarmas

I1

Con sonido 00:35 seg. I,

El tiempo de respuesta implica el tiempo desde que ocurrió la alarma, haski el

tiempo en que el usuario la reconoce y ejecuta alguna acción de control. Por tanto, este

tiempo implica detectar y silenciar la alarma, reconocerla y finalmente apagarla; todo esto

mediante los controles que ofrece la interfaz. I

103 Sistema multimedia y su aplicación en el disefio de interfaces para la supervisión y control de procesos \,

Resultados, conclusiones y Gnpectivas

11 Como se observa en la tabla 5.3, el tiempo de respuesta fue menor cuando se utilizó

sonido en la interfaz, por lo que se puede afirmar que el sonido en las alarmas mioró el

tiempo de respuesta del usuario ante eventos anormales que sucedieron en el proceso y le

permitió reaccionar más rápida y oportunamente! Por otra parte, cuando la interfaz se

presentó sin sonido, los usuarios requirieron realibr un mayor esfuerzo en las tareas de

monitoreo, pues de lo contrario no percibían de manera inmediata cuando s u c e p una

alarma en el proceso.

li

I/

11

I1

I1

La gráfica 5.2. muestra los tiempos de respuesta obtenidos por cada sujeto que utilizó la I

interfaz en la evaluación de control de alarmas. II

Tiempos de Respuesta enel control de alarmas

Sujetos I I Gráfica 5 2 Resultados de la incorporación de sonido en el control de alarmas. /1

La @ca anterior muestra que todas las personas que evaluaron la interfaz tuvieion

tiempos de respuesta menores cuando utilizaron la interfaz con sonido, además de que

pudieron completar sus tareas con mayor seguridad. Todos los participantes expresaron que

el sonido le es indispensable para la detección y manejo de alarmas. I

1 04 Sistema multimedia y su aplicación en el diseño de interfaces para la supervisión y control de procesos 11

II II

Resultados, conclusiones y perspectivas I1

I1

‘I

11. CONCLUSIONES El trabajo expuesto se sustenta en un simulador de aula prototipo para

entrenamiento de operadores de una central nucleo-eléctrica, el cual sirvió como pipforma

experimental para la investigación del efecto del sonido en una interfaz para control de

iI

I

II

procesos.

11

La propuesta de incorporación de características multimedia a una interfaz J\

de

control de procesos esta sujeta a la h@$esis planteada d principio de esta investigación~ la

cual establece que ‘‘la interfaces multimedia ayudan a 10s OpemdOres ETon<ables del

control de procesos a reducir su carga cognoSCitiVa ai estar frente a un ~idema que despliega información y que requiere de toda suatención y de una manipulación cuidadosa de los datos”. Los resultados de la evaluación realizada al sistema empleado en el presente Pabq’o, proporcionan evidencia sustantiva de que dicha hipótesis se cumple en el contexto

planteado, esto es para los sonidos que se implementaron y en un ambiente de;Fontrol de

i

!I

!I

11

procesos dónde suceden eventos imprevistos en’lcualquier tiempo del monitoreo. I¡ I!

(I

LOS objetivos principales del presente trabajo fueron la incorporación de sonido a

una interfa Para Control de Procesos y la, realización de una evaluación dinámica

considerando aspectos de factores humanos, ‘con el propósito de poder establecer m a COnClUSiÓn mpeCt0 a la hipótesis planteada.

11

11 11

11

El análisis de resultados sustenta las siguientes aseveraciones. ‘i

a El sonido, en un contexto como el que se ha planteado en este trabajo de

1 proporciona ai usuario un mayor control de la interfaz.

la Los usuarios requieren saber si las acciones que realizan en la interfaz fueron

correctas o erróneas, por lo que el sonido de retroaiimentación es muy importante.

Los usuarios perciben mejor la situación del proceso cuando tienen un

escenario que muestra en forma gráfica 1. sonora lo que ocurre. If

I1 105

, .

Sistema multimedia y su aplicaci6n en el diseño de interfaces para la supervisión y control de procesos

11 r :, ..,

11

Resultados, conclusiones y perspectivas /I

El sonido en alarmas permite al usuario detectar enforma más rápida los

eventos críticos que se generan en los procesos, sin demandar atención visual en un 11 la

lugar determinado. I1

0 El tiempo de respuesta de un usuario de una interfaz para control de

procesos es menor cuando existen alarmas sonoras, que cuando solo se presentan las alarmas en forma visual.

I t

I1

Algunas desventajas encontradas son: I I1

I Una interfaz para control de procesos que cuenta con despliegues baffcos,

touch screen, y sonido, consume más recursos del sistema que una 'interfaz tradicional, por lo que el sistema resulta más costoso.

I

I1

Los sonidos que se incorporen a lpna interfaz deben ser cuidadosamente

seleccionados, de tal forma, que sean Similares a los que el operador va a escuchar en 11

IB

la planta; de lo contrario puede causar confusión. I1

I/

La incorporación de sonido en una interfaz debe considerar que los, eventos que se generan pueden ser paraielos, por lo que si no existe programación concurrente puede haber bloqueo de eventos inhabilitando al operador de recibir dichos evlentos.

I1 111. PERSPECTIVAS FUTURAS

Algunas de las perspectivas que se proponen en base a los resultados obtenidos:, I 111

k Incorporación de sonido en todas las alarmas,del simulador de aula prototipo. Debido

a las evidencias obtenidas al concluir el presente trabajo, se propone que todos los

tableros de alarmas de la interface bb09 tengan sonido y sean contro1adas:con los

controles correspondientes.

iJ

!I

11 'O6 Sistema multimedia y su aplicación en el diseño de interfaces para la supervisión y control de procesos

Resultados, conclusiones y perspectivas

II 9 Incorporación de sonido ambiental en todos los controles del panel BB09, utilizando

los sonidos reales de la CNLV. Se propone que todos los instrumentos de control tengan

sonido referente a la función que realizan; por ejemplo, la palanca que arranca o apaga

bombas, debe tener el sonido similar que se prbduce en el ambiente real cuando sucede

esta operación.

11 I

9 Investigación del uso de vídeo en este tipo de aplicaciones. Durante el desarrollo de la

investigación realizada, se encontró que el uso de video en interfaces para control de

procesos puede ayudar a monitorear de manera más eficiente procesos peligrosos que

requieren de continua y cercana vigilancia. Asimismo, se puede utilizar para obtener

I1

ti imágenes históricas de los eventos sucedidos en fechas anteriores. II

107

Sistema multimedia y su aplicación en el diseño de intelces para la supervision y control de procesos II

APÉNDICE A

I

EVALUACI~N DINÁMICA DE LA INTERFAZ

I

I Apéndice A

II

EVALUACI~N DEL DESPLIEGUE QUE SIMULA EL PANEL BBOQ DE

It LA CNLV DESARROLLADO EN EL IIE

I/

Gracias por ayudarme a realizar las pruebas y evaluaciones pertinentes a los

despliegues gráficos que simulan paneles de control de una planta eléctrica, quhica

o de alguna área de procesos.

El objetivo de las pruebas es evaluar la interacción que tienen las interiaces

con el usuario en esta área de control de procesos; así que por favor siéntase libre de

expresar su opinión acerca de la interface. I f

Por favor no escriba su nombre en est? documento. Estoy evaluando la

interacción de la interface con el usuario, estoy evaluando la capacidad del usuario

en cuanto al manejo de la interface. Si existe algún1 problema al realizar alguna de las

tareas, es mi falla en el diseño del sistema y no es error de usted.

I __._

I I1

11 Muchas gracias por su tiempo, su disponibilidad y comentarios.

11

11

11

Apéndice A

EVALUACION DEL PANEL DE NAVEGACION

La figura que observa en el monitor muestra el despliegue de un panel de

control virtual que se opera en el ambiente de control de procesos. Este despliegue

cuenta con objetos de control manipulables por el usuario.

11

I1

11

El despliegue que simula el panel de control está dividido en tres partes: el

menú de control del sistema, que se encuentra en ¡a parte superior del despliegue; el

área de despliegue del panel, que contiene todos los objetos gráficos; y el menú de

navegación, que se encuentra en la parte inferior del despliegue.

I(

,I

II

I1

A continuación se listan algunas tareas para realizar en el despliegue del

panel. n

j!

Apéndice A I

LISTA DE TAREAS:

1. En la parte superior del despliegue del panel se localizan los tableros de alarmas.

Localice el primer tablero de despliegue de alarmas que se encuentra ublicado

en la parte superior izquierda. Haga una amplificación de dicho tablero usando la

función Zoom To. I

2. Visualice la alarma HPCS actuado que se encuentra en el tablero de alarmad que

amplificó en el paso anterior (está ubicada dentro de un recuadro rojo). Realice un

acercamiento de tal forma que solo se visualice, esta alarma en la pantalla. Utilice

la función de Zoom To. I/

3. Restablezca el despliegue al 100%.

I’

1 4. Localice los botones de control de alarma (están de color amarillo), y realice una

amplificación de tal forma que pueda visualizar las etiquetas de los botones.

Vuelva a utilizar la función de Zoom To.

5. Presione el botón de prueba, y después despliegue el tablero al 100%. Obseive

los tableros de alarmas.

6. Haga una vez más una amplificación de los botones de control de alarmas

(recuerde que están en un tablero de color amarillo); y desactive el botón de

prueba presionándolo una vez más.

I\

11

I

7. Restablezca el despliegue a un 100%. li

A 4 !I

I

I<

Apéndice A I

8. Realice un Zoom Out (alejamiento) presionando el botón que realiza esa función

II

Como habrá observado, el sistema no ejecuta ninguna acción, pues cuarido el

despliegue está al 100% no es posible hacer un alejamiento. I

9. Realice un Zoom In (un acercamiento).

1 O. Repita el paso anterior 5 veces. 11

I/ Como habrá observado el sistema tiene un límite de acercamiento a los objetos,

por lo que cuando los objetos ya llegaron a su amplificación máxima, ya no

permite un acercamiento mas. h

I\

11.Deshaga las acciones anteriores hasta llegar a una vista del 100%. Utilice la I1

función de deshacer.

!I

b

Si se llega a una pantalla no deseada, favor de usar la función de rehacer. 11

I!

12. Disminuya el factor de escalación menor al 2%. , I

Apéndice A I1

13.Realice un acercamiento utilizando el Zoom In,

I

:I


15.Aumente el factor de escalación mayor a 4%.

16. Realice un acercamiento utilizando un Zoom in. 1

17.Utilice el icono del panel de control que está en la parte inferior de la pantalla, para

localizar los botones de control de alarmas (recuerde que están en un table& de

color amarillo).

18. Utilice las flechas de desplazamiento para ubicar con más precisión el tablero

dónde se encuentran los botones de control de alarmas que acaba usted be

seleccionar en el paso anterior. I

,I

19.Utilizando nuevamente el icono del panel, seleccione cualquier área de su interés,

utilizando también las flechas de desplazamiento lpara precisar los objetos. Y

A-6

I

Apéndice A

20.Realice un acercamiento a los botones de control de alarmas, utilizando la I1

$

función Zoom que usted prefiera.

21. Restablezca el despliegue del tablero al 200%.

22. En el despliegue se encuentran algunas palancas que realizan ciertas acciones de

control en cuanto a arranquelparo de bombas. Éstas están localizadas dentrÓ de

recuadros blancos. Localice cualquiera de las bombas del tablero y realice un

acercamiento. Utilice las funciones de Zoom para hacer acercarnientos.

11

It

23.Seleccione cualquier parte dentro del recuadro rojo de la palanca.

24.Arranque la bomba de hpcs presionando en la etiqueta 'arrancar' de la palanca he 1,

hpcs. 'I


H

1i 26.Tómese un par de minutos para explorar libremente la interface.

Una vez más, gracias por su disponibilidad. ..

A-7,

Apéndice A

CUESTIONARIO t

Abajo de cada pregunta se presenta una escala del 1 al 7 (siempre-nunca).

Por favor marque con una X el número que mejor describa su respuesta.

1. ‘Cuando interactúa con el sistema, puede percibir si la acción que ejecuta es correcta 11 o incorrecta?

7 6 5 4 3 u SIEMPRE NUNCA

2. ¿Es sencillo desarrollar las tareas en la interface del sistema?

7 6 5 4 3

SIEMPRE NUNCA

3. ¿La interface indica si una acción ha sido.0 no realizada?

SIEMPRE NUNCA

4. ¿La interface responde adecuadamente a las acciones o comandos realizados?

&I% . A SIEMPRE

A-8

Apéndice A

SIEMPRE NUNCA

6. Sintió usted realmente tener el control de la interface?

SIEMPRE NUNCA

'1

7. 'Resulta claro para usted cuando comete algún error en el manejo de la interface? , i

SIEMPRE NUNCA

8. Resulta fácil corregir errores de manejo en el sistema?

9. ¿Le resulta sencillo y agradable la manipulación de la interface?

SIEMPRE NUNCA

I

A-9

Apéndice A

!!

I/

10. En cuanto a la manipulación de las palancas, ¿Es clara su ejecución y manejo? J

SIEMPRE NUNCA

I

OPINIONES I/

A continuación se listan algunas preguntas abiertas, por favor sientase

en confianza de contestar a su libre albedrío. ,b

1.

2.

3.

4.

11

'Qué aspectos de la Interface piensa usted que se deben mejorar, añadit o I!

I1

quitar? I

AI efectuar las tareas solicitadas en esta evaluación, ¿las herramientas que ofrece

la interface fueron suficientes y adecuadas o algunas entorpecieron la ejecuchn

de estas tareas? II

11

II

// Existe algo en la interface que le cause molestia o le impida sentirse bien al

realizar sus tareas? 11

\ I

I

II Tiene algún comentario (bueno o malo) que desee añadir a esta evaluación?

'1

A-I O 11

\ - .

'I

Apéndice A II

EVALUACIÓN Y PRUEBA DE Of€RACIÓN DE ALARMAS I,

INFORMACIÓN GENERAL:

!' LOS despliegues que observas en las pantallas simulan un panel de control de

Procesos, Por 10 que un elemento indispensable es el manejo y control de alarmas que se disparan cuando ocurren eventos críticos. En el despliegue principal se

muestra uno de los 4 tableros de alarmas, además, del tablero donde se encuentran

10s botones control de alarmas: Silenciar, Reconocer, Restablecer y Prueba. ,I

En el despliegue que se encuentra a la izquierda del monitor que contiene el

despliegue principal (el de las alarmas), se muestra una gráfica que monitorea el

comportamiento de ciertos parámetros importantes en el proceso. La gráfica ''va

tomando valores de acuerdo al estado del proceso q$e está monitoreando. :I

~ ... -~ . l i

I1

En el último monitor de la izquierda se encuentra'el despliegue de la palanca que

controla los eventos críticos de las alarmas, por lo que al presionarla en la posición de I/

I/ arranque o paro (según sea el caso) la alarma será controlada.

,I

11

El escenario está preparado para que ocurran eventos anormales durante ,la A operación de la interface, tal como sucede en ocasiones en una planta de control de 11

procesos. A continuación se presentan las instrucciones a seguir en esta evaluación,i !I

11

1 A-I 1

Apéndice A I/

INSTRUCCIONES PARA LA EVALUACIÓN DE OPERACIÓN DE ALARMA'S

I1

La tarea consiste principalmente en observar las alarmas que se dispaian y

realizar la acción pertinente para solucionar el problema; al mismo tiempo que se'está

monitoreando los valores que despliega la gráfica de tendencia. I

!O

11

INSTRUCCIONES:

1. Anote en una hoja los diferentes valores que ;a mostrando la gráfica que,, se J,

muestra en el despliegue.

2. Si se dispara una alarma, presione el 'botón de silenciar, y después accione$ la

palanca de control de eventos críticos, ya sea, que la ponga en posición jde

arranque o de paro (según se requiera). I

#!

Nota: En cuánto a las tareas, dé prioridad a las alarmas que se disparan. 1,

I

I1

11

!

!\

Gracias por su tiempo y disponibilidad. , j

A-12

\ Apéndice A

II

EVALUACION DEL DESPLIEGUE VASIJA: ANÁLISIS DE LA SITUACIÓN I

I

11

11

i

En esta sesión se ha preparado un escenario que involucra eventos anormales

en el funcionamiento de la planta que representa la interface. En esta evaluación no

hay ninguna tarea que ejecutar por parte del usuario, solo observar los eventos,que

ocurren en la interface. 1

AI finalizar la sesión responde por favor al cuestionario correspondiente a esta I1

evaluación.

,I

A-I 3

Y Apéndice A

CUESTIONARIO

I. ‘Percibió el momento preciso en que se dispararon cada una de las alarmas? I

SIEMPRE NUNCA

11

2. ¿En algún momento de la sesión, la situación que se presentó en el despliegue te pareció grave en

cuanto al proceso?

7 6 5 4 3 2 1 u SIEMPRE

3. ‘Captó los momentos críticos de la sesión? I1

7 4 3 2 1

SIEMPRE NUNCA

/I

4. ‘Piensa que la interface mostró de alguna manera el ambiente que se da en una planta de control I1

de procesos cuando suceden eventos críticos?

7 6 5 4 3 2 1 , I!

SIEMPRE NUNCA

I /

A-14

I 6. Si se dispara una alarma, ¿la interface le indica claramente y sin ambigüedad porqué se generó?

ll

7 6 5 4 3 2 1 u SIEMPRE NUNCA

1

7. 'Pudo percibir cuántas alarmas se encuentran activadas d e manera simultánea? 11

SIEMPRE NUNCA,

8. AI final de la sesión, 'podría resumir el estado de la vasija del reactor?

SIEMPRE NUNCA ';

11

A-I 5

11

Apéndice A

9. 'Percibió la causa (o causas) que originaron las alarmas? '/

'I

7 6 5 4 3

SIEMPRE NUNCA

8,

10. Con lo que ofrece el despliegue de vasija, 'considera que un operador podria estar más preparado 11

para enfrentarse a eventos críticos en la operación y manejo de una planta?

7 6 5 4 3 2 1 u SIEMPRE NUNCA

!:

'I

A-1 6

- _

11

t Apéndice A

O P I N I O N E S F I N A L E S 1,

I. ¿Percibió usted alguna diferencia entre la primer sesión y esta última?

I

I 2. En el caso de que haya notado alguna diferencia, ‘podría describirla?

I

14

3. ¿En cuál de las dos sesiones se sintió usted más seguro en la ejecución de’ las tareas?

I

4. ‘Cuál fue el aspecto que lo hizo sentirse más seguro? , (o en su defecto, que I/ lo hizo sentirse inseguro? I

I

/I

A-17

\

Apéndice A

VALORES DE LA PLUMILLA AZUL I 3

VALORES DE LA PLUMILLA ROJA

I

I

I I/

I

I1 I

I I

A-1'8

APÉNDICE t B

EN LA GRABADOS,, ARCHIVOS DE DATOS

EVALUACI~N DINÁMICA DE LA INTERFAZ

alarmas

CANAL canal 7 0 0 canal 704 canal 7 0 7 canal 7 2 0 canal 7 2 1 canal 3 4 2 canal 343 canal 33 canal 3 4 2 canal 3 4 2 canal 3 4 2 canal 3 4 2 canal 7 0 0 canal 7 0 1 canal 33 canal 48 canal 342 canal 3 4 2 canal 7 0 0 canal 7 0 1 canal 48 canal 343 canal 343 canal 5 1 canal 5 1 canal 4 9 canal 3 4 2 canal 3 4 2 canal 344 canal 344 canal 3 2 canal 3 2 canal 4 9 canal 7 0 0 canal 7 0 1 canal 42 canal 344 canal 344 canal 42 canal 48 canal 342 canal 3 4 2 canal 3 4 2 canal 3 4 2 canal 3 4 3 canal 48 canal 3 4 3 canal 51 canal 343 canal 5 1 canal 343 canal 3 2 canal 342

VALOR valor valor valor valor valor valor valor valor valor valor valor valor valor valor valor valor valor valor valor valor valor valor valor valor valor valor valor valor valor valor valor valor valor valor valor valor valor valor valor valor valor valor valor valor valor valor valor valor valor valor valor valor valor

/SERAL 1 . 0 0 1 . 0 0 0 .00 1 . 0 0 0.00 0.00 0 .00 1 . 0 0 1 . 0 0 0 . 0 0 1 . 0 0 0 . 0 0 0 . 0 0 1 . 0 0 0 . 0 0 1 . 0 0 1 . 0 0 0 . 0 0 1 . 0 0 0 .00 0 .00 1 . 0 0 0 . 0 0 1 . 0 0 0 . 0 0 1 . 0 0 1 . 0 0 0 . 0 0 1 . 0 0 0 .00 1 . 0 0 0 .00 0 .00 0 .00 1 . 0 0 1 . 0 0 1.00 0 .00 0 .00 1 . 0 0 1.00 0.00 1 . 0 0 0 . 0 0 1 . 0 0 0 . 0 0 0 . 0 0 1 . 0 0 1 . 0 0 0 . 0 0 0 .00 1 . 0 0 1 . 0 0

Apéndice B Archivo que registra los tiempos de un usuario en el manejo de

1)

FECHA/HORA Mon Dec 1 4 1 8 : 4 9 : 0 2 1 9 9 8 Mon Dec 1 4 1 8 : 4 9 : 0 2 Mon Dec 1 4 1 8 : 4 9 : 0 2 i :gg8 Mon Dec 1 4 1 8 : 4 9 : 0 2 1 9 9 8 Mon Dec 1 4 1 8 : 4 9 : 0 2 1 9 9 8 Mon Dec 1 4 1 8 : 4 9 : 0 2 1 9 9 8 Mon Dec 1 4 1 8 : 4 9 : 0 2 1 9 9 8 Mon Dec 1 4 18 :49 :24 1 9 9 8 Mon Dec 1 4 18 :49 :44 1 9 9 8 Mon Dec 1 4 1 8 : 4 9 : 4 5 1 9 9 8 Mon Dec 1 4 1 8 : 4 9 : 4 6 1 9 9 8 Mon Dec 1 4 1 8 : 4 9 : 4 7 1 9 9 8 Mon Dec 1 4 1 8 : 5 0 : 0 9 1 9 9 8 Mon Dec 1 4 1 8 : 5 0 : 0 9 1 9 9 8 Mon Dec 1 4 1 8 : 5 0 : 0 9 1 9 9 8 .,

Mon Dec 1 4 1 8 : 5 0 : 3 2 1 9 9 8 Mon Dec 1 4 1 8 : 5 0 : 4 0 1 9 9 8 Mon Dec 1 4 1 8 : 5 0 : 4 0 1 9 9 8 Mon Dec 1 4 1 8 : 5 0 : 4 9 1 9 9 8 Mon Dec 1 4 1 8 : 5 0 : 4 9 1 9 9 8 Mon Dec 1 4 1 8 : 5 0 : 5 1 1 9 9 8 Mon Dec 1 4 1 8 : 5 1 : 4 9 1 9 9 8 Mon Dec 1 4 1 8 : 5 1 : 4 9 1 9 9 8 Mon Dec 1 4 1 8 : 5 2 : 3 2 1 9 9 8 Mon Dec 1 4 1 8 : 5 2 : 3 3 1 9 9 8 Mon Dec 1 4 1 8 : 5 3 : 3 2 1 9 9 8 Mon Dec 1 4 1 8 : 5 3 : 3 9 1 9 9 8 Mon Dec 1 4 1 8 : 5 3 : 4 0 199,s Mon Dec 1 4 18 :53 :47 199.8 Mon Dec 1 4 1 8 : 5 3 : 4 7 199,8 Mon Dec 1 4 1 8 : 5 3 : 5 2 1 9 9 8 Mon Dec 1 4 1 8 : 5 3 : 5 3 1 9 9 8 Mon Dec 1 4 1 8 : 5 4 : 0 5 1 9 9 8 Mon Dec 1 4 1 8 : 5 4 : 0 5 1 9 9 8 Mon Dec 1 4 1 8 : 5 4 : 0 5 1 9 9 8 Mon Dec 1 4 1 8 : 5 8 : 4 9 1 9 9 8 Mon Dec 1 4 1 8 : 5 8 : 5 3 1 9 9 8 Mon Dec 1 4 1 8 : 5 8 : 5 3 1 9 9 8 Mon Dec 1 4 1 8 : 5 9 : 0 7 1 9 9 8 Mon Dec 1 4 1 8 : 5 9 : 5 4 1 9 9 8 Mon Dec 1 4 1 9 : 0 0 : 0 4 1 9 9 8 Mon Dec.14 1 9 : 0 0 : 0 4 1 9 9 8 Mon Dec 1 4 1 9 : 0 0 : 0 6 1 9 9 8 Mon Dec 1 4 1 9 : 0 0 : 0 6 1 9 9 8 Mon Dec 1 4 1 9 : 0 0 : 5 5 1 9 9 8 Mon Dec 1 4 1 9 : 0 0 : 5 5 1 9 9 8 Mon Dec 1 4 1 9 : 0 0 : 5 5 1998. Mon Dec 1 4 1 9 : 0 1 : 5 4 1 9 9 8 Mon Dec 1 4 1 9 : 0 2 : 0 2 1 9 9 8 Mon Dec 1 4 1 9 : 0 2 : 0 3 1 9 9 8 Mon Dec 1 4 1 9 : 0 2 : 0 3 1 9 9 8 Mon Dec 1 4 1 9 : 0 3 : 1 4 1998' Mon Dec 1 4 1 9 : 0 3 : 1 9 1 9 9 8 ,

B-2

Apéndice B

canal 342 valor 0.00 Mon Dec 14 19:03:20 1'998 canal 342 valor 1.00 Mon Dec 14 19:03:23 1'998 canal 342 valor 0.00 Mon Dec 14 19:03:23 1'998 canal 344 valor 1.00 Mon Dec 14 19:03:25 1998 canal 344 valor 0.00 Mon Dec 14 19:03:25 1998 canal 32 valor 0.00 Mon Dec 14 19:05:39 1998

Apénbice B

(Otro usuario) Archivo que registra 10s tiempos de un usuario en el manejo de alarmas

CANAL VALOR/SER& FECHA/HORA canal 702 valor 1.00 Thu Dec io 10:44:53 1998 canal 707 valor 0.00 Thu Dec io 10:44:53 1998 canal 720 valor 1.00 Thu Dec io io:44:53 1998 canal 721 valor 0.00 Thu Dec 10 10:44:53 11998 canal 342 valor 0.00 Thu Dec i o io:44:53 1998

canal 33 valor 1.00 Thu Dec 10 10:46:50 1998


canal 342 valor 1.00 Thu Dec 10 10:47:00 1998 canal 342 valor 0.00 Thu Dec 10 10:47:02 1998 canal 342 valor 1.00 Thu Dec 10 10:47:04 1998 canal 342 valor 0.00 Thu Dec 10 10:47:05 1998 canal 701 valor 1.00 Thu Dec 10 10:47:19 1998 canal 33 valor 0.00 Thu Dec 10 10:47:20 1998 canal 344 valor 1.00 Thu Dec 10 10:47:45 1998 canal 344 valor 0.00 Thu Dec 10 10:47:46 1998

canal 344 valor 0.00 Thu Dec 10 10:47:46 19.98


canal 48 valor 1.00 Thu Dec 10 10:47:58 1998 canal 48 valor 0.00 Thu Dec 10 10:47:59 1998 canal 51 valor 1.00 Thu Dec 10 10:49:58 1998 canal 51 valor 0.00 Thu Dec 10 10:49:59 1998 canal 49 valor 1.00 Thu Dec 10 10:50:59 1998 canal 342 valor 1.00 Thu Dec 10 10:51:09 1998

canal 342 valor 1.00 Thu Dec 10 10:51:12 1998 canal 342 valor 0.00 Thu Dec 10 10:51:12 1998 canal 344 valor 1.00 Thu Dec 10 10:51:14 1998 canal 344 valor 0.00 Thu Dec 10 10:51:14 1998 canal 32 valor 1.00 Thu Dec 10 10:51:18 1998 canal 32 valor 0.00 Thu Dec 10 10:51:19 1998


!I

!I

'1

canal 343 valor 0.00 Thu Dec 10 10:44:53 11998 11

canal 42 valor 1.00 Thu Dec io 10:46:53 1998 11:

canal 342 valor 0.00 Thu Dec 10 10:46:58 1998 ;!

'11

canal 344 valor 1.00 Thu Dec 10 10:47:46 1998 !I

canal 42 valor 0.00 Thu Dec 10 10:47:55 19,98 !I

canal 701 valor 0.00 Thu Dec 10 10:47:55 1998 I/

'I

canal 342 valor 0.00 Thu Dec 10 10:51:09 1998 !I

I!

il

canal 700 valor 0.00 Thu Dec 10 10:51:26 1998 11

canal 49 valor 0:OO Thu Dec 10 10:51:26 1998 /I

APENDICE c I/

PROGRAMAS DESARROLLADOS ' Ij PARA REALIZAR LA EVALUACIÓN

DE CONTROL DE ALARMAS

I!

Anexo C I

Escribe-mem.c

Programa que simula señales de alarma cada cierto tiempo, las escribe en memkria compartida. Esto con el objeto de que el programa que despliega el panel bbO9 pueda accesar a ellas y se generen alarmas en el tablero, sin tener que realizar la simulación utilizando el código MAAP. 11

Guardadat0s.c I!

Programa que lee un archivo de datos llamado datalog.indices y guarda las señales que se vayan generando con el simulador del código'VASIJA. Este programa es &a adaptación del programa original datal0g.c proporcionado por el Dr. Carlos Chavez Mercado. El objetivo de este programa es capturar todas las señales de a l m a que genera el código VASIJA durante una sesión, para despues reproducirlas sin necesidad de volver 'L ejecutar el simulador del código VASIJA. Lo anterior con el fin de que todos los usuarios tuvieran el mismo escenario de evaluación, con las mismas alarmas en el mismo tiempo.

I II Recobra-datosc

I

Programa que obtiene los datos que se guardaron con el archivo guarda-dat0s.c y permite la simulación de señales para que el despliegue VASIJA se ejecute recibiendo señales (previamente capturadas con guarda-dat0s.c). I/

11

Dataloghdices d

Archivo de datos que contiene todos los canales de memoria del despliegue de' VASiJA que reciben señales de a l m a del simulador de código correspondiente a este1 despliegue. El primer número indica que pertenece al despliegue vasija (1-Mmp, 2-Vasija,

I) 3-Paneles de control); el segundo es el canal de memoria donde recibe la señal.

Tmpo-acces0.c 11

Programa que registra las acciones del operador sobre el despliegue de los paneles de control, durante una sesión de evaluación. El programa,accesa a la memoria compartidal! para ver los valores de los canales de la memoria compartida, si hay algún cambio en ellos, lo registra en un archivo de texto, escribiendo el canal,el valor, y la fecha y hora en que se !! dio el cambio. 1

* /I

c-1

,I

Apéndice C

E s c r i b e mem.c - //Programa que escribe en la memoria señales de Blarma en determinado tiempo I1

#include "shmem3A. h" #include "ccommon. h" #include <unistd.h>

struct shmid ds viewbuf; int viewid; BE9 - VDS *viewptr;

- 6

main (argc, argv) int argc; char *argv[] ; t

i,

int channel, oper, i; float value; char *create-shm() ; r

(viektr = (BB9-VDS * ) create-shrn(&viewid,atoi (argv[ll), 11 if ( SHM C

MEM SIZE, &viewbuf)) < O) ( printf ("Error in bb9db cuando trata de crear'memoria compartida\n") I; exit (-1) ;

1 ¡I

/*Cambia el valor de las alarmas despues de un tiempo*/ , I fflush(stdout); usleep (15000000) ; viewptr->values [ 3 3 ] =1. O;

I)

fflush(stdout1; usleep (3000000); viewptr->values[421=1.0;

fflush(stdout1; usleep (60000000); viewptr->values[311=1.0;

fflush(std0ut); usleep(5000000) ; viewptr->values[481=1.0;

fflush(stdout); usleep(120000000) ; viewptr-zvalues[51]=1.0;

fflush(stdout) ; usleep(60000000); viewptr->values [491=¡. O;

fflush(stdout); usleep (200000001 ; viewptr->values[32]=1.0;

'!

d Apéndice C

j/

}/*fin main*/ !

I1

*create-shmo función \ / * * f * * * * * * * * f * * * * * * * * t * * * * * * * * * * * * * * * * * ~ ~ ~ ~ * ~ * * ~ ~ ~ * ~ * ~ ~ * * ~ ~ ~ ~ ~ * ~ ~ ~ ~ * ~ * ~ ~ * ~ ~ ~

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . *

char * create shm(shmid, key, size, buf) / * added from uti1ity.c * / key t key; int-* shmid, size ; struct shmid ds *buf; {

char *shm seg;

- 11

-

,\ - if ((*shmid = shmget(key, size, IPC-CREAT I 0666)) < O ) (

perror ("create-shm ( ) : shmget ( ) " ) ; '1 return ((char * ) -1);

) if (shmctl(*shmid, IPC STAT, buf) < O) {

perror ("create-shm (7: shmcti ( ) O') ; return ((char * ) -1);

,

1

i!

/ * Obtiene la dirección de la memoria compartida.'*/ if ((shm-seg = shmat(*shmid, .(char * ) NULL, 1PC.CREAT - I 0 6 6 6 ) ) == (char * ) -1)

( I !Y perror ("create-shm ( ) : shmat ( 1 " ) ; return ((char * ) - 1 ) ;

1 return (shm-seg) ;

char * att shm(shmid, key, size, shm-flag) int *chid; size, shm - flag; key-t key; I

char *shm-seg; ¡I

if ((*shmid = shmget(key, size, O ) ) < O ) í printf("*** In ini, att-shm: problem with shmget ***\n"); return ((char * ) - l ) ;

,! 1

if ( ( s h m seg = shmat<*shmid, (char *)NULL, shm flag)) == (char * ) -1) { printf ( I r * * * In ini, att-shm: problem wilth shmat ***\,"I ; return ((char *). - 1 ) ;

1,

1 return (shm-seg) ;

)

11

~

I\

Apéndice C

i

Guarda - dat0s.c / * * * * * * * * i * * * * * * * * * * t * * * * * * * * * * * * * t * f * * * ~ ~ * ~ ~ * ~ ~ * ~ ~ ~ ~ * ~ * * ~ * * * * ~ ~ * ~ ~ ~ ~ ~ * ~ ~ ~ ~ ~ * ~ ,

* Archivo que guarda los datos que lee de un ayhivo de texto llamado * *datalog.indices que en este caso guarda los canales que reciben señales*

i(

* *de . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vasija ¡I

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ARCHIVOS INCLUDE

#include <stdio.h> #include "termlib. h" #include "ccommon . h" #include "shmemiie. h"

PNL VDS *pnlptr; MF-VDS *maapptr; VAS VDS *vasptr; stafic int attfiag=O; void onintr ( 1 ; FILE *fp; '!

1!

? #define MAXINDICES 256

main ( ) t

int flag=l;

long last-secs,current-secs; long last-usec, current-usec; float secs=l; unsigned udoze=100000;

/ * PARA EL TIEMPO*/

/ * micro segundos * / struct timeval tp; struct timezone tzp;

int itimes; float duration; / * " * / !

int sh-getdata(); ¡I

C-4

Apéndice C

char filename[40]; char shmbuf [ 4 *MAXINDICES+16 J ; char tme 191, dt [ 9 ] ; int ni,indices[MAXINDICESl,wherefrom[MAXINDICES];

signal (SIGINT, onintr) ; signal (SIGTERM, onintr) ;

ni=get-indices (indices,wherefrom);

printf ("Enter data save filename: " ) ; do i

gets(fi1ename); ) while ( ! *filename) ;

if ( (fp = fopen(filename, "w"))==NULL) { perror (filename) ; exit ( O ) ;

)

shm getdata (ni, indices, wherefrom, shmbuf+20, ,&attflag) ; mem~pyishmbuf,&pnlptr->date[OI,16); / * first 16 bytes for DAS date * / memcpy(shmbuf+l6,&ni,4); memcpy(shmbuf+20,indices,4*ni); / * and channels indices recorded * / memcpy(shmbuf+20+4*ni,wherefrom,4*ni); / * and channels indices recorded

/ * record number of indices * / , I

* / if (!fwrite(shmbuf,1,8*ni+ZO,fp))

printf ("error writing data\n") ;

/ * ARADE TIEMPO PARA INICIALIZACION * { if ( gettimeofday(&tp,&tzp)) {

printf ("error getting time of day\n"); last-secs=O; last-usec=O;

) else { last secs=tp.tv-sec; iastIusec=tp. tv-usec;

) /*========= FIN DEL TIEMPO DE INICIALIZACION . . . . . . . . . . . . . . . . . . . . . . . . .

CLEAR; while (flag != O ) ( / * CICLO PRINCIPAL */

memcpy(shmbuf, &pnlptr->dateto], 16) ; shm-getdata(ni, indices, wherefrom, shmbuf+20, &attflag); memcpy(tme,shmbuf,8); memcpy(dt,shmbuf+8,8); MOVI2,l); printf ( "DAS Time : % s , Date : %s\n", tme, dt 1 ;

if ( ! fwrite (shmbuf, 1,4'ni+20, fp) ) printf("error writing data\n");

/ * TIMING LOOP PER DATA EXCHANGE * /

if ( gettimeofday(&tp,&tzp)) (

c-5

Apéndice C

printf("error getting time of day\n") ; current-secs=O; current-usec=O;

1 else {

current-secs=tp.tv-sec; current-usec=tp.tv-usec;

1 duration=(float) (current secs-last secs)+ !

(float) (current-usec-last-usec) - - /IOOOOOO. o; / *

* / printf ("%f seconds for data save\n",duration)';

if(duration > secs) printf("WARN1NG: data save took %f times more than allotted.\n",

duration/secs); for (itimes= SHM~C(lOOOOOO.O*secs/udoze); itimes>O ; itimes-) (

if ( gettimeofday(&tp,&tzp)) ( printf ("error getting time of day\n"); current-secs=O; .current-usec=O;

1 else I current-secs=tp.tv-sec; current-usec=tp.tv-usec;

1 duration=(float) (current-secs-last-secs)+

if(duration > secs)

usleep(udoze) ; 1 last-secs=current-secs; last-usec=current-usec;

if (itimes<=O)

(float)(current~usec-last~usec)/,l000000.0;

break;

/ *

printf("maxed out on dozing intervals in TIMING function\n"); * /

1

int sh-getdata (numvar, indices, wherefrom, data, attflag) int numvar; int indices [ I ; int wherefrom [ I ; float data[]; int *attflag; I

1

int i, index, reply, ghmid; char *att - s hm0 ;

if (*attflag != 3) I if(SHM C(pn1ptr = (PNL-VDS *)att-shm(&gsmid, PNL KEY, PNL SIZE, O ) ) < O ) {

priñtf ("***In ini, sh-getdata: unable to attach to PN¿ shm ***\n") ;" perror("PNL attaching error");

I/ exit (-1) ; I\

C-6

Apeydice C

if(SHM-C(maapptr = (MAAP VDS *)att shm(&gsmid, MAAP KEY, MAAP SIZE, O)) < - - - -

0) ( printf("***In ini, shm-getdata: unable to attach to MAAP shm ***\n"); 11 perror("MAAP attaching error") ; exit (-1) ;

1 I1

if(SHM C(vaSPtr = (VAS-VDS *)att shmí&gsmid, VAS KEY, VAS SIZE, O ) ) < , O ) ( priñtf ("***in ini , shm-getdata: unable to attach to VAS shm ***\n"); perror ("VAS attaching error") ; exit (-1) ;

I

*attflag = 3; 1 reply = O;

for (i=O; i<numvar; i++) ( index = indices[i]; if (wherefrom[il == O)

if (wherefrom[il == 1)

if (wherefrom[il == 2)

printf ("%f\n",data[il ) ;

data[i] = pnlptr->values[index];

data[i] = maapptr->values[index];

data [i] = vasptr->values [index] ;

I i I

1 return reply;

) ,I

char * create-shm(shmid, key, size, buf) / * added,from uti1ity.c * / key-t key; int *shmid, size; struct shmid-ds *buf; 4

11

I1

/*char *shmatO, *shm-seg;*/ char *shm-seg;

if ((*shmid = shmget(key, size, IPC - CREAT I 0 6 6 6 ) ) < O ) I perror ("create-shm() : shmget í ) " ) ; return ((char * ) -1);

1 if (shmctl(*shmid, IPC-STAT, buf) < O ) (

perror ("create-shm() : shmctl() " ) ; I

return ((char * ) -1); 1

/ * Get shared memory address. * / if ((shm-seg = shmat('shmid, (char '1 NULL, IPC-CREAT I 0666)) == (char * ) -

~

1) perror("create-shm0 : shmat 0" ) ; return ((char * ) -1);

char att-shm(shmid, key, size, shm-flag) int *shmid, size, shm-flag; key-t key;

c-7

Apéndice C I'

{ /*char *shmat O, *shm-seg;*/

char 'shm seg; - if ((*shmid = shmget(key, size, O)) < O) { '

printf("*** In ioc, att-shm: problem with shmget ***\n"); return ((char *)-l);

1 if ((shm-seg = shmat(*shmid, (char *)NULL, ;shm-flag)) == (char * ) - 1 ) ' t

printf("*** In ini, att shm: problem.with shmat ***\n"); return ((char * ) -1); , -

1 return (shm - seg);

1

usage í ) t

I

windup ( )

exit (-1) ;

1 exit (O) ;

1

int get-indices(indices,wherefrom) int indices[l,wherefrom[]; I int dummy, dummy2, count;

if ( (fp=fopen ("datalog. indices", "r") )==NULL) t printf ("Error opening datalog.indices file,\n") ; exit (1) ;

1

count=O; 11 while( (fscanf(fp,"%d %d\n]",&dumy,&dummy2 ) ! = EOF) & & count < MAXINDICES)

11

if(dummy2 > O & & dummy2 <1024) { wherefrom[countl=dumy;

indices [countl=dummy2; printf ("channel %d %d\n",dumy,dummyZ) ; count++;

I I \

else printf ("BAD indice read %d\n",dummy) ; !

1

printf("%d Indices to be recorded\n",count); fclose (fpl ; return (count) ;

void onintr ( ) t fclose(fp); exit (O) ;

C-8

Apéndice C ,(

I Recobra dat0s.c -

I!

#include <stdio,h> #include "term1ib.h"

PNL VDS 'pnlptr; MAAP VDS *maapptr; VAS VDS *vasptr; stafic int attfiag=O; void onintr ( 1 ; FILE *fp;

/ * *+* * * * * ** * ** ** ** * * * * ** ** * *** ** * * * * * ** * * +* * * * * * * * * * ** * ** ** * ** ***** * \

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

I1 main ( )

main ( )

( int flag=l; int count,start;

long last-secs, current-secs; long last-usec,current-usec; float secs=l; unsigned udoze=100000; struct timeval tp; struct timezone tzp;

int itimes;

C-9

Apéndice C \

float duration; / * 'I * / int shm putdata(); char filename [40] ;

char tme[9], dt [9] ; int ni, indices [MAXINDICES] , wherefrom[MAXINDICES] ;

signal (SIGINT, onintr) ; signal(SIGTERM, onintr);

ni=get-indices(indices,wherefrom);

printf ("Enter data saved filename: " ) ; do (

gets(fi1ename); } while ( !*filename) ;

char Shmbuf [4*MAXINDICES+16] ;

if ( (fp = fopen(filename, "r"))==NiJLL) t perrorlfilename); exit ( O ) ;

1 printf ("enter start time\n") ; fflush(stdout); scanf ("%d", &start) ;

if (!fread(shmbuf,l,k?*ni+20,fp)) printf ("error reading data\n") ;

memcpy(&ni,shmbuf+16,4); / * despliega numero de indices * /

shm-putdata(ni, indices, wherefrom, shmbuf+20, &attflag); 'I

mem~py(indices,shmbuf+20,4~ni); / * y los canales de dichos * / memcpy(wherefrom,shmbuf+4*ni+20,4*ni);

if ( gettimeofday(&tp,&tzp)) ( printf ("error getting time of day\n") ; last-secs=O; last-usec=O;

1 else (

last-secs=tp.tv-sec; last-usec=tp.tv-usec;

1 1

count=O; CLEAR; printf("!!!! DATA DISPLAY OF PREVIOUSLY RECORDED DATA ! ! ! ! ! ! ! ! ! ! ! ! ! ! !\n");

while (flag != O)( ' / * CICLO PRINCIPAL * / I,

if (!fread(shmbuf,l,4*ni+20,fp))

memcpy(&pnlptr->date[O] ,shmbuf, 16); printf ("error writing data\n");

I!

II

shm - putdata(ni, indices, wherefrom, shmbuf+ZO, &attflag); I

c-i o

Apéndice C

printf ("DAS Time:%s, Date:%s\n",tme,dt);

count++; if(count>start) (

if ( gettimeofday(&tp,&tzp)){ printf("error getting time of day\n"); current-secs=O; current-usec=O;

I else {

current-secs=tp.tv-sec; current-usec=tp.tv-usec;

I duration=(float) (current-secs-last secs)+

(float) (current - usec-iastrusec) / ~ O O O O O O . O,; /"

* / printf("%f seconds for data save\n",duration);

if(duration > secs) printf("WARN1NG: data save took %f times more than allotted.\n", I duration/secs);

for (itimes= SHM C(1000000.0*secs/udoze); itimes>O ; itimes--1 { if ( gettimeofday(&tp,&tzp)) {. printf ("error getting time of day\n") ; I current-secs=O; current-usec=O; ,

1 else i current-secs=tp.tv-sec; current-usec=tp.tv-usec;

1 duration=(float) (current-secs-last-secs)+

if(duration > secs)

usleep (udoze) ; I last-secs=current-secs; last-usec=current-usec;

(float) (current~usec-last~usec)/lOOOOOO.O;

break;

/ * ' I

if (itimes<=O) printf("maxed out on dozing intervals in TIMING function\n");

* / I

) I

int shm-putdata(numvar, indices, wherefrom, data, attflag) int numvar; int indices[],wherefrom[1; float data[]; int *attflag; {

I c-I 1

Apé$dice C

int i, index, reply, gsmid; struct shmid ds trainbuf; char *att-shm();

if ( 'attflag ! = 3)( if(SHM C(PnlPtr = (PNL-VDS *)att shm(&gsmid, PNL KEY, PNL-SIZE, o ) ) <, o) {

printf ( " * * * In ini. shm-putdafa: unable' to attach to PNL shm **\ne'$ ; perror ( " PNL shm attaching error") ; exit (-1) ;

1 ifíSHM-Címaapptr = (MAAP VDS *)att shm(&gsmid, MAAP KEY, MAAP-SIZE, O)) < - - -

0) { printf("*** In ini, shm-putdata: unable,to attach to MAAP shm **\n"); perror ( " MAAP shm attaching error") ; exit (-1) ; i/

1 ,I if(SHM C(vasptr = (VAS-VDS +)att shm(&gsmidi VAS-KEY, VAS SIZE, O)) < ,P I (

pri%f("*+* In ini, shm-putdata: unable to attach to VAS shm **\n"); perror(" VAS shm attaching error") ; exit (-1) ;

1 *attflag = 3 ;

1 reply = O; for (i=O; i<numvar; it+) {

index = indices [il ; if ( wherefromIi1 ==O)

if ( wherefromlil ==1)

if ( wherefrom[il ==21

printf ("%f\n",data[il);

pnlptr->values[index1 = data[il;

maapptr->values[indexl = data[il;

vasptr->values [index] = data [il ;

1 return reply;

)

char * att shm(shmid, key, size, shm-flag) int *shmid; size, shm-flag; key-t key; i

/ * char *shmatO, *shm-seg; * / char *shm-seg;

if ((*shmid = shmget(key, size, O ) ) < O) { ,

printf ("*** In ioc, att-shm: problem with shmget ***\n") ; 'I return ( (char * ) -1) ; l.

1 II if ((shm-seg = shmat(+shmid, (char *)NULL, shm-flag)) == (char * ) -1) I

11 printf("*** In ini, att-shm: problem with shmat ***\n"); return ((char * ) -1);

) return (shm-seg) ;

Apéndice C

if ((*shmid = shmget(key, size, O)) < O) ( printf("*** In ioc, att-shm: problem with shmget ***\n"); return ((char *)-l);

} if ( (six-seg = shmat (*shmid, (char *)NULL," shm-flag)) == (char * ) -1) {

printf ( ' I * * * In ini, att-shm: problem,with shmat ***\n"); return ((char * ) -1);

) return (shm-seg);

1

usage ( )

I

windup ( ) I

1

exit (-1) ;

exit ( O ) ;

int get indices(indices,wherefrom) int indices[] ,wherefrom[]; t int damy, dummy2, count ;

if ( (fp=fopen("datalog.indices", "r") )==NULL) ( printf("Error opening datalog.indices file\n"); exit (1);

Ij count=O; while( (fscanf(fp,"%d %d\n]",&dummy,&dummyZ) != ,EOF) & & count < MAXINDICES) I

if(dummy2 > O 6 6 dummy2 <1024) í wherefrom[countl=dummy;

indices[countl=dummy2; count++;

1 else

printf ("BAD indice read %d\n",dummyl ;

printf ("%d Indices to be displayed\n", count) ; fclase (fp) ; return (count) ;

1

void onintr ( ) í

fclose(fp); exit ( O ) ;

1

,I

i

Apéndice C

Datalog.indices 11

Canales de memoria de vasija que reciben serial de alarma o guardan valores,lde algún instrumento de control.

2 1 2 5 2 6 2 1 2 10 2 11 2 12 2 13 2 1 4 2 15 2 1 6 2 17 2 1 8 2 22 2 2 3 2 24 2 25 2 26 2 27 2 28 2 29 2 30 2 3 1 2 33 2 34 2 35 2 36 2 39 2 40 2 4 1 2 42 2 43 2 4 4 2 45 2 46 2 47 2 48 2 49 2 50 2 5 1 2 54 2 55 2 56 2 7 1 2 1 2 2 1 3 2 74 2 75 2 76 2 77

I!

II

/I

c-14 !I

Apéndice C ,

2 78 2 100 2 101 2 102 2 103 2 104 2 105 2 106 2 107 2 108 2 109 2 110 2 111 2 112 2 113 2 114 2 115 2 116 2 117 2 118 2 119 2 160 2 161

II 4 SEP CENlDET DGIT 1,

CENTRO DE fNFQRMACIQN

11

C-I 5 t

cedidet 4 - cenidet.edu.mx · a mis amigos paty y rafa, por su amistad sincera y leal, por...

Documents