INSTITUTO POLITÉCNICO NACIONAL

Centro de Investigación en Ciencia Aplicada y

Tecnología Avanzada

Unidad Querétaro

Desarrollo de interfaz gráfica humano-máquina

GHMI para entrenamiento en control de procesos

TESIS
QUE PARA OBTENER EL GRADO DE:

MAESTRÍA EN TECNOLOGÍA AVANZADA

PRESENTA:

ING. JULIAN ANDRES RAMIREZ BAUTISTA

DIRECTOR DE TESIS:

DR. ANTONIO HERNÁNDEZ ZAVALA

Santiago de Querétaro, Qro., Agosto de 2016

1
2
Agr

3
 Agradecimientos

Este trabajo no hubiese sido posible sin la participación de personas e

instituciones que han facilitado las cosas para llegar a este feliz término. Por tanto, es
para mí un placer, expresar mis agradecimientos.

A Dios creador de la vida por permitirme avanzar siempre hacia adelante, hacia
nuevos rumbos. Que en todo momento estuvo conmigo ayudándome a aprender de mis
errores.

Al gobierno Mexicano que a través del CONACYT me apoyó con la beca de

postgrado, gracias a ello fue posible mi estancia en este proyecto de investigación para
cumplir uno de mis sueños.

Al Dr. Antonio Hernández Zavala por su aporte y participación activa en el desarrollo

de esta tesis. También deseo agradecer a los sinodales encargados de revisar y corregir
este trabajo, Dr. José Joel González Barbosa, Dr. Juan Bautista Hurtado Ramos, Dr.
Jorge Adalberto Huerta Ruelas y Dr. Joaquín Salas Rodríguez.

A mi esposa Silvia por ese optimismo que siempre me impulso a seguir adelante y por los
días y horas que alegró mi vida en los momentos de cansancio y exasperación.

A mis padres Humberto y Rosalba y mi hermano Camilo, por su gran ejemplo de

superación y valioso apoyo en todo momento a pesar de la distancia desde el inicio de
mis estudios de maestría.

A mis amigos compañeros que siempre tuvieron una palabra de apoyo y ánimo en
los momentos difíciles durante mi estadía

Finalmente quisiera agradecer a todas aquellas personas que estuvieron

acompañándome y fortaleciéndome para concluir esta etapa de mi vida, y agradezco a
la vida por darme esta oportunidad para crecer en mi carrera profesional, para ser una
mejor persona con mejores valores y principios.

4
 Resumen
Actualmente, debido a los altos estándares de personal capacitado que necesita la
industria, se tiene la necesidad de cambiar del método clásico donde el profesor impartía
el conocimiento de manera teórica, al conocimiento innovador, donde el estudiante pone
en práctica lo aprendido en clase en sistemas didácticos que simulan en cierta manera el
comportamiento de procesos industriales, de este modo el estudiante adquiere la destreza
para solucionar problemas desde diversos puntos de vista, cuando el proceso lo requiera.
Además, mediante estas prácticas se puede acortar la brecha que hay entre el conocimiento
teórico y el mundo real.
Existen empresas que fabrican módulos didácticos y software de entrenamiento
proporcionando entornos amigables, guías de aprendizaje establecidas y estructuras
robustas. Pero tiene la desventaja de depender de tiempo completo de tecnologías
extranjeras, de las metodologías impuestas por el fabricante, además de los altos costos que
representa para algunas instituciones, ya sea con la adquisición del equipo o con la
capacitación constante del profesor o instructor.
El proyecto consiste en realizar un software flexible y estandarizado para
entrenamiento en control de procesos, en el cual, el estudiante pueda seleccionar alguno
entre distintos tipos de controladores y modificar a gusto los parámetros necesarios para su
operación, así como el tipo de señal de entrada que se enviará al proceso. El software debe
tener la flexibilidad suficiente para añadir nuevos procesos, así como permitir visualizar su
comportamiento en la pantalla, para observar de manera instantánea el funcionamiento de
las variables más importantes del proceso implementado y tener una idea más clara de
cómo controlarlas. Como casos de aplicación se utiliza control de velocidad, nivel y
presión. La interfaz gráfica se realiza para propiciar una interacción más amigable entre el
alumno y el sistema mediante el uso de un lenguaje visual.

5
 Abstract
Currently, due to the high standards of trained staff that needed by the industry,
there is the need to change the traditional method where the teacher taught the knowledge
theoretically, to the innovative knowledge, where students put into practice what they
learned class on teaching systems that simulate the behavior of industrial processes, thereby
the student acquires the skills to solve problems from different points of view, when the
process requires it. In addition, through these practices you can bridge the gap between
theoretical knowledge and the real world.
There are companies that produce educational modules and training software
providing guidelines established friendly learning environments, and robust structures. But
has the disadvantage of relying on full-time foreign technologies, methodologies imposed
by the manufacturer, in addition to the high costs of some institutions, either with the
acquisition of equipment or the constant training of the teacher or instructor.
The project is to produce a flexible and standardized software to training process
control, in which the student can select any among different control types and modify the
parameters required for its operation, as well as the type of input signal to be sent to the
process. The software should have the flexibility to add new processes, as well as, visualize
their behavior on the screen to instantly observe the operation of the most important
variables of the process implemented and have a clearer idea of how to control them. speed
control, level and pressure is used as cases of application . The graphical interface is done
to foster a friendlier interaction between the student and the system through using a visual
language.

6
 ÍNDICE GENERAL

Capítulo 1. Introducción ................................................................................................ 13

1.1. Sistemas Didácticos de Control de Procesos...................................................... 13
1.1.1. Módulo central de procesamiento ............................................................... 14
1.1.2. Software de control y simulación ............................................................... 15
1.1.3. Planta de pruebas ........................................................................................ 16
1.2. Importancia de los Sistemas Didácticos de Control de Procesos ....................... 16
1.3. Antecedentes ...................................................................................................... 16
1.3.1. Rama comercial .......................................................................................... 17
1.3.2. Rama científica ........................................................................................... 18
1.4. Descripción del Problema .................................................................................. 18
1.5. Justificación ........................................................................................................ 19
1.6. Objetivos ............................................................................................................ 20
1.6.1. Objetivo General ......................................................................................... 20
1.6.2. Objetivos Específicos.................................................................................. 20
1.7. Hipótesis ............................................................................................................. 20
1.8. Resumen de Contenido....................................................................................... 20
Capítulo 2. Sistemas Didácticos para Control de Procesos ..................................... 22
2.1. Clasificación de Empresas Fabricantes de Sistemas Didácticos de Control de
Procesos ......................................................................................................................... 22
2.1.1. Empresas que fabrican el Sistema Didáctico de Control Completo ................ 22
2.1.2. Empresas que utilizan controladores comerciales acondicionados a sus propias
estructura con el software del controlador ................................................................. 23
2.1.3. Empresas que utilizan controladores comerciales con desarrollos propios de
software ..................................................................................................................... 27
2.1.4. Empresas que utilizan como módulo de procesamiento una computadora y
diseñan sus propias estructuras para las plantas de proceso ...................................... 27
2.1.5. Empresas que desarrollan laboratorios virtuales ............................................. 27
2.2. Clasificación de los Sistemas Didácticos de Control de Procesos Obtenidos a Nivel
Científico por Instituciones ........................................................................................... 31

7
 2.2.1. Desarrollos de PLCs didácticos basados en micro-controladores con
desarrollos propios de software ................................................................................. 31
2.2.2. Desarrollos de PLCs didácticos basados en micro-controladores con software
comerciales ................................................................................................................ 31
2.2.3. Desarrollos de interfaces gráficas para control de procesos ............................ 35
Capítulo 3. Normatividad Aplicable a Interfaces Gráficas Humano-Máquina ............. 38
3.1. Interfaces Humano Computadora........................................................................... 38
3.1.1. Monitoreo de Sistemas de Control .................................................................. 38
3.2. Estándares y Normativas......................................................................................... 39
3.2.1. UNE-ES 9241 .................................................................................................. 40
3.2.2. Guía ergonómica de diseño de interfaz de supervisión “GEDIS” ................... 44
3.2.3. NUREG-0700 .................................................................................................. 51
3.2.4. Isa-S5.5 1985 ................................................................................................... 56
Capítulo 4. Software de GHMI ...................................................................................... 58
4.1. Entorno de Desarrollo ............................................................................................ 58
4.2. Consideraciones de Diseño .................................................................................... 58
4.3. Diagrama de Estados de la Interfaz Gráfica ........................................................... 58
4.4. Interfaz Gráfica Desarrollada ................................................................................. 60
4.1.1. Interfaz gráfica principal ................................................................................. 60
4.1.2. Modo simulación ............................................................................................ 66
4.1.3. Modo real ......................................................................................................... 68
4.1.4. Conexión con módulo externo ......................................................................... 69
4.1.5. Interfaz gráfica control PID ............................................................................. 69
4.1.6. Interfaz gráfica control difuso ......................................................................... 70
Figura 26. Representación gráfica de control difuso..................................................... 72
Capítulo 5. Aplicaciones ................................................................................................ 73
5.1. Diagrama a Bloques para Módulos Periféricos ..................................................... 73
5.2. Algoritmo para Módulos Periféricos ..................................................................... 73
5.3. Control de Velocidad ............................................................................................. 75
5.3.1. Circuito y Esquemático de Módulo para Control de Motor 12 VDC .............. 75
5.3.2. Caracterización de la Planta ............................................................................ 78

8
 5.4. Control de Nivel de Líquido .................................................................................. 83
5.4.1. Esquemático de módulo de control de nivel .................................................... 83
5.5. Control de Presión .................................................................................................. 85
5.5.1. Esquemático de módulo de control de presión ................................................ 85
Capítulo 6. Experimentación y Resultados .................................................................... 87
6.1. Control PID para Velocidad de un Motor DC........................................................ 87
6.1.1. Diseño del controlador..................................................................................... 87
6.1.2. Puesta en marcha del controlador en la interfaz .............................................. 90
6.2. Control Difuso para Velocidad .............................................................................. 91
6.2.1. Diseño del controlador difuso.......................................................................... 92
6.2.2. Puesta en marcha del control difuso en la interfaz .......................................... 94
6.3. Diseño y Puesta en Marcha de Control Difuso para Nivel .................................... 95
6.4. Diseño y Puesta en Marcha de Control Difuso para Presión ................................. 97
6.5. Discusión ................................................................................................................ 98
Capítulo 7. Conclusiones y Propuestas para Trabajos Futuros .................................... 100
7.1. Conclusiones ........................................................................................................ 100
7.2. Trabajo Futuro ...................................................................................................... 101
7.3. Productos .............................................................................................................. 101
Referencias...................................................................................................................... 102

9
 Índice de Figuras

Figura 1. Partes de los sistemas didácticos de control de procesos .................................. 13

Figura 2. PLC Siemens Simatic serie S7 [3]..................................................................... 14
Figura 3. Planta didáctica de control de procesos [8] ....................................................... 16
Figura 4. Auto-descripción del sistema [51] ..................................................................... 40
Figura 5. Ventana que explica tipo de error [56] .............................................................. 41
Figura 6. Semejanza entre procesos. (a) real. (b) virtual [51]........................................... 41
Figura 7. Aspecto coherente de la información. (a) Incorrecto. (b) Correcto [51] ........... 42
Figura 8. Diálogos con indicaciones claras. (a) Incorrecto. (b) Correcto [51] ................. 43
Figura 9. Instrucciones de información breves. (a) Información innecesaria. (b)
Información necesaria [51] ............................................................................................... 43
Figura 10. Polaridad de las imágenes. (a) Figura acromática sobre fondo de color. (b)
Figura a color sobre fondo acromático [51] ...................................................................... 44
Figura 11. Ejemplos de uso del color en función de grupos de información [54] ............ 48
Figura 12. Diagrama de estados del software de la interfaz. ............................................ 59
Figura 13. Módulo principal de la interfaz gráfica. .......................................................... 61
Figura 14. Barra de menús ................................................................................................ 62
Figura 15. Primera sección de barra de herramientas ....................................................... 63
Figura 16. Sección habilitada para modo simulación. ...................................................... 63
Figura 17. Segunda sección de barra de herramientas ...................................................... 63
Figura 18. Panel de configuración de parámetros. (a) Selección de proceso. (b)
Configuración control PID. (c) Configuración control Difuso ......................................... 65
Figura 19. Ejemplo de gráfico de tendencia RPM vs tiempo ........................................... 66
Figura 20. Ejemplo gráfico de respuesta en modo de simulación. ................................... 67
Figura 21. Ejemplo de ampliación de gráfico de respuesta en modo simulación ............. 67
Figura 22. Panel para configurar modo real...................................................................... 68
Figura 23. Ventana que muestra la configuración para conexión con el módulo externo 69
Figura 24. Panel para configuración de control PID......................................................... 70
Figura 25. Panel para configuración de control difuso ..................................................... 71
Figura 26. Representación gráfica de control difuso. ....................................................... 72
Figura 27. Diagrama a bloques de módulo periférico....................................................... 73
Figura 28. Diagrama de estados del algoritmo para micro-controlador ........................... 74
Figura 29. Motor 12 VDC empleado [62]. ....................................................................... 76
Figura 30. Filtro RC para el encoder. ............................................................................... 76
Figura 31. Manejo de potencia.......................................................................................... 77
Figura 32. Conversor USB y programador Pololu [63]. ................................................... 77
Figura 33. Circuito diseñado para control de velocidad. .................................................. 77
Figura 34. Módulo para control de velocidad de motor de 12VDC ................................. 78

10
Figura 35. Planta utilizada para control de velocidad. ...................................................... 78
Figura 36. Diagrama de la simulación en Simulink .......................................................... 82
Figura 37. Gráfica de modelo matemático contra datos reales obtenida en Simulink ...... 82
Figura 38. Datos en el panel de configuración de parámetros para ecuaciones de primer
orden en DEVCO .............................................................................................................. 82
Figura 39. Respuesta al escalón obtenida con DEVCO .................................................... 83
Figura 40. Sensor ultrasónico de distancia SRF04 ........................................................... 83
Figura 41. Circuito para conexión de sensor SRF04 ........................................................ 84
Figura 42. Moto-bomba empleada en la planta de control de nivel.................................. 84
Figura 43. Circuito completo para control de nivel .......................................................... 84
Figura 44. Sensor de presión MPX5700 [65]. .................................................................. 85
Figura 45. Conexión sensor de presión MPX5700 ........................................................... 85
Figura 46. Electro-válvula PVQ31 [66]. ........................................................................... 86
Figura 47. Circuito para manejo de electro-válvula.......................................................... 86
Figura 48. Circuito para control de presión ...................................................................... 86
Figura 49. Esquema general PID. ..................................................................................... 87
Figura 50. Reglas de sintonización para PID .................................................................... 88
Figura 51. Fórmulas de primer método de las reglas de Ziegler-Nichols ......................... 88
Figura 52. Respuesta de la planta real al escalón.............................................................. 88
Figura 53. Simulación de la planta en Simulink de Matlab. ............................................. 89
Figura 54. Gráfica simulada de respuesta al escalón del controlador. .............................. 89
Figura 55. Gráfica simulada de respuesta al escalón del controlador con constantes
afinadas. ............................................................................................................................ 90
Figura 56. Configuración de ganancias PID en DEVCO ................................................. 90
Figura 57. Respuesta al escalón del sistema real .............................................................. 91
Figura 58. Respuesta real a cambio de escalón................................................................. 91
Figura 59. Diagrama a bloques de control difuso ............................................................. 92
Figura 60. Conjuntos difusos empleados para control de velocidad. ............................... 93
Figura 61. Base de reglas. ................................................................................................. 93
Figura 62. Diagrama de control Difuso donde se muestra el operador de agregación. .... 94
Figura 63. Respuesta real a un escalón ............................................................................. 94
Figura 64. Respuesta real a un perfil. ............................................................................... 95
Figura 65. Base de reglas control de nivel ........................................................................ 96
Figura 66. Conjuntos Difusos para control de nivel ......................................................... 96
Figura 67. Respuesta real al escalón del sistema de control de nivel ............................... 96
Figura 68. Base de reglas control de presión .................................................................... 97
Figura 69. Conjuntos Difusos para control de presión ..................................................... 97
Figura 70. Respuesta real al escalón de control de presión .............................................. 98

11
 Índice de Tablas

Tabla 1. Empresas fabricantes del sistema completo........................................................ 24

Tabla 2. Empresas fabricantes de plantas de procesos didácticas .................................... 25
Tabla 3. Empresas que hacen su propio software pero utilizan autómatas comerciales ... 28
Tabla 4. Empresas cuyo sistema de control se basa en computadoras ............................. 29
Tabla 5. Empresa que diseñan laboratorios virtuales........................................................ 30
Tabla 6. Desarrollo hardware y software de un controlador de procesos industriales ..... 32
Tabla 7. PLCs didáctico con software comerciales .......................................................... 34
Tabla 8. Interfaces gráficas para control de procesos ....................................................... 36
Tabla 9. Asociaciones y características relacionadas de colores que se utilizan normalmente
en el diseño del panel [57] ................................................................................................ 53
Tabla 10. Funciones de control para el procesamiento de comandos [57] ....................... 55
Tabla 11. Funciones de control para ingresar información [57] ....................................... 55
Tabla 12. Usos del color propuestos por estándar ISA S5.5 [59]. .................................... 56
Tabla 13. Trama de datos enviada por el micro-controlador. ........................................... 74
Tabla 14. Trama de datos recibida por el micro-controlador............................................ 74
Tabla 15. Datos de caracterización de la planta. ............................................................... 79

12
Capítulo 1. Introducción

En este capítulo se hará una introducción a los sistemas didácticos de control de

procesos, dando a conocer sus partes y la importancia que representan para los estudiantes
en control y automatización. Se presentan los antecedentes de este tipo de sistemas a nivel
comercial y científico para posteriormente exponer la propuesta donde se centra el presente
trabajo de investigación, resaltando las necesidades de las interfaces humano-máquina a
nivel escolar. Finalmente, se dan a conocer los objetivos para realizar el trabajo.

1.1.Sistemas Didácticos de Control de Procesos

Los sistemas didácticos de control de procesos son plantas piloto diseñadas para
entrenar a estudiantes y profesionales en el campo del control y automatización. Éstos
sistemas se pueden trabajar como una planta real pero en una pequeña escala, adaptadas a
fines didácticos. Están compuestos por tres partes fundamentales: software, hardware y
planta didáctica; como se observa en la Figura 1.

Figura 1. Partes de los sistemas didácticos de control de procesos

 Módulo central de procesamiento (Hardware): Son dispositivos utilizados para el

control de procesos entendidos como PLC, PAC o controladores diseñados con
micro-controladores, los cuales reciben las señales del proceso a través de
transductores, las procesan en base al control diseñado y como resultado se obtiene
una señal para un actuador.

 Software de control y simulación (software): Es el lenguaje mediante el cual el

usuario se comunica con el sistema, donde puede configurar el lazo de control y
observar el funcionamiento del proceso para atender los fallos.

13
  Planta de pruebas (Mecánica): Son plantas industriales en pequeña escala, que
emulan procesos pero enfocados en la enseñananza.
De modo general los tres bloques comunican al usuario con la máquina, traduciendo de
un entorno gráfico y fácil de manejar a un entorno de manejo de potencia y conversiones
de datos físicos a digitales, necesarios en el cómputo de los controles y manejo de variables.
A continuación, se presentan una descripción más a fondo.

1.1.1. Módulo central de procesamiento

La mayoría de los sistemas didácticos utilizan como módulo central un controlador

lógico programable, PLC por sus siglas en inglés, dada su proximidad con la industria. El
PLC tuvo su inicio a finales de los años 60, donde la evolución en la industria se debió a
que en esa época utilizaban como algoritmo de control conjuntos de relés
electromagnéticos. Sin embargo resultaban deficientes por el elevado costo de
mantenimiento, el ruido que se producía al conmutar constantemente, además, era difícil
detectar problemas en el control y poseían poca flexibilidad de configuración. Cuando la
empresa tenía que realizar cambios en el proceso de automatización se tenía que desmontar
y realizar un circuito nuevo aumentando el costo y la cantidad de hora-hombre que se
ocupaban para estas tareas [1].
Bedford Associates propuso el primer PLC, que denominó como controlador
digital modular, MODICOM por sus siglas en inglés, el cual fue un pedido de un fabricante
de coches. El éxito fue inmediato y su evolución fue constante desde su invención,
marchando de la mano con los avances en la electrónica, los relés solo eran utilizados en
las etapas de salida y de entrada del dispositivo a modo de protección del núcleo del PLC.
Empezaron a hacerse pequeños y dotados cada vez más de funciones, vino la flexibilidad
de comunicarlos entre sí a través de buses de comunicación de manera alámbrica o
inalámbrica y con ellos los estándares de los protocolos de comunicación [2].

Figura 2. PLC Siemens Simatic serie S7 [3]

En la Figura 2, se muestran a manera de ejemplo, los PLCs diseñados por Siemens,

los cuales son confiables y de fácil manejo.

14
 Otro módulo central de procesamiento usado en sistemas de control son los
controladores automáticos programables, PAC por sus siglas en inglés, término acuñado
en el 2011 por la firma ARC. Este sistema en muchos casos es comprendido como un PLC
avanzado y en otros casos como una unión entre un PLC y una computadora. Proporcionan
una mayor flexibilidad de programación, mayor capacidad de memoria, mejor
interoperabilidad y más características pues son sistemas orientados hacia arquitecturas
complejas de automatización, integrando aplicaciones de software basadas en
computadoras, así como funciones de interfaz humano-máquina, HMI por sus siglas en
inglés y control avanzado de procesos [4].
Por otra parte, existen módulos centrales de procesamiento para sistemas didácticos
basados en micro-controladores, con la finalidad de reducir costos y para obtener una
autonomía completa del dispositivo. Estos sistemas se basan en la forma básica de un
autómata donde se tiene: una etapa de entrada, una etapa de salida, una etapa de
procesamiento de datos, una etapa de comunicación para la programación y un software
para programar el algoritmo de control [5].

1.1.2. Software de control y simulación

El software realiza la perfecta comunicación entre el usuario y el módulo central de

procesamiento. El lenguaje de programación para el caso de los PLCs, fue surgiendo como
ambientes gráficos D.O.S para programación en escalera e instrucciones. En la actualidad,
los fabricantes de PLCs han normalizado los lenguajes de programación bajo la norma
internacional IEC 61131-3, que considera cinco lenguajes: Diagrama de Bloque
Funcionales (FBD), Lista de Instrucciones (IL), Diagrama de Escalera (LD), Texto
Estructurado (ST) y Gráfica de Funciones Secuenciales (SFC) [6]. Por otra parte, los PAC
ofrecen una amplia gama de software para su control utilizando programación basada en
etiquetas, empleando protocolos estándar: Ethernet, OPC y SQL.
El software, además de permitir configurar la CPU de un dispositivo, permite
realizar simulaciones previas de la lógica implementada y monitorear los contactores de
entrada y salida, a esto se le ha unido la flexibilidad de monitorear las variables de proceso
a través de entornos gráficos. Los sistemas de adquisición de datos y supervisión de control,
SCADA por sus siglas en inglés, son realizados en computadoras y proporcionan
información de diversos procesos, permitiendo el control y visualización de las variables
en tiempo real para lograr una perfecta sincronización de varios procesos en el mismo
lugar.
Las interfaces humano máquina, HMI por sus siglas en inglés; son sistemas que
permiten la interacción entre una persona y una máquina, compuestos por paneles
indicadores y comandos que hacen posible la interconexión con el proceso [7]. En la
actualidad existen HMI robustas que permiten conexiones rápidas y de bajo costo con el
proceso físico.

15
1.1.3. Planta de pruebas

Tienen como enfoque facilitar el entendimiento en control y automatización,

apoyando la labor de enseñanza y aprendizaje. Son equipos estructurados que se asemejan
en cierta parte a procesos industriales ya sea en control de flujo, temperatura, velocidad,
etc., con el fin de que el estudiante no pierda el enfoque del área realizando montajes de
motores y circuitos y se centre en el análisis y en el control. La Figura 3, muestra un modelo
de material didáctico el cual está compuesto por una parte mecánica y otra electrónica.

Figura 3. Planta didáctica de control de procesos [8]

1.2. Importancia de los Sistemas Didácticos de Control de Procesos

Los sistemas didácticos emulan un entorno similar al laboral, donde el estudiante

aprende a enfrentar problemas de ingeniería, y de esta manera tiene la posibilidad de
proporcionar soluciones reales, teniendo la habilidad de enfrentarlos desde diferentes
puntos de vista. Por otra parte, estos sistemas didácticos facilitan una mejor preparación
para los estudiantes en el mundo laboral que cada día necesita más personal capacitado,
que aproveche al máximo las nuevas tecnologías y que pueda dar soluciones a problemas
en planta de manera inmediata sin necesidad de detener los procesos.

1.3. Antecedentes

Los procesos industriales han evolucionado a lo largo del tiempo, siendo una pieza
estratégica del desarrollo económico e industrial, es por esto que la ingeniería enfrenta
cambios radicales por estar involucrada directamente [9].

16
 Actualmente, cientos de personas reciben formación de ingeniería de procesos
obteniendo una amplia gama de cualificaciones en las disciplinas técnicas más disímiles,
implementando contenidos como: conocimiento de la estructura, montaje de componentes
y piezas de producción, al igual que la puesta en marcha y mantenimiento de plantas.
Siendo éste un factor que permite ubicar los sistemas de entrenamiento en mecatrónica en
el punto de mira de la formación profesional [10] y teniendo en cuenta que el interés de los
estudiantes en los cursos de ingeniería eléctrica y electrónica ha aumentado [11].
Atendiendo a este llamado, la enseñanza ha cambiado con el transcurso del tiempo,
pasando desde el método en que el docente impartía el conocimiento al alumno de manera
teórica, al conocimiento innovador donde el estudiante realimenta conceptos realizando
prácticas experimentales sobre sistemas reales, superando de este modo aspectos difíciles
de abordar de forma conceptual.
Los programas de simulación empleados desde hace un par de décadas, se han
convertido en un apoyo fundamental, que acerca a los alumnos a la comprensión de los
principios que rigen el aprendizaje, y los llevan a enfrentar situaciones casi reales. Por otra
parte, están los sistemas didácticos de control de procesos, que fortalecen la educación
tecnológica y científica, apoyando la labor de los educadores y la comprensión de los
estudiantes, quienes a través de la interacción con las variables físicas que proporcionan
estos entornos desarrollan habilidades y destrezas para la resolución de problemas en el
campo de la ingeniería [12] [13][14].
Para dar solución a esta necesidad existen dos ramas: comercial y científica. Ambas
bajo la misma filosofía de brindar al estudiante un entorno amigable y fácil de interactuar
con las variables físicas. Estos sistemas van desde las plataformas más sencillas y
artesanales dedicadas a un solo proceso, hasta las más robustas y tecnológicas que permiten
controlar más de un proceso.

1.3.1. Rama comercial

Son empresas que se dedican a la enseñanza de control y automatización ya sea a

nivel industrial como capacitadores de personal o a nivel educativo para las buenas
prácticas en la etapa de aprendizaje de automatismos. De acuerdo con su producto final
se clasificaron en cinco tipos:

a) Empresas que fabrican el módulo central de procesamiento, el software de

control y la planta.

b) Empresas que utilizan controladores comerciales, lo acondicionan a la

estructura que fabrican y usan el software del controlador.

17
 c) Empresas que utilizan controladores comerciales, pero mejoran el software
haciendo sus propios desarrollos.

d) Empresas que utilizan como módulo de procesamiento una computadora y

diseñan sus propias estructuras para las plantas de proceso.

e) Empresas que desarrollan laboratorios virtuales.

1.3.2. Rama científica

Con la finalidad de reducir costos, muchas instituciones construyen sus sistemas

didácticos basándose en las necesidades propias para el aprendizaje. De acuerdo
con la forma de desarrollo se clasifican en tres tipos:

a) Desarrollos de PLCs didácticos basados en micro-controladores y

desarrollos de software.

b) Desarrollos de PLCs didácticos basados en micro-controlador con software

comercial.

c) Desarrollos de laboratorios virtuales basados en plataformas como

Labview, matlab o simulink.

En el capítulo dos se abordarán en detalle el estado del arte de este tema, pues son
muchas las empresas y los trabajos científicos que han afrontado esta problemática que
aumenta con el pasar de los días y con las exigencias y necesidades de la industria.

1.4. Descripción del Problema

El control y la automatización de procesos se han desarrollado para resolver

problemas de ingeniería y optimizar los procesos de producción. Sin embargo, éste es un
reto que asumirá el estudiante, por este motivo, necesita realizar prácticas en sistemas que
se acerquen a la realidad para fortalecer los procesos teóricos vistos en clase.
Es difícil que el estudiante realice sus prácticas en instalaciones complejas
industriales, por esta razón, en la enseñanza del control automático se usan los sistemas
didácticos de control de procesos, en los cuales el estudiante puede practicar, comprender
mejor los conceptos y desarrollar habilidades y destrezas para solucionar problemas en los
procesos de control físicos. En estas prácticas de laboratorio es necesario tener un registro

18
y control sobre las variables de proceso; evidenciando la gran importancia de las interfaces
humano-máquina con las cuales se pueda interactuar con el sistema y hacer menos
compleja esta tarea.
Una interfaz humano-máquina cambia el lenguaje complejo que usan los sistemas
por entornos gráficos ofreciendo al usuario una manera ágil de usar los recursos que le
interesan, optimizando su función de análisis de información sin preocuparse del manejo
interno de la misma. Estas interfaces juegan un papel fundamental tanto en la industria
como en la academia, donde proporciona un apoyo didáctico, visual y proveen múltiples
herramientas para que se puedan visualizar las respuestas a distintos cambios, integrar
resultados y tomar decisiones frente a la configuración del lazo de control ya sea PID,
difuso o neuro-difuso [7].
Actualmente a nivel de investigación, se ha realizado gran cantidad de interfaces de
usuario utilizando software como Matlab, Labview, simulink, lo que representa un alto
costo para las instituciones y sujetándose a lo que el fabricante produce.
A nivel industrial, hay productos de interfaces de usuario para PLCs o para sistemas
didácticos de control de procesos, pero al igual que una licencia para Matlab, Labview o
Simulink representan un costo que muchas instituciones no pueden asumir.

1.5. Justificación

Teniendo en cuenta la importancia del uso de sistemas didácticos tanto en la

academia como en la industria para la introducción al área de control de procesos, se hace
necesario desarrollar sistemas más flexibles, que proporcionen herramientas para que los
estudiantes comprendan de una manera más fácil, el mundo de la automatización. En el
caso presentado se realizará el software de interfaz humano-máquina, para un sistema
didáctico de control de procesos con la cual el estudiante pueda interactuar para realizar
las modificaciones necesarias en las prácticas de laboratorio, a su vez, que sea lo
suficientemente robusto y funcional para que cumpla con las exigencias, y deberá ser
versátil para realizar mejoras e incluir diferentes procesos.
Con el creciente avance tecnológico que se ha visto en el país, se necesitan
proyectos que demuestren la confiabilidad en los productos desarrollados, que incentiven
a la industria y la academia a hacer uso de ellos, con esto se reducirían costos de
importación de equipos y mantenimiento, y se invertiría en mejoras y nuevos proyectos
para los desafíos que cada día impone la industria.

19
1.6. Objetivos

1.6.1. Objetivo General

Diseñar e implementar en software la interfaz gráfica humano-máquina (GHMI)

para la manipulación y configuración de parámetros de un sistema didáctico de control de
procesos.

1.6.2. Objetivos Específicos

 Recolectar información para definir el sistema mediante encuestas a profesores y

alumnos de diversas instituciones de educación superior.
 Diseñar los paneles de configuración de parámetros iniciales, de selección del
método de control, señal de arranque y visualizadores de variables.
 Diseñar y construir el módulo periférico para control de velocidad.
 Validar el desarrollo del software mediante aplicaciones en control de velocidad,
nivel y presión.

1.7. Hipótesis

Al contar con un entrenador electrónico para sistemas de control flexible los

estudiantes tendrán una herramienta cuya finalidad es la de apoyarlos de manera práctica,
para que alcancen las competencias necesarias en la elaboración de modelos que
interactúen directamente con variables físicas. El software de interfaz humano-máquina
para el sistema de control requiere de un diseño flexible que permita la reconfiguración del
sistema mediante variables y la visualización del comportamiento del proceso. Obteniendo
así, una herramienta versátil y funcional que no pretende sustituir al profesor ni quitarle
habilidades al estudiante, sino brindar un entorno fácil para desarrollar sus actividades.

1.8. Resumen de Contenido

En el capítulo 2 se presenta el estado del arte acerca de los sistemas didácticos de

control de procesos desarrollados hasta el momento, obteniendo una clasificación que se
presenta en diversas tablas donde se muestra lugar del desarrollo, características en
hardware y software, además, de las funcionalidades, donde se observa la necesidad de
crear interfaces humano-máquina más flexibles.

20
 El capítulo 3 trata los aspectos de los estándares y normas pertinentes para el
desarrollo de interfaces gráficas de usuario ergonómicas y flexibles con las cuales los
usuarios puedan alcanzar sus metas de manera eficiente.

En el capítulo 4 se presentan las fases de desarrollo del software de la interfaz

gráfica de usuario, así como la descripción detallada del mismo teniendo como guía de
diseño las pautas marcadas en el capítulo 3 de la presente tesis.

Posteriormente en el capítulo 5 se presentan las aplicaciones de control de

velocidad, nivel y presión con que fue puesta a prueba DEVCO. El caso de estudio
principal es el control de velocidad, por lo que se muestra el diseño y la construcción del
módulo periférico con las diferentes etapas: acondicionamiento de señal, manejo de
potencia y comunicación con una computadora mediante el protocolo de comunicación
USB, además de la abstracción de su modelo matemático aproximado.

El capítulo 6 corresponde a las pruebas que se realizaron en la interfaz tomando

como caso de estudio principal el control de velocidad de un motor DC de 12 voltios, al
cual se le implementó control PID y control difuso para observar el comportamiento del
motor con los dos controles por separado. Así, como los resultados del control difuso para
nivel y presión. Comprobando de esta forma la flexibilidad de DEVCO.

Finalmente en el capítulo 7 se presentan las conclusiones del trabajo presentado, así

como los trabajos futuros sobre la interfaz que se debería realizar tanto para ponerla a punto
como para programar en ella otros controles u optimizar los que tiene hasta el momento.

21
Capítulo 2. Sistemas Didácticos para Control de Procesos

En éste capítulo se presentan los antecedentes del tema que se está abordando,
dando a conocer en detalle los sistemas didácticos de control que hay actualmente, ya sea
en el mercado o en las instituciones de educación para facilitar el entendimiento en el área
de control y automatización.
Los sistemas didácticos de control de procesos son una herramienta fundamental
para preparar personal en el área de control y automatización [15], es por esta razón que
muchas empresas han optado enfoques de diseño y construcción de sistemas que faciliten
la enseñanza y la preparación en entornos simulados, han obtenido como resultado sistemas
robustos con objetivos bien definidos que con el paso del tiempo y atendiendo las
necesidades de la industria han mejorado, pero poseen la desventaja de tener un costo
elevado. A raíz de esto algunas instituciones de educación han preferido construir los
propios para reducir costos y convertirlos en una tecnología más accesible [16][17][18].

2.1. Clasificación de Empresas Fabricantes de Sistemas Didácticos de Control de

Procesos

Para la elaboración del proyecto se clasificaron las empresas en cinco tipos teniendo en
cuenta la forma como entregan su producto final:

 Empresas que fabrican el módulo central de procesamiento, el software de control

y la planta.

 Empresas que utilizan controladores comerciales, lo acondicionan a la estructura

que fabrican y usan el software del controlador.

 Empresas que utilizan controladores comerciales, pero mejoran el software

haciendo sus propios desarrollos.

 Empresas que utilizan como módulo de procesamiento una computadora y diseñan

sus propias estructuras para las plantas de proceso.

 Empresas que desarrollan laboratorios virtuales.

2.1.1. Empresas que fabrican el Sistema Didáctico de Control Completo

Dentro de la investigación realizada se encontró que estas empresas fabricantes del

sistema didáctico en su mayoria, son Europeas con sucursales en diferentes partes del
mundo. En la Tabla 1, se muestra en detalle las áreas de aplicación en las que trabajan

22
actualmente, así como los sistemas de control en hardware y en software con los cuales
ofrecen sus servicios para la capacitación de personal en entornos controlados.
El software se realiza teniendo en cuenta los protocolos y estándares industriales
para la programación de los autómatas, pero sin dejar de un lado los requerimientos
didácticos para que sean tomados como entrenadores. De este modo desarrollan tutores
virtuales gráficos y guías físicas que sirven de apoyo a los profesores o personal encargado
para las capacitaciones.

2.1.2. Empresas que utilizan controladores comerciales acondicionados a sus

propias estructura con el software del controlador

Estas empresas están distribuidas en diferentes partes del mundo. En sus trabajos
omiten la complejidad de desarrollo del sistema de control y utilizan sistemas comerciales
de marcas como Siemens, Omrom, Schneider electric, Allen Bradley, Mitsubishi, etc. Son
fabricantes de plantas para prácticas en procesos de control. El software que utilizan es el
mismo que les provee el fabricante del autómata muy similar al que se usa a nivel industrial.
En la Tabla 2, se muestra en detalle las empresas relacionadas con la clasificación las cuales
hacen presencia en las diferentes ramas de la ingeniería.

23
Tabla 1. Empresas fabricantes del sistema completo

EMPRESA LUGAR APLICACIÓN HARDWARE SOFTWARE CARACTERÍSTICAS

SOFTWARE
BOSCH-REXROTH Alemania *Hidráulica Indra logic L20, IndraWorksWinS Programación
[19] *Electro neumática IndraWorks HMI tudio Simulación
*Mecatrónica
*Sistemas de entrenamiento en
automatización

DISCOVER ARM Inglaterra *Consolas de control PC Consola Armsolft301/306 Control

FIELD [20] *Entrenador en plantas de PCT43 LV/910LV V1
proceso. Labview
*Nivel, presión, pH Matlab

EDIBON [21] España *Electrónica PLC-PI Versión Software CAI Control y

*Comunicaciones propia (Computer aided Simulación
*Electricidad instruction)
*Sistemas y automática
*Mecánica de fluidos
*Aerodinámica
*Termodinámica
*Control de procesos
*Tecnología de alimentos
SCHNEIDER Argentina *configuración, depuración y PLC Versión Propio del PLC Programación
ELECTRIC [22] diagnostico en automatismos propia Simulación
sencillos y de mediana Visualización
complejidad

24
Tabla 2. Empresas fabricantes de plantas de procesos didácticas

EMPRESA LUGAR APLICACIÓN HARDWARE SOFTWARE CARACTERÍSTICAS

SOFTWARE
ASTI [23] Romania *Hidráulica PLCs y HMI Siemens: Simulador Simulación
*Neumática S7-300, S7-200, didáctico Programación
*Análisis de vibraciones LOGO!, TP 117B, PROSIM, Step 7,
*Entrenador de motores y KTP600 Basic TIA portal
driver
*Líneas de ensamble

DELORENZO Italia *Ingeniería eléctrica Schneider electric: Twido suite Programación

[24] *Electrónica básica PLC Twido Simulación
*Electrónica de potencia
*Neumática
*Hidráulica
*Automatización
*Energías renovables
*Termo trónica

HITECH México *Mecánica PLC o PAC Propio del PLC o Programación

INGENIUM *Neumática PAC Simulación
[25] *Hidráulica Visualización
*Electrotécnica
*Análisis sensorial
*Técnica de PLC
*Técnica de robots

FEEDBACK Inglaterra *Sistema de tanques Mitsubishi De cada Programación

INSTRUMENT *Levitación magnética Allen Bradley proveedor de PLC Simulación
S [26] *Sistema de doble roto Siemens Matlab Visualización
*Control de servo Simulink
*Control de péndulo
*Celdas de trabajo con PLC

25
INNCOMEX México *Entrenador de PLC Mitsubishi No especifica
[27] *Laboratorio de PLC's Allen Bradley
Siemens
Omrom
SMC [28] México *Introducción a la Mitsubishi No especifica
automatización Allen Bradley
*Tecnología neumática Siemens
*Tecnología eléctrica Omrom
*Electricidad
*Estado sólido
*Controladores
programables
*Tecnología de sensores
TECNOEDU Argentina *Neumática Schneider electric Propios del Programación
[29] *Hidráulica Mitsubishi fabricante de PLC Simulación
*Mecánica Visualización
*PLC
*Robótica
WUEKRO [30] Alemania *Ingeniería de Siemens Propio del Programación
Automatizacion fabricante de PLC Simulación
*Electrónica de potencia Visualización
*Ingeniería eléctrica

26
2.1.3. Empresas que utilizan controladores comerciales con desarrollos propios de
software

Estas empresas combinan el software de los fabricantes de autómatas con

desarrollos propios, brindando mayor flexibilidad tanto de la planta didáctica como del
modo de aprendizaje. Como resultado obtienen tutores virtuales y software poco más
didácticos, o dispositivos que permiten la interconexión mecánica o electrónica con los
controladores de la planta.
La Tabla 3 muestra en detalle estas empresas, las cuales se sitúan en Europa y
distribuyen a nivel global atendiendo a las necesidades de la industria o académicas para
fortalecer los procesos de enseñanza en las diferentes ramas de la ingeniería.

2.1.4. Empresas que utilizan como módulo de procesamiento una computadora y

diseñan sus propias estructuras para las plantas de proceso

Estas empresas utilizan software comercial base como Labview que provee un
entorno gráfico para diseñar aplicaciones. Pero también hay otras que diseñan su propio
software para brindar al estudiante interfaces más dinámicas. Como se muestra en la Tabla
4, las plantas son contraladas desde la computadora utilizando circuitos de adquisición de
datos para comunicarse con las variables físicas.

2.1.5. Empresas que desarrollan laboratorios virtuales

Estas empresas nacen atendiendo a las necesidades como falta de recursos dado que
los laboratorios físicos son más costosos en cuanto a su dotación, mantenimiento y
capacitación del personal especializado, necesidades especiales y por que con esta
estrategia amplían la capacidad para que cada alumno disponga de una unidad para
practicar. Los laboratorios virtuales en cierta medida son una herramienta para que los
estudiantes desarrollen destrezas de operatividad, pero falta la interacción con variables
físicas las cuales proveen los sistemas didácticos de control de procesos. En la Tabla 5 se
mencionan algunas empresas que trabajan bajo el enfoque presentado. No se profundizó
en la búsqueda debido a que se sale del radio de trabajo del proyecto.

27
Tabla 3. Empresas que hacen su propio software pero utilizan autómatas comerciales

EMPRESA LUGAR APLICACIÓN HARDWARE SOFTWARE CARACTERÍSTICAS

SOFTWARE
ELECTTRONICA- Italia *Electrónica Siemens Desarrollos Programación
VENETA [31] *Telecomunicaciones propios Simulación
*Auto trónica Propios de PLC Visualización
*Automatizacion
*Energías renovables
*Control de procesos
industriales
*Mecánica de fluidos
*Termodinámica

FESTO [32] Alemania *Mecatrónica Cualquier PLC, Fluid Lab Programación

*Técnicas de manipulación mediante el Labview Simulación
*Automatizacion de procesos dispositivo C++ Visualización
*Sistemas de producción EASYPORT Visual basic
modular Easy veep
*Reactores Ciros
*Mezclas y filtrado CodeSys Soft-SPS

LUKAS NULLE [10] Alemania *Tecnología de SIEMENS Labsoft Programación

automatización UNITRAIN-L Simulación
*Robótica (Tarjeta de Visualización
*Procesos de automatización experimentación CPU Aprendizaje
industrial con funcionalidad
*Sistema mecatrónica PLC)
industrial
*CIM

28
Tabla 4. Empresas cuyo sistema de control se basa en computadoras

EMPRESA LUGAR APLICACIÓN HARDWARE SOFTWARE CARACTERÍSTICAS

SOFTWARE
ALFREDOROCA [33] España Prácticas en PC Software *Graficador
control diseñado *configuración señal de entrada
*Software de control sencillo.
EDUDEVICE [34] Argentina Módulo de PC Tipo industrial
instrumentación y
control de
procesos
GUNT HAMBURG Alemania *Ingeniería PC Labview *Programación
[35] mecánica *Simulación
*Mecatrónica *Visualización
*Ingeniería
térmica
*Mecánica de
fluidos
*Ingeniería de
procesos
TELETERNIK[36] México *Unidad de PC Labview *Visualización de parámetros
control de
procesos, flujo,
presión,
temperatura, Ph.

29
Tabla 5. Empresa que diseñan laboratorios virtuales

EMPRESA LUGAR APLICACIÓN HARDWARE SOFTWARE CARACTERÍSTICAS

SOFTWARE
IMEPI [37] México Control y automatización PC Aurora SCADA HMI Simulación
AURORA LE Visualización

SIEMENS [38] Alemania Control y automatización PC SIMIT SCE Permite crear un

laboratorio virtual,
ensayar programas,
reproducir complejas
secuencias de procesos.

30
2.2. Clasificación de los Sistemas Didácticos de Control de Procesos Obtenidos a
Nivel Científico por Instituciones

Con la premisa de reducir costos y no depender tecnológicamente de las empresas

fabricantes de sistemas didácticos, muchas instituciones han desarrollado sus propios
sistemas atendiendo a las necesidades de sus alumnos en automatización. Algunos
desarrollos parten desde el diseño del controlador y otros se basan en controladores
comerciales para sus plantas de aprendizaje, la búsqueda solo se realizó en el mercado
potencial. Los desarrollos a nivel científico se clasifican en:

 Desarrollos de PLCs didácticos basados en micro-controladores y desarrollos de

software.

 Desarrollos de PLCs didácticos basados en micro-controlador con software

comercial.

 Desarrollos de laboratorios virtuales basados en plataformas como Labview, matlab

o simulink.

2.2.1. Desarrollos de PLCs didácticos basados en micro-controladores con

desarrollos propios de software

En la búsqueda realizada, se encontraron pocas instituciones que fabrican tanto el

software como el hardware para sistemas de control de procesos. En la Tabla 6, se
presentan los proyectos donde la principal razón fue reducir costos debido a que cada día
los controladores son más robustos pero su costo se eleva, haciéndolos poco prácticos o
accesibles para los profesionales que los utilizan en procesos más simples.

2.2.2. Desarrollos de PLCs didácticos basados en micro-controladores con software

comerciales

Estos desarrollos los han tomado las instituciones analizando que las tecnologías
para automatización cada vez son más costosas y no son accesibles para las micro y
pequeñas empresas. Además los controladores se tienen que importar dado que a nivel
industrial son de vital importancia para optimizar la producción. Para facilitar la
elaboración del sistema, desarrollan el software del dispositivo en plataformas de
programación que proveen una interfaz prediseñada gráfica. En la tabla 7, se presentan en
detalle estos desarrollos.

31
Tabla 6. Desarrollo hardware y software de un controlador de procesos industriales

LUGAR PAÍS TÍTULO DE HARDWARE SOFTWARE CARACTERÍSTICAS DEL

PROYECTO SOFTWARE

UNIVERSIDAD Brasil Controlador Lógico PIC 18F4550 Lenguaje C Equivalente digital a la lógica
DE BELO programable utilizando del ladder
HORIZONTE [39] PIC 18F4550

UNIVERSIDAD Colombia Implementación de un PIC 16F877 Visual Studio Programación por bloque como
MINUTO DE PLC didáctico para 2010 lo hacen los PLC
DIOS [40] prácticas de laboratorio

ESCUELA Ecuador Diseño y construcción PIC18F4620 Visual Basic Programación en diagrama de

POLITÉCNICA de un PLC modular a bloques.
DEL EJERCITO base de micro Simulación de entradas y
[41] controladores salidas mediante indicadores
UNIVERSIDAD El salvador Diseño y construcción PIC 16F877 Visual Basic Sistema módular grafico
DE EL de un (PLC) Control versión 6.0 controlado por eventos del
SALVADOR [5] Lógico Programable teclado:
basado en la tecnología *contador
del micro controlador ascendente/descendente
*conversión de analógico a
digital
*Lógica secuencial entre las
salidas
*Lógica convencional entre las
entradas y las salidas
INSTITUTO México Low cost multi-channel COP8CDR9LVA8 C++ Builder 5.0 *Comunicación USB
POLITÉCNICO data acquisition system *Prueba en control de
NACIONAL [17] with graphical HMI temperatura
*Diseño de tarjeta de
adquisición de datos con MCU.
*Grabar señales con intervalos
de tiempo.

32
 *Adquisición de seis canales.

INSTITUTO México Multipurpose interface COP8CDR9LVA8 C++ Builder 5.0 *Comunicación USB
POLITÉCNICO card for data *Prueba en control de
NACIONAL [18] acquisition and control temperatura
with low technological *Diseño de tarjeta de
hardware costs adquisición de datos
*Algoritmos fáciles de
modificar

INSTITUTO México Diseño y Construccion COP8CDR9LVA8 C++ Builder 5.0 *Ambiente gráfico de fácil uso.
POLITÉCNICO de un Sistema Basico *Área de graficado amplia
NACIONAL [16] de Interaccion y Accion *Comunicación USB
con Procesos Reales *Prueba en control de
Reconfigurable y de temperatura
Bajo costo HMI-CIC *Diseño de tarjeta de
adquisición de datos
*Fácil de modificar

33
Tabla 7. PLCs didáctico con software comerciales

LUGAR PAÍS TÍTULO DE HARDWARE SOFTWARE CARACTERÍSTICAS

PROYECTO DEL SOFTWARE

CENTRO DE México Propuesta de desarrollo AVR No especifica No especifica

ESTUDIOS de una interface de AT90S8515
SUPERIORES control tipo PLC
NAVALES [2] mediante micro
controlador AVR.
UNIVERSIDAD DE Ecuador Diseño de un PLC con PIC 16F873,
PINAR DEL RIO Cuba micro controlador PIC Solo diseño
UNIVERSIDAD 16F873 virtual
TECNICA DE
COTOPAXI [1]
UNIVERSIDAD Colombia Plataforma Plataforma Sistema Operativo Linux Programación lógica
NACIONAL [42] hardware/software Stamps con gráfica, grafcet
abierta para aplicaciones procesador
en procesos de i.MX233 de
automatización Freescale

34
2.2.3. Desarrollos de interfaces gráficas para control de procesos

Las instituciones han desarrollado interfaces gráficas y laboratorios virtuales tanto

para apoyar a sus alumnos en la comprensión de los fenómenos, como para solucionar
problemas a necesidades que posee. Laboratorios virtuales brindan la posibilidad a más
estudiantes que tengan acceso a las prácticas en control de procesos, pero el problema
persiste dado que los alumnos necesitan interactuar con las variables físicas para desarrollar
destrezas que son útiles en campo. Se encontró que muchos de estos laboratorios virtuales
e interfaces están basados en software predefinidos como Labview, por la facilidad que
ofrece su entorno grafico donde el estudiante tiene un medio interactivo y visual para
comprender los fenómenos de los sistemas de control., en la Tabla 8 se presentan en detalle
estos desarrollos.

35
Tabla 8. Interfaces gráficas para control de procesos

LUGAR PAÍS TÍTULO DE HARDWARE SOFTWARE CARACTERÍSTICAS

PROYECTO DEL SOFTWARE

UNIVERSIDAD Portugal Creación de una interfaz Computadora Labview Simulación de procesos

TECNICA DE gráfica virtual aplicada a un de control,
LISBOA [43] sistema de control de programación por
procesos diagrama de bloques
UNIVERSIDAD DE Italia Hardware y software para el Computadora Labview, C++ Medición de variables a
CALABRIA [44] diseño de laboratorio virtual través de dispositivos
para la educación en la remotos de una planta
instrumentación y medición didáctica de procesos

UNIVERSIDAD Venezuela Web-LABAI: Laboratorio Computadora JAVA Control a distancia de

POLITECNICA Remoto de Automatización procesos a través de
ANTONIO JOSE DE Industrial dispositivos remotos
SUCRE [45]
ESCUELA Ecuador Diseño y Simulación de la Computadora RSView Studio Monitoreo, simulación
POLITÉCNICA Lógica de Control y de la y PLC de planta,
DEL Interfaz HMI de un ControlLogix Ensambe de nuevo
EJÉRCITO [46] Prototipo de Sistema de proyecto, control,
Transportación para visualización gráfica de
Ensamblaje en una planta variables
Automotriz
INSTITUTO México Aplicación de un HMI en un Computadora Genesis 32, Vizapp Monitoreo
POLITÉCNICO sistema de control de flujo y Mod30ML
NACIONAL [47] de agua

UNIVERSIDAD DE Colombia Implementación de una Computadora LabVIEW Control y monitoreo (

LA SALLE [48] interfaz hmi para la y PLC Simatic Gráficos mímicos y de
operación del modulo tendencia)
control de procesos del
laboratorio de robótica

36
POLYTECHNIC OF Italia SCADA/HMI Systems in Computadora LabVIEW y RSLogix Monitoreo y control (
BARI [49] Advanced Educational y PLC gráficos mímicos, de
Courses Rockwell tendencia y numéricos)

INSTITUTO Colombia Design and implementation Computadora Visual Studio 2010 Control y
TECNOLÓGICO of an automation didactic y PLC Simatic procesamiento.
METROPOLITANO module focused to machine
[50] vision and programmable
logic control

37
Capítulo 3. Normatividad Aplicable a Interfaces Gráficas Humano-
Máquina

En éste capítulo se presentan los estándares y normas pertinentes para el desarrollo de

interfaces gráficas de usuario ergonómicas y flexibles con las cuales los usuarios puedan alcanzar
sus metas de manera eficiente.

3.1. Interfaces Humano Computadora

La interacción entre los humanos y las computadoras, (HCI) Human-Computer Interaction,

es un área de investigación multidisciplinaria que involucra disciplinas relacionadas con la ciencia
de la computación como: procesamiento de imágenes, visión computarizada, lenguajes de
programación y otras similares, así como disciplinas relacionadas con las ciencias humanas como:
ergonomía, factores humanos, psicología cognitiva, y otras similares [51].

En los inicios los diseñadores y desarrolladores, se preocupaban poco por hacer que el
hardware y el software se hicieran utilizables o amigables al usuario pero esto vino cambiando de
la mano con la evolución tanto de la informática como de los procesos de control, lo que dio origen
al concepto de usabilidad. La organización internacional de estandarización ISO, más
específicamente en la norma ISO 9241-11: Guidance on Usability (1998), define la usabilidad
como el conjunto de criterios como eficiencia, seguridad y utilidad, con los cuales un usuario puede
alcanzar los objetivos de una manera eficiente [50].

3.1.1. Monitoreo de Sistemas de Control

La óptima comunicación entre el usuario y la máquina a través de una interfaz es la clave

en toda buena automatización de procesos industriales en cualquier nivel, ya que marca la
diferencia en la efectividad con la cual se alcanzan los resultados. Una HMI debe contener
componentes gráficos, numéricos, así como terminología estandarizada y clara para hacer mucho
más fácil y cómoda la acción frente a un problema en el proceso controlado. Otro aspecto
importante son las variables de proceso, variable de referencia y variable de control, ya que deben
ser lo suficientemente claras para el usuario; y se debe mantener un registro histórico, para estudiar
el comportamiento y poder realizar las correcciones respectivas [50][51].

38
 Las pantallas de visualización de datos (PVD) pueden ser alfanuméricas o gráficas, que
despliegan información independientemente de la representación visual. Debido a las tareas de
alto nivel de visualización en pantallas para consultar datos y diálogos presentan a menudo
problemas relacionados con fatiga visual y mental en los usuarios, ya que la vista es el sentido más
explotado al estar frente a una PVD. Además de la fatiga mental, donde el factor determinante lo
constituye el inadecuado diseño de los programas informáticos utilizados por el usuario para la
realización de su tarea.

Los objetivos principales de una buena HMI son [54]:

 Disminuir la tasa de errores de los operarios gracias a unas presentaciones claras e

intuitivas de las fases de control (optimizar la efectividad del usuario).
 Incrementar al máximo la productividad.
 Mejorar la calidad y reducir los costos operacionales, de desarrollo y de mantenimiento.
 Reducir los tiempos de aprendizaje del proceso en los nuevos operadores.
 Reducir los costos de rediseño al estandarizar procedimientos.

Muchos de los problemas de los que adolecen este tipo de sistemas se deben al gran volumen
de información a mostrar, lo cual nos lleva al campo de la Visualización de Información [55].
Algunos de los desafíos planteados son:

 Cantidad de elementos a mostrar. El tamaño de las plantillas puede ser considerablemente

grande en relación al espacio disponible en los monitores.
 Cantidad de variables asociadas a cada elemento que necesitan ser visualizadas.
 Diversidad de instrumentos/elementos representados en las visualizaciones.
 Falta de estándares homogéneos en la manera de mostrar la información. Convivencia de
información de distinta naturaleza en una misma visualización. Lo que determina la
visualización de elementos codificados según sus propios estándares, los cuales pueden
llegar a ser confusos o directamente contradictorios.
 Restricciones en cuanto a la ubicación relativa de los elementos de la plantilla.
Conveniencia de respetar la disposición física de los elementos.
 Falta de consistencia entre las distintas visualizaciones.

3.2. Estándares y Normativas

Existen estándares que regulan de forma específica el diseño de interfaces gráficas, con el
fin de atacar los problemas que se mencionan en el apartado anterior, dentro de sus prioridades se
encuentra lo referente a diseños de ventanas, controles, visualizadores, sistemas de alarma y
formas de evaluación que tiene como criterio: consistencia, visibilidad, perceptibilidad,

39
informatividad, interactividad y tiempos de respuesta. Cada uno de estos temas se presenta a
continuación en los estándares UNE-ES 9241, NUREG-0700, ISA S5.5 y la guía de evaluación
GEDIS.

3.2.1. UNE-ES 9241

En el trabajo que tiene por título “Guía metodológica para el diseño de interfaces
de usuario para control y supervisión de procesos industriales” [51], se destacan los ocho
aspectos más importantes de la norma UNE-ES 9241, del Instituto Nacional de Seguridad
e Higiene en el trabajo de España la cual basa su contenido en el estándar ISO 9241, los
cuales se citan a continuación:

I. Capacidad de adecuación a la tarea

Los diálogos que se presentan en una interfaz de usuario deben proporcionar

las herramientas de interactividad y deben presentar y exigir la información
necesaria relacionada con el contexto de la tarea para lograr terminarla con eficacia
y eficiencia. A demás, debe ser auto-descriptivo y presentar explicaciones oportunas
y claras, dos aplicaciones típicas son:

 El diálogo debe advertir al usuario sobre los resultados a que pueden

conducir sus acciones en el caso de que las consecuencias sean importantes.
 El usuario debe ser asistido mediante una retroacción o explicación
suministrada por el sistema, que le ayuden a conseguir una comprensión
general y le puedan servir de entrenamiento suplementario.

Figura 4. Auto-descripción del sistema [51]

II. Controlabilidad

El sistema debe facilitar al usuario la ejecución de operaciones como

anulación, es decir, deshacer lo efectuado en el último paso, de esta manera puede
interactuar con la tarea más fácilmente.

40
 III. Conformidad con las expectativas del usuario

El sistema de diálogos debe contener los siguientes aspectos:

 La terminología debe ser expresada en el contexto del trabajador.
 Los diálogos usados para tareas similares deben ser también
similares.
 En la introducción de datos se debe dar una señal de retroacción
inmediata cuando así lo espera el usuario. Es decir, mover el cursor
a la posición de la próxima entrada de datos automáticamente.
 El sistema debe satisfacer siempre las expectativas del usuario
relativas al tiempo de respuesta.

IV. Tolerancia a los errores

El sistema debe proporcionar mensajes claros de error, informar la causa y

brindar sugerencias para corregirlos.

Figura 5. Ventana que explica tipo de error [56]

El mensaje de error debe ser presentado de manera comprensible, objetiva

y constructiva.

V. Facilidad de aprendizaje

Tiene que ver con la similitud entre el sistema virtual y el sistema real,
mientras la interfaz asemeje el sistema virtual de la manera más adecuada y correcta
con el sistema real, más fácil será para el usuario aprender a utilizarlo.

(a) (b)
Figura 6. Semejanza entre procesos. (a) real. (b) virtual [51]

41
 VI. Presentación de la información

La información se debe presentar de manera clara, definida, exacta,

comprensible e interpretable. Para darle al usuario una forma visual satisfactoria
para realizar su tarea.

VII. Usabilidad

Se define como el conjunto de criterios como eficiencia, eficacia y

satisfacción, con los cuales un usuario puede alcanzar los objetivos de su tarea. Esta
propiedad permite reconocer si una interfaz es fácil de utilizar, cómoda y amable
para todos los usuarios, sin importar el nivel de experiencia que tengan con el
sistema.
A continuación se presentan los principios que se deben seguir, comparando
la visualización de información en las ventanas:

 Tener un aspecto coherente

Como se observa en la Figura 7, el diálogo debe agilizar la respuesta

del usuario, la imagen de la derecha es la forma correcta, ya que
estamos acostumbrados a leer de arriba abajo y de derecha a
izquierda.

(a) (b)
Figura 7. Aspecto coherente de la información. (a) Incorrecto. (b) Correcto [51]

 Dar indicaciones de claridad

La información debe ser clara como se presenta en la Figura 8

derecha, ya que esta le permite al usuario realizar una acción, en
cambio en la Figura 8 en la imagen izquierda, no le da una acción
clara que pueda realizar el usuario.

42
 (a) (b)

Figura 8. Diálogos con indicaciones claras. (a) Incorrecto. (b) Correcto [51]

 Ser concisa

Evitar explicaciones innecesarias que puedan confundir al usuario.

(a) (b)
Figura 9. Instrucciones de información breves. (a) Información
innecesaria. (b) Información necesaria [51]

 Aportar detectabilidad

Las imágenes en los diálogos hacen que estos sean más atrayentes
ya que ayudan a entender el tipo de problema que se presenta, como se
observa en la Figura 9, las franjas amarillas y negras de la barra dan claridad
visual al usuario con respecto al problema.

VIII. Requerimientos para pantallas en color

Los colores en una interfaz gráfica no representan pura estética, ya que

los colores tanto del fondo como de la imagen influyen de manera
significativa en la percepción visual e interpretación de la información que
recibe. La apariencia del color depende de factores como: la pantalla
utilizada, las imágenes, el nivel de iluminación de la sala y del propio
usuario por la capacidad para distinguir el color. A continuación se
presentan algunas recomendaciones para el uso del color:

 Se recomienda para optimizar la discriminación e identificación de

los colores, utilizar uno de estos dos sistemas de representación:
figuras en color sobre fondo acromático o figuras acromáticas sobre
fondo en color. Los fondos acromáticos, como el gris medio u

43
 oscuro, maximizan la visibilidad de las representaciones en color
como se observa en la Figura 10.

(a) (b)
Figura 10. Polaridad de las imágenes. (a) Figura acromática sobre fondo
de color. (b) Figura a color sobre fondo acromático [51]

 Los colores extremos del espectro cromático (rojo y azul) no deben

representarse en pantalla al mismo tiempo, porque inducen un
excesivo esfuerzo de acomodación visual que es la capacidad que
tiene el ojo para enfocar y ver nítido a diferentes distancias, o ciertos
efectos de profundidad.
 El número de colores presentados simultáneamente en una pantalla
se deben reducir al mínimo necesario, y deben estar fundamentados
en los requerimientos de la tarea.
 No se deben utilizar más de 6 colores distintos acromáticos si el
significado de los colores debe ser recordado.
 Cuando sean necesarios más de 6 colores distintivos, y el significado
deba ser recordado, se deben proporcionar referencias, con el
significado de cada color, que sea fácilmente comprensible.
 En imágenes compuestas por trazos finos, evite las combinaciones
de colores difíciles de percibir, tales como amarillo-blanco, rojo-
naranja, azul-púrpura.

3.2.2. Guía ergonómica de diseño de interfaz de supervisión “GEDIS”

Esta guía se detalla muy bien en el trabajo titulado “Aplicación de la guía GEDIS
a los sistemas SCADA del NAP (Network Access Point) de Canarias” [54]. A continuación
se citan aspectos relevantes de este trabajo referente a la evaluación de HMI’s.

La guía GEDIS ofrece un método de diseño especializado en los distintos tipos de

pantallas de los sistemas de control supervisor industrial, se divide en dos partes, en la
primera se encuentran un conjunto de indicadores de los cuales se eligieron los que marcan
las pautas para el diseño de interfaces multimedia, estos son: distribución de pantalla,

44
navegación, uso del color, información textual, estatus de los equipos y eventos de proceso,
información y valores de proceso, gráficos de tendencias y tablas, comandos e ingreso de
datos y alarmas. Y la segunda parte muestra cómo obtener las medidas cuantitativas de la
evaluación de los indicadores, para que el diseñador o el usuario puedan analizar las
posibles mejoras, pero para los alcances del proyecto solo se trabajará con la primera parte
concerniente a los indicadoresz [54].

I. Distribución de pantalla

Esta distribución se especifica llevando a cabo las siguientes directrices:

 Según el diagrama de Gutenberg, el movimiento del ojo va de arriba

a abajo y de izquierda a derecha, describiendo el movimiento de una
“Z”.
 De este modo la información más importante debe ir en la parte de
arriba.
 Otro lugar de alta visibilidad es el centro de la pantalla.
 La información miscelánea debe ir abajo a la izquierda.
 Las funciones e informaciones críticas deben estar en un lugar fijo
en la pantalla.
 Los gráficos se deben ubicar a la izquierda del campo visual.
 Se debe establecer una estructura de rejilla regular.
 La densidad de los gráficos, no debe sobrepasar el 50%, para que no
se vean muy aglutinados.
 La carga de elementos debe estar balanceada en toda la pantalla.
 El nivel de información efectiva, se debe considerar primero las
distribuciones simples sobre las complejas.

II. Navegación

El resultado que se debe obtener con la aplicación de este paso es definir

formalmente las formas de navegación, entendidas como iconos, menús, botones,
etc., además de la ubicación de las funciones, el tamaño de las barras, los botones,
los menús, etc.

Con el fin que la navegación sea fácil para el usuario se puede utilizar
cualquier de los siguientes métodos o también la combinación entre ellos:

 Menús y submenús
 Barra de botones
 Barras de iconos gráficos

45
  Link con hipertexto
 Link con gráficos de proceso
 Teclas de función
 Cajas combo o listas desplegables

Para establecer la forma de navegación en la pantalla se deben seguir las

siguientes directrices:

 La navegación debe ser clara y no debe representar un obstáculo al

operador en situaciones de emergencia.
 Los iconos deben ir acompañados de una ayuda textual.
 Los menús, barra de botones, de iconos, botones de atrás, adelante,
inicio, cierre, etc. Se recomiendan estar ubicados en zonas
predefinidas de la pantalla.
 Los menús deben agrupase en base a la similitud funcional de sus
elementos.
 Los menús se deben mostrar en base a la importancia de la función
o a la frecuencia de uso.
 Los textos que describen las funciones deben ser cortos y concisos.
 Para favorecer la claridad se pueden usar separadores entre
diferentes grupos de opciones del menú.

III. Uso del color

El color es un factor importante dentro del diseño de interfaces hombre-

máquina, ya que la calidad del producto final depende del buen uso de los colores,
se deben definir estándares de color para:

 Representar el estado de los equipos de la planta como: marcha,

paro, falla, automático, manual, etc.
 Color de los materiales o fluidos del proceso como: agua, aire, gases,
etc., y valores de proceso como temperatura, presión, etc.
 Identificar alarmas tales como: críticas, advertencias, etc.
 Fondos de las diferentes pantallas ya sea la general, la de detalles,
etc.

Para las especificaciones de color se deben tener en cuenta las siguientes

especificaciones con el fin de que el operario no presente confusiones:

 El número de colores debe estar limitado tanto para principiantes

como para expertos, de modo que el número máximo para los
principiantes es de cuatro y de siete para los expertos.

46
  Debe maximizarse el contraste entre colores cuando sea necesario
mezclarlos
 Existen combinaciones de color que no deben usarse tales como:
Rojo-azul, rojo-verde, azul-amarillo, amarillo-blanco, verde-azul.
 Para minimizar aún más el riesgo de confusiones en operarios que
no puedan distinguir muy bien entre colores, estos deben ir
acompañados de texto, tamaño del elemento, forma, etc.
 El color blanco es preferible usarlo para información periférica.
 El objeto que lleva el color debe ser de buen tamaño para que el color
sea visible y se pueda distinguir.
 Evitar el uso de intermitencias de color.
 En el caso que sean necesarias las intermitencias, se debe
proporcionar al operador una forma fácil y rápida de detenerla una
vez se detecte el evento.

Para la selección del color de fondo de pantalla se presentan a continuación

unas directrices que se deben seguir para obtener un resultado satisfactorio:

 Usar colores como gris, arena, azul. Ya que son colores neutros.
 Evitar los colores blanco o negro, ya que dan mucho resplandor.
 Los colores que se usen de fondo deben contrastar con los demás
elementos de la pantalla.
 No utilizar colores fuertes en las zonas grandes de la pantalla.

47
Figura 11. Ejemplos de uso del color en función de grupos de información [54]

48
IV. Información textual

La información presentada en texto es la más utilizada por el operador, de

aquí la importancia de regularizarla para que proporcione una ayuda útil y eficaz al
momento de consultarla, algunas recomendaciones se presentan a continuación:

 En una interfaz no utilizar más de tres fuentes ni más de tres tamaños de la

misma fuente.
 El tamaño de la fuente debe permitir al operador leer a distancia. Una fuente
menor a 8 es difícil de leer.
 Procurar no mezclar letras mayúsculas con minúsculas en el texto.
 Evitar utilizar énfasis en el texto como: subrayado, itálico, sombreado.
 El color del texto debe respetar el código de colores del que se habló en el
apartado anterior en uso del color.
 El color en el texto debe ser homogéneo en toda la palabra y no en ciertos
caracteres.
 El texto se debe alinear a la pantalla teniendo en cuenta que las etiquetas
deben ir a la izquierda y los números a la derecha.
 El punto decimal siempre debe ir alineado.
 Los alineamientos verticales se deben reducir al máximo.
 Evitar aglutinamientos del texto.
 El texto que muestra información crítica, se debe espaciar suficientemente.

V. Estatus de los equipos y eventos de proceso

En esta etapa se debe recurrir a los estándares nacionales, internacionales,

referentes a símbolos e iconos que representan los diversos equipos de la planta
como: ventiladores, bombas, motores, válvulas, solenoides, etc., para que la
simbología sea homogénea y fácil de identificar por el operador [54].

VI. Información y valores de procesos

La representación de los datos analógicos de la planta se puede realizar por

dos formas ya sea a través de gráficos o mímicos de proceso, o por tablas y gráficos
de tendencias. El principal propósito de mostrar estos datos, es el de mantener al
operador enterado de lo que sucede en el proceso, lo que significa que se debe
mostrar el valor mínimo que se obtenga de una medida y además mostrarlos de una
manera coherente al proceso, existen diferentes datos como:

 Relativos a la seguridad de la planta: deben ubicarse en un lugar con mayor

visibilidad como en la parte superior o central de la pantalla.
 Alarmas de proceso que causan paros de producción: se deben ubicar cerca
del equipo referente.

49
  Alarmas de proceso que NO causan paros en producción.
 Alarmas de dispositivo.
 Estadísticos de área y/o estadísticos de equipos individuales: estos pueden
ubicarse en lugares de menor visibilidad, como lo sería en la parte inferior
de la pantalla.

VII. Gráficos de tendencias y tablas

Son un método de agrupación de datos informativos al usuario para crear

esquemas con los que pueda interactuar más fácilmente, algunas directrices que se
deben seguir referentes a gráficos se muestran a continuación:

 No se deben poner más de 9 variables en una sola gráfica.

 Los diferentes datos de una gráfica se deben mostrar con diferentes colores
y tipos de líneas.
 Los rangos del gráfico deben ser adecuados para la operación donde se
pueda mostrar tanto el valor mínimo como el máximo de la variable.
 Se deben utilizar rejillas tenues para ayudar a guíar al operador.
 Etiquetar los ejes y puntos representados.
 Permitir al operador interactuar con la gráfica, ya sea quitando o poniendo
variables de tendencia o cambiando el tamaño de la ventana.

Las tendencias permiten mostrar de forma cómoda la evolución de una o

varias variables del proceso ya sea en tiempo real o consultar el registro del histórico
para analizar el comportamiento del sistema.

Referente a las tablas se recomienda:

 Titular la tabla.
 Separar las celdas con rejilla de preferencia tenue.
 Las filas y las columnas deben estar ordenas ya sea por importancia,
frecuencia de uso, función, tiempo, tipo o alfabéticamente.
 Distinguir la tabla con un color diferente al fondo de la pantalla.

VIII. Comandos e ingreso de datos

Esta fase trata la forma como el usuario interacciona con el sistema

ingresando datos y/o comandos para que este se comporte de acuerdo a sus
objetivos. Los comandos deben permitir la facilidad de operación así como su
visualización, se clasifican en:

 Comandos de arranque y paro.

 Confirmación de alarmas.

50
  Selección de una sola opción entre varias.
 Selección de varias opciones al mismo tiempo.
 Selección simple ( aceptar o no una acción).

Los comandos deben ser claros para que el operador los pueda distinguir
rápidamente y no deben estar cerca los comandos de uso frecuente con los que
activan una acción crítica.

IX. Alarmas

Son una parte esencial en los sistemas, ya que alertan al operario de

situaciones anómalas, que requieren su intervención rápida y efectiva, se clasifican
en:

 Críticas: amenazan la seguridad de la planta y pueden indicar detención.

 Advertencias: puede desencadenar una alarma crítica si el evento que se
originó empeora y no es consultado a tiempo.
 Mensaje: eventos que se deben transmitir al operario pero no representan
amenazas a la seguridad de la planta y/o el proceso.

Los mensajes y las alarmas se deben apegar a los estándares de color,

tamaño, espaciamiento y alineamiento para que represente homogeneidad, además
se deben ubicar en lugares en la pantalla que tengan mayor prioridad como lo es la
parte superior para que el usuario pueda acceder más rápidamente.

Otro aspecto de mayor relevancia, es que las alarmas vayan acompañadas de

iconos y sonidos, teniendo en cuenta que debe asignarse sonidos agudos y de alta
frecuencia a alarmas de mayor prioridad.

3.2.3. NUREG-0700

El estándar NUREG 0700 fue desarrollado por la Comisión de Regulación Nuclear

de los EE.UU. para revisar el diseño de las interfaces persona-sistema (Human System
Interfaces, HSI) desde el punto de vista de factores humanos [57], a continuación se citan
los aspectos mas relevantes.

Los criterios de factores humanos de ingeniería (HFE) que propone el estándar, se

organizan en cuatro partes básicas, que se dividen en secciones. Para efectos del diseño de
la HMI se toma la Parte I, que contiene directrices para los elementos básicos de HMI:
Visualización de la información, Interacción del usuario-interfaz y gestión, y Controles.

51
 I. Visualización de la información

 Caracteres alfanuméricos:

Debe utilizarse una fuente clara y legible evitando, los tipos de letra cursiva, sombreada o
en tres dimensiones, debe ser posible distinguir claramente entre los siguientes caracteres:
X y K, T y S, I y L, I y 1, O y Q, O y 0, S y 5, y U y V. La separación horizontal entre
caracteres o símbolos debe estar entre 10 y 65 por ciento de la altura del carácter o símbolo.

 Etiquetas:

Las etiquetas deben ser de forma única y coherente, de relieve, con mayúscula, o de lo
contrario enfatizarlas para diferenciarlas de otras estructuras de la pantalla y los datos.
Deben estar separadas entre sí por al menos dos espacios y su ubicación debe ser siempre
horizontal para facilitar la lectura del operario.

 Iconos y símbolos:

El principal uso de iconos en pantallas gráficas es el de representar objetos o acciones

reales. Estos deben asemejarse en gran medida a procesos, objetos u operaciones que
representan pero sin dejar de lado la simplicidad. Los iconos y símbolos utilizados en
pantalla deben ser compatibles con otras fuentes de informaciones utilizadas en los
procesos tales como los diagramas P&ID’s y los diagramas lógicos.

 Escalas ejes y grillas:

Cuando los datos escalados contienen valores muy lejanos, se deben duplicar los ejes, de
manera que el eje X aparezca en la parte superior e inferior, y el eje Y, tanto en el lado
derecho de la gráfica como al izquierdo. Esto con el fin de brindar comodidad al operario
cuando los datos se encuentran lejos de los ejes convencionales.

El uso de escalas tridimensionales se debe restringir a menos que sea necesario, pero se
recomienda en este caso utilizar técnicas a través del uso de la codificación auxiliar (por
ejemplo, color o forma de codificación, o anotación complementaria), que puede resultar
más eficaz que tratar de representar una tercera dimensión añadiendo un eje Z ya que puede
confundir a muchos usuarios.

Si se emplea la escala tridimensional, se pueden utilizar métodos de proyección como:

isométrica u ortográfica, dibujo en perspectiva, triangular o cuadrícula de coordenadas.

52
 II. Color:

El color debe ser utilizado de forma conservadora y consistente, además el número

de colores utilizados para la codificación deben mantenerse al mínimo necesario, para
proporcionar al usuario la información necesaria sin saturarlo. El uso arbitrario de los
colores en las pantallas puede causar pantallas desordenadas pero a su vez, el uso casual
del color puede reducir la probabilidad de que el usuario pueda interpretarlo rápido y
adecuadamente.

Cuando un usuario debe distinguir rápidamente entre varias categorías de datos, se

debe utilizar un color único para mostrar los datos de cada categoría.

En la actualidad los equipos ofrecen una amplia gama de colores en pantalla,

permitiéndoles a los diseñadores caer en la tentación de explotarlos. Sin embargo, tal
capacidad proporciona una desventaja porque puede recargar la vista del operador, pero la
ventaja es que puede permitir al diseñador seleccionar más cuidadosamente los colores para
ser utilizados como códigos.

La Tabla 9, proporciona los significados generales de color en las plantas nucleares.

Tabla 9. Asociaciones y características relacionadas de colores que se utilizan normalmente en el diseño del panel
[57]

COLOR SIGNIFICADO VALOR PARA LLAMAR CONTRASTA BIEN

ASOCIADO LA ATENCIÓN CON
ROJO Inseguro Bueno Blanco
Peligro
Estado de alarma
Caliente
Abierto / que fluye1
Cerrar / parado1
AMARILLO Riesgo Bueno Negro
Precaución Azul oscuro
Estado anormal
Aceite
VERDE Seguro Pobre Blanco
Satisfactorio
Estado normal
Abierto / que fluye1
Cerrar / parado1
AZUL Asesoría Pobre Negro
CLARO Agua gaseosa
(CIAN) Frío
AZUL Asesoría Pobre Blanco
OSCURO Agua sin tratar
MAGENTA2 Estado de alarma Bueno Blanco

53
 BLANCO Asesoría Pobre Verde
Vapor Negro
Rojo
Azul oscuro
Magenta
NEGRO Segundo plano Pobre Blanco
Azul claro
Amarillo

1 Los significados asociados con los colores rojo y verde son diferentes, dependen de la experiencia. El personal con experiencia
previa en planta de combustibles fósiles suelen asociar a un estado abierto con rojo y un estado cerrado con verde, pero se revierten
estas asociaciones típicamente por el personal con experiencia previa de la Armada.

2 Magenta en el amarillo es el estándar de la industria nuclear con precaución radiación

Una recomendación adicional, es evitar el uso de símbolos rojos sobre fondo verde,
así mismo se debe evitar el uso simultáneo de rojo puro y azul puro sobre fondos oscuros,
ya que puede presentar una incomodidad tridimensional.

Se deben evitar las longitudes de onda por encima de 650 nanómetros en las
pantallas, como es el caso del rojo puro.

III. Interacción y gestión de la interfaz de usuario:

Se entiende como la forma en que el usuario interactua con el sistema, para ello se
requieren tanto de menús como de botones para interrumpir al sistema.

 Menús:

Los menús se pueden organizar de diferentes maneras:

o Categórico: agrupados en las relaciones conceptuales entre las

opciones.
o Alfabético: enumerados en el orden alfabético de los nombres de las
opciones.
o Frecuencia: enumerado en términos de la frecuencia de uso de cada
opción.
o Secuencial: enumerados en el orden en que se usan las opciones.
o Mezclado: agrupados utilizando más de un esquema. Por ejemplo,
el principio del menú puede contener opciones que se utilizan con
mucha frecuencia, mientras que el resto de las opciones de menú
están dispuestos en orden alfabético.

Los menús pueden contener una combinación de texto y formas gráficas.

54
 IV. Interrupciones de transacción del usuario:

Para realizar interrupciones en un proceso no es deseable tener una sola tecla que
tiene efectos diferentes dependiendo de si se empuja una o dos veces, esto puede provocar
confusión en los usuarios. A continuación se presentan dos tablas que resumen las
funciones de control para el procesamiento de comandos y las funciones de control para
ingresar información.

Tabla 10. Funciones de control para el procesamiento de comandos [57]

FUNCIÓN RESULTADO EJEMPLO DE APLICACIÓN

END Concluye una secuencia En una secuencia repetitiva de

repetitiva de acciones. entradas de datos, END rompe el
ciclo permitiendo al usuario
seleccionar otra acción.

PAUSE/ Permite interrumpir y reanudar El usuario puede interrumpir una

CONTINUE posteriormente una secuencia de tarea actual para leer un mensaje
operaciones sin ningún cambio a entrante.
las entradas de datos.

SUSPEND Permite preservar el estado El usuario puede posponer la

actual de los datos cuando un finalización de una tarea hasta que
usuario sale del sistema. se disponga de los datos necesarios.

Tabla 11. Funciones de control para ingresar información [57]

FUNCIÓN RESULTADO EJEMPLOS DE APLICACIÓN

CANCEL Borra todos los cambios que Corrección de entradas erróneas de

hace el usuario y restaura la información.
pantalla actual a su versión
anterior.

BACK Regresa al visualizador En una secuencia de entradas de datos

anterior. relacionados, en varios marcos de
visualización, regresar a la imagen
anterior.

55
 REVIEW Permiten al usuario revisar una Permite al usuario volver al primer
secuencia de entradas y hacer visualizador, en una secuencia de
los cambios necesarios. entradas de datos relacionados, en
varios marcos de visualización.

RESTART Cancela ventanas y vuelve a la Permite en una secuencia de entradas

principal. de datos relacionados en una pantalla
de rellenado de formularios, borra
todas las entradas de datos y regresa al
primer campo en el formulario

3.2.4. Isa-S5.5 1985

La norma ISA-S5.5 es un complemento a las normas ISA-S5.1 e ISA-S5.3 para

proporcionar una combinación cohesiva de la simbología y los diagramas de flujo de uso en la
industria, además, del uso del color para representar los estados del sistema [58]. El estándar
tiene como objetivo facilitar la comprensión de la información por el usuario y establece la
uniformidad a lo largo de las diferentes industrias de procesos. Los beneficios son [59]:

 Una disminución en los errores del operador.

 Un acortamiento de la capacitación de los operadores.
 Mejor comunicación de la intención del diseñador del sistema de control a los
usuarios del sistema.

A continuación en la Tabla 12, se presentan los colores propuestos por la norma Isa-S5.5

Tabla 12. Usos del color propuestos por estándar ISA S5.5 [59].

COLOR SIGNIFICADO ELEMENTO ASOCIADO

GENÉRICO
NEGRO Segundo plano

ROJO Emergencia A) Detenido

B) Alarma de alta prioridad
C) Cerrado
D) Apagado

AMARILLO Precaución A) Condición anormal

B) Alarma de segunda prioridad

56
VERDE Seguro A) Operación normal
B) Comenzar
C) Abierto
D) Encendido

CIAN (AZUL Estático y A) Equipo de proceso en servicio

CLARO) significativo B) Nivel mayor

No esencial A) Equipo de proceso en espera

AZUL B) Nivel, etiquetas, etc.

MAGENTA Radiación A) Alarma de radiación

(PURPURA) B) Valor cuestionable

BLANCO Datos dinámicos A) Medición e información de estado

B) mensajes del sistema
C) Tendencia
D) Paso secuencia activo

57
Capítulo 4. Software de GHMI

En éste capítulo se presentan las fases de desarrollo del software de la interfaz gráfica de
usuario, así como la descripción detallada del mismo teniendo como guía de diseño las pautas
marcadas en el capítulo 3.

4.1. Entorno de Desarrollo

La interfaz gráfica se desarrolló en Visual C# de Visual Studio. C# es un lenguaje de

programación diseñado para compilar diversas aplicaciones que se ejecutan en .NET Framework,
es un lenguaje simple y orientado a objetos. Por otra parte, Visual Studio en el lenguaje de
programación C#, ofrece un completo editor de código, un compilador, plantillas de proyecto,
diseñadores, asistentes para código, un depurador eficaz y de fácil uso y otras herramientas además
de ofrecer la biblioteca de clases de .NET Framework [60].

4.2. Consideraciones de Diseño

Las consideraciones de diseño se basan en los aspectos que se deben considerar en el desarrollo
de una interfaz los cuales fueron extraídos de los estándares expuestos en el capítulo 3, donde en
resumen una interfaz debe tener:

 Capacidad de adecuación a la tarea.

 Controlabilidad.
 Tolerancia a errores.
 Utilización eficiente del color.
 Distribución de la información.
 Información textual clara.
 Información y valores del proceso.
 Interacción con los datos de los gráficos.

4.3. Diagrama de Estados de la Interfaz Gráfica

El software de la interfaz funciona en base a los estados que se muestran en la Figura 12.

58
Figura 12. Diagrama de estados del software de la interfaz.

59
 De modo general, una vez configurados los parámetros de funcionamiento, que se
entienden como: configuración de la comunicación USB, selección del método de control,
configuración del mismo y selección de valor de referencia; el sistema opera de acuerdo al
diagrama de estados para obtener el objetivo final que es controlar las variables físicas de un
proceso.

4.4. Interfaz Gráfica Desarrollada

El desarrollo de interfaz cuenta como se describe a continuación, con paneles para la

configuración de controles PID y Difuso, así como gráficos de tendencias para visualizar el
comportamiento del proceso, gráficos mímicos que se asemejan a la planta real para facilitar el
aprendizaje, botones y cajas de texto para interactuar con los tiempos y con las operaciones
necesarias que se deben ejercer, cuando se controla un proceso. Como se menciona la interfaz
resultante es flexible a cambios en la configuración de la comunicación con el dispositivo externo,
cambios en la configuración de los controladores (P, PI, PD, PID, Difuso) y permite interactuar
con las variables del entorno. La realización de mejoras en la interfaz para incluir otros procesos
u otros controles se hacen directamente en el código fuente, en las clases correspondientes.

4.1.1. Interfaz gráfica principal

El módulo principal de la interfaz gráfica está dividido en paneles como se observa en la

Figura 13, distribuyendo de manera adecuada la información sin que resulte una carga para el
usuario. Cuenta con barra de menús (1), barras de herramientas (2)(3), panel para la configuración
de parámetros de los controladores y de selección de proceso (4), panel de estatus de proceso y de
errores (5), valores numéricos de proceso (6), panel de gráfico mímico y panel de gráfico de
tendencia (7), así como los botones necesarios para interactuar con el proceso físico iniciándolo,
pausádolo o deteniéndolo en caso de observar anomalías. Esta interfaz fue llamada DEVCO cuyo
significado es un juego de palabras de development Control, sintetizando la funcionalidad de la
interfaz en desarrollo de control PID o Difuso para procesos. Sirviendo como entrenamiento para
estudiantes de las áreas donde se utilizan este tipo de controles.

60
 8

1
2

4 6
5 7

Figura 13. Módulo principal de la interfaz gráfica.

61
Donde:

1. Barra de menús: como se observa más claramente en la Figura 14, está compuesta por las
funciones básicas de archivo, editar y ver; pero estas funciones aún no están disponibles en
esta versión.

Figura 14. Barra de menús

Por otra parte la elección de la opción planta despliega el modelo matemático de planta que
se desee usar, DEVCO puede simular plantas de primer y segundo orden de modo:
𝐾
𝑓(𝑠) = (1)
𝑇𝑠+1

𝑎1 𝑠 +𝑎2
𝑓(𝑠) = (2)
𝑠 2 +𝑏1 𝑠+𝑏2

De este modo se habilita la configuración de las variables en el panel de configuración de

parámetros 4 de la Figura 13.

La barra de menús permite seleccionar el método de control que se desea trabajar, al

seleccionar Control, se despliegan las dos opciones que son PID en cualquiera de sus
formas P, PI, PD o PID y Difuso, esta opción habilita la configuración de parámetros de la
Figura 13, correspondientes al control seleccionado.

La selección de estímulo que se muestra en la Figura 14 como parte de las funcionalidades

de la barra de menús, solo funciona en modo simulación seleccionado que se encuentra en
la barra de herramientas. Se puede elegir entre: escalón, rampa y perfiles pudiendo
configurar sus amplitudes respetivas siendo esta la señal con que se simulan los modelos
matemáticos de las plantas.

La opción de comunicación de la barra de menús habilita una ventana que permite la

configuración de la comunicación serial con el dispositivo externo.

La selección gráfica despliega las opciones de transitorio o histórico. El funcionamiento

de las dos opciones es muy distinto ya que transitorio muestra los datos a modo de
tendencia desde 0 a 3 minutos sin dejar de visualizar los datos pasados, el tiempo puede ser

62
 configurado en la barra de herramientas; e histórico muestra 10 datos y limpia los datos
anteriores para mantener a la vista solo valores actuales.

2. Primera sección de barra de herramientas: esta sección contiene los botones estándar de
copiar, cortar y pegar que le dan controlabilidad a la interfaz, así como el selector de modo
real ó simulado como se observa en la Figura 15. Para acceder a esta función se da un clic
en el primer desplegable para habilitar una de las dos opciones. Cuando se selecciona modo
real en esta sección solo es posible configurar el valor de referencia para el control en el
cuadro de texto habilitado en la Figura 15.

Figura 15. Primera sección de barra de herramientas

Al seleccionar modo simulación como se observa en la Figura 16, se habilita el selector de

señal de estímulo. Es muy importante este paso porque si no se selecciona una opción de
las que se despliegan aquí el software no realiza la simulación, ya que le faltan parámetros
para completar las variables del proceso mismo, las señales disponibles en esta versión son:
escalón, perfil a través del cambio de amplitud al escalón y rampa. Este modo también
habilita el botón que permite el inicio de la simulación con los parámetros
configurados.

Figura 16. Sección habilitada para modo simulación.

3. Segunda sección de barra de herramientas: esta sección como se observa en la Figura 17,
está compuesta por los botones de control de conexión con el dispositivo externo; control
de paro de emergencia; cuadros de texto para configuración de número de muestras y de
tiempo de ejecución para el modo real; configuración de tiempo de simulación para la
respuesta a un estímulo de una función de transferencia; botones básicos de control en
modo real, botón para guardar datos del proceso y acceso directo para la conexión USB
con el módulo periférico.

Figura 17. Segunda sección de barra de herramientas

63
En forma más detallada, los botones de control de conexión permiten luego de
configurar la comunicación en el panel, acceder al dispositivo externo e iniciar el
intercambio de datos para ejecutar las acciones de control correspondientes o cerrar el
puerto virtual para terminar la comunicación y evitar dejar puertos abiertos en la
computadora que no se están utilizando.

El botón de paro de emergencia solo está habilitado (rojo) cuando el dispositivo

externo está conectado a la computadora y el proceso está corriendo, de lo contrario
permanece deshabilitado (gris), la función de este botón es enviar un cero como señal de
salida del control para apagar el actuador y ver como se comporta la variable luego de
detener el proceso.

Con la elección de modo real en la primera sección de la barra de herramientas se habilitan

dos cuadros de texto que permiten configurar el número de
muestras (cuadro de texto izquierda) y el tiempo de ejecución (cuadro central) este va a
depender del tipo de gráfica, porque si se usa un gráfico histórico no va a tener un límite
de tiempo. Con la elección de modo simulación se habilita el cuadro de la derecha y
deshabilita los otros dos, permitiendo solamente establecer un límite de tiempo para la
simulación, el muestreo no se hace necesario porque está implícito en la configuración de
parámetros de la planta.

Los botones de control de la puesta en marcha del proceso permiten poner

en funcionamiento el proceso (botón izquierdo), suspenderlo (botón central) o reiniciarlo
(botón derecho), son los botones básicos de control que permiten interactuar con el proceso
y hacerle un seguimiento sin hacer necesario el paro de emergencia repetidas veces. Se usa
un botón diferente para cada acción, atendiendo el estándar NUREG 0700-Interrupciones
de transacción del usuario.

El botón grabar genera un archivo de texto (.txt) con el valor de referencia, el valor de
control, el error y la hora en que se realizó la práctica, con la finalidad de tener datos útiles
en el momento de realizar un análisis o el desarrollo de los controles.

El acceso directo a la conexión con el dispositivo externo permite

elegir el puerto virtual en que esta el dispositivo pero no permite hacer modificaciones de
parámetros, para ello se debe hacer uso en barra de menús/comunicación.

64
4. Panel de configuración de parámetros: el panel está dividido en tres secciones como se
observa en la Figura 18, la primera sección (izquierda de la Figura 18) es la pestaña
propiedades, que muestra las aplicaciones disponibles en la versión actual (velocidad, nivel
y presión); la segunda sección (centro en la Figura 18) es la pestaña de control difuso que
contiene lo necesario para su configuración (mayor información referirse al ítem 4.1.6.); y
la tercera sección (derecha en la Figura 18) es la pestaña de control PID que contiene lo
referente a configuración del orden de la planta así como las cajas de texto para configurar
la variables del control (mayor información referirse al ítem 4.1.5.).

(a) (b) (c)

Figura 18. Panel de configuración de parámetros. (a) Selección de proceso. (b)

Configuración control PID. (c) Configuración control Difuso

5. Panel de estatus del proceso y errores: la pestaña de estatus muestra a modo de lista el
estado de la salida, el error, la señal de referencia para tener en modo de texto la tendencia
del proceso; en la pestaña de lista de errores se muestran todas las acciones erróneas que
se han realizado en el manejo de la interfaz.

6. Valores numéricos del proceso: las cajas de texto del panel muestran en valor decimal los
valores actuales de: salida, lectura del sensor, acción de control, valor de referencia y error
en el modo real para tener un mayor control del estado del proceso.

65
7. Panel de gráfico mímico: permiten la facilidad de aprendizaje por su similitud con la planta
real, el panel contiene indicadores gráficos del comportamiento de la salida y del nivel de
error.

8. Panel de gráficos de tendencia: siendo la información más usada por el usuario, el panel
permite interactuar con los valores que desea ver, como quitar y poner datos con los
selectores; así como acercamiento a zonas de interés y manejo de cursores para obtener
datos precisos capturados en la gráfica. Se puede apreciar gráficamente en la Figura 19, el
panel permite visualizar la señal de entrada, la acción de control y el valor de referencias.

Figura 19. Ejemplo de gráfico de tendencia RPM vs tiempo

4.1.2. Modo simulación

El módulo de simulación propuesto en la interfaz permiten en control PID graficar la

respuesta a un escalón, una rampa o un perfil de un modelo de planta de primer (1) o segundo
orden (2).

Obteniendo respuestas como se observa en la Figura 20, con la cual se puede interactuar
tomando valores con el cursor o haciendo uso del acercamiento para enfocar en zonas de
interés. La configuración de este módulo se expresa en 2 de la Figura 13, donde para su
funcionamiento se debe elegir el modo en la primera sección de la barra de herramientas, el
tipo de señal de estimulo junto con su amplitud, y posteriormente en la segunda sección de la
barra de herramientas la duración en tiempo de la simulación misma. La configuración de las

66
variables de la planta se ubica en el panel de configuración de parámetros en la pestaña de
control PID.

Si se desea ampliar la gráfica basta con hacer doble clic dentro de la gráfica, exportándola a
una ventana nueva de mayor tamaño, como se observa en la Figura 21. Se puede realizar toma
de datos y/o analizar el comportamiento de la planta simulada interactuando con los cursores
y el acercamiento.

Figura 20. Ejemplo gráfico de respuesta en modo de simulación.

Figura 21. Ejemplo de ampliación de gráfico de respuesta en modo simulación

67
4.1.3. Modo real

El modo real propuesto (Figura 22), permite obtener datos del módulo externo por
medio del protocolo de comunicación USB, para el funcionamiento se elige el modo en la
barra de herramientas, se ubica el puerto virtual en la comunicación USB que se expone en
el ítem 4.1.4, y se elige un método de control PID o difuso.

La configuración de este módulo se muestra en 2 de la Figura 13, donde para operarlo se

usan los botones de inicio, suspensión o reinicio. La lectura se observa en el panel de
gráficos de tendencia, en las cajas de texto en forma numérica y en el panel de gráficos
mímicos. A su vez permite interactuar con los valores obtenidos, con el valor de muestreo
que puede ser configurado en la segunda sección de la barra de herramientas, con el tiempo
de ejecución en caso de estar usando gráfico transitorio y variar el valor de referencia para
observar la respuesta del sistema.

Figura 22. Panel para configurar modo real

68
4.1.4. Conexión con módulo externo

La conexión con el módulo externo se realiza por medio del protocolo de

comunicación USB, la conexión es práctica, rápida y flexible. En la barra de menús se
ubica un ítem con el nombre de comunicación al hacer clic sobre USB se despliega una
ventana como se observa en la Figura 23, en ella es posible configurar lo correspondiente
al protocolo serial: se elige un puerto de comunicación virtual, la velocidad de transmisión,
los bits de parada, la paridad y el control de flujo. Una vez configurada la comunicación en
la segunda barra de herramientas se ubica el botón de conexión y desconexión, los cuales
permiten abrir y/o cerrar el puerto virtual.

Figura 23. Ventana que muestra la configuración para conexión con el módulo externo

4.1.5. Interfaz gráfica control PID

El panel para la configuración de control PID, permite elegir en primera instancia

el orden de la planta que se va a operar, en la versión actual es posible realizar controles de
este tipo para modelos matemáticos de plantas como se describe en 4.1.2.

Y en segunda instancia el modo de control ya sea P, PI, PD, PID. La edición de las
ganancias y del valor de muestreo se realiza a través de cajas de texto ubicadas en el panel
como se observa en la Figura 24, permitiendo realizar acciones de deshacer y rehacer
brindando controlabilidad a la interfaz.

69
 Figura 24. Panel para configuración de control PID

La elección del tipo de control P, I, PD o PID se puede hacer utilizando la barra de

menús en la opción control o utilizando la configuración de parámetros del mismo panel,
dicha selección provoca cambios en los cuadros de texto, debido a que el sistema solo
muestra la cantidad de variables necesaria para configurar dicho modo.

4.1.6. Interfaz gráfica control difuso

El panel de configuración de control difuso es un muy fácil de utilizar, ya que a

través de botones y selectores permite configurar el número de conjuntos de entrada y
salida, su universo de valores y su forma (triangular o trapezoidal), como se observa en la
Figura 25. Otro aspecto importante es que permite observar la representación gráfica de los
conjuntos difusos como se observa en la Figura 26, dando al usuario una idea más clara de
los valores que está introduciendo y su comportamiento.

70
 Figura 25. Panel para configuración de control difuso

La interfaz desarrollada permite realizar operaciones utilizando de 3 a 7 conjuntos

de entrada/salida, agregación por el máximo valor y defuzzificación por centroide. Para
observar de manera gráfica como responden los conjuntos ante un valor de entrada, se
utiliza el modo simulación de la interfaz, donde en la caja de texto destinada para el valor
de referencia se digita un valor de entrada para validarlo en los conjuntos difusos diseñados,
teniendo en cuenta el método de implicación de agregación y de defuzificación muestra
como resultado donde se ubica el valor resultante y de manera numérica en las cajas de
texto correspondientes, como se observa en la parte inferior de la Figura 26.

71
Figura 26. Representación gráfica de control difuso.

72
Capítulo 5. Aplicaciones

En éste capítulo se presentan las aplicaciones de control de velocidad, nivel y presión con
que fue puesta a prueba DEVCO. El caso de estudio principal es el control de velocidad, por lo
que se muestra el diseño y la construcción del módulo periférico con las diferentes etapas:
acondicionamiento de señal, manejo de potencia y comunicación con una computadora mediante
el protocolo de comunicación USB, además de la abstracción de su modelo matemático
aproximado.

5.1. Diagrama a Bloques para Módulos Periféricos

El hardware para módulo periférico de control se compone como se observa en la Figura

27. El módulo funciona como tarjeta de adquisición de datos y manejo de potencia. Adquiere y
acondiciona la señal del sensor, la envía por USB a la computadora y esta una vez procesa el valor
de control, por el mismo protocolo envía el dato al micro-controlador, quien la convierte en una
señal PWM útil para el actuador a través de la etapa de potencia.

Figura 27. Diagrama a bloques de módulo periférico.

5.2. Algoritmo para Módulos Periféricos

El micro-controlador AVR328P-PU del módulo periférico, cuenta con un algoritmo que le

permite comunicarse con una computadora por medio de la USART, incluir código para leer un
sensor y manejar un actuador mediante la modulación del ancho de pulso (PWM) por sus siglas
en ingles. El diagrama de la Figura 28, representa el funcionamiento de los estados con que está
programado el micro-controlador.

73
 Figura 28. Diagrama de estados del algoritmo para micro-controlador

La comunicación serial del micro-controlador se desarrolló utilizando la USART interna y

la configuración propuesta por el fabricante del dispositivo. Para el cambio de protocolo de Serie
a USB y viceversa se emplea el dispositivo de Pololu de la Figura 33.

La trama de datos que se envía a la interfaz está compuesto como se observa en la Tabla
13. Donde se transmite un inicio de trama (0x21) para tener un mejor control de los datos que
recibe la interfaz, evitando así que datos erróneos sean procesados por los algoritmos de control.
Por otra parte si el micro-controlador envía un dato de más de 8-bit, este es dividido en dos datos
de 8-bits, ocupando el lugar de dato 2 que se muestra en la Tabla 13, para que la interfaz lo pueda
recibir y procesar.

Tabla 13. Trama de datos enviada por el micro-controlador.

INICIO DE TRAMA DATO DE 8-BITS DATO DE 8-BITS

0X21 Dato 1 Dato 2

La trama de datos que se recibe en el micro-controlador posee la estructura de la Tabla 14.

Un inicio de trasmisión 0x01 activa el micro-controlador, empezando el flujo de datos y con un
inicio de transmisión 0x00 se suspende la transmisión de datos y el proceso se detiene.

Tabla 14. Trama de datos recibida por el micro-controlador.

INICIO DE TRAMA DATO DE 8-BITS

0X01/0X00 Dato señal de control

74
 En resumen, con las formas de transmisión y recepción de datos se tiene un control sobre
los mismos, el software de la computadora solo recibe la trama que inicia con el dato correcto y
compacta los dos datos que le siguen, esto para prever cuando el micro-controlador envía un dato
de 10-bits poderlo procesar y no perder información del proceso. De la misma forma el micro-
controlador, solo acepta la información con la trama de inicio correcta para posteriormente
procesar el dato siguiente y convertirlo en una señal PWM útil para el actuador del proceso.

El algoritmo cuenta con la flexibilidad de transmitir y recibir n cantidad de paquetes

dependiendo de las necesidades del usuario, solo se deben respetar las tramas de inicios. La
velocidad de transmisión, los bits de parada, de paridad, etc., pueden ser reconfigurados.

5.3. Control de Velocidad

El caso de estudio principal es el control de velocidad de un motor DC de 12 voltios. Entre

los 3 casos de aplicación propuestos, este varía con mayor rapidez, siendo el apropiado para
evaluar la respuesta de DEVCO, ante cambios rapidos en sus variables de control.

5.3.1. Circuito y Esquemático de Módulo para Control de Motor 12 VDC

Se emplea un micro-controlador AVR328P-PU de Atmel, el cual tiene una arquitectura

RISC de 8-bit, comunicación serial, I2C, SPI, 23 pines de propósito general, 6 canales analógicos
de 10 bits entre otras características [61].

Se emplea un motor de 12 VDC mostrado en la Figura 29, el cual tiene un máximo de 200
RPM y como sensor de retroalimentación un encoder de efecto Hall de 4288 pulsos por revolución.

El motor cuenta con 5 cables los cuales tienen los colores Rojo, Negro, Verde, Azul,
Amarillo y Blanco; que corresponde a:

Rojo: Potencia del motor

Negro Potencia del motor

Verde Tierra o GND del sensor

Azul Vdd (3.5V a 20 Con corriente de 10mA)

Amarillo salida A del encoder

75
 Blanco salida B del encoder

Figura 29. Motor 12 VDC empleado [62].

Para la lectura del encoder de 4288 pulsos por revolución ubicado en el motor, se utiliza el
módulo de captura la entrada del micro-controlador, el cual cuenta los pulsos del encoder y cada
vez que hay un desboramiento del timer, calcula la cantidad de revoluciones.
Para el acondicionamiento de la señal proveniente de encoder de efecto Hall, se usa un
filtro RC como el de la Figura 30, el cual es recomendado por el fabricante del motor, para
disminuir el ruido y aumentar la corriente de la señal enviada al micro-controlador.

Señal encoder Micro-controlador

R1
1k

C1
0.1uF

Figura 30. Filtro RC para el encoder.

El manejo de la potencia para el motor, lo tiene el circuito básico que se muestra en la

Figura 31, en el cual se utiliza un opto-acoplador 4N35 que une de forma óptica la señal de control
con la de potencia y esta a su vez es manejada por un TIP122 capaz de soportar corrientes hasta
de 5 amperios, garantizando que no existan corrientes de fuga que puedan afectar el
funcionamiento del micro-controlador.

76
 12VDC

Motor
D1
1N4007

Micro-controlador U1
R3 B 6
1 A C 5
1k
2 4 R2 Q1
K E TIP122
4N35 220

Figura 31. Manejo de potencia.

Para la conversión de serie a USB y viceversa, se utiliza el conversor del programador de

Pololu que se muestra en la Figura 32, el cual permite también programar el micro-controlador del
módulo periférico.

Figura 32. Conversor USB y programador Pololu [63].

El resultado final es el circuito de la Figura 33, capaz de adquirir las señales de un encoder
de efecto hall y manejo de motor DC de hasta 24 VDC, desacoplando las señales de control de las
de potencia.

Figura 33. Circuito diseñado para control de velocidad.

77
 El módulo periférico resultante, puede ser empleado para leer cualquier encoder y para
manejar motores DC de hasta 24 voltios, la comunicación con una computadora la realiza mediante
el protocolo USB y es flexible en cuanto a la configuración del protocolo de comunicación serial.
El módulo se detalla en la Figura 34.

Figura 34. Módulo para control de velocidad de motor de 12VDC

5.3.2. Caracterización de la Planta

La planta empleada para realizar control de velocidad se observa en la Figura 35, está
compuesta por un motor DC de 12 voltios y un encoder de 4288 pulsos por revolución.

Figura 35. Planta utilizada para control de velocidad.

78
 Para obtener la forma matemática, se utilizó el módulo periférico para control de
velocidad, la interfaz diseñada y el método numérico de mínimos cuadrados:

Como se había mencionado en el capítulo anterior, el módulo periférico envía los datos del
encoder por medio del USB, de esta manera se configuró la interfaz gráfica para que adquiriera 31
muestras con intervalos entre ellas de 0.1 segundos con un escalón de 100 RPM’s, los resultados
se muestran a continuación en la Tabla 15.

Tabla 15. Datos de caracterización de la planta.

MUESTRA TIEMPO ESCALÓN VALOR

OBTENIDO
0 0 0 0
1 0.1 100 17
2 0.2 100 57
3 0.3 100 108
4 0.4 100 125
5 0.5 100 132
6 0.6 100 135
7 0.7 100 136
8 0.8 100 138
9 0.9 100 138
10 1.0 100 138
11 1.1 100 138
12 1.2 100 139
13 1.3 100 139
14 1.4 100 140
15 1.5 100 140
16 1.6 100 139
17 1.7 100 140
18 1.8 100 140
19 1.9 100 140
20 2.0 100 140
21 2.1 100 140
22 2.2 100 140
23 2.3 100 140
24 2.4 100 140
25 2.5 100 141
26 2.6 100 140
27 2.7 100 141
28 2.8 100 141
29 2.9 100 141
30 3.0 100 141

79
 5.3.3. Modelo matemático aproximado

Utilizando los datos obtenidos con ayuda de la interfaz, se aplica el método matemático de
mínimos cuadrados, el cual dado un conjunto de pares ordenados intenta encontrar la función
continua que más se aproxime al conjunto de datos ingresados.

Para iniciar con el método se elige el orden de la función de transferencia que se desea, que
para la presente prueba fue una ecuación de primer orden como se observa en (3).
𝑦(𝑠) 𝐾
= (3)
𝑢(𝑠) 𝑇𝑠+1

La forma clásica del método se indica en (4), donde v es el vector columna de los datos de
salida en una posición adelantada, ∅ es la matriz que relaciona los datos de salida en una posición
atrás y los datos de entrada, y 𝐵̂ son los dos coeficientes 𝑎̂ y 𝑏̂ que se aproximan a la planta real.

𝐵̂ = (∅𝑡 ∗ ∅)−1 ∗ ∅𝑡 ∗ 𝑣 (4)

Para resolver (2) se utilizó el software de Matlab, dicha ecuación puesta en código de
programación queda expresada como se muestra:

n=1; %orden del polinomio

N=31; %número de muestras
v=y((n+1):(N)); %para poner el vector en una posición adelantada y
llenar el vector V
N1=N-1;
y1=y(1:(N1));
yn=-y1;
u1=u(1:(N1));
fi=[yn u1]; %matriz ∅
fit=fi';
invfi=inv(fit*fi);
B=(invfi)*fit*v %fórmula para hallar los valores estimados

Como resultado se tiene que los coeficientes continuos 𝐵̂ son: 𝑎̂ = -0.5827, 𝑏̂ = 0.5872
con un coeficiente de aproximación j = 704.7486. Una vez obtenidos los coeficientes, el paso
que sigue es pasarlos de su forma continua a discreta, para esto se convierte (3) a ecuaciones en
diferencia y se encuentran las relaciones, de la siguiente manera:

𝑦(𝑠) 𝐾
=
𝑢(𝑠) 𝑇𝑠 + 1

80
 𝑇𝑆𝑦(𝑠) + 𝑦(𝑠) = 𝐾𝑢(𝑠)

𝑑𝑦(𝑡)
𝑇 + 𝑦(𝑡) = 𝐾𝑢(𝑡)
𝑑𝑡
Luego se convierte a ecuaciones en diferencia y se adelanta:

𝑦(𝑘 + 1) − 𝑦(𝑘)
𝑇[ ] + 𝑦(𝐾) = 𝐾𝑢(𝑘)
∆

𝑇 𝑇
𝑦(𝑘 + 1) − 𝑦(𝑘) + 𝑦(𝑘) = 𝐾𝑢(𝑘)
∆ ∆
Luego se atrasa:

𝑇 ∆−𝑇
𝑦(𝑘) + 𝑦(𝑘 − 1) = 𝐾𝑢(𝑘 − 1)
∆ ∆

Ecuación en diferencias de un motor:

∆−T K∆
y(k) + y(k − 1) = u(k − 1)
T T
Los coeficientes obtenidos se igualan:

∆−𝑇
= 𝑎̂
1
𝑇
𝐾∆
= 𝑏̂
1
𝑇
Donde k se denomina ganancia del proceso, T es la constante de tiempo del sistema y ∆
es el muestreo. Se Despeja T y K, y sabiendo que ∆= tiempo de muestreo/ número de muestras,
se tiene la ecuación del motor (5).

𝑦(𝑠) 1.407
= (5)
𝑢(𝑠) 0.239 𝑆+1

Para comprobar que el modelo de planta obtenido es real, con ayuda de Simulink de Matlab
se hace la simulación como se observa en la Figura 36.

81
 Figura 36. Diagrama de la simulación en Simulink

Los resultados se presentan en la Figura 37, donde la línea continua es el comportamiento

de los datos adquiridos y la línea discontinua es el modelo aproximado encontrado con el método.
La diferencia existente entre las dos señales se debe a que se uso un modelo de primer orden para
aproximar la planta.

Figura 37. Gráfica de modelo matemático contra datos reales obtenida en Simulink

Los coeficientes encontrados se pusieron en el panel de configuración de parámetros de

DEVCO como se observa en la Figura 38, utilizando la ecuación de primer orden.

Figura 38. Datos en el panel de configuración de parámetros para ecuaciones de primer orden en DEVCO

82
 El resultado obtenido es similar al graficado con Matlab, en la Figura 39 se observa el
mismo comportamiento ante la señal escalón de excitación, y es posible interactuar con ella para
sacar datos de interés para el cálculo del controlador.

Figura 39. Respuesta al escalón obtenida con DEVCO

5.4. Control de Nivel de Líquido

Para comprobar la flexibilidad de DEVCO, se implementó un control difuso para nivel de

líquidos. A diferencia del control de velocidad, el control de líquidos es un poco más lento
permitiendo ver el comportamiento del sistema ante variaciones de este tipo. La planta que se
utilizó es la construida para la tesis: “Diseño y construcción de un módulo de desarrollo para
control de procesos” [64].

5.4.1. Esquemático de módulo de control de nivel

Se emplea un sensor ultrasónico SRF04 para medir el nivel del líquido. El sensor envía un
pulso que al encontrarse con un cambio de densidad en el ambiente, en este caso agua, regresa al
sensor que con ayuda de un micro-controlador calcula la distancia. El sensor se observa en la
Figura 40.

Figura 40. Sensor ultrasónico de distancia SRF04

83
 El sensor no necesita etapa de acondicionamiento, se conecta directamente al micro-
controlador como se observa en la Figura 41.
U1
2 14
PD0/RXD/PCINT16 PB0/ICP1/CLKO/PCINT0
3 15
PD1/TXD/PCINT17 PB1/OC1A/PCINT1
4 16
PD2/INT0/PCINT18 PB2/SS/OC1B/PCINT2
5 17
PD3/INT1/OC2B/PCINT19 PB3/MOSI/OC2A/PCINT3
6 18
PD4/T0/XCK/PCINT20 PB4/MISO/PCINT4
11 19
PD5/T1/OC0B/PCINT21 PB5/SCK/PCINT5
12 9
PD6/AIN0/OC0A/PCINT22 PB6/TOSC1/XTAL1/PCINT6
13 10
PD7/AIN1/PCINT23 PB7/TOSC2/XTAL2/PCINT7
21 23
AREF PC0/ADC0/PCINT8
20 24
AVCC PC1/ADC1/PCINT9
25
PC2/ADC2/PCINT10
26
PC3/ADC3/PCINT11
27
5 Vdc PC4/ADC4/SDA/PCINT12
PC5/ADC5/SCL/PCINT13
28
1
Trig PC6/RESET/PCINT14
ATMEGA328P
Echo
GND

Figura 41. Circuito para conexión de sensor SRF04

El actuador es una moto-bomba similar a la Figura 42. Es de usos automotriz pero funciona
muy bien para el objetivo del control.

Figura 42. Moto-bomba empleada en la planta de control de nivel

Para el control de la moto-bomba, se usa el circuito de control de motor de la Figura 31. El

circuito completo para el desarrollo de la práctica se observa en la Figura 43, cuenta con
comunicación USB, control de potencia y conexión del sensor de ultrasonido.

Figura 43. Circuito completo para control de nivel

84
 5.5. Control de Presión

Para el control de presión se utilizó el módulo para caracterización de películas flexibles,

ubicado en el laboratorio de metrología óptica del Centro de Investigación en Ciencia Aplicada y
Tecnología Avanzada, unidad Querétaro del Instituto Politécnico Nacional.

5.5.1. Esquemático de módulo de control de presión

Se emplea un sensor MPX5700 como se observa en la Figura 44, el cual es sensor de

presión diferencial piezo-resistivo con salida analógica. Su rango de presión esta entre 0 y 101.5
PSI, con una salida de 0.2 a 4.7 Vdc.

Figura 44. Sensor de presión MPX5700 [65].

Para acondicionar la señal del sensor se utilizó un LM358 como seguidor de voltaje, con la
finalidad de acoplar impedancias, así como los capacitores recomendados por el fabricante del
sensor para la alimentación y la salida de la señal analógica. El circuito se observa en la Figura 45.

8vdc

C1
470pF

U4:A
Input
8

3
1 Output
GND 2

VCC
4

LM358N

C2 C3
1uF 0.01uF

Figura 45. Conexión sensor de presión MPX5700

El actuador para controlar la presión en la celda, es una electro-válvula PVQ31 como se

muestra en la Figura 46. Es una electro-válvula proporcional controlada por corriente de 0 a 330
mA con una tensión de 12 Vdc.

85
 Figura 46. Electro-válvula PVQ31 [66].

El circuito utilizado para el manejo de la electro-válvula se observa en la Figura 47. Se

tiene una fuente de corriente de 0 a 300mA controlados con voltaje, el arreglo de transistores va a
una fuente de 12 Vdc proporcionando los mili-Amperios requeridos por la electro-válvula. Para
lograr manejar la corriente con el micro-controlador, se usa un opto-acoplador 4N35, el cual recibe
la señal PWM que puede ser traducida como voltaje analógico 0 a 5 voltios y los eleva de 0 a 12
voltios.

Q1(C)

Q1
TIP41

U2 Q3
TIP41
B 6
Microcontrolador 1 A C 5
+88.8
AC mA
2 4
K E R1 R5
4N35 1M
100
R4
ELECTRO-VÁLVULA
1k

26

R11
56k

Figura 47. Circuito para manejo de electro-válvula

El circuito completo empleado se observa en la Figura 48. Esta compuesto por el

acondicionamiento del sensor de presión, el manejo de la electro-válvula y la comunicación con
la computadora misma empleada en el control de la velocidad que se presenta en 5.3.1.

Figura 48. Circuito para control de presión

86
Capítulo 6. Experimentación y Resultados

En el presente capítulo se muestran las pruebas que se realizaron en la interfaz tomando

como caso de estudio principal el control de velocidad de un motor DC de 12 voltios, al cual se le
implementó control PID y control difuso para observar el comportamiento del motor con los dos
controles por separado. Así, como los resultados del control difuso para nivel y presión.
Comprobando de esta forma la flexibilidad de DEVCO.

6.1. Control PID para Velocidad de un Motor DC

El control PID, es un mecanismo de control en lazo cerrado ampliamente utilizado en la

industria, está conformador por tres acciones: proporcional, integral y derivativa. Pero
dependiendo el uso y la planta varias acciones pueden ser cero lo que origina los controles
conocidos como: P, PI, PD. El diagrama general de este mecanismo de control se observa en la
Figura 49.

Figura 49. Esquema general PID.

Donde la acción P, es una respuesta proporcional con una ganancia a la diferencia entre el
valor de referencia y el valor de la retroalimentación. La acción I elimina el error en régimen
estacionario, pero se obtiene un mayor tiempo de establecimiento, una respuesta más lenta. La
acción D disminuye el exceso de sobre-oscilaciones [67].

6.1.1. Diseño del controlador

Para calcular las constantes del control PID se utilizó el primer método de las reglas de
sintonización de Ziegler-Nichols, el cual y como se observa en la Figura 50, se aplica una señal
escalón a la planta para obtener su comportamiento de manera experimental y luego se dibuja un
recta tangente en el punto de inflexión, con esto se obtiene el tiempo de retardo L y la constante

87
de tiempo T. Es importante tener en cuenta que para que el método sea pertinente la curva de la
planta debe tener forma de “S”.

Figura 50. Reglas de sintonización para PID

El método sugiere establecer los valores de Kp, Ti y Td de acuerdo con las fórmulas de la
Figura 51.

Figura 51. Fórmulas de primer método de las reglas de Ziegler-Nichols

Al excitar con un escalón de amplitud 100 la planta del caso de estudio, se tiene como
resultado la Figura 53, la cual tiene la forma de la curva requerida por el método. Con ayuda de
Matlab se extraen los valores L=0.05842 y T=0.4077, para reemplazar en las ecuación para PID
de la Figura 52.
RPM

Tiempo (Sg)

Figura 52. Respuesta de la planta real al escalón.

88
 Aplicando las formulas se obtiene los resultados (6), (7) y (8).

Cálculo constante P:
0.4077
𝐾𝑝 = 1.2 ∗ (0.05842) = 8.374 (6)

Cálculo constante I:
𝑇𝑖 = 2 ∗ 0.05842 = 0.116 (7)

Cálculo constante D:
𝑇𝑑 = 0.5 ∗ 0.05842 = 0.029 (8)

Con apoyo de Simulink de Matlab, se simula el comportamiento del controlador y la planta ante un
escalón, obteniendo como resultado una señal estable pero que no llega al punto de referencia, vista en la
Figura 54. La simulación se establece como se observa en la Figura 53, para obtener el esquema general
del control PID.

Figura 53. Simulación de la planta en Simulink de Matlab.

Figura 54. Gráfica simulada de respuesta al escalón del controlador.

89
 Para lograr el resultado deseado, tanto en rapidez como en alcanzar el punto de referencia,
se aumenta la constante proporcional, para incrementar la ganancia en el sistema y a su vez la
velocidad de respuesta, también se disminuye Td para reducir las oscilaciones bruscas, como
resultado se obtiene la señal de Figura 55, la cual es satisfactoria para probar con el sistema físico.
Los valores finales son: Tp=20, Ti=0.116, Td=0.025.

Figura 55. Gráfica simulada de respuesta al escalón del controlador con constantes afinadas.

6.1.2. Puesta en marcha del controlador en la interfaz

Las ganancias del PID calculadas, se configuraron en DEVCO en el panel de configuración

de parámetros, como se muestra en la Figura 56.

Como resultado se tiene que al excitar el sistema con un escalón de 160 RPM’s este alcanza
el valor de referencia y su estabilidad en 0.7 segundos (Señal verde en la Figura 57), sin sobre
pasos y con oscilaciones de +- 2 RPM’s producto de la fluctuación del encoder que es quien cierra
el lazo de control. Para efectos de entendimiento se grafica la respuesta del controlador, (señal azul
en la Figura 57).

Figura 56. Configuración de ganancias PID en DEVCO

90
 Figura 57. Respuesta al escalón del sistema real

Se excitó el sistema con un perfil para observar el comportamiento del controlador ante el
cambio de escalón, y como se muestra en la Figura 58, el controlador alcanza el primer
valor de referencia de 160 RPM’s en 0.7 segundos, posteriormente el cambio de escalón a
180 RPM’s lo alcanza en 1.4 segundos y este comportamiento se repite cuando el cambio
vuelve a ser a 160 RPM’s. El sistema varía en +- 2RPM’s sin sobrepasos en los cambios
de escalón igual que en el experimento anterior con un escalón de 160 RPM’s.

Figura 58. Respuesta real a cambio de escalón.

6.2. Control Difuso para Velocidad

Los sistemas difusos se refieren a situaciones en las que no se puede expresar como
verdadero o falso, sino como parcialmente cierto. Una de las ventajas que posee es que se trabaja
en base a la experiencia humana del proceso lo que hace que sea más fácil desarrollar tareas. Los
conjuntos difusos se expresan con términos lingüísticos los cuales representan rangos de valores
en un universo definido. Un sistema difuso está compuesto por cuatro componentes fundamentales
como se describe en la Figura 59, donde los valores de entrada y salida se les denominan valores
crisp.

91
 Figura 59. Diagrama a bloques de control difuso

La función del fuzzificador es convertir los valores crisp a valores difusos, el cual compara
el valor actual en cada conjunto difuso dándole un valor de membresía. La base de reglas son
sentencias condicionales (9).

IF <condición> THEN <conclusión> (9)

Donde las condiciones corresponden a un antecedente que desencadena una conclusión o

consecuente. El mecanismo de inferencia proporciona los métodos para combinar las reglas y
proporciona la información para agregar los conjuntos involucrados en cada entrada, este puede
ser por media aritmética, producto, media geométrica, mínimo, máximo o función suma. Por
último el método de defuzzificación, el cual a partir de un conjunto difuso da como resultado un
valor crisp, este puede ser por máximo, centro del máximo, centro de gravedad, centro de área,
entre otros [68].

6.2.1. Diseño del controlador difuso

El control difuso diseñado para el control de velocidad del motor, se basa en 3 conjunto de
entrada y 3 de salida como se observa en la Figura 60. Los 3 conjuntos de entrada representan el
error:

𝐸𝑟𝑟𝑜𝑟 = 𝑅𝑒𝑓𝑒𝑟𝑒𝑛𝑐𝑖𝑎 − 𝑉𝑎𝑙𝑜𝑟 𝑙𝑒í𝑑𝑜 (10)

En la Figura 60, se muestra en azul el conjunto sobrepaso, en naranja el conjunto error

cercano y en verde el conjunto máximo del error, tomando un universo de valores que va de -200
a 200.

Por otro lado, los 3 conjuntos de salida, tienen un universo de valores que van de -3 a 3,
para obtener valores de incremento pequeños cuando se aplique el método de defuzzificación, los
3 conjuntos se definen como: incremento rápido mostrado en azul, incremento lento mostrado en
naranja y decremento rápido mostrado en verde. Los pares ordenados que representan los
conjuntos son:

92
 Conjuntos entrada= [-200, -200, -120, -2; -200, 0, 200; 1, 10, 200, 200]

Conjuntos de salida= [-3, -3, -3, 0; -3, 0, 3; 0, 3, 3, 3]

Figura 60. Conjuntos difusos empleados para control de velocidad.

Mientas más conjuntos se tengan se obtiene mayor resolución ya que la incertidumbre en

que cae una entrada es más pequeña.

La base de reglas empleada se muestra en la Figura 61, donde se tiene en cuenta la

experiencia en el sistema así: Cuando el motor esta lejos del error aumenta rápidamente su
velocidad, cuando se aproxima al valor de referencia sus incrementos son lentos y cuando hay un
sobrepaso rápidamente decrementa su velocidad.

Figura 61. Base de reglas.

El operador de agregación empleado es el máximo, el cual como se observa en las Figuras

60 y 62, nos proporciona como resultado los valores mayores de los conjuntos involucrados.

93
 Figura 62. Diagrama de control Difuso donde se muestra el operador de agregación.

Como paso final para el método de defuzificación se implementó el defuzificador por

centro de gravedad COG (Center of Gravity) (11).

∑𝑘
𝑖=1 𝑥𝑖∗𝜇(𝑥𝑖)
𝑌𝐶𝑂𝐺 = (11)
∑𝑘
𝑖=1 𝜇(𝑥𝑖)

Este método calcula el área del conjunto agregado y luego encuentra su punto medio o
centro de gravedad, también se le conoce como media difusa (Fuzzy Mean FM).

6.2.2. Puesta en marcha del control difuso en la interfaz

Para la puesta en marcha en DEVCO, se configuraron los valores de los conjuntos difusos,
y se simuló la respuesta a una entrada como se observa en la Figura 62, teniendo en cuenta que la
entrada al sistema es la diferencia entre el valor de referencia y la entrada actual leída. Como
resultado se tienen incrementos cercanos a cero cuando el valor leído se acerca al valor de
referencia. Utilizando la planta y con un valor de referencia de 160 RPM’s se tiene como resultado
la Figura 63.

Figura 63. Respuesta real a un escalón

94
 Se obtuvo una respuesta al escalón en 2.4 segundos, que no presentan sobrepasos y su
estabilización se obtiene con pequeñas oscilaciones de +/- 2 RPM’s. Estas variaciones se deben a
la lectura del encoder que a pesar que tiene un filtro en software varía en +/- 5 RPM’s.

Se realizaron pruebas a perfiles para observar el comportamiento del control con diferente
escalón y como se observa en la Figura 64, el cambio de escalón de 160 RPM a 200 RPM lo realiza
en 3 segundos aproximadamente y con el cambio descendente de 200 RPM a 160 RPM lo realiza
en 4 segundos.

Figura 64. Respuesta real a un perfil.

La interfaz soporta el desarrollo de controles difusos de 3 a 7 conjuntos, agregación por el

máximo valor y defuzificación por el método del centroide.

6.3. Diseño y Puesta en Marcha de Control Difuso para Nivel

Al igual que para el control de velocidad, se emplearon 3 conjuntos difusos de entrada y

salida, teniendo en cuenta que la entrada es el error del sistema. Los pares ordenados que
representan los conjuntos son:

Conjuntos entrada= [-31, -31, -5, -1; -5, 0, 5; 0, 3, 31, 31;]

Conjuntos de salida= [-256, -256, -60, -1; -6, 0, 6; 5, 70, 256, 256;]

La base de reglas empleada, se observa en la Figura 65, en la cual se usa una relación
directa como en el control de velocidad, obteniendo así incrementos en la variable de salida
grandes cuando el error es muy grande e incrementos pequeños cuando la variable se acerca a la
referencia.

95
 Figura 65. Base de reglas control de nivel

El operador de agregación empleado es el máximo y como defuzificador el método de

centro de gravedad, como resultado de diseño se tiene la Figura 66, en la que se muestran los
conjuntos difusos empleados, además los valores de incremento pequeños cuando el error se acerca
a cero.

Figura 66. Conjuntos Difusos para control de nivel

Como resultado se tiene la Figura 67, en la que se presenta la respuesta del sistema ante un
escalón de 8 centímetros de nivel. El sistema alcanza el valor de referencia en 6 segundos, sin
sobrepasos. Las variaciones que se observan se deben a que el sensor solo mide en centímetros, de
modo que las lecturas las aproxima al valor entero más cercano.

Figura 67. Respuesta real al escalón del sistema de control de nivel

96
 6.4. Diseño y Puesta en Marcha de Control Difuso para Presión

Al igual que los dos controles anteriores, el controlador se hizo en base al error con 3
conjuntos difusos como se observa en los pares ordenados:

Conjuntos entrada= [-20, -20, -3, 0; -15, 0, 7; 1, 3, 20, 20;]

Conjuntos de salida= [-3, -3, -3, -1; -3, 0, 3; 1, 3, 3, 3;]

La relación que se usa es directa al igual que en los dos controles anteriores, cambiando
únicamente el significado de los conjuntos. La base de reglas empleada, se observa en la Figura
68, donde se tiene que variar la apertura de la válvula para permitir o no el paso de aire a la cámara.

Figura 68. Base de reglas control de presión

Los conjuntos difusos empleados se muestran en la Figura 69, donde se visualizan los
rangos de valores, así como los incrementos que se obtienen cuando el error tiende a cero.

Figura 69. Conjuntos Difusos para control de presión

El operador de agregación y el método de defuzificación son el mismo que para los dos
caso de aplicación anteriores. Se obtiene como respuesta al escalón la Figura 70, donde el sistema

97
alcanza su valor de referencia de 10 PSI en 8 segundos, manteniendo un pequeño ruido dada por
la sensibilidad del sensor.

Figura 70. Respuesta real al escalón de control de presión

6.5. Discusión

El proyecto tiene como propósito desarrollar una GHMI para control de procesos útil en
diferentes tipos de control, como se muestra en apartados anteriores en control PID y control
Difuso. De acuerdo con los resultados obtenidos, DEVCO tiene las herramientas necesarias para
desarrollar este tipo de controles. Con las aplicaciones se comprobó la eficiencia del software así
como la facilidad para interactuar con los procesos y realizar cambios mediante variables.

Por otro lado, con la utilización de los dos tipos de controladores se puede decir que son
similares en su comportamiento, cumpliendo con el objetivo de estabilizar el proceso en un punto
de referencia dado por el usuario. Los tiempos de respuesta van a depender de los parámetros con
que se diseñe así como el sobre-paso y las oscilaciones.

Puntualmente en el caso presentado de control de velocidad, el control PID responde más

rápido, ya que su naturaleza es realizar incrementos grandes cuando está lejos del punto de
referencia y muy pequeños de casi milésimas cuando el error es casi cero. Por otra parte el control
difuso que se diseñó, basa su defuzificación en el método del centroide que no permite tener
incrementos muy pequeños cuando el error se acerca a cero y grandes cuanto está lejos, en este
sentido se tiene que sacrificar velocidad en respuesta para obtener estabilidad, esto porque si
utilizamos un universo con valores grandes se obtienen valores de incremento de la misma
magnitud, pero cuando el error es casi cero estos incrementos no permiten la estabilidad del
sistema. Pero si en su lugar se usa un universo de valores pequeño se obtienen valores de
incremento de la misma magnitud para la estabilización del sistema y la misma magnitud cuando
el error es muy grande, esto se traduce en respuesta lenta pero estable, una posible solución es

98
realizar defuzificación utilizando funciones Singleton o con otro método de defuzificación que no
sea por promedio ya que este promedio es el que provoca dicho comportamiento.

Las otras dos aplicaciones permiten confirmar que la interfaz es flexible en cuanto al
proceso a manipular. No se deben realizar cambios significativos para incluir más aplicaciones, la
interfaz espera los datos provenientes del USB ya sea de 8 o 12 bits, independientemente del tipo
de sensor y como resultado envía una señal PWM útil para gran cantidad de actuadores.

99
Capítulo 7. Conclusiones y Propuestas para Trabajos Futuros

En éste capítulo se presentan las conclusiones del trabajo, así como los trabajos futuros
sobre la interfaz que se deberían realizar tanto para ponerla a punto como para programar en ella
otros controles u optimizar los que tiene hasta el momento.

7.1. Conclusiones

 Con la utilización de la normativa referente a diseño ergonómico de interfaces gráficas de

usuario, se obtiene un desarrollo que no solo cumple con los objetivos de ser reconfigurable
a través de variables, donde el método de control se pueda elegir entre dos diferentes; sino
que su distribución y formas de intervención del usuario están enmarcadas en conceptos
como usabilidad, capacidad de adecuación a la tarea; brindando al usuario un entorno
practico, entendible y rápido con el cual puede realizar sus tareas en control y
automatización de procesos.

 La flexibilidad que propone la interfaz en la utilización de dos métodos de control

diferentes (Difuso y PID) provee una forma rápida para comparar el control de un proceso
mediante estos dos diferentes métodos y poder establecer conclusiones u observar cual es
el control más indicado para la planta objeto de estudio.

 La interacción con variables físicas que promueve DEVCO permite poner en práctica los
conceptos de control que se adquieren en las aulas de clase y ver cómo se comportan
nuestros sistemas en ambientes físicos controlados.

 Los casos de aplicación permitieron en primera instancia, poner a prueba el funcionamiento

de la interfaz interactuando con variables físicas, y en segunda instancia siendo casos con
diferente manejo de datos se pudo constatar que la interfaz cuenta con la suficiente rapidez
de procesamiento para datos tan rapidos provenientes de un control de velocidad, hasta no
tan rapidos como los de un control de nivel.

 La interfaz es funcional, cuenta con las herramientas necesarias para interactuar con el
proceso y con los datos provenientes del mismo, además, se adapta a diferentes procesos
evidenciándolo con los casos de aplicación, donde se trabajó con señales de encoder, sensor
ultrasónico y sensor analógico de presión, sin importar la cantidad de bits.

100
7.2. Trabajo Futuro

 Desarrollar en DEVCO la propiedad de crear un nuevo proyecto de trabajo para guardar la

información de procesos de control en que se haya experimentado.

 Mejorar los gráficos mímicos e incluir más procesos. Actualmente cuenta con lo necesario
para un control de velocidad, pero es importante que incluya la flexibilidad de gráficos para
procesos comunes como: control de temperatura, nivel, posición, entre otros.

 Hacer más didáctico el sistema incluyendo bloques de texto con ayuda interactiva en el
manejo de la interfaz y/o un tutor virtual que guie el uso y provea información del proceso
que se pretende realizar.

 Incluir comunicación Ethernet para aumentar la flexibilidad del software.

7.3. Productos

Artículo con nombre “Guía para el Desarrollo de Interfaces Gráficas humano-Máquina

(GHMI)” para el Congreso Internacional de Investigación Aplicada e Innovación Tecnológica
2015, San Juan del Río, Qro., Méx.

Póster con nombre “Desarrollo de interfaz Gráfica Humano-Máquina (GHMI) para

sistemas de control de procesos” para el 2do Congreso de Ciencia y Tecnología avanzada 2015.
Querétaro, Qro., Méx.

Artículo en proceso para la revista IEEE Latin America Transactions, con nombre “Guide
Development Graphic Human Machine Interface (GHMI)”.

Derechos de autor en proceso para el software de la interfaz grafica desarrollada.

101
Referencias

[1] L. F. Palma Pozo and S. E. Sangopanta Ardila, “Diseño de un PLC con Microcontrolador
PIC 16F873.,” Universidad de Pinar del Río, 2011.
[2] E. Martínez Paredes, “Propuesta de desarrollo de una interfaz de control tipo PLC
mediante micro-controladores AVR,” Cent. Estud. Super. Nav., no. 04–2004–
030110032500–102, pp. 97 – 112, 2006.
[3] Siemen_ssupply, “Siemens Simatic S5 S7 TI Simadyn Teleperm Texas Instruments PLC
DCS,” 2013. [Online]. Available: http://www.siemenssupply.com/. [Accessed: 09-Dec-
2014].
[4] J. Payne, “PLC vs PAC,” Control Engineering, 2013. [Online]. Available:
http://www.controleng.com/single-article/plc-vs-
pac/44448cf771be09bff7115c621633bd94.html?print=1.
[5] J. A. Cartagena Méndez and C. O. Pocasangre Jiménez, “‘ Diseño y construcción de un (
PLC ) Control Lógico Programable basado en la tecnología del microcontrolador ,’”
Universidad de el Salvador, 2004.
[6] T. Thayer., “Speaking in Tongues: Understanding the IEC 61131-3 Programming
Languages,” Control Engineering, 2009. [Online]. Available:
http://www.controleng.com/industry-news/more-news/single-article/speaking-in-tongues-
understanding-the-iec-61131-3-programming-languages/4123b0e66c.html.
[7] J. L. Bossa, “Interfaz gráfica para un banco didáctico dedicado a la electrónica de
potencia,” 2008, p. 6.
[8] Rexroth Bosch Group, “Training systems for automation,” no. 09.2012, p. 88, 2012.
[9] E. R. Larraguivel, “Retos y amenazas a la formación de ingenieros frente a las
tranformaciones de la producción industrial . El caso del área metropolitana de la ciudad
de México,” vol. 11, pp. 197–216, 2000.
[10] Lucas-Nulle, “Training Systems for Automation Technology,” vol. 4, no. P5142, p. 136,
2013.
[11] P. Gamboa, J. Faria, J. Palma, and L. Ferreira, “Modern Technologies for Experimental
Education in Industrial Electronics and Electric Drives,” in IEEE, 2005, pp. 1–8.
[12] U. Maracaibo and E. Zulia, “Modelo didáctico para el aprendizaje significativo en los
sistemas automáticos de control,” REDHECS, vol. 7, no. 5, pp. 24–44, 2009.
[13] F. A. B. Batista, C. A. Petry, E. L. F. Santos, and B. R. Almeida, “DIDACTIC SYSTEM
FOR DIGITAL CONTROL OF POWER ELECTRONICS APPLICATIONS,” IEEE, no.

102
 978–1–4244–3370–4, pp. 1093–1098, 2009.
[14] M. S. Bernasconi and A. E. Puglesi, “EL LABORATORIO DE CONTROL
AUTOMÁTICO COMO INGENIEROS,” in World Enginneerin Education Forum, 2013,
p. 10.
[15] P. G. López, J. Salvador, F. López, R. Junior, S. Gómez, J. De Jesús, and M. Juárez,
“Equipos didácticos industriales en el modelo educativo de los Cecati,” Redalyc, vol. vol:
9, no. 48, México, pp. 73–81, 2009.
[16] A. Hernández Zavala, O. Camacho Nieto, O. Espinosa Sosa, L. Galindo Soria, and A.
Gutiérrez Aldana, Diseño y construcción de un sistema básico de interacción y acción con
procesos reales reconfigurable y de bajo costo HMI-CIC. Zacatenco, México, 2007.
[17] A. Hernández Zavala, O. Camacho Nieto, C. Yañez Márquez, and O. Espinosa Sosa,
“Low cost multi-channel data acquisition system with graphical HMI,” Res. Comput. Sci.,
vol. 24, pp. 85–93, 2006.
[18] A. Hernández Zavala, O. Camacho Nieto, O. Espinosa Sosa, and C. Yañez Márquez,
“Multipurpose Interface Card for Data Acquisition and Control with Low Technological
Hardware Cost,” in ROC&C’2006-CP-21, 2006, pp. 1–5.
[19] Rexroth Bosch Group, “Rexroth IndraLogic L20 System Description,” vol. 01, no.
R911312329, p. 124, 2005.
[20] Armfiel inc., “Multifunction Process Control Teaching System - PCT40,” no. 4, pp. 1–8,
2009.
[21] Edibon, “Equipamiento didáctico técnico 100%.” Edibon, España, p. 28, 2007.
[22] Schneider Electric, “Equipamiento Pedagógico,” p. 18.
[23] Asti Industrial Process Automation, “Didactic equipment systems Engineering.” Romania,
p. 16.
[24] De-Lorenzo, “Contolador logico programable – 36 in/28 outr,” Italia.
[25] H. Ingenium, “Módulo Mecatrónico Compacto - Neumático Clasificar y Transportar ‘
Clasificador Neumático de Piezas Cúbicas mMS .’”
[26] Feedback Instruments Limited, “Industrial Process Control Trainers with Discovery
software,” vol. 1, no. I 38S- I, p. 16.
[27] Inncomex, “PLC-300 entrenador de PLC MITSUBISHI,” p. 1, 2014.
[28] smctraining, “AUTOMATE-200,” pp. 144–155, 2013.
[29] Tecnología Educativa s.a, “Equipamento Educativo y Audiovisual.” [Online]. Available:

103
 http://www.tecnoedu.com/Didacticcos.php.
[30] Wuekro, “Training & Didactic Systems Control,” Catalog, vol. 2014, no. WA2E/03, p.
12.
[31] Electtronica Venerta S.P.A, “SOFTWARE DI SUPERVISIONE PLC LIVELLO
AVANZATO,” p. 1.
[32] Festo didactic GmbH, “Virtual Mechatronics,” teciam, p. 14.
[33] “Control automático de procesos industriales. Simulación por ordenador PC.” [Online].
Available: http://www.alfredoroca.com/. [Accessed: 09-Dec-2014].
[34] Edudevices, “Modulo I + C, Módulo para instrumentación y control .,” Catalog, p. 2.
[35] Gunt-Hamburg, “Kit de Demostración : Regulación de Nivel RT 614,” vol. 49, no. 40, pp.
40–42, 2013.
[36] I. T. S. A. de C.V., “Unidad de Control de Procesos,” 2007. [Online]. Available:
http://www.teleternik.com/laboratorios_didácticos_y_simuladores/unidad_de_control_de_
procesos. [Accessed: 09-Dec-2014].
[37] IMEPI S.A de C.V, “Aurora HMI SCADA,” 2014. [Online]. Available:
http://www.imepi.com.mx/productos/aurora-hmi-scada.html. [Accessed: 09-Dec-2014].
[38] Siemens, “Software Industrial SIMIT SCE : El laboratorio virtual SIMATIC,” pp. 43–44,
2009.
[39] W. A. Eleutério, W. A. A. Hovadich, and E. Q. Braga, “CONTROLADOR LÓGICO
PROGRAMABLE UTILIZANDO PIC 18F4550,” E-xacta, vol. 4, no. 3, pp. 159–179,
2011.
[40] W. Avila Zambrano and J. E. Rodríguez Garzón, “Implementación de un PLC didáctico
para prácticas de laboratorio,” Uniminuto de Dios, 2012.
[41] J. C. Bedón Salazar and I. R. León Guerrero, “Diseño y construcción de un PLC modular
a base de microcontroladores,” Universidad Politécnica del ejercito, Latacunga, Ecuador,
2009.
[42] C. I. Camargo B, L. K. Durán B, and N. F. Rosas J, “Plataforma hardware / software
abierta para aplicaciones en procesos de automatización industrial,” Ingenium, no. 26, pp.
76–85, 2013.
[43] P. Beirão and D. Valério, “Creation of a Virtual Graphic Interface Applied to a Process
Control System,” Procedia - Soc. Behav. Sci., vol. 46, pp. 565–569, 2012.
[44] D. Grimaldi and S. Rapuano, “Hardware and software to design virtual laboratory for
education in instrumentation and measurement,” Measurement, vol. 42, no. 4, pp. 485–

104
 493, May 2009.
[45] F. De La Cruz F., M. Díaz-Granados, S. Zerpa, and D. Giménez, “Web-LABAI:
Laboratorio Remoto de Automatización Industrial,” Rev. Iberoam. Automática e
Informática Ind. RIAI, vol. 7, no. 1, pp. 101–106, Jan. 2010.
[46] E. D. De la Torre Hurtado, “Diseño y Simulación de la Lógica de Control y de la Interfaz
HMI de un Prototipo de Sistema de Transportación para Ensamblaje en una planta
Automotriz”,” ESCUELA POLITÉCNICA DEL EJÉRCITO, 2008.
[47] F. J. Beltrán Carranza and M. A. López Thomas, “Aplicación de un HMI en un sistema de
contrl de flujo de agua,” Instituto Politécnico Nacional, 2010.
[48] J. J. Grueso Delgado, “Implementación de una interfaz HMI para la operación del módulo
control de procesos del laboratorio de robótica,” Universidad de la Salle, 2008.
[49] F. Adamo, F. Attivissimo, G. Cavone, and N. Giaquinto, “SCADA / HMI Systems in
Advanced Educational Courses,” IEEE, vol. 56, no. Transaction on Instrumentation and
Measurement, pp. 17–19, 2007.
[50] M. Bustamante, G. Moreno, A. Pelaez, and C. Madrigal, “Design and Implementation of
an Automation Didactic Module focused to Machine Vision and Programmable Logic
Control,” IEEE, no. 978–1–4799–7932–5, pp. 1–5, 2014.
[51] S. P. Valencia Aguilar, “Guia Metodológica para diseño de interfaces de usuario para
control y supervisión de procesos industriales,” Universidad Nacional de Colombia, 2012.
[52] P. Montuschi, A. Sanna, F. Lamberti, and G. Paravati, “‘Human-Computer Interaction:
Present and Future Trends,’” Comput. Now, vol. 7, no 9., p. 2, 2014.
[53] E. Ru, J. Lu, I. Mitma, A. Ram, and C. Pinz, “Desarrollo de una interfaz hombre máquina
orientada al control de procesos,” vol. 11, no. 1, pp. 70–72, 2008.
[54] S. F. Yachou, “Aplicación de la guía GEDIS a los Sistemas SCADA del NAP ( Network
Access Point ) de Canarias,” Universidad de La Laguna, 2014.
[55] M. Larrea, S. Martig, and S. Castro, “IHC en Ingeniería : Interfaces Industriales como un
caso de estudio .,” Argentina, 2005.
[56] Usuariowindows, “Cómo evitar que un usuario cambie la contraseña de inicio de sesión en
Windows.” [Online]. Available: http://usuariowindows.com/como-evitar-que-un-usuario-
cambie-la-contrasena-de-inicio-de-sesion-en-windows/. [Accessed: 22-May-2015].
[57] U.S. Nuclear Regulatory Commission Office of Nuclear Regulatory Research, “Human-
System Interface Design Review Guidelines Human-System Interface Design Review
Guidelines,” Washington,DC 20555-0001, 2002.
[58] J. R. Quintero H and H. de J. Cuicas R, “Símbolos Gráficos para el despliegue de procesos

105
 Norma ANSI/ISA -S5.5-1985,” 1996.
[59] “ISA–5.5–1985,” Joel Rodríguez Guillén, 2012. [Online]. Available:
http://es.scribd.com/doc/83566377/ISA-5-5-1985#scribd. [Accessed: 22-May-2015].
[60] Msdn.microsoft, “Visual C#,” 2016. [Online]. Available: https://msdn.microsoft.com/es-
mx/library/kx37x362.aspx. [Accessed: 03-Feb-2016].
[61] A. Corporation, “ATmega8U2 ATmega16U2 ATmega32U2 Datasheet - doc7799.pdf,”
2010. [Online]. Available: http://www.atmel.com/Images/doc7799.pdf. [Accessed: 29-
Feb-2016].
[62] Dynamo electronis, “Motorreductor 12Kg.cm, Vel 200rpm, 12Vdc, relacion 50:1.”
[Online]. Available:
http://www.dynamoelectronics.com/index.php?page=shop.product_details&flypage=dyna
mo.tpl&product_id=1118&category_id=100&option=com_virtuemart&Itemid=58.
[Accessed: 29-Feb-2016].
[63] Pololu Corporation, “Pololu USB AVR Programmer.” [Online]. Available:
https://www.pololu.com/product/1300. [Accessed: 29-Feb-2016].
[64] S. L. Chaparro Cardenas, “Diseño y construcción de un módulo de desarrollo para control
de procesos,” Instituto Politécnico Nacional, 2016.
[65] S. T. Data, “Integrated Silicon Pressure Sensor On-Chip Signal Conditioned ,
Temperature Compensated and Calibrated SERIES,” Time, pp. 1–9, 2001.
[66] SMC®, “Electroválvula proporcional compacta.”
[67] National Instruments, “PID Theory Explained - National Instruments,” mar 29, 2011.
[Online]. Available: http://www.ni.com/white-paper/3782/en/#toc2. [Accessed: 08-Feb-
2016].
[68] G. J. Klir, “Fuzzy logic unearthing its meaning and significance,” IEEE Potentials, vol.
14, no. 4, pp. 10–15, 1995.

106
 ANEXOS

Anexo 1. Algoritmo para micro-controlador de módulo externo

Comunicación.c
#include <stdlib.h>
#include <avr/io.h>
#include <avr/interrupt.h>
#include <avr/pgmspace.h>
#include <avr/delay.h>
#include "serial.h"

/* Define frecuencia de CPU en Hz */

#define F_CPU 8000000

/* Define UART buad rate */

#define UART_BAUD_RATE 9600

#define ICP PINB0

volatile uint16_t revTick; // Pulsos por revolucion
volatile uint16_t revCtr; // Total de revoluciones
char cadenaRX[10];
void setupTimer()
{
TCCR1A = 0; // Modo normal
TCCR1B = 65; // (01000100)
TCCR1C = 0; // Modo normal
TIMSK1 = 33; // (00100001)
TCNT1 = 0; // Limpia bit
}

ISR(TIMER1_CAPT_vect) // Detección de pulso

{
revTick = ICR1; // Guarda duración de última revolución
TCNT1 = 0; // Reinicia timer para la siguiente revolución
revCtr++; // Suma una revolución a la cuenta
}

ISR(TIMER1_OVF_vect) // Contador overflow/timeout

{ revTick = 0; } // RPM = 0

void pwm_init()
{
TCCR2A |= _BV(COM0A1) | _BV(WGM00) | _BV(WGM01);
TCCR2B |= _BV(CS00);
DDRB |= _BV(PB3); // pin B3 como salida de PWM para atmega328p
}

int main(void)
{ pwm_init();
setupTimer();
PORTB|=(1<<ICP); //pullup Habilitado
DDRB&=~(1<<ICP); //ICR1 como entrada

107
 int valor;
char valor1;

int num=134;
char input;
int RPM, RPMP, contador, RPM_Ant;
char buff[20];
char str[8];
int a=0;
char i=0;

uart_init( UART_BAUD_SELECT(UART_BAUD_RATE,F_CPU) );

sei();

while(1)
{
if (uart_available())
{
_delay_ms(4);
valor = uart_getc(); // Inicio de transmisión
_delay_ms(4);
valor1 = uart_getc(); // Dato
if(valor==0x01)
{
OCR2A=valor1; // Valor para PWM
}

if (revTick > 0) // Si el motor está en movimiento

{
RPM = 550000 / revTick;
RPM_Ant=RPM+RPM_Ant;
contador++;
if(contador>50) // Filtra la lectura del encoder
{
RPMP=RPM_Ant/50;
contador=0;
RPM_Ant=0;
}

else if (revTick <= 0) // Si el motor no está en movimiento

{
RPM = 0;
contador=0;
RPM_Ant=0;
RPMP=0;
}

if(valor==0x01)
{
uart_putc( (unsigned char)0x21 ); // Envía inicio de transmisión
uart_putc( (unsigned char)RPMP ); // Envía lectura del encoder
_delay_ms(1); // Estabiliza lectura

108
 }

Serial.c

/*************************************************************************
Title: Interrupt UART library with receive/transmit circular buffers
Author: Peter Fleury <pfleury@gmx.ch> http://jump.to/fleury
File: $Id: uart.c,v 1.6.2.1 2007/07/01 11:14:38 peter Exp $
Software: AVR-GCC 4.1, AVR Libc 1.4.6 or higher
Hardware: any AVR with built-in UART,
License: GNU General Public License

*/

#include <avr/io.h>
#include <avr/interrupt.h>
#include <avr/pgmspace.h>
#include "serial.h"

/*
* constants and macros
*/

/* size of RX/TX buffers */

#define UART_RX_BUFFER_MASK ( UART_RX_BUFFER_SIZE - 1)
#define UART_TX_BUFFER_MASK ( UART_TX_BUFFER_SIZE - 1)

#if ( UART_RX_BUFFER_SIZE & UART_RX_BUFFER_MASK )

#error RX buffer size is not a power of 2
#endif
#if ( UART_TX_BUFFER_SIZE & UART_TX_BUFFER_MASK )
#error TX buffer size is not a power of 2
#endif

#if defined(__AVR_AT90S2313__) || defined(__AVR_AT90S4414__) ||

defined(__AVR_AT90S4434__) || defined(__AVR_AT90S8515__) || defined(__AVR_AT90S8535__)
|| defined(__AVR_ATmega103__)
/* old AVR classic or ATmega103 with one UART */
#define AT90_UART
#define UART0_RECEIVE_INTERRUPT UART_RX_vect
#define UART0_TRANSMIT_INTERRUPT UART_UDRE_vect
#define UART0_STATUS USR
#define UART0_CONTROL UCR
#define UART0_DATA UDR
#define UART0_UDRIE UDRIE
#elif defined(__AVR_AT90S2333__) || defined(__AVR_AT90S4433__)
/* old AVR classic with one UART */
#define AT90_UART
#define UART0_RECEIVE_INTERRUPT UART_RX_vect
#define UART0_TRANSMIT_INTERRUPT UART_UDRE_vect
#define UART0_STATUS UCSRA
#define UART0_CONTROL UCSRB
#define UART0_DATA UDR
#define UART0_UDRIE UDRIE

109
#elif defined(__AVR_ATmega8__) || defined(__AVR_ATmega16__) ||
defined(__AVR_ATmega32__) \
|| defined(__AVR_ATmega323__)
/* ATmega with one USART */
#define ATMEGA_USART
#define UART0_RECEIVE_INTERRUPT USART_RXC_vect
#define UART0_TRANSMIT_INTERRUPT USART_UDRE_vect
#define UART0_STATUS UCSRA
#define UART0_CONTROL UCSRB
#define UART0_DATA UDR
#define UART0_UDRIE UDRIE
#elif defined(__AVR_ATmega8515__) || defined(__AVR_ATmega8535__)
/* ATmega with one USART */
#define ATMEGA_USART
#define UART0_RECEIVE_INTERRUPT USART_RX_vect
#define UART0_TRANSMIT_INTERRUPT USART_UDRE_vect
#define UART0_STATUS UCSRA
#define UART0_CONTROL UCSRB
#define UART0_DATA UDR
#define UART0_UDRIE UDRIE
#elif defined(__AVR_ATmega163__)
/* ATmega163 with one UART */
#define ATMEGA_UART
#define UART0_RECEIVE_INTERRUPT UART_RX_vect
#define UART0_TRANSMIT_INTERRUPT UART_UDRE_vect
#define UART0_STATUS UCSRA
#define UART0_CONTROL UCSRB
#define UART0_DATA UDR
#define UART0_UDRIE UDRIE
#elif defined(__AVR_ATmega162__)
/* ATmega with two USART */
#define ATMEGA_USART0
#define ATMEGA_USART1
#define UART0_RECEIVE_INTERRUPT USART0_RXC_vect
#define UART1_RECEIVE_INTERRUPT USART1_RXC_vect
#define UART0_TRANSMIT_INTERRUPT USART0_UDRE_vect
#define UART1_TRANSMIT_INTERRUPT USART1_UDRE_vect
#define UART0_STATUS UCSR0A
#define UART0_CONTROL UCSR0B
#define UART0_DATA UDR0
#define UART0_UDRIE UDRIE0
#define UART1_STATUS UCSR1A
#define UART1_CONTROL UCSR1B
#define UART1_DATA UDR1
#define UART1_UDRIE UDRIE1
#elif defined(__AVR_ATmega64__) || defined(__AVR_ATmega128__)
/* ATmega with two USART */
#define ATMEGA_USART0
#define ATMEGA_USART1
#define UART0_RECEIVE_INTERRUPT USART0_RX_vect
#define UART1_RECEIVE_INTERRUPT USART1_RX_vect
#define UART0_TRANSMIT_INTERRUPT USART0_UDRE_vect
#define UART1_TRANSMIT_INTERRUPT USART1_UDRE_vect
#define UART0_STATUS UCSR0A
#define UART0_CONTROL UCSR0B
#define UART0_DATA UDR0
#define UART0_UDRIE UDRIE0
#define UART1_STATUS UCSR1A
#define UART1_CONTROL UCSR1B
#define UART1_DATA UDR1

110
 #define UART1_UDRIE UDRIE1
#elif defined(__AVR_ATmega161__)
/* ATmega with UART */
#error "AVR ATmega161 currently not supported by this libaray !"
#elif defined(__AVR_ATmega169__)
/* ATmega with one USART */
#define ATMEGA_USART
#define UART0_RECEIVE_INTERRUPT USART0_RX_vect
#define UART0_TRANSMIT_INTERRUPT USART0_UDRE_vect
#define UART0_STATUS UCSRA
#define UART0_CONTROL UCSRB
#define UART0_DATA UDR
#define UART0_UDRIE UDRIE
#elif defined(__AVR_ATmega48__) ||defined(__AVR_ATmega88__) ||
defined(__AVR_ATmega168__) || \
defined(__AVR_ATmega48P__) ||defined(__AVR_ATmega88P__) ||
defined(__AVR_ATmega168P__) || \
defined(__AVR_ATmega328P__)
/* TLS-Added 48P/88P/168P/328P */
/* ATmega with one USART */
#define ATMEGA_USART0
#define UART0_RECEIVE_INTERRUPT USART_RX_vect
#define UART0_TRANSMIT_INTERRUPT USART_UDRE_vect
#define UART0_STATUS UCSR0A
#define UART0_CONTROL UCSR0B
#define UART0_DATA UDR0
#define UART0_UDRIE UDRIE0
#elif defined(__AVR_ATtiny2313__)
#define ATMEGA_USART
#define UART0_RECEIVE_INTERRUPT USART_RX_vect
#define UART0_TRANSMIT_INTERRUPT USART_UDRE_vect
#define UART0_STATUS UCSRA
#define UART0_CONTROL UCSRB
#define UART0_DATA UDR
#define UART0_UDRIE UDRIE
#elif defined(__AVR_ATmega329__) || defined(__AVR_ATmega649__) ||
defined(__AVR_ATmega325__) ||defined(__AVR_ATmega3250__) ||
defined(__AVR_ATmega645__) ||defined(__AVR_ATmega6450__)
/* ATmega with one USART */
#define ATMEGA_USART0
#define UART0_RECEIVE_INTERRUPT USART0_RX_vect
#define UART0_TRANSMIT_INTERRUPT USART0_UDRE_vect
#define UART0_STATUS UCSR0A
#define UART0_CONTROL UCSR0B
#define UART0_DATA UDR0
#define UART0_UDRIE UDRIE0
#elif defined(__AVR_ATmega3290__) || defined(__AVR_ATmega6490__)
/* TLS-Separated these two from the previous group because of inconsistency in the
USART_RX */
/* ATmega with one USART */
#define ATMEGA_USART0
#define UART0_RECEIVE_INTERRUPT USART_RX_vect
#define UART0_TRANSMIT_INTERRUPT USART0_UDRE_vect
#define UART0_STATUS UCSR0A
#define UART0_CONTROL UCSR0B
#define UART0_DATA UDR0
#define UART0_UDRIE UDRIE0
#elif defined(__AVR_ATmega2560__) || defined(__AVR_ATmega1280__) ||
defined(__AVR_ATmega640__)
/* ATmega with two USART */

111
 #define ATMEGA_USART0
#define ATMEGA_USART1
#define UART0_RECEIVE_INTERRUPT USART0_RX_vect
#define UART1_RECEIVE_INTERRUPT USART0_UDRE_vect
#define UART0_TRANSMIT_INTERRUPT USART1_RX_vect
#define UART1_TRANSMIT_INTERRUPT USART1_UDRE_vect
#define UART0_STATUS UCSR0A
#define UART0_CONTROL UCSR0B
#define UART0_DATA UDR0
#define UART0_UDRIE UDRIE0
#define UART1_STATUS UCSR1A
#define UART1_CONTROL UCSR1B
#define UART1_DATA UDR1
#define UART1_UDRIE UDRIE1
#elif defined(__AVR_ATmega644__)
/* ATmega with one USART */
#define ATMEGA_USART0
#define UART0_RECEIVE_INTERRUPT USART0_RX_vect
#define UART0_TRANSMIT_INTERRUPT USART0_UDRE_vect
#define UART0_STATUS UCSR0A
#define UART0_CONTROL UCSR0B
#define UART0_DATA UDR0
#define UART0_UDRIE UDRIE0
#elif defined(__AVR_ATmega164P__) || defined(__AVR_ATmega324P__) ||
defined(__AVR_ATmega644P__)
/* ATmega with two USART */
#define ATMEGA_USART0
#define ATMEGA_USART1
#define UART0_RECEIVE_INTERRUPT USART0_RX_vect
#define UART1_RECEIVE_INTERRUPT USART0_UDRE_vect
#define UART0_TRANSMIT_INTERRUPT USART1_RX_vect
#define UART1_TRANSMIT_INTERRUPT USART1_UDRE_vect
#define UART0_STATUS UCSR0A
#define UART0_CONTROL UCSR0B
#define UART0_DATA UDR0
#define UART0_UDRIE UDRIE0
#define UART1_STATUS UCSR1A
#define UART1_CONTROL UCSR1B
#define UART1_DATA UDR1
#define UART1_UDRIE UDRIE1
#else
#error "no UART definition for MCU available"
#endif

/*
* module global variables
*/
static volatile unsigned char UART_TxBuf[UART_TX_BUFFER_SIZE];
static volatile unsigned char UART_RxBuf[UART_RX_BUFFER_SIZE];
static volatile unsigned char UART_TxHead;
static volatile unsigned char UART_TxTail;
static volatile unsigned char UART_RxHead;
static volatile unsigned char UART_RxTail;
static volatile unsigned char UART_LastRxError;

#if defined( ATMEGA_USART1 )

static volatile unsigned char UART1_TxBuf[UART_TX_BUFFER_SIZE];
static volatile unsigned char UART1_RxBuf[UART_RX_BUFFER_SIZE];
static volatile unsigned char UART1_TxHead;

112
static volatile unsigned char UART1_TxTail;
static volatile unsigned char UART1_RxHead;
static volatile unsigned char UART1_RxTail;
static volatile unsigned char UART1_LastRxError;
#endif

ISR(UART0_RECEIVE_INTERRUPT)
/*************************************************************************
Function: UART Receive Complete interrupt
Purpose: called when the UART has received a character
**************************************************************************/
{
unsigned char tmphead;
unsigned char data;
unsigned char usr;
unsigned char lastRxError;

/* read UART status register and UART data register */

usr = UART0_STATUS;
data = UART0_DATA;

/* */
#if defined( AT90_UART )
lastRxError = (usr & (_BV(FE)|_BV(DOR)) );
#elif defined( ATMEGA_USART )
lastRxError = (usr & (_BV(FE)|_BV(DOR)) );
#elif defined( ATMEGA_USART0 )
lastRxError = (usr & (_BV(FE0)|_BV(DOR0)) );
#elif defined ( ATMEGA_UART )
lastRxError = (usr & (_BV(FE)|_BV(DOR)) );
#endif

/* calculate buffer index */

tmphead = ( UART_RxHead + 1) & UART_RX_BUFFER_MASK;

if ( tmphead == UART_RxTail ) {
/* error: receive buffer overflow */
lastRxError = UART_BUFFER_OVERFLOW >> 8;
}else{
/* store new index */
UART_RxHead = tmphead;
/* store received data in buffer */
UART_RxBuf[tmphead] = data;
}
UART_LastRxError = lastRxError;
}

ISR(UART0_TRANSMIT_INTERRUPT)
/*************************************************************************
Function: UART Data Register Empty interrupt
Purpose: called when the UART is ready to transmit the next byte
**************************************************************************/
{
unsigned char tmptail;

113
 if ( UART_TxHead != UART_TxTail) {
/* calculate and store new buffer index */
tmptail = (UART_TxTail + 1) & UART_TX_BUFFER_MASK;
UART_TxTail = tmptail;
/* get one byte from buffer and write it to UART */
UART0_DATA = UART_TxBuf[tmptail]; /* start transmission */
}else{
/* tx buffer empty, disable UDRE interrupt */
UART0_CONTROL &= ~_BV(UART0_UDRIE);
}
}

/*************************************************************************
Function: uart_init()
Purpose: initialize UART and set baudrate
Input: baudrate using macro UART_BAUD_SELECT()
Returns: none
**************************************************************************/
void uart_init(unsigned int baudrate)
{
UART_TxHead = 0;
UART_TxTail = 0;
UART_RxHead = 0;
UART_RxTail = 0;

#if defined( AT90_UART )

/* set baud rate */
UBRR = (unsigned char)baudrate;

/* enable UART receiver and transmmitter and receive complete interrupt */

UART0_CONTROL = _BV(RXCIE)|_BV(RXEN)|_BV(TXEN);

#elif defined (ATMEGA_USART)

/* Set baud rate */
if ( baudrate & 0x8000 )
{
UART0_STATUS = (1<<U2X); //Enable 2x speed
baudrate &= ~0x8000;
}
UBRRH = (unsigned char)(baudrate>>8);
UBRRL = (unsigned char) baudrate;

/* Enable USART receiver and transmitter and receive complete interrupt */

UART0_CONTROL = _BV(RXCIE)|(1<<RXEN)|(1<<TXEN);

/* Set frame format: asynchronous, 8data, no parity, 1stop bit */

#ifdef URSEL
UCSRC = (1<<URSEL)|(3<<UCSZ0);
#else
UCSRC = (3<<UCSZ0);
#endif

#elif defined (ATMEGA_USART0 )

/* Set baud rate */
if ( baudrate & 0x8000 )
{
UART0_STATUS = (1<<U2X0); //Enable 2x speed
baudrate &= ~0x8000;
}

114
 UBRR0H = (unsigned char)(baudrate>>8);
UBRR0L = (unsigned char) baudrate;

/* Enable USART receiver and transmitter and receive complete interrupt */

UART0_CONTROL = _BV(RXCIE0)|(1<<RXEN0)|(1<<TXEN0);

/* Set frame format: asynchronous, 8data, no parity, 1stop bit */

#ifdef URSEL0
UCSR0C = (1<<URSEL0)|(3<<UCSZ00);
#else
UCSR0C = (3<<UCSZ00);
#endif

#elif defined ( ATMEGA_UART )

/* set baud rate */
if ( baudrate & 0x8000 )
{
UART0_STATUS = (1<<U2X); //Enable 2x speed
baudrate &= ~0x8000;
}
UBRRHI = (unsigned char)(baudrate>>8);
UBRR = (unsigned char) baudrate;

/* Enable UART receiver and transmitter and receive complete interrupt */

UART0_CONTROL = _BV(RXCIE)|(1<<RXEN)|(1<<TXEN);

#endif

}/* uart_init */

/*************************************************************************
Function: uart_getc()
Purpose: return byte from ringbuffer
Returns: lower byte: received byte from ringbuffer
higher byte: last receive error
**************************************************************************/
unsigned int uart_getc(void)
{
unsigned char tmptail;
unsigned char data;

if ( UART_RxHead == UART_RxTail ) {
return UART_NO_DATA; /* no data available */
}

/* calculate /store buffer index */

tmptail = (UART_RxTail + 1) & UART_RX_BUFFER_MASK;
UART_RxTail = tmptail;

/* get data from receive buffer */

data = UART_RxBuf[tmptail];

return (UART_LastRxError << 8) + data;

}/* uart_getc */

/*************************************************************************

115
Function: uart_putc()
Purpose: write byte to ringbuffer for transmitting via UART
Input: byte to be transmitted
Returns: none
**************************************************************************/
void uart_putc(unsigned char data)
{
unsigned int tmphead;

tmphead = (UART_TxHead + 1) & UART_TX_BUFFER_MASK;

while ( tmphead == UART_TxTail ){

;/* wait for free space in buffer */
}

UART_TxBuf[tmphead] = data;
UART_TxHead = tmphead;

/* enable UDRE interrupt */

UART0_CONTROL |= _BV(UART0_UDRIE);

}/* uart_putc */

/*************************************************************************
Function: uart_puts()
Purpose: transmit string to UART
Input: string to be transmitted
Returns: none
**************************************************************************/
void uart_puts(const char *s )
{
while (*s)
uart_putc(*s++);

}/* uart_puts */

/*************************************************************************
Function: uart_puts_p()
Purpose: transmit string from program memory to UART
Input: program memory string to be transmitted
Returns: none
**************************************************************************/
void uart_puts_p(const char *progmem_s )
{
register char c;

while ( (c = pgm_read_byte(progmem_s++)) )
uart_putc(c);

}/* uart_puts_p */

/*************************************************************************
Function: uart_available()
Purpose: Determine the number of bytes waiting in the receive buffer
Input: None

116
Returns: Integer number of bytes in the receive buffer
**************************************************************************/
int uart_available(void)
{
return (UART_RX_BUFFER_MASK + UART_RxHead - UART_RxTail) %
UART_RX_BUFFER_MASK;
}/* uart_available */

/*************************************************************************
Function: uart_flush()
Purpose: Flush bytes waiting the receive buffer. Acutally ignores them.
Input: None
Returns: None
**************************************************************************/
void uart_flush(void)
{
UART_RxHead = UART_RxTail;
}/* uart_flush */

/*
* these functions are only for ATmegas with two USART
*/
#if defined( ATMEGA_USART1 )

SIGNAL(UART1_RECEIVE_INTERRUPT)
/*************************************************************************
Function: UART1 Receive Complete interrupt
Purpose: called when the UART1 has received a character
**************************************************************************/
{
unsigned char tmphead;
unsigned char data;
unsigned char usr;
unsigned char lastRxError;

/* read UART status register and UART data register */

usr = UART1_STATUS;
data = UART1_DATA;

/* */
lastRxError = (usr & (_BV(FE1)|_BV(DOR1)) );

/* calculate buffer index */

tmphead = ( UART1_RxHead + 1) & UART_RX_BUFFER_MASK;

if ( tmphead == UART1_RxTail ) {
/* error: receive buffer overflow */
lastRxError = UART_BUFFER_OVERFLOW >> 8;
}else{
/* store new index */
UART1_RxHead = tmphead;
/* store received data in buffer */
UART1_RxBuf[tmphead] = data;
}
UART1_LastRxError = lastRxError;
}

117
SIGNAL(UART1_TRANSMIT_INTERRUPT)
/*************************************************************************
Function: UART1 Data Register Empty interrupt
Purpose: called when the UART1 is ready to transmit the next byte
**************************************************************************/
{
unsigned char tmptail;

if ( UART1_TxHead != UART1_TxTail) {
/* calculate and store new buffer index */
tmptail = (UART1_TxTail + 1) & UART_TX_BUFFER_MASK;
UART1_TxTail = tmptail;
/* get one byte from buffer and write it to UART */
UART1_DATA = UART1_TxBuf[tmptail]; /* start transmission */
}else{
/* tx buffer empty, disable UDRE interrupt */
UART1_CONTROL &= ~_BV(UART1_UDRIE);
}
}

/*************************************************************************
Function: uart1_init()
Purpose: initialize UART1 and set baudrate
Input: baudrate using macro UART_BAUD_SELECT()
Returns: none
**************************************************************************/
void uart1_init(unsigned int baudrate)
{
UART1_TxHead = 0;
UART1_TxTail = 0;
UART1_RxHead = 0;
UART1_RxTail = 0;

/* Set baud rate */

if ( baudrate & 0x8000 )
{
UART1_STATUS = (1<<U2X1); //Enable 2x speed
baudrate &= ~0x8000;
}
UBRR1H = (unsigned char)(baudrate>>8);
UBRR1L = (unsigned char) baudrate;

/* Enable USART receiver and transmitter and receive complete interrupt */

UART1_CONTROL = _BV(RXCIE1)|(1<<RXEN1)|(1<<TXEN1);

/* Set frame format: asynchronous, 8data, no parity, 1stop bit */

#ifdef URSEL1
UCSR1C = (1<<URSEL1)|(3<<UCSZ10);
#else
UCSR1C = (3<<UCSZ10);
#endif
}/* uart_init */

/*************************************************************************

118
Function: uart1_getc()
Purpose: return byte from ringbuffer
Returns: lower byte: received byte from ringbuffer
higher byte: last receive error
**************************************************************************/
unsigned int uart1_getc(void)
{
unsigned char tmptail;
unsigned char data;

if ( UART1_RxHead == UART1_RxTail ) {
return UART_NO_DATA; /* no data available */
}

/* calculate /store buffer index */

tmptail = (UART1_RxTail + 1) & UART_RX_BUFFER_MASK;
UART1_RxTail = tmptail;

/* get data from receive buffer */

data = UART1_RxBuf[tmptail];

return (UART1_LastRxError << 8) + data;

}/* uart1_getc */

/*************************************************************************
Function: uart1_putc()
Purpose: write byte to ringbuffer for transmitting via UART
Input: byte to be transmitted
Returns: none
**************************************************************************/
void uart1_putc(unsigned char data)
{
unsigned char tmphead;

tmphead = (UART1_TxHead + 1) & UART_TX_BUFFER_MASK;

while ( tmphead == UART1_TxTail ){

;/* wait for free space in buffer */
}

UART1_TxBuf[tmphead] = data;
UART1_TxHead = tmphead;

/* enable UDRE interrupt */

UART1_CONTROL |= _BV(UART1_UDRIE);

}/* uart1_putc */

/*************************************************************************
Function: uart1_puts()
Purpose: transmit string to UART1
Input: string to be transmitted
Returns: none
**************************************************************************/
void uart1_puts(const char *s )

119
{
while (*s)
uart1_putc(*s++);

}/* uart1_puts */

/*************************************************************************
Function: uart1_puts_p()
Purpose: transmit string from program memory to UART1
Input: program memory string to be transmitted
Returns: none
**************************************************************************/
void uart1_puts_p(const char *progmem_s )
{
register char c;

while ( (c = pgm_read_byte(progmem_s++)) )
uart1_putc(c);

}/* uart1_puts_p */

/*************************************************************************
Function: uart1_available()
Purpose: Determine the number of bytes waiting in the receive buffer
Input: None
Returns: Integer number of bytes in the receive buffer
**************************************************************************/
int uart1_available(void)
{
return (UART_RX_BUFFER_MASK + UART1_RxHead - UART1_RxTail) %
UART_RX_BUFFER_MASK;
}/* uart1_available */

/*************************************************************************
Function: uart1_flush()
Purpose: Flush bytes waiting the receive buffer. Acutally ignores them.
Input: None
Returns: None
**************************************************************************/
void uart1_flush(void)
{
UART1_RxHead = UART1_RxTail;
}/* uart1_flush */

#endif

Serial.h

#ifndef UART_H
#define UART_H
/************************************************************************
Title: Interrupt UART library with receive/transmit circular buffers

120
Author: Peter Fleury <pfleury@gmx.ch> http://jump.to/fleury
File: $Id: uart.h,v 1.8.2.1 2007/07/01 11:14:38 peter Exp $
Software: AVR-GCC 4.1, AVR Libc 1.4
Hardware: any AVR with built-in UART, tested on AT90S8515 & ATmega8 at 4 Mhz
License: GNU General Public License
Usage: see Doxygen manual

/**@{*/

#if (__GNUC__ * 100 + __GNUC_MINOR__) < 304

#error "This library requires AVR-GCC 3.4 or later, update to newer AVR-GCC compiler
!"
#endif

/*
** constants and macros
*/

/** @brief UART Baudrate Expression

* @param xtalcpu system clock in Mhz, e.g. 4000000L for 4Mhz
* @param baudrate baudrate in bps, e.g. 1200, 2400, 9600
*/
#define UART_BAUD_SELECT(baudRate,xtalCpu) ((xtalCpu)/((baudRate)*16l)-1)

/** @brief UART Baudrate Expression for ATmega double speed mode
* @param xtalcpu system clock in Mhz, e.g. 4000000L for 4Mhz
* @param baudrate baudrate in bps, e.g. 1200, 2400, 9600
*/
#define UART_BAUD_SELECT_DOUBLE_SPEED(baudRate,xtalCpu) (((xtalCpu)/((baudRate)*8l)-
1)|0x8000)

/** Size of the circular receive buffer, must be power of 2 */

#ifndef UART_RX_BUFFER_SIZE
#define UART_RX_BUFFER_SIZE 32
#endif
/** Size of the circular transmit buffer, must be power of 2 */
#ifndef UART_TX_BUFFER_SIZE
#define UART_TX_BUFFER_SIZE 32
#endif

/* test if the size of the circular buffers fits into SRAM */

#if ( (UART_RX_BUFFER_SIZE+UART_TX_BUFFER_SIZE) >= (RAMEND-0x60 ) )
#error "size of UART_RX_BUFFER_SIZE + UART_TX_BUFFER_SIZE larger than size of SRAM"
#endif

/*
** high byte error return code of uart_getc()
*/
#define UART_FRAME_ERROR 0x0800 /* Framing Error by UART */
#define UART_OVERRUN_ERROR 0x0400 /* Overrun condition by UART */
#define UART_BUFFER_OVERFLOW 0x0200 /* receive ringbuffer overflow */
#define UART_NO_DATA 0x0100 /* no receive data available */

/*
** function prototypes

121
*/

/**
@brief Initialize UART and set baudrate
@param baudrate Specify baudrate using macro UART_BAUD_SELECT()
@return none
*/
extern void uart_init(unsigned int baudrate);

/**
* @brief Get received byte from ringbuffer
*
* Returns in the lower byte the received character and in the
* higher byte the last receive error.
* UART_NO_DATA is returned when no data is available.
*
* @param void
* @return lower byte: received byte from ringbuffer
* @return higher byte: last receive status
* - \b 0 successfully received data from UART
* - \b UART_NO_DATA
* <br>no receive data available
* - \b UART_BUFFER_OVERFLOW
* <br>Receive ringbuffer overflow.
* We are not reading the receive buffer fast enough,
* one or more received character have been dropped
* - \b UART_OVERRUN_ERROR
* <br>Overrun condition by UART.
* A character already present in the UART UDR register was
* not read by the interrupt handler before the next character arrived,
* one or more received characters have been dropped.
* - \b UART_FRAME_ERROR
* <br>Framing Error by UART
*/
extern unsigned int uart_getc(void);

/**
* @brief Put byte to ringbuffer for transmitting via UART
* @param data byte to be transmitted
* @return none
*/
extern void uart_putc(unsigned char data);

/**
* @brief Put string to ringbuffer for transmitting via UART
*
* The string is buffered by the uart library in a circular buffer
* and one character at a time is transmitted to the UART using interrupts.
* Blocks if it can not write the whole string into the circular buffer.
*
* @param s string to be transmitted
* @return none
*/
extern void uart_puts(const char *s );

/**

122
 * @brief Put string from program memory to ringbuffer for transmitting via UART.
*
* The string is buffered by the uart library in a circular buffer
* and one character at a time is transmitted to the UART using interrupts.
* Blocks if it can not write the whole string into the circular buffer.
*
* @param s program memory string to be transmitted
* @return none
* @see uart_puts_P
*/
extern void uart_puts_p(const char *s );

/**
* @brief Macro to automatically put a string constant into program memory
*/
#define uart_puts_P(__s) uart_puts_p(PSTR(__s))

/**
* @brief Return number of bytes waiting in the receive buffer
* @param none
* @return bytes waiting in the receive buffer
*/
extern int uart_available(void);

/**
* @brief Flush bytes waiting in receive buffer
* @param none
* @return none
*/
extern void uart_flush(void);

/** @brief Initialize USART1 (only available on selected ATmegas) @see uart_init */
extern void uart1_init(unsigned int baudrate);
/** @brief Get received byte of USART1 from ringbuffer. (only available on selected
ATmega) @see uart_getc */
extern unsigned int uart1_getc(void);
/** @brief Put byte to ringbuffer for transmitting via USART1 (only available on
selected ATmega) @see uart_putc */
extern void uart1_putc(unsigned char data);
/** @brief Put string to ringbuffer for transmitting via USART1 (only available on
selected ATmega) @see uart_puts */
extern void uart1_puts(const char *s );
/** @brief Put string from program memory to ringbuffer for transmitting via USART1
(only available on selected ATmega) @see uart_puts_p */
extern void uart1_puts_p(const char *s );
/** @brief Macro to automatically put a string constant into program memory */
#define uart1_puts_P(__s) uart1_puts_p(PSTR(__s))
/** @brief Return number of bytes waiting in the receive buffer */
extern int uart1_available(void);
/** @brief Flush bytes waiting in receive buffer */
extern void uart1_flush(void);

/**@}*/

#endif // UART_H

123