Automat As

Descargar como pdf o txt
Descargar como pdf o txt
Está en la página 1de 144

INSTITUTO TECNOLÓGICO Y DE ESTUDIOS

SUPERIORES DE MONTERREY

CAMPUS MONTERREY

PROGRAMA DE GRADUACIÓN EN MECATRÓNICA Y


TECNOLOGIAS DE INFORMACIÓN

SÍNTESIS E IMPLEMENTACIÓN DE SUPERVISORES DISCRETOS,


EN EL MARCO DE RAMADGE-WONHAM, EN UNA APLICACIÓN
INDUSTRIAL Y EN TEORÍA DE JUEGOS

TESIS

TESIS PRESENTADA COMO CUMPLIMIENTO PARCIAL DE LOS REQUISITOS


PARA OBTENER EL TÍTULO DE:

MASESTRÍA EN CIENCIAS DE LA AUTOMATIZACIÓN

POR:

JOSÉ ERNESTO PÉREZ ROBLES

MONTERREY, N.L. Mayo, 2010


INSTITUTO TECNOLÓGICO Y DE ESTUDIOS
SUPERIORES DE MONTERREY
CAMPUS MONTERREY

PROGRAMA DE GRADUADOS EN MECATRÓNICA Y


TECNOLOGÍAS DE INFORMACIÓN

Los miembros del comité de Tesis recomendamos que el presente proyecto de


tesis del Ing. José Ernesto Pérez Robles, sea aceptado como requisito parcial
para obtener el grado académico de:

M A E S T R O E N CIENCIAS C O N
ESPECIALIDAD E N AUTOMATIZACIÓN

Comité de tesis:
SÍNTESIS E IMPLEMENTACIÓN DE SUPERVISORES DISCRETOS,
EN EL MARCO DE RAMADGE-WONHAM, EN UNA APLICACIÓN
INDUSTRIAL Y EN TEORÍA DE JUEGOS

POR:
JOSÉ ERNESTO PÉREZ ROBLES

TESIS

Presentada al Programa de Graduados en Mecatrónica y Tecnologías de


Información

Este trabajo es requisito para obtener el grado de:


Maestro en Ciencias con Especialidad en Automatización

INSTITUTO TECNOLÓGICO Y DE ESTUDIOS


SUPERIORES DE MONTERREY
CAMPUS MONTERREY

MAYO 2010
Agradecimientos

A Dios

Por darme la oportunidad de vivir, llegar hasta aquí y por iluminarme en los
momentos difíciles de mi vida.

A mis padres

José Luis y Celia, por el inmenso amor que me tienen y todo el apoyo
incondicional que me han dado, porque gracias a ustedes he podido lograr una
meta más en mi vida. Gracias a ti reinita por todas tus oraciones y consejos y a ti
papi por confiar en mí y motivarme a lograr metas altas. Los amo mucho, son el
regalo más grande que Dios me dio.

A mi hermana

Gaby, por empujarme siempre hacia arriba, mi Pinka espero que te guste esta
nueva meta que alcanzamos y que sigas orgullosa de tu hermano así como el está
orgulloso de ti, te quiero muchísimo.

A mi demás familia

Tías, tíos, abuelitas y demás familiares, por su apoyo incondicional sin el cual no
hubiera sido posible está nueva meta los quiero muchísimo.

A mis amigos y amigas

Por aligerarme la carga que nos toca soportar cada día y ayudarme cuando los
necesité, gracias por estar siempre ahí.

i
Al Departamento de Mecatrónica y al Departamento de Ingeniería Industrial

Por apoyarme para culminar mis estudios de posgrado y mi tesis.

Al Dr. Francisco Palomera, a la M.C. Aline Drivet y al M.C. Luis Carlos Félix

Por aceptar formar parte de mi comité de tesis y contribuir para la culminación de


la misma.

ii
Resumen

En la actualidad la automatización de un sistema de manufactura es uno de los


aspectos más importantes a considerar durante el diseño del proceso de
fabricación de algún producto, y dentro de este aspecto es importante que dicha
automatización se haga de manera eficiente, robusta y segura. Por tal motivo en
ésta tesis se propone un diseño de supervisores discretos, basados en el marco
de Ramadge-Wonham, enfocados en brindar flexibilidad y robustez a los procesos
de manufactura automatizados, dichos supervisores serán sintetizados utilizado
diferentes modalidades como lo son: supervisores modulares, locales modulares y
monolíticos; para evaluar su desempeño y seleccionar el supervisor adecuado.

Durante el desarrollo de esta tesis se tratan de manera básica ejemplos didácticos


de sistemas de eventos discretos que se controlan mediante supervisores
sintetizados aplicando la teoría de control supervisorio. Una vez desarrollados los
ejemplos básicos, se presenta el diseño completo de supervisores enfocados en
lograr la robustez en un sistema automatizado de manufactura real y se muestra
paso a paso como se lleva a cabo la implementación de los mismos, de esta
manera se pretende disminuir el espacio existente entre la industria y la academia.
Además se presentará la solución del famoso rompecabezas “Cruzar el Río”.

iii
Contenido

CAPÍTULO 1. INTRODUCCIÓN ................................................................................................ 1


1.1 Antecedentes .................................................................................................................... 1
1.2 Motivación .......................................................................................................................... 3
1.3 Objetivos ............................................................................................................................ 3
1.4 Alcance............................................................................................................................... 4
1.5 Estructura de la Tesis ...................................................................................................... 5
CAPÍTULO 2. REVISIÓN DE LA LITERATURA ...................................................................... 6
2.1 Sistemas de Eventos Discretos (SED). .............................................................................. 6
2.2 Lenguajes de los autómatas .............................................................................................. 14
2.3 Autómatas ............................................................................................................................. 17
2.4 Control Supervisorio ............................................................................................................ 28
CAPÍTULO 3. EJEMPLOS BÁSICOS DE AUTÓMATAS Y CONTROL SUPERVISORIO
MEDIANTE TCT, SUPREMICA Y GRAFCET (IMPLEMENTACIÓN). ............................... 45
3.1 Ejercicios de Control Supervisorio Mediante TCT (Toy Control Theory) .................... 45
3.2 Ejercicios de Control Supervisorio Mediante Supremica............................................... 59
3.3 GRAFCET e implementación de supervisores discretos en un PLC .......................... 67
CAPÍTULO 4. SÍNTESIS DE SUPERVISORES Y SU IMPLEMENTACIÓN .................... 78
4.1 Solución del problema basado en un proceso real ........................................................ 78
4.2 Solución del rompecabezas “Cruzar el Rio” .................................................................. 100
CAPÍTULO 5. CONCLUSIONES Y TRABAJOS FUTUROS ............................................. 114
5.1 Conclusión en base a los resultados obtenidos en la solución del problema de tipo
industrial..................................................................................................................................... 114
5.2 Conclusión en base a la solución del rompecabezas de cruzar el río ...................... 115
5.3 Trabajos Futuros ................................................................................................................ 116
Bibliografía ................................................................................................................................. 117
ANEXOS .................................................................................................................................... 120
GUÍA RÁPIDA PARA EL USO DE SUPREMICA ................................................................ 120
GUÍA RÁPIDA PARA LA GENERACIÓN DE IMÁGENES DE AUTÓMATAS MEDIANTE
GRAPHIZ ................................................................................................................................... 129
LISTA DE ENTREGABLES .................................................................................................... 133

iv
Lista de Figuras por Capítulo
Capítulo 2
Figura 2. 1 Raíces de los sistemas de eventos discretos (SED). ............................................. 7
Figura 2. 2 Trayectoria de un SED a través del tiempo. .......................................................... 12
Figura 2. 3 Diagrama de transición de estados del autómata del ejemplo. .......................... 18
Figura 2. 4 Autómata con bloqueos: El estado 5 es un “deadlock” y los estados 3 y 4 están
envueltos en un “livelock”, cabe mencionar que el estado 2 representa un estado
marcado. .......................................................................................................................................... 22
Figura 2. 5 (a) CoAC(G) y (b)Trim(G) ......................................................................................... 24
Figura 2. 6 Operación producto y operación de composición paralela.................................. 25
Figura 2. 7 (a) representa G1 y (b) a G2. ................................................................................... 26
Figura 2. 8 Producto de G1 y G2 (MEET en el TCT)................................................................ 26
Figura 2. 9 Composición paralela de G1 y G2 (SYNC en el TCT). ........................................ 27
Figura 2. 10 Lazo de retroalimentación del control supervisorio. ........................................... 30
Figura 2. 11 Autómata de dos estados que forza la alternancia de eventos a y b. ............. 35
Figura 2. 12 Control modular con dos supervisores ................................................................. 42

Capítulo 3
Figura 3. 1 Modelo de la máquina 1. ........................................................................................... 46
Figura 3. 2 Pantalla de inicio del TCT ......................................................................................... 46
Figura 3. 3 Menú principal del TCT ............................................................................................. 47
Figura 3. 4 Menú de procedimientos TCT. ................................................................................. 47
Figura 3. 5 Primer paso en la creación de un autómata con TCT. ......................................... 48
Figura 3. 6 Pantalla de establecimiento del nombre del autómata. ....................................... 48
Figura 3. 7 Pantalla para seleccionar el número de estados del autómata. ......................... 49
Figura 3. 8 Pantalla para ingresar los estados marcados del autómata. .............................. 49
Figura 3. 9 Pantalla para ingresar los estados vocales ............................................................ 50
Figura 3. 10 Pantalla para ingresar la función f o lista de transiciones. ................................ 50
Figura 3. 11 Ejemplo de donde se presentan las transiciones declaradas para el autómata
maquina1. ........................................................................................................................................ 51
Figura 3. 12 Pantalla final de la creación del autómata que verifica si es o no
determinístico. ................................................................................................................................. 51
Figura 3. 13 Autómata generado de la máquina 1. ................................................................... 52
Figura 3. 14 Modelo del autómata máquina 2. .......................................................................... 52
Figura 3. 15 Autómata de la máquina 2. ..................................................................................... 52
Figura 3. 16 Sincronizando “MAQUINA1” Y “MAQUINA2”. ..................................................... 53
Figura 3. 17 Mostrando mediante TCT el autómata MAQUINA12. ........................................ 54
Figura 3. 18 Panta a controlar (sincronización de MAQUINA1 con MAQUINA2). ............... 54

v
Figura 3. 19 Especificación preliminar. ....................................................................................... 55
Figura 3. 20 Autómata All. ............................................................................................................. 56
Figura 3. 21 Autómata “Especificación Final”. ........................................................................... 56
Figura 3. 22 Autómata del controlador: “SUPERVISOR”. ........................................................ 57
Figura 3. 23 Planta bajo control ................................................................................................... 57
Figura 3. 24 Generando los datos de control del sistema. ...................................................... 58
Figura 3. 25 Datos de control generados mediante la opción CONDAT. .............................. 58
Figura 3. 26 Autómatas de la maquina 1, maquina 2 y el robot. ............................................ 60
Figura 3. 27. Estadísticas de la planta creada ........................................................................... 61
Figura 3. 28 Planta generada mediante las dos máquinas y el robot. ................................... 62
Figura 3. 29 Especificación 1 para el supervisor 1. .................................................................. 63
Figura 3. 30 Supervisor de la especificación 1. ......................................................................... 64
Figura 3. 31 Supervisor de la especificación 2. ......................................................................... 65
Figura 3. 32 Supervisor general. .................................................................................................. 66
Figura 3. 33 Equipo neumático simulado en Automation Studio. ........................................... 71
Figura 3. 34 Modelos de las máquinas ....................................................................................... 72
Figura 3. 35 Todos los posibles estados que genera la planta sin control. .......................... 72
Figura 3. 36 Especificación para controlar los cilindros neumáticos ...................................... 73
Figura 3. 37 Planta bajo la acción del supervisor ...................................................................... 73
Figura 3. 38 GRAFCETS de las máquinas en AS. ................................................................... 74
Figura 3. 39 Especificación implementada ................................................................................. 75
Figura 3. 40 Planta con la acción de control implementada. ................................................... 76
Figura 3. 41 Funcionamiento de la planta bajo control. ........................................................... 77

Capítulo 4
Figura 4. 1 Autómata de la máquina. .......................................................................................... 82
Figura 4. 2 Especificación del robot ............................................................................................ 83
Figura 4. 3 Especificación del robot para la planta de tres máquinas. .................................. 85
Figura 4. 4 Autómatas de las tres máquinas que forman la planta. ....................................... 85
Figura 4. 5 Validación de la controlabilidad del sistema mediante Supremica..................... 86
Figura 4. 6 Validación del no bloqueo del sistema mediante Supremica. ............................. 86
Figura 4. 7 Validación de la total inclusión del lenguaje del sistema mediante Supremica.
........................................................................................................................................................... 86
Figura 4. 8 Estadísticas de control mediante Supremica. ........................................................ 87
Figura 4. 9 PLC a programar. ....................................................................................................... 90
Figura 4. 10 Estación de control lógico del ITESM. .................................................................. 91
Figura 4. 11 Conexiones de las entradas al PLC. ..................................................................... 94
Figura 4. 12 Conexiones de las salidas del PLC....................................................................... 94
Figura 4. 13 Conexiones de las salidas del PLC....................................................................... 95
Figura 4. 14 Segunda parte de la etapa preliminar ................................................................... 95

vi
Figura 4. 15 Implementación de las tres máquinas en el PLC ................................................ 96
Figura 4. 16 Especificación del robot, primera parte. ............................................................... 97
Figura 4. 17 Supervisor Segunda parte ...................................................................................... 97
Figura 4. 18 Acciones de la máquina 1 ....................................................................................... 98
Figura 4. 19 Robot en reposo ....................................................................................................... 98
Figura 4. 20 Acción del robot al atender la máquina 1. ............................................................ 99
Figura 4. 21 Personas que necesitan cruzar el río. ................................................................ 101
Figura 4. 22 Autómata que representa al hijo 1. ..................................................................... 104
Figura 4. 23 Autómata que representa al padre. ..................................................................... 104
Figura 4. 24 Autómata que representa al ladrón. .................................................................... 105
Figura 4. 25 Autómata que representa la balsa. ..................................................................... 105
Figura 4. 26 Especificación 1...................................................................................................... 107
Figura 4. 27 Especificación 2. .................................................................................................... 107
Figura 4. 28 Especificación 3. .................................................................................................... 107
Figura 4. 29 Especificación general. ......................................................................................... 108
Figura 4. 30 Resultados del sistema con el supervisor monolítico. ..................................... 109
Figura 4. 31 Especificación óptima. ........................................................................................... 112
Figura 4. 32 Supervisor óptimo .................................................................................................. 113

Lista de tablas
Tabla 1 Estados y eventos con su interpretación...................................................................... 60
Tabla 2 Elementos de programación en GRAFCET. ................................................................ 70
Tabla 3 Eventos y su interpretación de acuerdo al sistema. ................................................... 87
Tabla 4 Conexiones asignadas .................................................................................................... 93
Tabla 5 Alfabeto del problema de cruzar el rio ........................................................................ 103
Tabla 6 Resultados de los supervisores ................................................................................... 108

vii
Figura 4. 15 Implementación de las tres máquinas en el PLC ................................................ 96
Figura 4. 16 Especificación del robot, primera parte. ............................................................... 97
Figura 4. 17 Supervisor Segunda parte ...................................................................................... 97
Figura 4. 18 Acciones de la máquina 1 ....................................................................................... 98
Figura 4. 19 Robot en reposo ....................................................................................................... 98
Figura 4. 20 Acción del robot al atender la máquina 1. ............................................................ 99
Figura 4. 21 Personas que necesitan cruzar el río. ................................................................ 101
Figura 4. 22 Autómata que representa al hijo 1. ..................................................................... 104
Figura 4. 23 Autómata que representa al padre. ..................................................................... 104
Figura 4. 24 Autómata que representa al ladrón. .................................................................... 105
Figura 4. 25 Autómata que representa la balsa. ..................................................................... 105
Figura 4. 26 Especificación 1...................................................................................................... 107
Figura 4. 27 Especificación 2. .................................................................................................... 107
Figura 4. 28 Especificación 3. .................................................................................................... 107
Figura 4. 29 Especificación general. ......................................................................................... 108
Figura 4. 30 Resultados del sistema con el supervisor monolítico. ..................................... 109
Figura 4. 31 Especificación óptima. ........................................................................................... 112
Figura 4. 32 Supervisor óptimo .................................................................................................. 113

Lista de tablas
Tabla 1 Estados y eventos con su interpretación...................................................................... 60
Tabla 2 Elementos de programación en GRAFCET. ................................................................ 70
Tabla 3 Eventos y su interpretación de acuerdo al sistema. ................................................... 87
Tabla 4 Conexiones asignadas .................................................................................................... 93
Tabla 5 Alfabeto del problema de cruzar el rio ........................................................................ 103
Tabla 6 Resultados de los supervisores ................................................................................... 108

vii
CAPÍTULO 1. INTRODUCCIÓN

1.1 Antecedentes

Durante las últimas décadas, la rápida evolución de la tecnología ha producido


una proliferación de nuevos sistemas dinámicos, hechos por el hombre y
generalmente de gran complejidad. Ejemplos de ellos son las redes de
computadoras, sistemas de producción automatizados, de control de tráfico aéreo;
y sistemas en general de control, de comunicaciones y de información. Este tipo
de sistemas pertenecen a una amplia clase denominada: “Sistemas de eventos
discretos” (SED). Todas las actividades en estos sistemas se deben a la
ocurrencia asincrónica de eventos discretos, algunos controlados (tales como el
pulsado de una tecla) y otros no (como la falla espontánea de un equipo). En este
tipo de sistemas, a diferencia de los continuos, el estado y el tiempo son
discretizados a valores específicos. Además, el estado cambia instantáneamente
en respuesta a la ocurrencia de eventos controlados o no controlados como se
ejemplificó anteriormente. Debido a que los SED aparecen en varias actividades
del ser humano, se han convertido en un importante campo de investigación [3].

Ya sea que se trate de una empresa dedicada a la manufactura o una empresa


basada en el servicio, la clave para mantenerse en la cúspide de la competencia
mundial es satisfacer las necesidades cambiantes de los clientes. Los sistemas
flexibles de manufactura (SFM) combinan el sofisticado equipo de manufactura
con la informática avanzada para impartir flexibilidad a las operaciones de
manufactura. De esta manera cumplen los requisitos variantes de los clientes.
Estos consisten en varios tipos de máquinas, computadoras, robots y vehículos
guiados automáticamente, diseñados para producir gran cantidad de productos. Si
bien, los SFM ofrecen una ventaja vanguardista a la empresa manufacturera a
través de su flexibilidad, estos sistemas presentan un problema complejo en su
planeación, diseño, programación, control y monitoreo. Esto es principalmente por
la naturaleza inherente de los SFM que son sistemas asincrónicos concurrentes.
CAPÍTULO 1. INTRODUCCIÓN José Ernesto Pérez Robles

Las herramientas de modelación a menudo ayudan a resolver los problemas


mencionados. Es por esta razón que el hombre ha desarrollado diversas técnicas
o herramientas para modelar los SED con el fin de facilitar su comprensión,
análisis y control. Existen importantes herramientas para modelar SED, siendo las
más populares los autómatas finitos (AF) y las redes de Petri. Los AF describen a
los sistemas como grafos, donde cada estado de interés del sistema es
representado por un nodo, los eventos a su vez son representados por arcos que
van de un estado a otro. Este tipo de modelado provee una descripción clara de
sistemas pequeños; sin embargo para sistemas más complejos, el número de
estados en el modelo se incrementa exponencialmente haciendo sumamente
complicados el análisis y la interpretación de los resultados. Aunque los AF
posean la desventaja anteriormente señalada, en esta tesis se mostrará que
modelando eficientemente los autómatas que representarán el sistema y haciendo
uso de la modularidad y otras herramientas que nos ayudan a disminuir la
complejidad del mismo, es posible resolver problemas que de lo contrario serían
intratables. Además se utilizarán algunos paquetes computacionales para realizar
la modelación y simulación del sistema trabajando bajo la supervisión de los
diferentes controladores.

Algunos de los lenguajes de programación de Controladores Lógicos


Programables (PLCs) que se usan en aplicaciones industriales para la elaboración
de programas de control de eventos discretos son: la lista de instrucciones, los
bloques funcionales, el diagrama de escalera y el GRAFCET/SFC. El diagrama de
escalera ha sido el lenguaje tradicional en la elaboración de los diagramas de
control, debido a su origen histórico como reemplazo al diagrama eléctrico de
escalera y a que cualquier PLC incluye por lo menos, al diagrama de escalera
como su lenguaje básico de programación. Sin embargo el GRAFCET/SFC es una
de las nuevas herramientas poderosas incluidas en algunos PLCs para la
programación de mediana y alta complejidad, la cual día a día va ganando más
adeptos.

Debido a que el PLC proporcionado por el Instituto Tecnológico y de Estudios


Superiores de Monterrey (ITESM), Campus Monterrey, cuenta con ésta nueva

2
CAPÍTULO 1. INTRODUCCIÓN José Ernesto Pérez Robles

herramienta de programación (GRAFCET). Una vez correctamente modelado el


sistema de manufactura real, utilizando GRAFCET se implementarán en el PLC
los modelos obtenidos para probar de una manera más tangible el buen
desempeño de los autómatas al interactuar con el hardware de la estación de
control lógico industrial del instituto.

1.2 Motivación

La principal motivación de esta tesis es poder brindar a los lectores herramientas


que ayuden a explorar de una mejor manera el control lógico, aprovechando la
teoría de control supervisorio (TCS) en el marco de Ramadge-Wonham,
proponiendo incrementar la robustez en un sentido parecido al presentado en [2]
en dónde se mantiene el control del sistema tomando en cuanto los diferentes
conjuntos de comportamientos que éste puede tener sin conocer precisamente el
comportamiento actual. Además, de hacer uso de la modularidad y la modularidad
local presentada en [4] con su mesa giratoria, y sobre todo mejorar la eficiencia,
que es el motivo principal de los trabajos presentados de [5] al [8] entre otros.

La diferencia que presenta este trabajo en comparación al los trabajos referidos


anteriormente, es principalmente el uso de redes de memoria para incrementar la
robustez de un sistema, haciendo uso de la modularidad local para mantener el
sistema en una complejidad tratable, sencilla de visualizar y fácilmente
implementable.

1.3 Objetivos

El objetivo de esta tesis es presentar de una manera sencilla y práctica en qué


consiste la teoría de SED y como es que se aplica dentro de la TCS [1], para esto
se utilizarán algunas de las herramientas formales para la modelación (disponibles

3
CAPÍTULO 1. INTRODUCCIÓN José Ernesto Pérez Robles

gratuitamente para el usuario) e implementación de SED y TCS que existen


actualmente.

De manera puntual los objetivos de esta tesis son:

1. Mostrar la aplicación de los SED y la TCS mediante nuevos ejemplos que


faciliten su comprensión.
2. Aplicar conceptos de la TCS e implementar nuevas soluciones a problemas
industriales de hoy en día y a algunos otros problemas, como lo son los
rompecabezas.
3. Documentar la modelación de SED y TCS mediante herramientas
computacionales formales para el análisis, síntesis y validación de
supervisores, que además se encuentren disponibles y de libre acceso.
4. Implementación con GRAFCET la solución basada en el uso de la TCS y
facilitar su aplicación, buscando de esta manera disminuir la brecha entre
dicha teoría y su implementación.

1.4 Alcance

Se presentará de manera clara y completa la solución a un problema de robustez


de un sistema flexible de manufactura, basado en una aplicación real, mediante su
modelación en SED y la aplicación de la TCS. Dicho sistema se simulará en una
estación de control lógico industrial del Departamento de Mecatrónica del
Tecnológico de Monterrey. En ella se probará el diseño de supervisores discretos
encargados del control de los cilindros electro-neumáticos. Además, como parte
complementaria se presentará la solución obtenida mediante SED y la TCS al
famoso problema de “cruzar el río”, introduciendo con esta parte un nuevo
concepto de supervisor óptimo.

Las soluciones de ambos problemas se incluyen de manera completa en este


documento. Pero además, se incluirán en un disco compacto (CD), los archivos de
los programas generados en GRAFCET para el PLC, las modelaciones en

4
CAPÍTULO 1. INTRODUCCIÓN José Ernesto Pérez Robles

Supremica y sobre todo los videos que muestren el correcto desempeño de las
soluciones propuestas.

1.5 Estructura de la Tesis

Esta tesis está organizada de la siguiente manera:

 Capítulo 1: Introducción. Presenta el marco teórico de la tesis, la


motivación, los objetivos y el alcance de la misma.
 Capítulo 2: Revisión de la literatura. Presenta los fundamentos de la teoría
de control supervisorio discreto bajo el marco Ramadge-Wonham que se
utilizará en la solución a los problemas presentados en esta Tesis.
 Capítulo 3: Solución a ejemplos basados en autómatas, aplicando la teoría
de control supervisorio, utilizando como herramientas de diseño TCT y
Supremica. Además, Se presenta a grandes rasgos el lenguaje de
programación (GRAFCET) a utilizar en la implementación de los
supervisores sintetizados y la manera en que se lleva a cabo dicha
implementación.
 Capítulo 4: Casos de estudio: Muestra el planteamiento de los principales
casos de estudio de la tesis. En primer lugar se presenta la solución al
problema referente al sistema de manufactura automatizado y su
implementación en un PLC y en segundo lugar la solución de la prueba de
inteligencia cruzar el río.
 Capítulo 5: Conclusiones y trabajos futuros: Presenta las conclusiones en
base a los resultados obtenidos y propuestas para lectores que se interesen
en este tema y quisieran ideas para continuar con la realización de nuevos
trabajos.

5
CAPÍTULO 2. REVISIÓN DE LA LITERATURA

A lo largo de este capítulo se establecerán los conceptos básicos que


fundamentan la teoría de los SED, además se presentarán sus raíces
fundamentales y la aportación de cada una de ellas a dicha teoría, también se
describen las bases de la teoría de control supervisorio (TCS) que fueron
desarrolladas por W. M. Whonam, P. J. Ramadage y sus colaboradores,
reconociendo a su vez que desde entonces, muchos otros investigadores han
hecho contribuciones para el desarrollo y aplicación de la misma.

La teoría presentada en este capítulo se basa principalmente en el trabajo de


Christos G. Cassandras y Stéphane Lafortune, en su libro “Introduction to Discrete
Event Systems”[3]. Por tal motivo se presentarán referencias de aportaciones
puntuales de algunos otros investigadores dando por hecho que la referencia
principal ha sido [3] y que no se está haciendo invención de nuevas ecuaciones o
teoremas que no estén ya validados y mencionados en trabajos como: [5], [9], [4],
[10], [11], [12], en los que se comprueban los fundamentos de la TCS.

2.1 Sistemas de Eventos Discretos (SED).

Cuando el espacio de estado de un sistema es naturalmente descrito por un


conjunto discreto como {1,2,…} y las transiciones entre sus estados son sólo
observadas en puntos discretos en el tiempo, las cuales están asociadas con
“eventos”, entonces se habla de un “sistema de eventos discretos”. Se comenzará
el estudio de estos sistemas presentado sus raíces formales, definiendo
primeramente sus características fundamentales y proporcionando algunos
ejemplos de estos sistemas.

En la Figura 2.1 se muestran las áreas de conocimiento que se unieron para dar
lugar a la teoría de SED y la principal aportación que le dio cada una de ellas a la
misma
CAPÍTULO 2. Revisión de la literatura José Ernesto Pérez Robles

 Computación: Lenguajes o expresiones regulares, es decir una


representación formal de los autómatas y sus operaciones.
 Investigación de operaciones: Optimización de los procesos de
producción de un producto o servicio y las restricciones de los mismos.
 Control: Diseño de supervisores (controladores) que cumplen ciertas
especificaciones para el correcto funcionamiento de un sistema.

Figura 2. 1 Raíces de los sistemas de eventos discretos (SED).

Concepto de sistema

Sistema es uno de aquellos conceptos primitivos que el hecho de entenderlo a


veces puede ser mejor que una definición exacta. Pero aun así, se presentarán a
continuación tres definiciones representativas encontradas en la literatura:

 Un ensamblaje de cosas realizado por la naturaleza o por el hombre para


formar algo integralmente completo [10].

7
CAPÍTULO 2. Revisión de la literatura José Ernesto Pérez Robles

 Una regular interacción o un grupo interdependiente de cosas formando un


todo unificado [11].
 Una combinación de componentes que actúan juntos para realizar alguna
función que no sería posible para cada una de las partes individuales [12].

Hay dos salientes principales en estas definiciones. Primero, un sistema consiste


en la interacción de “componentes”, y en segundo lugar un sistema está asociado
con una “función”, la cual se pretende lograr. Es también importante destacar que
un sistema puede no estar siempre asociado con objetos físicos o leyes naturales.

Concepto de estado y espacio de estado

Estrictamente hablando, el estado de un sistema en un tiempo t debe describir su


comportamiento en ese instante de una manera medible. En la teoría de SED, el
término “estado” es mucho más preciso y constituye el fundamento del proceso de
modelado en varias técnicas analíticas.

Definición. El estado de un sistema en el tiempo t 0 es la información requerida en


el tiempo t 0 para que la salida, para todo t ≥ t o , esté únicamente determinada por
esta información y la entrada en t ≥ t o .

Definición. El espacio de estado de un sistema, es el conjunto de todos los


posibles valores que los estados pueden tomar.

Concepto de evento

Como el término de “sistema”, nosotros no nos enfocaremos en definir


formalmente lo que es un “evento”. Lo que deseamos enfatizar es que un evento
debe ser pensado como una ocurrencia instantánea que causa transiciones de un
estado a otro.

8
CAPÍTULO 2. Revisión de la literatura José Ernesto Pérez Robles

Un evento puede ser identificado como una acción específica (por ejemplo cuando
alguien presiona algún botón). También puede ser visto como una ocurrencia
espontánea dictada por naturaleza (por ejemplo una computadora se apaga por
cualquier razón que es complicado de investigar).O también puede ser el resultado
de varias condiciones, las cuales de repente se juntan (como el hecho de que el
nivel de fluido de un tanque exceda del valor definido).

Para nuestro propósito, usaremos el símbolo 𝑒 para representar un evento.


Cuando consideramos un sistema afectado por diferentes tipos de eventos,
asumimos que podemos definir un conjunto de eventos E cuyos elementos son
todos esos eventos. Claramente E es un conjunto discreto.

Sistemas cuya evolución es regida por el tiempo o por la ocurrencia de


eventos

En sistemas de estados continuos, los estados cambian generalmente a medida


que el tiempo cambia. Esto es particularmente evidente en los modelos de tiempo
discreto, en donde el reloj (“clock”) es lo que maneja típicamente el tiempo de
muestreo, con cada tick del reloj se espera que el estado cambie; mientras que en
los modelos continuos, las variables de estado están cambiando continuamente
con el tiempo. Es por esta propiedad que nos referimos a estos sistemas como
sistemas manejados por el tiempo. En este caso la variable tiempo (t en tiempo
continuo y k en tiempo discreto) es una variable natural independiente que
aparece como argumento de todas las funciones de entradas, estados y salidas.

En los sistemas de eventos discretos, sabemos que el estado cambia sólo en


ciertos puntos en el tiempo a través de transiciones instantáneas. Con cada
transición nosotros podemos asociar un evento. Lo que aun no hemos discutido es
la base de tiempo en la cual los eventos tienen lugar. Permitámonos asumir que
existe un reloj a través del cual podemos medir el tiempo y considerar dos
posibilidades:

9
CAPÍTULO 2. Revisión de la literatura José Ernesto Pérez Robles

1. En cada tick de reloj un evento 𝑒 es seleccionado entre el conjunto de


eventos 𝐸. Si ningún evento tiene lugar, nosotros podemos considerar que
un “evento nulo o vacío”, 𝜀 , es miembro de 𝐸, este evento tiene la
propiedad de que no causa ningún cambio de estado o evolución.
2. En varios instantes de tiempo, no necesariamente conocidos, o no
necesariamente coincide con el tick del reloj, un evento 𝑒 anuncia que está
ocurriendo.

Existe una diferencia fundamental entre estas dos formas de ocurrencia de


eventos.

 En 1, las transiciones de estado son sincronizadas mediante el reloj: hay un


tick de reloj, un evento (o no evento) es seleccionado, el estado cambia y el
proceso se repite. El reloj es responsable de cualquier transición de estado
posible.
 En 2, cada evento 𝑒 ∈ 𝐸 define un proceso a través del cual los instantes de
tiempo son determinados cuando un evento 𝑒 ocurre. Las transiciones son
el resultado de combinar estas ocurrencias asíncronas de los eventos.

La distinción entre 1 y 2 da el nombre a los términos: “Sistemas manejados por


el tiempo” y “Sistemas manejados por eventos” respectivamente. Como ya
hemos visto, los sistemas de estados continuos son por naturaleza sistemas
manejados por el tiempo. Sin embargo, en los sistemas de eventos discretos esto
depende de que las transiciones sean sincronizadas por un reloj o que ocurran
asincrónicamente. Claramente, los sistemas manejados por eventos son más
complicados de modelar y analizar, ya que hay varias ocurrencias asincrónicas, de
eventos, temporizadas por distintos mecanismos. Las cuales es necesario
especificar como parte del entendimiento del sistema.

10
CAPÍTULO 2. Revisión de la literatura José Ernesto Pérez Robles

Propiedades características de los sistemas de eventos discretos

Sabemos que la mayoría de los sucesos en los sistemas de control y procesos


ingenieriles se han relacionado con modelos basados en ecuaciones diferenciales,
o alguna ecuación de diferencias análoga. Para usar estos modelos de manera
matemáticamente conveniente, hay dos propiedades principales que los sistemas
deben de satisfacer:

1. Deben ser sistemas de estados continuos.


2. El mecanismo de la transición de estados debe ser manejado por el tiempo.

La primera propiedad nos permite definir el estado mediante variables continuas,


las cuales pueden tomar cualquier valor real (o complejo). Esta es la razón por la
que nos referiremos a esta clase de sistemas como Sistemas Dinámicos
Continuamente Variables (SDCV). Algunas variables físicas comunes, tales como
la posición, velocidad, aceleración, temperatura, presión, flujo, etc. caen en esta
categoría. Debido a que algunas de esas variables pueden ser derivadas de ellas
mismas, los modelos con ecuaciones diferenciales pueden ser usados.

La segunda propiedad se enfoca en el hecho de que el estado generalmente


cambia mientras el tiempo avanza. Como resultado, la variable tiempo es
naturalmente independiente para la modelación de esos sistemas.

En contraste con los SDCV, los Sistemas Dinámicos de Eventos Discretos (SEDD)
o más brevemente, Sistemas de Eventos Discretos (SED), satisfacen las
siguientes dos propiedades:

1. El espacio de espacio de estado es un conjunto discreto.


2. El mecanismo de transición entre estados es manejado mediante eventos.

A continuación se presenta una primera definición informal para los SED basada
en estas dos propiedades.

Definición. Un SED es un sistema discreto, cuyo mecanismo de transición es


manejado mediante eventos, es decir, la evolución de sus estados depende

11
CAPÍTULO 2. Revisión de la literatura José Ernesto Pérez Robles

enteramente de la ocurrencia asincrónica de eventos discretos a través del


tiempo.

Tres niveles de abstracción en el estudio de los SED

A menudo es conveniente representar un SED como un diagrama de tiempo con


eventos representados por flechas en el instante en que estos ocurren y los
estados a los que tienen lugar una vez ocurrido dicho evento. Un ejemplo se
muestra en la siguiente figura.

Figura 2. 2 Trayectoria de un SED a través del tiempo.

Por simplicidad, algunas veces resulta más cómodo escribir las secuencias
temporizadas de eventos para representar los SED, una forma de hacerlo es:

e1 , t1 , e2 , t 2 , e3 , t 3 , e4 , t 4 , e5 , t 5 , e6 , t 6 , e6 , t 6 e7 , t 7

El primer evento e1 ocurre en t = t1 ; el segundo evento es e2 y ocurre en t = t 2 , y


así sucesivamente. Cuando esta notación es usada, se asume implícitamente que
el estado inicial del sistema es conocido y que el sistema es “determinístico” en
el sentido de que el siguiente estado después de la ocurrencia de un evento es
único.

Considere el conjunto de todas las secuencias temporizadas de eventos que un


sistema dado puede ejecutar. Llamaremos a este conjunto el modelo del
“lenguaje temporizado” del sistema. La palabra “lenguaje” viene del hecho de
que podemos pensar en el conjunto de eventos E como un “alfabeto” y de

12
CAPÍTULO 2. Revisión de la literatura José Ernesto Pérez Robles

(finitas) secuencias de eventos como “palabras”. Podemos además refinar


nuestro modelo del sistema, si está disponible alguna información estadística
acerca del conjunto de muestras o trayectorias del sistema. Asumamos que están
disponibles funciones de distribución de probabilidad acerca del “tiempo de vida”
de cada evento, esto es, el lapso de tiempo entre ocurrencias sucesivas de cada
evento. Llamaremos “lenguaje estocástico temporizado” al leguaje temporizado
junto con las funciones de distribución de probabilidad asociadas a los eventos. El
lenguaje estocástico temporizado es entonces el modelo del sistema que enlista
todas las posibles trayectorias junto con la información estadística relevante
acerca de estas.

El modelado mediante “lenguaje estocástico temporizado” es el más detallado


de todos, ya que contiene información de la forma en la que los eventos ocurren y
son solicitados, así como la información del tiempo exacto en el cual los eventos
ocurren e información estadística acerca de la ocurrencia sucesiva de eventos. Si
se omite alguna de esta información, entonces esto corresponde al “lenguaje
temporizado” el cual enumera todas las posibles trayectorias de los SED, con
información de tiempo. Finalmente, si borramos la información de tiempo del
lenguaje temporizado entonces obtenemos un “lenguaje no temporizado” o
simplemente “lenguaje”, el cual es el conjunto de todas las posibles trayectorias
de los eventos que pueden ocurrir en un sistema dado. Estos tres tipos de
lenguaje representan los tres niveles de abstracción con los que los SED son
modelados y estudiados. La elección del nivel de abstracción adecuado
dependerá de los objetivos del análisis que se desee realizar [5].

13
CAPÍTULO 2. Revisión de la literatura José Ernesto Pérez Robles

2.2 Lenguajes de los autómatas

Modelos del lenguaje de los SED

Una de las maneras formales que existen para el estudio de los SED y su
comportamiento lógico se basa en la teoría de lenguajes y autómatas. El punto de
partida es el hecho de que cualquier SED contiene un conjunto de eventos E
asociados con él. Este conjunto es pensado como el “alfabeto” del lenguaje y las
secuencias de eventos son pensadas como “palabras” en este lenguaje.

Notación del lenguaje y sus definiciones

Comenzaremos declarando al conjunto de eventos E de un SED como su alfabeto.


Asumiremos, además, que E es finito. Una secuencia de eventos tomada de este
alfabeto forma una “palabra” o “trazo” como es llamado en algunas otras
literaturas. Una palabra que no está formada por ningún evento es llamada vacía y
se denota por el símbolo ε (Es importante tener cuidado de no confundir el símbolo
ε con el símbolo 𝑒 que se utiliza para representar un elemento de E). La longitud
de una palabra es el número de eventos contenidos en ella, contando la múltiple
ocurrencia del mismo evento. Si s es una palabra (s proviene del hecho que en [3]
se refiere a las palabras como “strings”) se denotará su longitud mediante s . Por
convenio, la longitud de una palabra vacía ε se toma como cero.

Definición. Un lenguaje definido sobre un conjunto de eventos E es un conjunto


de palabras de longitud finita formadas de eventos que se encuentran dentro de E.

Por ejemplo, si E = {a, b, g} es el conjunto de eventos, se puede entonces definir el


lenguaje 𝐿1 .

L1 = {ε, a, abb}

El cual consta solamente de tres palabras.

14
CAPÍTULO 2. Revisión de la literatura José Ernesto Pérez Robles

También se podría definir 𝐿2

L2 = Todas las posibles palabras de longitud tres que comiencen con a

El cual contiene nueve palabras. O el lenguaje 𝐿3 .

L3 = Todas las posibles palabras de longitud finita que comiencen con el evento a

El cual contiene un número infinito de palabras.

La principal operación involucrada en la construcción de palabras y lenguajes de


un conjunto de eventos de E es la concatenación. La palabra abb en 𝐿1 es la
concatenación de la palabra ab con el evento (o palabra de longitud uno) b; ab es
a su vez la concatenación de a y b.

La concatenación uv, de dos palabras: u y v, es la nueva palabra que consta de


los eventos que están dentro u seguidos por los eventos pertenecientes a v. La
palabra vacía ε es el elemento identidad de la concatenación: εu = uε = u.

Se denotará mediante E ∗ el conjunto de todas las palabras finitas formadas por los
elementos de E, incluyendo la palabra vacía ε; la operación * es llamada Kleene-
Closure o (en español) la operación de cerradura de Kleene. Es importante
observar que el conjunto de E ∗ es contablemente infinito puesto que contiene
palabras de longitud arbitraria. Por ejemplo, si E = a, b, c , entonces:

E ∗ = {ε, a, b, c, aa, ab, ac, ba, bb, bc, ca, cb, cc, aaa, … }

Un lenguaje a partir de un conjunto de eventos E es entonces un subconjunto de


E∗.

Se concluirá esta sección con alguna terminología acerca de las palabras. Si


tuv = s donde t, u, v ∈ E ∗ , entonces:

 t es llamado prefijo de s
 u es llamada sub-palabra de s, y
 v es llamado sufijo de s.

15
CAPÍTULO 2. Revisión de la literatura José Ernesto Pérez Robles

Algunas operaciones básicas con lenguajes

Las operaciones usuales de conjuntos como lo son unión, intersección, resta y


complemento con respecto a E ∗ , son aplicables a los lenguajes debido a que éstos
son conjuntos. Además en la teoría de SED se usan algunas otras operaciones
básicas como las que se presentan a continuación.

 Concatenación: si 𝐿𝑎 , 𝐿𝑏 ⊆ 𝐸 ∗ , entonces
𝐿𝑎 𝐿𝑏 ≔ {𝑠 ∈ 𝐸 ∗ : 𝑠 = 𝑠𝑎 𝑠𝑏 𝑎𝑛𝑑 𝑠𝑎 ∈ 𝐿𝑎 𝑎𝑛𝑑 𝑠𝑏 ∈ 𝐿𝑏 }
Esto es, una palabra esta dentro de 𝐿𝑎 𝐿𝑏 si puede ser escrita como la
concatenación de una palabra que está en 𝐿𝑎 con una palabra en 𝐿𝑏 .

 Prefijo de cerradura: si 𝐿 ⊆ 𝐸 ∗ , entonces


𝐿 ≔ {𝑠 ∈ 𝐸 ∗ : ∃𝑡 ∈ 𝐸 ∗ 𝑠𝑡 ∈ 𝐿 }
En palabras, el prefijo de cerradura de 𝐿 es el lenguaje denotado por 𝐿 y
consta de todos los prefijos de todas las palabras en 𝐿. En general 𝐿 ⊆ 𝐿.
Se dice 𝐿 es un prefijo cerrado si 𝐿 = 𝐿.

 Cerradura de Kleene: si 𝐿 ⊆ 𝐸 ∗ , entonces


𝐿∗ ≔ 𝜀 ∪ 𝐿 ∪ 𝐿𝐿 ∪ 𝐿𝐿𝐿 ∪ …
Esta es la misma operación que se definió anteriormente para el conjunto
𝐸, excepto que ahora es aplicada al conjunto 𝐿 cuyos elementos pueden
ser palabras de longitud mayor a uno. Nótese que la operación * es
idempotente: (𝐿∗ )∗ = 𝐿∗ .

NOTA:“:=” significa: “igual por definición” (3).

16
CAPÍTULO 2. Revisión de la literatura José Ernesto Pérez Robles

2.3 Autómatas

Un autómata es una máquina de estados capaz de representar un lenguaje de


acuerdo a reglas bien definidas. La manera más simple de representar un
autómata es considerar directamente su representación gráfica llamada diagrama
de transición de estados.

Ejemplo (un autómata simple):

Considere el conjunto de eventos E = {Arranca, Finaliza, Falla, Repara}. Considere


también el diagrama de transición de estados de la Figura 2.3, donde los nodos
representan los estados y los arcos (flechas) etiquetados representan las
transiciones entre esos estados. Este grafo proporciona una descripción de la
dinámica de un autómata. El conjunto de nodos es el conjunto de estados del
autómata, X = {Reposo, Ocupada, Descompuesta}. Las etiquetas de las transiciones
son elementos del conjunto de eventos (alfabeto) E del autómata. Los arcos en el
grafo proveen una representación gráfica de la función de transición del autómata,
la cual se define como f: X × E → X:

f Reposo, Arranca = Ocupada

f Ocupada, Falla = Descompuesta

f Ocupada, Finaliza = Reposo

f Descompuesta, Repara = Reposo

La notación “f Reposo, Arranca = Ocupada”, significa que si el autómata está en el


estado: “Reposo” y ocurre el evento: “Arranca”, el autómata hará una transición
instantánea al estado de: “Ocupada”. La causa del evento es irrelevante; el evento
puede ser causado por una entrada externa al sistema modelado por el autómata,
o puede ser que haya sido espontáneamente generado por el sistema. El ejemplo
del sistema modelado anteriormente muestra la representación básica de una
máquina y su diagrama de transición de estados (figura 2.3).

17
CAPÍTULO 2. Revisión de la literatura José Ernesto Pérez Robles

Figura 2. 3 Diagrama de transición de estados del autómata del ejemplo.

Existen algunas cosas importantes que se deben tomar en cuenta en la


modelación de un sistema. Por ejemplo, pueden ocurrir eventos que no generen
un cambio de estado. Es decir, que al ocurrir dicho evento el autómata
permanezca en el mismo estado. En segundo lugar es importante recordar que es
posible que en un estado dado, dos o más eventos distintos causen la misma
transición. Y por último pero no menos importante, la función f es una función
parcial dentro del dominio X × E, esto es, no es necesario que exista una
transisción definida para cada evento de E en cada estado de X. Por ejemplo, en el
autómata de la figura 2.3 la función: f(Reposo, Falla) no está definida.

Otros dos ingredientes son necesarios para definir completamente un autómata:


un estado inicial definido por x0 , y un subconjunto Xm de X que representa los
estados de X que son marcados. Los estados son marcados cuando es necesario
agregar un significado especial a ellos. Se pueden referir por ejemplo a estados de
aceptación o estados de finalización de algún proceso. En los diagramas de
transición de estados, el estado inicial puede ser identificado mediante una flecha
proveniente de ningún estado apuntando a éste, y los estados que pertenecen a
Xm serán identificados por los dobles círculos. En el caso del ejemplo anterior, el
estado Reposo es un estado inicial y además es un estado marcado.

Ahora se puede definir de manera formal un autómata. Cabe mencionar que se


definirá el caso del autómata determinístico, que es el caso que abarca los
problemas que se presentarán durante la tesis. Sin embargo, existe también una
parte importante de la teoría de SED que trata a los autómatas no determinísticos,
no incluida en este trabajo.

18
CAPÍTULO 2. Revisión de la literatura José Ernesto Pérez Robles

Definición. Un autómata determinístico, definido por G, es una séxtupla (5)

G = (X, E, f, Γ, x0 , Xm )

Donde:

X es el conjunto de estados

E es el conjunto finito de eventos asociados a G.

f: X × E → X Es la función de transición: f x, ℯ = y que significa que hay una


transición mediante el evento ℯ del estado x al estado y.

Γ: X → 2E es la función de evento activo (o función de evento factible); Γ(x) es el


conjunto de todos los eventos 𝑒 para los cuales f x, ℯ está definida, es llamado
conjunto de evento activo o conjunto de evento factible de G en x.

x0 es el estado inicial

Xm ⊆ X es el conjunto de estados marcados.

Algunos datos acerca de esta definición:

 Las palabras máquinas de estado y generador, lo cual explica la notación 𝐺,


son también usadas frecuentemente para describir los diagramas de
transición de estados.
 Si 𝑋 es un conjunto finito, G es llamado determinístico de estado finito.
 Las funciones 𝑓 y Γ son completamente descritas por el diagrama de
transición de estados del autómata.
 El autómata se dice que es determinístico porque 𝑓 es una función de 𝑋 × 𝐸
para 𝑋, no puede haber dos transiciones con el mismo evento saliendo de
un mismo estado. En contraste, la estructura de transición de un autómata
no determinístico se define por medio de una función 𝑋 × 𝐸 𝑡𝑜 2𝑋 ; en este
caso, puede haber múltiples transiciones con el mismo evento saliendo de
un estado. Nótese que por defecto, la palabra autómata se referirá a un
autómata determinístico en esta tesis.

19
CAPÍTULO 2. Revisión de la literatura José Ernesto Pérez Robles

 El hecho de que se permita la función de transición 𝑓 ser parcialmente


definida a través del dominio 𝑋 × 𝐸, es una variación sobre la definición
usual de un autómata en literatura de la ciencia computacional, que es muy
importante en la teoría de SED.
 Formalmente hablando, la inclusión de Γ en la definición de 𝐺 es superflua
en el sentido de que Γ es derivada de 𝑓. Por esta razón, se omitirá algunas
veces su escritura explícita cuando específicamente en un autómata dicha
función Γ no sea el tema central de discusión. Una de las razones por las
que sería interesante el estudio del contenido de Γ(x) para el estado 𝑥, es
para ayudar a distinguir entre eventos 𝑒 que son factibles en 𝑥 pero que no
causan una transición de estado, esto es,𝑓 𝑥, 𝑒 = 𝑥, y eventos 𝑒´ que no
son factibles en 𝑥, esto es, 𝑓(𝑥, 𝑒´) no está definida.

Lenguajes representados por autómatas

La conexión entre lenguajes y autómatas es fácilmente realizada mediante la


inspección del diagrama de transición de estados. Considere todas las trayectorias
que pueden ser seguidas en el diagrama de transición de estados, comenzando
en el estado inicial; considere también dentro de éstas, a todas aquellas que
terminan en un estado marcado. Esto da lugar a las nociones de los lenguajes
generados y marcado de un autómata.

Definición. (Lenguajes Marcados y Generados)

El Lenguaje generado por G = (X, E, f, Γ, x0 , Xm ) es:

ℒ G ≔ {s ∈ E ∗ : f x0 , s esta definida} Nota: ε ∈ ℒ(G)

El lenguaje marcado por G = (X, E, f, Γ, x0 , Xm ) es:

ℒm G ≔ {s ∈ ℒ G : f(x0 , s) ∈ Xm }

El lenguaje ℒ(G) representa todas las trayectorias que pueden ser seguidas a lo
largo del diagrama de transición de estados, comenzando con el estado inicial.

20
CAPÍTULO 2. Revisión de la literatura José Ernesto Pérez Robles

La palabra correspondiente a una trayectoria es la concatenación de los eventos


de las transiciones que forman dicha trayectoria. Por lo tanto, una palabra esta
dentro de ℒ G si y sólo si f está definida en (x0 , s).

El segundo lenguaje representado por G, ℒm (G), es un subconjunto de ℒ G ,


compuesto solo de las palabras s para las cuales f(x0 , s) ∈ Xm , esto es, aquellas
palabras que corresponden a trayectorias que terminan en un estado marcado en
el diagrama de transición de estados.

Bloqueos

Cuando un autómata G puede alcanzar un estado x donde Γ x = ∅ pero x ∉ Xm ,


se dice que posee un estado de deadlock, porque ningún evento más puede ser
ejecutado. Dada nuestra interpretación de marcaje, se puede decir que el sistema
“se bloquea o presenta bloqueo” debido a que entra en un estado de “deadlock” en
el cual no ha terminado su tarea.

Otra situación a considerar es cuando hay un conjunto de estados no marcados en


G que forman un componente fuertemente conectado (por ejemplo: estos estados
son alcanzables uno de del otro), pero no hay transiciones que los saquen de este
conjunto. Si el sistema entra en este conjunto de estados, entonces se obtiene lo
que llamamos un livelock.

La importancia del “deadlock” y “livelock” en SED nos permite formular la siguiente


definición.

Definición. (Blocking)

El autómata G se dice que presenta bloqueo (blocking) si

Lm (G) ⊂ ℒ(G)

Y no presenta bloqueo (nonblocking) cuando

Lm (G) = ℒ(G)

21
CAPÍTULO 2. Revisión de la literatura José Ernesto Pérez Robles

Por lo tanto si el autómata presenta bloqueo, significa que pueden ocurrir


“deadlocks” y/o “livelocks”. Para entender mejor, estos tipos de bloqueos se
aprecian en la figura 2.4.

Figura 2. 4 Autómata con bloqueos: El estado 5 es un “deadlock” y los estados 3 y 4 están


envueltos en un “livelock”, cabe mencionar que el estado 2 representa un estado marcado.

Algunas operaciones sobre los autómatas

Es importante definir operaciones que nos permitan combinar o complementar,


dos o más autómatas, debido a que sistemas completos pueden ser construidos a
partir de componentes individuales del sistema y es necesario poder llevar a cabo
estas operaciones para realizar ciertas acciones de control entre otras.

Operaciones unitarias

Las operaciones unitarias son aquellas operaciones que alteran el diagrama de


transición de estados de un autómata, sin embargo es importante remarcar que el
conjunto de eventos E permanece sin cambio.

De las definiciones de ℒ G y ℒm G , se puede ver que podemos borrar de G todos


los estados que no son accesibles o alcanzables desde x0 mediante alguna
palabra en ℒ G , sin afectar el lenguaje generado y marcado generado por G.
Cuando se “elimina” un estado, también se deben anular todas las transiciones

22
CAPÍTULO 2. Revisión de la literatura José Ernesto Pérez Robles

adjuntas a ese estado. Se definirá esta operación mediante Ac G , donde Ac


proviene del hecho de que al autómata se le toma solamente la parte “accesible”.

Formalmente:

Ac G ≔ (Xac , E, fac , x0 , Xac ,m )

Xac = x ∈ X: ∃s ∈ E ∗ f x0 , s = x

Xac ,m = Xm ∩ Xac

fac = f Xac × E → Xac

La notación fac = f Xac × E → Xac significa que f esta restringida al dominio más
pequeño de estados accesibles Xac .

Claramente se puede observar que la operación Ac no tiene efecto sobre ℒ G y


ℒm G . Por lo tanto, de ahora en adelante, se asumirá sin pérdida de generalidad,
que un autómata es “accesible” si G = Ac(G).

Un estado x de G es coaccesible a Xm , o simplemente coaccesible, si hay una


trayectoria en el diagrama de transición de estados de G, desde el estado x al
estado marcado. La operación de eliminar todos los estados de G que no son
coaccesibles se define mediante CoAc(G), donde CoAc proviene del hecho de
tomar la parte coaccesible de G.

Formalmente:

CoAc ≔ (Xcoac , E, fcoac , x0,coac , Xm ) donde

Xcoac = x ∈ X: ∃s ∈ E ∗ f x, s ∈ Xm

x0 Si x0 ∈ Xcoac
X0,coac =
Indefinido cualquier otro

fcoac = f Xcoac × E → Xcoac

La operación CoAc reduce ℒ G , debido a que puede eliminar estados que son
accesibles desde x0 . Sin embargo, la operación CoAc no afecta ℒm G , debido a
que los estados borrados no pueden estar sobre la trayectoria desde x0 a Xm . Si
G = CoAc (G) entonces G se dice que es coaccesible; en este caso G = ℒm (G).

23
CAPÍTULO 2. Revisión de la literatura José Ernesto Pérez Robles

La coaccesiblidad está estrechamente relacionada con el concepto de bloqueo;


es importante recordar que un autómata presenta “bloqueo” cuando Lm (G) ≠
ℒ(G).

Un autómata que es accesible y coaccesible (ambas) se dice que esta podado o


“trim” en inglés. Se definirá la operación de poda como:

Trim G ≔ CoAc Ac G = Ac[CoAc(G)]

En la cual fácilmente se puede apreciar la propiedad de conmutatividad de las


operaciones Ac y CoAc.

Figura 2. 5 (a) CoAC(G) y (b)Trim(G)

En la Figura 2.4 se mostró un diagrama de transición de estados con la finalidad


de ilustrar los “deadlocks” y “livelocks” de un autómata, ahora tomando en cuenta
ese mismo diagrama, se presentan los autómatas de la figura 2.5(a) y figura
2.5(b), como resultado de las operaciones Coac G y Trim(G) aplicadas al
autómata en cuestión.

Cabe mencionar que existen otras operaciones unitarias como lo son: proyección,
proyección Inversa, complemento, entre otras, que no se incluyen en este estudio
porque no serán utilizadas en nuestra síntesis de supervisores.

24
CAPÍTULO 2. Revisión de la literatura José Ernesto Pérez Robles

Operaciones de composición

En esta sección se definirán solamente dos operaciones que se realizan sobre los
autómatas, la operación producto. Definida por × y la operación “composición
parallela” definida por ∥.

Se puede pensar de G1 × G2 y de G1 ∥ G2 como dos tipos de interconexión de los


componentes de los sistemas G1 y G2 con sus conjuntos de eventos E1 y E2
respectivamente, como lo muestra la figura 2.6.

Figura 2. 6 Operación producto y operación de composición paralela.

Se considerará ahora que G1 = (X1 , E1 , f1 , Γ1 , x01 , Xm1 ) y G2 = (X2 , E2 , f2 , Γ2 , x02 , Xm2 )

El “producto” de los autómatas G1 y G2 es el autómata:

G1 × G2 ≔ Ac(X1 × X2 , E1 ∪ E2 , f, Γ1×2 , x01 , x02 , Xm1 × Xm2 )

Donde

f1 x1 , ℯ , f2 (x2 , ℯ) if ℯ ∈ Γ1 (x1 ) ∩ Γ2 (x2 )


f x1 , x2 , ℯ ∶=
Indefinido De otra manera

Y por lo tanto Γ1×2 x1 , x2 = Γ1 x1 ∩ Γ2 x2 .

Además fácilmente se puede apreciar que:

ℒ G1 × G2 = ℒ(G1 ) ∩ ℒ(G2 )

ℒm G1 × G2 = ℒm (G1 ) ∩ ℒm (G2 )

25
CAPÍTULO 2. Revisión de la literatura José Ernesto Pérez Robles

Propiedades de la operación producto:

 El producto es conmutativo.
 El producto es asociativo y se define

G1 × G2 × G3 ≔ G1 × G2 × G3 = G1 × G2 × G3

Un ejemplo de la operación producto propuesto en (5) en el ejemplo 2.15 se


realizó mediante el programa TCT, (6) y se muestra en la figura 2.8, el cual es el
producto entre los autómatas presentados en la figura 2.7. Cabe mencionar que
dentro del programa de TCT la operación producto se define como “MEET”.

Figura 2. 7 (a) representa G1 y (b) a G2.

Figura 2. 8 Producto de G1 y G2 (MEET en el TCT).

La composición paralela de los autómatas G1 y G2 es el autómata:

G1 ∥ G2 ≔ Ac(X1 × X2 , E1 ∪ E2 , f, Γ1∥2 , x01 , x02 , Xm1 × Xm2

donde

f1 x1 , ℯ , f2 (x2 , ℯ) if ℯ ∈ Γ1 (x1 ) ∩ Γ2 (x2 ) α


f1 x1 , ℯ , x2 if ℯ ∈ Γ1 (x1 )\E2 β
f x1 , x2 , ℯ ∶= γ
x1 , f2 x2 , ℯ if ℯ ∈ Γ2 x2 \E1
Indefinida De otra manera

26
CAPÍTULO 2. Revisión de la literatura José Ernesto Pérez Robles

En la función "f" descrita anteriormente se agregaron los símbolos {α, β, γ} los


cuales no tienen ningún significado relevante dentro de la misma, sólo se utilizan
como etiquetas, para definir cuál es la condición que se cumple al hacer la
composición paralela de los autómatas G1 y G2 . El resultado de la composición
paralela procesado mediante el TCT (“SYNC” es la operación equivalente dentro
de este programa) se muestra en la figura 2.9.

Figura 2. 9 Composición paralela de G1 y G2 (SYNC en el TCT).

Las propiedades de la operación producto también son aplicables a la operación


paralela. Este tipo de operaciones de composición serán muy útiles en la
generación de plantas y el control de las mismas, por tal motivo es importante
entender correctamente cada una de ellas.

Propiedades de seguridad

Las propiedades de seguridad son aquellas que tienen que ver con la
alcanzabilidad de ciertos estados indeseables, ya sea desde el estado inicial o de
cualquier otro estado dentro del autómata. La presencia de ciertas palabras o sub-
palabras indeseables en el lenguaje generado por el autómata, son las que se
tratan de evitar para generar un autómata seguro, nótese que esto ocurre

27
CAPÍTULO 2. Revisión de la literatura José Ernesto Pérez Robles

principalmente en la formación de un autómata a partir de autómatas más simples,


mediante alguna de las operaciones de composición y es por eso que no es tan
fácil evitarlas como cuando usamos las operaciones unitarias en la creación de un
autómata.

Propiedades de bloqueo

Las propiedades de bloqueo son aquellas propiedades que tienen que ver con la
coaccesibilidad de estados al conjunto de estados marcados. La característica
más común de bloqueo es determinar si:

Lm (G) = ℒ G o Lm (G) ⊂ ℒ(G)

En el último caso, G presenta bloqueo. Para determinar si un autómata accesible G


presenta bloqueo o no, se puede hacer uso de la operación co-accsesible. Si
alguno de los estados de G es eliminado entonces G presenta bloqueo, de otra
forma G, no presenta bloqueo. Por último si el autómata G presenta bloqueo
entonces es deseable que se identifiquen explícitamente los “dead-locks” y los
“live-lock” y se analice el motivo de su ocurrencia.

2.4 Control Supervisorio

La que se va a considerar en esta sección es que dado un SED, modelado en un


nivel lógico de abstracción (no temporizado), cuyo comportamiento se debe
modificar mediante un control retroalimentado para lograr un conjunto de
especificaciones dadas. Asumamos que el SED dado es modelado mediante el
autómata G, donde el espacio de estado de G no tiene por qué ser finito. Siendo E
el conjunto de eventos de G. El autómata G modela un “comportamiento no
controlado” del SED. La premisa es que este comportamiento no es satisfactorio y
por lo tanto debe ser “modificado” por un control.

28
CAPÍTULO 2. Revisión de la literatura José Ernesto Pérez Robles

Modificar el sistema debe ser entendido como restringir el comportamiento a un


subconjunto de ℒ(G). Para alterar el comportamiento de G se introduce un
supervisor S. Nótese que separamos la “planta” G del “controlador” (supervisor) S,
como se acostumbra en la teoría de control. Finalmente, es importante remarcar
que el cuerpo de esta sección es parte de lo que es generalmente conocido como
“Supervisory Control Theory” (teoría de control supervisorio TCS) [1]. Los
fundamentos de esa teoría fueron desarrollados por W.M. Whoham y P.J.
Ramadage y sus colaboradores, en los años de 1980’s. Desde ese entonces
muchos otros investigadores han hecho contribuciones para el desarrollo y
aplicación de esta teoría en SED algunos de los trabajos más importantes son: [1],
[16], [17], [18], [13], [15], entre otros.

Sistemas de eventos discretos controlados

Consideremos un SED modelado mediante un par de lenguajes, L and Lm , donde


L es el conjunto de todas las palabras que el SED puede generar y Lm ⊆ L es el
lenguaje de palabras marcadas que se utiliza para representar la finalización de
algunas operaciones o tareas. Sin perder generalidad asumiremos que L y Lm son
lenguajes generados por el autómata

G = (X, E, f, Γ, x0 , Xm )

Donde X no tiene por qué ser finito, esto es:

L G = L y Lm G = Lm

Entonces estamos hablando del “SED G.”

Lo que deseamos es adjuntar un supervisor, definido por S, para interactuar con G


de la manera como se ve en la figura 2.10. En este aspecto, vamos a permitirnos,
dividir el alfabeto E en dos subconjuntos disjuntos

E = Ec ∪ Enc

29
CAPÍTULO 2. Revisión de la literatura José Ernesto Pérez Robles

donde:

 𝐸𝑐 es el conjunto de eventos controlables, estos son los eventos que son


prohibidos o deshabilitados por el supervisor 𝑆 para evitar su ejecución.
 𝐸𝑢 es el conjunto de eventos no controlables, estos son los eventos que no
pueden ser prohibidos o deshabilitados por el supervisor 𝑆.

Hay varias razones por las que un evento puede ser modelado como un evento no
controlable. Por ejemplo, puede ser alguna falla en el sistema, lo cual es algo que
no se puede prohibir o deshabilitar. De manera similar, existen muchos eventos
que pueden ser modelados como eventos controlables como lo es un botón de
inicio de un proceso, la reparación de una falla, etc.

Figura 2. 10 Lazo de retroalimentación del control supervisorio.

Asumamos que todos los eventos de E ejecutados por G son observados por el
supervisor S. Por lo tanto en la Figura 2.9, s es la palabra formada por todos los
eventos ejecutados por G y s es totalmente observado por S. Existe otra
configuración de control, como lo es el control con eventos parcialmente
observados pero esa no se tratará en el desarrollo de esta tesis.

El paradigma de control es el siguiente. La planta G puede ser controlada


mediante S en el sentido que los eventos controlables de G puedan ser
dinámicamente habilitados y deshabilitados por S. Formalmente el supervisor S es
una función del lenguaje generado por G al conjunto potencia de E:

S: ℒ G → 2E

30
CAPÍTULO 2. Revisión de la literatura José Ernesto Pérez Robles

Para cada s ∈ ℒ(G) generada mediante G (bajo el control de S),

S s ∩ Γ f x0 , s

es el conjunto habilitado de eventos que G puede ejecutar en su estado actual


f(x0 , s). En otras palabras G no puede ejecutar un evento que esta en su conjunto
activo de eventos, Γ f x0 , s , si ese evento no está también contenido en S(s). En
vista de la división de E en eventos controlable y no controlables, se dice que un
supervisor S es “admisible” si para todos los s ∈ ℒ(G)

Enc ∩ Γ f x0 , s ⊆ S(s)

lo que significa que S no tiene permitido deshabilitar un evento alcanzable “no


controlable”.

Llamaremos a S s la acción de control en s. S es la política de control. Este lazo


de retroalimentación es un ejemplo de una retroalimentación dinámica en el
sentido de que el dominio de S es ℒ G y no X; en consecuencia la acción de
control puede cambiar en las subsecuentes visitas a un estado. Dado G y un
supervisor admisible S, el sistema de lazo cerrado resultante se define mediante
S/G (se lee “S controlando G”). El sistema controlado S/G es un SED, y por lo tanto
se pueden caracterizar sus lenguajes generados y marcados. Estos dos lenguajes
son simplemente los subconjuntos de L G y Lm G que contienen las palabras
que permanecen accesibles en la presencia de S. Esto se formaliza en la siguiente
definición.

Definición. (Lenguajes generados y marcados por S/G)

El lenguaje generado por S/G es definido recursivamente como sigue:

1. ε ∈ ℒ(S/G)
2. [(s ∈ ℒ(S/G)) y (sσ ∈ ℒ G ) y (σ ∈ S s )] ⇔ [(sσ ∈ ℒ S/G )].

El lenguaje marcado mediante S/G es definido:

ℒm (S/G) ≔ ℒ S/G ∩ ℒm (G)

31
CAPÍTULO 2. Revisión de la literatura José Ernesto Pérez Robles

de manera final tenemos las siguientes inclusiones

∅ ⊆ ℒm (S/G) ⊆ ℒm S/G ⊆ ℒ(S/G) ⊆ ℒ(G)

La definición de bloqueo definida anteriormente para los autómatas es también


válida para el SED S/G, puesto que este SED posee lenguajes generados y
marcados. La manera obvia de definir bloqueo se presenta a continuación.

Definición. (bloqueo en los sistemas controlados).

El SED S/G presenta bloqueo si

ℒ(S/G) ≠ ℒm (S/G)

Y no presenta bloqueo cuando

ℒ(S/G) = ℒm (S/G)

Especificaciones de los sistemas controlados

Como se mencionó anteriormente, el supervisor es necesario porque el


comportamiento del sistema G sin control no es satisfactorio y debe ser restringido
a un subconjunto de ℒ(G),

ℒ(S/G) ⊆ La ⊂ ℒ G y/o ℒm (S/G) ⊆ Lam ⊂ ℒm (G)

O dentro de un rango de sublenguajes de ℒ G ,

Lr ⊆ ℒ(S/G) ⊆ La ⊂ ℒ G y/o ℒrm (S/G) ⊆ Lam ⊂ ℒm (G)

Adoptamos la notación La para referirnos al “sublenguaje admisible del lenguaje


generado” y Lam para el “sublenguaje admisible del lenguaje marcado”. Debemos
asumir que La es prefijo cerrado, es decir, La = La.

En los problemas donde el bloqueo no es motivo de preocupación, el


comportamiento admisible es descrito mendiante La y debemos enfocarnos en
asegurar que:

ℒ(S/G) ⊆ La

32
CAPÍTULO 2. Revisión de la literatura José Ernesto Pérez Robles

En los problemas donde el bloqueo es un hecho, el comportamiento admisible


será descrito por Lam y nos debemos enfocar en asegurar que

ℒm (S/G) ⊆ Lam

para mitigar el bloqueo en el sistema controlado.

Modelación de las especificaciones como autómatas

Como veremos, en el desarrollo de los ejercicios de la tesis, para sintetizar los


supervisores que son probablemente correctos en términos de los requerimientos
aplicables del lenguaje, necesitamos autómatas que representen esos
requerimientos en adición al modelo del autómata G del sistema o planta. Si un
autómata H marca el lenguaje K, decimos que H es un “reconocedor” de K. En la
práctica, usualmente debemos construir ese autómata reconocedor a partir
declaraciones naturales acerca de los requerimientos del comportamiento
necesario del SED G. Ejemplo de esas declaraciones o requerimientos de
sistemas son: evitar la lista de eventos ilegales, ejecutar los eventos en cierto
orden prioritario, etc.

En la mayoría de los casos la construcción del autómata que genera los


requerimientos del lenguaje aplicable, en este caso La , es precedida de la
construcción de un simple autómata que captura la esencia de la especificación en
un lenguaje natural. Llamaremos a ese autómata Hesp . Podemos entonces
combinar Hesp con G, usando la composición paralela o la composición producto,
apropiadamente, para obtener Ha donde

ℒ(Ha ) = La

En el caso de haber varias especificaciones, habrá varias Hesp ,i , i = 1, 2, … , n, que


serán combinadas con G.

33
CAPÍTULO 2. Revisión de la literatura José Ernesto Pérez Robles

La decisión de cuál de las operaciones de composición se debe de escoger,


operación producto u operación paralela, para componer Hesp con G se basa en
los eventos que aparecen en el diagrama de transición de Hesp y en cómo se
desea definir el conjunto de eventos de Hesp .

 Si los eventos que pueden ser ejecutados en 𝐺 no aparecen en el diagrama


de transición de 𝐻𝑒𝑠𝑝 y son irrelevantes a lo que especificación 𝐻𝑒𝑠𝑝
implementa, entonces usamos la composición paralela y definimos el
conjunto de eventos de 𝐻𝑒𝑠𝑝 a ser aquellos eventos que aparecen en su
diagrama de transición.
 Por otro lado, si los eventos que pueden ser ejecutados en 𝐺 no aparecen
en el diagrama de transición de 𝐻𝑒𝑠𝑝 y están ausentes de 𝐻𝑒𝑠𝑝 porque estos
no deberían de ocurrir en el comportamiento admisible 𝐿𝑎 , entonces el
producto es la operación de composición indicada.

Estados ilegales

Si una especificación identifica ciertos estados como ilegales, entonces eso basta
para borrar esos estados de G, esto es, eliminar estos estados y todas aquellas
transiciones adjuntas a ellos, entonces se realiza la operación Ac para obtener Ha
tal que ℒ Ha = La . Si la especificación también requiere un comportamiento de
no-bloqueo después de que los estados ilegales han sido removidos, entonces le
realizamos la operación “Trim” en vez de la operación Ac y obtenemos Ha tal que
ℒm Ha = Lma y ℒ Ha = L_ma.

Eventos alternantes

Si una especificación requiere que dos eventos: a y b ocurran alternativamente. Es


decir, a y b, siendo a el primero en ocurrir, entonces podemos construir un

34
CAPÍTULO 2. Revisión de la literatura José Ernesto Pérez Robles

autómata de dos estados Hesp que capture esta alternancia. Hesp se muestra en
Figura 2.11, su conjunto de eventos es {a, b}. El autómata deseado Ha es entonces
definido como:

Ha ∶= Hesp ∥ G

Donde, por definición, la composición paralela del conjunto de eventos de Ha es


igual a la de G. Aquí, las reglas de la composición paralela previenen una segunda
ocurrencia consecutiva de a hasta que b sea ejecutada por G y viceversa. Los
otros eventos de G no son afectados debido a que ellos no aparecen en el
conjunto de eventos de Hesp . Nosotros marcamos los dos estados de Hesp debido
a que la especificación de la alternancia de los eventos no involucra bloqueo, por
lo tanto marcar en Ha es consistente con marcar en G.

Figura 2. 11 Autómata de dos estados que forza la alternancia de eventos a y b.

Control con una controlabilidad parcial

El propósito de esta sección es estudiar lo que comportamientos controlados


pueden lograr cuando se controla un SED G con un supervisor de completa
observación S. Y se enfocará principalmente en cómo es que se logra un
comportamiento controlado a pesar de existir eventos no controlables.

Teorema de la controlabilidad

Empezaremos declarando la existencia de los supervisores en presencia de


eventos no controlables. Nos referimos a esto como el teorema de controlabilidad
que se expresará de aquí en adelante como TC.

35
CAPÍTULO 2. Revisión de la literatura José Ernesto Pérez Robles

Teorema. (Teorema de Controlabilidad (TC)).

Considere un SED G = (X, E, f, Γ, x0 ) donde Enc ⊆ E es el conjunto de eventos no


controlables. K ⊆ ℒ(G), donde K ≠ ∅. Entonces existe un supervisor S tal que
ℒ(S/G) = K si y solo si

KEnc ∩ ℒ G ⊆ K

Esta condición sobre K es llamada la condición de controlabilidad y significa


que el lenguaje que incluye los eventos no controlables, es a su vez parte del
lenguaje especificado, en otras palabras el controlador no deshabilita ningún
evento no controlable, debido a que estos eventos forman parte de palabras
legales dadas por la especificación.

Comprobación

La comprobación de esta parte es constructiva. Para s ∈ ℒ(G), se define S(s) de


acuerdo a:

S s = Enc ∩ Γ f x0 , s ∪ {σ ∈ Ec : sσ ∈ K}

Este supervisor habilita después de la palabra s: (i) todos los eventos no


controlables que son accesibles en G después de la palabra s y (ii) todos los
eventos controlables que son parte de s y se encuentran dentro de K. La parte (i)
asegura que S es admisible, esto es, S nunca deshabilita un evento accesible no
controlable.

Ya probamos que con este S, ℒ S/G = K. El desarrollo de la comprobación más a


detalle se presenta en (7) y (1).

La condición de controlabilidad en el teorema de controlabilidad es intuitiva y


además es un concepto central dentro del control supervisorio. Esta puede ser
parafraseada mediante

“Si no puedes evitarlo, entonces debe ser legal”

36
CAPÍTULO 2. Revisión de la literatura José Ernesto Pérez Robles

Definición. (Controlabilidad)

K y M = M son lenguajes a partir del conjunto de eventos E. Donde existe Enc . Se


dice que K es controlable con respecto a M y Enc si

KEnc ∩ M ⊆ K

Por definición, controlabilidad es una propiedad de prefijo de cerrado de un


lenguaje. Por lo tanto K es controlable si y solo si K es controlable. La expresión
de lenguaje para la condición de controlabilidad puede ser reescrita como sigue:

Para toda s ∈ K, para todo e ∈ Enc , se ∈ M ⟹ se ∈ K.

Sea H el autómata que genera K y G el autómata que genera M. La controlabilidad


puede ser verificada mediante la comparación del conjunto de eventos activos de
cada estado de H × G con el conjunto de eventos activos de G, si existe algún
evento no-controlable de G que no aparece en H × G entonces K es no controlable.

Realización de supervisores

Asumamos que el lenguaje K ⊆ ℒ(G) es controlable. Sabemos entonces que el


supervisor S está definido mediante

S s = Enc ∩ Γ f x0 , s ∪ {σ ∈ Ec : sσ ∈ K}

Resulta en

ℒ(S/G) = K

Podemos descartar los dos casos K = ℒ(G) y K = ∅. En el primer caso, S no juega


ningún papel, es decir no deshabilita ningún evento y el segundo caso no está
permitido según del teorema de la controlabilidad.

En lo que necesitamos enfocarnos es en que para propósitos de implementación,


necesitamos una representación conveniente de S; esto es porque sería muy
impráctico la lista de S(s) para todas las s ∈ ℒ(S/G). Por lo tanto dado que usamos
un autómata para representar el sistema, nos vamos a permitir usar un autómata

37
CAPÍTULO 2. Revisión de la literatura José Ernesto Pérez Robles

para representar el supervisor S. En este caso cuando estemos tratando con


lenguajes regulares ℒ G y K, la representación requerida será finita y por lo tanto
implementable. Además seremos capaces de utilizar la composición paralela del
autómata como un medio algebraico para el efecto de S controlando G. Esto será
muy útil cuando tratemos con sistemas interconectados y supervisores. Nosotros
llamamos a la representación del autómata del supervisor S la “realización” de S.

Es importante enfatizar que, hasta este momento lo que nos interesa es la


modelación la planta, las especificaciones y el supervisor. Es decir, lo que
estamos construyendo es la completa realización de S en forma simulada o fuera
de línea, esta realización servirá para simular el sistema y ver el funcionamiento
del supervisor sin necesidad de implementarlo en línea.

Para construir un autómata de realización de S, basta con construir un autómata


que marque el lenguaje K. Llamaremos a este autómata R y es:

R ≔ Y, E, g, ΓR , Y0 , Y

Donde R es “trim” y

ℒm R = ℒ R = K

Si “conectamos” R a G mediante la operación de composición paralela, el resultado


R ∥ G es exactamente el comportamiento que deseamos para el sistema en lazo
cerrado de S/G siempre y cuando R y G tengan el mismo conjunto de eventos,
entonces R ∥ G = R × G y se obtiene:

ℒ R ∥ G = ℒ(R) ∩ ℒ(G)

= K ∩ ℒ(G)

= K = ℒ(S/G)

ℒm R ∥ G = ℒm R ∩ ℒm G

= K ∩ Lm G

= ℒ(S/G) ∩ Lm G = Lm S/G

38
CAPÍTULO 2. Revisión de la literatura José Ernesto Pérez Robles

Nótese que el lenguaje marcado es completamente capturado por el sistema


mediante el modelo G y que el supervisor no juega ningún papel en los estados
marcados, por este motivo todos los estados del supervisor son marcados.

Le llamamos R representando que es derivado del proceso de la realización de S.


La acción de control S(s) es “codificada” en la estructura de transición de R,
formalmente

S s = Enc ∩ Γ f x0 , s ∪ {σ ∈ Ec : sσ ∈ K}

= ΓR g y0 , s

= ΓR∥G g ∥ f y0 , s , s

Donde la primera igualdad se deriva de la controlabilidad de K y la segunda se


deriva del hecho que K ⊆ ℒ(G). Aquí ΓR∥G y g ∥ f define el conjunto de eventos
activos y la función de transición de R ∥ G, respectivamente.

La interpretación del sistema de control presentado anteriormente es la siguiente:

“Si G está en un estado x y R en el estado y y a continuación se presenta la


ocurrencia de una palabra s ∈ ℒ(s/G). G genera un evento σ que está habilitado en
ese momento. Esto significa que este evento está también presente en el conjunto
de eventos activos de R en y. Por lo tanto R tambien ejecuta el evento como un
observador pasivo de G. Ahora digamos que x′ y y′ son los nuevos estados de G y
R después de la ejecución de σ. El conjunto de eventos activos de G después de la
palabra sσ es ahora dado mediante el conjunto de eventos activos de R en y′.

Por lo tanto, hemos construido una representación de S que en el caso de un K


regular, sólo se requiere una memoria finita. Además, hemos capturado el
mecanismo de control S/G dentro de la herramienta algebraica de la operación de
composición paralela del autómata.

A continuación se presentaran algunas propiedades de la controlabilidad, donde


K1 y K 2 representan distintos lenguajes, las pruebas de estas propiedades se
presentan de manera más completa en [7] y [1].

39
CAPÍTULO 2. Revisión de la literatura José Ernesto Pérez Robles

 Si 𝐾1 y 𝐾2 son controlables, entonces 𝐾1 ∪ 𝐾2 es controlable


 Si 𝐾1 y 𝐾2 son controlables, entonces 𝐾1 ∩ 𝐾2 no necesariamente es
controlable
 Si 𝐾1 ∩ 𝐾2 = (𝐾1 ∩ 𝐾2 ) y 𝐾1 y 𝐾2 son controlables, entonces 𝐾1 ∩ 𝐾2 es
controlable.
 Si 𝐾1 y 𝐾2 son de prefijo cerrado y controlables, entonces 𝐾1 ∩ 𝐾2 es de
prefijo cerrado y controlable.

La condición de la propiedad 3 la podemos declarar en el contexto de una


definición.

Definición. (Lenguajes sin conflictos “non-conflicting”)

Los lenguajes K1 y K 2 se dice que son “non-conflicting” si satisfacen la condición

K1 ∩ K 2 = (K1 ∩ K 2 )

En palabras, si K1 y K 2 comparten un prefijo, entonces ellos deben de compartir


una palabra que contenga ese prefijo.

Control sin bloqueos “NONBLOCKING”

En esta sección consideraremos los problemas de control supervisorio que


conciernen a los dos lenguajes ℒ(S/G) y Lm (S/G). Típicamente, las
especificaciones sobre el sistema controlado serán dadas como un sublenguaje de
Lm (G) y se requerirá que el supervisor S este sin bloqueos esto es:

ℒm (S/G) = ℒ(S/G)

Es importante mencionar que en el transcurso de esta tesis se tratará de buscar


este tipo de control (control sin bloqueos). Sin embargo, existen aplicaciones,
donde se puede trabajar con sistemas que presentan bloqueo si así se lo requiere,
esto ya dependerá de las características especiales del sistema y de lo que se
necesite. Algunas soluciones a estos problemas son presentadas en [19].

40
CAPÍTULO 2. Revisión de la literatura José Ernesto Pérez Robles

Teorema de la controlabilidad sin bloqueos

Teorema (Teorema de Controlabilidad Sin Bloqueos TCSB)

Considere el SED G = (X, E, f, Γ, x0 , Xm ) donde Enc ⊆ Ees el conjunto de eventos no-


controlables. Considere el lenguaje K ⊆ ℒm (G), donde K = ∅ . Entonces un
supervisor S es “no-bloqueado” para G, tal que

ℒm (S/G) = K y ℒ(S/G) = K

Si y solo si permanecen las dos de las siguientes condiciones:

 Controlabilidad: 𝐾 𝐸𝑛𝑐 ∩ ℒ 𝐺 ⊆ 𝐾
 ℒ𝑚 𝐺 − 𝑐𝑒𝑟𝑟𝑎𝑑𝑢𝑟𝑎:𝐾 = 𝐾 ∩ ℒ𝑚 𝐺

La primera condición se refiere a lo visto anteriormente en el teorema de la


controlabilidad y la segunda se refiere a la necesidad de que el controlador
permanezca sin bloqueo.

Control con especificaciones modulares y locales modulares

Hasta el momento se ha definido la forma de realizar supervisores sin problemas


de controlabilidad ni de bloqueos, sin embargo en términos prácticos o de
aplicación de control supervisorio, el principal reto es buscar la simplicidad, debido
a que al diseñar una especificación para un controlador monolítico (como lo
diseñado hasta ahora) e ir complementando dicha especificación, ésta crece de
manera exponencial hasta llegar al punto de no ser práctica o volverse intratable
en ciertos casos. Muchas veces esa especificación está formada por “sub-
especificaciones” que pudieran separarse y crear especificaciones individuales
para generar supervisores modulares. En esta sección se presentará una de las
formas que existen para aprovechar más la modularidad del sistema y las
especificaciones, con la finalidad simplificar algunos problemas muy extensos y
hacer un control viable para su implementación.

41
CAPÍTULO 2. Revisión de la literatura José Ernesto Pérez Robles

Asumamos que un SED dado necesita ser controlado para que cumpla ciertas
especificaciones que se encargan de la seguridad del sistema. Consideremos
ahora que dicha especificación de define mediante el lenguaje La (la a se refiere a
admisible), la cual puede ser descompuesta o está dada como la intersección de
dos lenguajes de prefijo cerrado

La = La1 ∩ La2

Esto aplica para cualquier número finito de especificaciones compuestas mediante


intersección, sin embargo por simplicidad solo hablaremos del caso de dos
especificaciones individuales. Supongamos entonces que el supervisor S1 ha sido
sintetizado para que el sistema mantenga el comportamiento deseado La1 y que el
supervisor S2 se encarga del comportamiento definido por La2 . Consistentemente
con la forma de La se define la siguiente estructura de control la cual es una
arquitectura de control modular que se muestra en la Figura 2.12 donde la red de
control de G es la conjunción (o intersección) de las respectivas acciones de
control de S1 y S2 .

Figura 2. 12 Control modular con dos supervisores

Formalmente, dados los supervisores admisibles S1 y S2 cada uno definido para el


SED G, se define el supervisor modular Smod 12 : ℒ G → 2E correspondiente a la
conjunción de S1 y S2 como sigue:

Smod 12 s ≔ S1 (s) ∩ S2

42
CAPÍTULO 2. Revisión de la literatura José Ernesto Pérez Robles

Esto significa que un evento es habilitado por Smod 12 si y sólo si este es habilitado
por S1 y S2 , en otras palabras, es suficiente con que un solo supervisor deshabilite
un evento, para que éste sea deshabilitado por el supervisor Smod 12 , en esta
arquitectura de control modular. De una manera sencilla se puede verificar que el
comportamiento del sistema en lazo-cerrado se encuentra bajo control si

ℒ Smod 12 /G = ℒ(S1 /G) ∩ ℒ(S2 /G)

Lm Smod 12 /G = ℒm (S1 /G) ∩ ℒm (S2 /G)

De nuevo, aquí se pudiera hacer la realización de los supervisores en forma


conjunta, pero en este punto el consejo es no hacerlo, si no implementar los
supervisores de manera individual lo que es más práctico y además permite
cambiar de manera independiente la especificación de cada uno de ellos sin tener
que realizar de nuevo el cambio completo de un supervisor total o monolítico. De
igual manera, en esta estructura de control, es importante verificar que no exista
bloqueo ni conflicto entre los supervisores, es decir que todos los estados
deseados sean alcanzables y co-alcanzables por los supervisores. Por último al
agregar el término de modularidad local en este trabajo, nos estamos refiriendo a
este tipo de estructura modular con la diferencia de que cada supervisor solo ve la
parte que le incumbe de la planta a controlar como se fundamenta en [4].

Robustez en el control de sistemas de eventos discretos

En general, el concepto de control robusto está disponible para el control de


sistemas que presentan incertidumbre, cuya dinámica sólo se conoce
parcialmente. Mientras que la teoría de control robusto se ha estudiado
extensamente para los sistemas dinámicos continuos, existen relativamente pocos
resultados para el control robusto de SED y estos se basan en resolver diferentes
tipos de incertidumbre. En (20), la incertidumbre del modelo se asume como sigue:
aunque el modelo exacto de un sistema no es conocido, éste pertenece a un
conjunto de algunos modelos posibles. La tarea de la supervisión robusta consiste

43
CAPÍTULO 2. Revisión de la literatura José Ernesto Pérez Robles

en sintetizar un supervisor en base a un comportamiento deseado para cualquier


modelo dentro de ese conjunto.

Por otra parte, el objetivo de [21] es especificar las condiciones y los algoritmos
que permiten la identificación del modelo adecuado en un número finito de
transiciones.

Recientemente, otros enfoques para modelar la incertidumbre en la estructura de


transición de los SED se han desarrollado para los sistemas no deterministas. El
trabajo de [22], introduce el formalismo del modelo de trayectoria para modelar un
comportamiento no determinista. Además, la composición sincrónica de prioridad
(CSP) se introduce al modelo de la interacción de un sistema y un supervisor. En
[23] y [24] se muestra que el control supervisorio de un SED no determinista
puede conseguirse utilizando la CSP como mecanismo de control y modelos de
trayectoria como un formalismo de modelado.

En (24), en particular, se demuestra que la noción usual de no bloqueo, puede no


ser adecuada en el entorno de los sistemas no deterministas, y una noción más
fuerte, llamada modelo de trayectoria, es necesaria para lograr un control
supervisorio de no bloqueo en sistemas no deterministas [2].

En este trabajo, en cuanto a robustez se refiere, se propone un nuevo marco


sobre el modelado de las especificaciones. En este nuevo contexto no existe
incertidumbre en los sistemas, sin embargo el hecho abarcar un completa
especificación muchas veces vuelve intratable al sistema, por ello, usando los
marcos de la modularidad y la modularidad local de [25], [11], [26] y [4] en
conjunto con un poco de la teoría de colas, se propone un sistema de red de
memorias, cuyo principal propósito es introducir de manera eficiente la mayor
cantidad de información en una especificación, sin que ésta se vuelva intratable.
Con esto se logra, mayor robustez al sistema debido a que de “manera ideal”, no
hay ninguna situación de interés, originada por el sistema que no esté
contemplada en la especificación.

44
CAPÍTULO 3. EJEMPLOS BÁSICOS DE AUTÓMATAS Y CONTROL
SUPERVISORIO MEDIANTE TCT, SUPREMICA Y GRAFCET
(IMPLEMENTACIÓN).

En esta sección se describirán de forma básica como se aplica la TCS dentro de la


teoría de SED y se aprovechará para presentar de manera rápida el uso del TCT y
Supremica, que son dos paquetes computacionales que servirán de herramienta
principal durante esta tesis para la modelación de los SED, cada uno de estos
programas posee sus propias ventajas y desventajas, el usuario podrá decidir,
después de esta sección, cual es el más conveniente para resolver algún
problema en especial o cual satisface mejor sus gustos y necesidades.

3.1 Ejercicios de Control Supervisorio Mediante TCT (Toy Control


Theory)

A continuación se presentará un ejercicio de control supervisorio realizado en


TCT, en esta ocasión se presentará todo el proceso de la creación de los
autómatas como una herramienta didáctica para el uso del TCT y como
documentación de las implementaciones de los ejercicios en este programa, sin
embargo en lo posterior sólo se documentarán los resultados. Es importante
mencionar que este programa no genera imágenes de los autómatas creados, si
se necesitan las imágenes de dichos autómatas, se pueden utilizar otras
aplicaciones para convertir los archivos generados en las figuras necesarias, esto
se documenta en la sección de anexos como Guía rápida para la generación de
imágenes de autómatas con Graphviz. Para más información acerca de este
programa se recomienda revisar [17], [12], entre otros.

El ejemplo a tratar consiste en la modelación de una planta formada por dos


máquinas (figura 3.1), cada una de ellas representada mediante un autómata de
dos estados, reposo (idle) y trabajando (working), su alfabeto posee solo dos
eventos, uno controlable (arranca) y otro no controlable (proceso terminado), los
cuales están representados por números, nones y pares, respectivamente. El uso
de números es parte de la sintaxis del TCT.
CAPÍTULO 3 Ejemplos básicos de autómatas y control supervisorio José Ernesto Pérez Robles

Una vez obtenida la planta se declarará la especificación que se desea cumplir


para finalizar con la implementación del supervisor correspondiente.

Figura 3. 1 Modelo de la máquina 1.

Para comenzar a crear nuestros autómatas se da doble click sobre la aplicación


del CTCT para ejecutarla y aparecerá la siguiente pantalla de inicio mostrada en la
figura 3.2.

Figura 3. 2 Pantalla de inicio del TCT

Una vez que se tiene la pantalla mostrada anteriormente, el primer paso será
presionar la tecla enter y en la pantalla que se presentará continuación oprimir la
tecla T para elegir la opción los procedimientos de TCT. Esto se muestra en la
figura 3.3.

46
CAPÍTULO 3 Ejemplos básicos de autómatas y control supervisorio José Ernesto Pérez Robles

Figura 3. 3 Menú principal del TCT

El siguiente paso es crear un autómata, seleccionando la opción “0” del menú


mostrado en la pantalla de la figura 3.4.

Figura 3. 4 Menú de procedimientos TCT.

En la figura 3.5 se elige la opción 1 para crear un archivo .DES del autómata, esta
extensión se refiera al un archivo tipo SED.

47
CAPÍTULO 3 Ejemplos básicos de autómatas y control supervisorio José Ernesto Pérez Robles

Figura 3. 5 Primer paso en la creación de un autómata con TCT.

El siguiente paso será asignar el nombre al autómata, en este caso se llamará


“MAQUINA1”; después se deberá ingresar el dato del número de estados que se
desea para dicho autómata. En las siguientes dos figuras, figuras 3.6 y 3.7, se
presentan las pantallas que aparecen al realizar estos pasos.

Nota: es importante leer las notas que proporciona la aplicación TCT en el proceso
en cuestión. Por ejemplo, tomar en cuenta que el estado inicial será el estado “0”.

Figura 3. 6 Pantalla de establecimiento del nombre del autómata.

48
CAPÍTULO 3 Ejemplos básicos de autómatas y control supervisorio José Ernesto Pérez Robles

Figura 3. 7 Pantalla para seleccionar el número de estados del autómata.

Lo siguiente que se debe hacer es teclear la lista de estados marcados, en este


caso solamente marcaremos el estado “0” (Idle). Al terminar se deberá teclear -1
para continuar con el siguiente paso.

Una vez finalizada la declaración de los estados marcados, se deberán introducir


los estados vocales, como en este caso no son necesarios solo se deberá teclear
“-1”. Lo descrito en estos dos párrafos se ilustra en las figuras 3.8 y 3.9.

Figura 3. 8 Pantalla para ingresar los estados marcados del autómata.

49
CAPÍTULO 3 Ejemplos básicos de autómatas y control supervisorio José Ernesto Pérez Robles

Figura 3. 9 Pantalla para ingresar los estados vocales

Lo que sigue es declarar los estados y las transiciones entre ellos de acuerdo con
la sintaxis que se va solicitando en la aplicación, es un procedimiento sencillo pero
es importante ir leyendo lo que se pide para evitar cometer errores. En caso de
que se cometa algún error, es recomendable apuntar dicho error y seguir
declarando las transiciones del autómata que se desea, y al final regresar al menú
principal para que mediante un menú de edición del autómata, se corrija el error
cometido.

Figura 3. 10 Pantalla para ingresar la función f o lista de transiciones.

50
CAPÍTULO 3 Ejemplos básicos de autómatas y control supervisorio José Ernesto Pérez Robles

Figura 3. 11 Ejemplo de donde se presentan las transiciones declaradas para el autómata


maquina1.

Por último, se verifica que el autómata haya sido ingresado correctamente.

Figura 3. 12 Pantalla final de la creación del autómata que verifica si es o no determinístico.

Al final de este proceso automáticamente se genera un archivo del tipo .DES. Si


se desea generar el diagrama de transición estados del autómata a partir de este
archivo, se siguen los pasos mostrados el anexo.

51
CAPÍTULO 3 Ejemplos básicos de autómatas y control supervisorio José Ernesto Pérez Robles

El diagrama de transición de estados del autómata “maquina 1” se presenta en la


figura 3.13.

Figura 3. 13 Autómata generado de la máquina 1.

Se propone ahora el autómata “máquina 2” de manera que quede modelado como


se muestra en la figura 3.14. Nótese que los eventos se llaman de manera
diferente esto con la finalidad de diferenciar los eventos de la máquina uno con los
eventos de la máquina dos y de esta manera poder realizar operaciones de
composición entre dichos autómatas.

Figura 3. 14 Modelo del autómata máquina 2.

Una vez que ya se tiene toda la información para crear el autómata de la máquina
dos, se procede a crear éste de la misma manera como se creó el autómata de la
máquina 1. Finalmente queda:

Figura 3. 15 Autómata de la máquina 2.

52
CAPÍTULO 3 Ejemplos básicos de autómatas y control supervisorio José Ernesto Pérez Robles

Hasta este momento se han generado los dos autómatas que integrarán la planta
que se requiere controlar, para generar la planta es necesario recordar en qué
cosiste la operación “composición paralela” descrita anteriormente, si se efectúa
esta operación entre los dos autómatas generados, obtendremos la planta
deseada. En TCT a dicha operación se le denomina SYNC que viene de la palabra
sincronización en inglés.

En la figura 3.3 se muestra el menú principal del programa TCT dónde se deberá
elegir la opción 3 (SYNC) para sincronizar los autómatas “MAQUINA1” y
“MAQUINA2” previamente creados. El autómata resultante lleva por nombre
MAQUINA12, como se muestra en la figura 3.16. Para visualizar cualquier SED
creado mediante el TCT se selecciona teclea la opción SE en el menú principal y
el nombre del autómata deseado, en este caso MAQUINA12 se muestra en la
figura 3.17.

Figura 3. 16 Sincronizando “MAQUINA1” Y “MAQUINA2”.

53
CAPÍTULO 3 Ejemplos básicos de autómatas y control supervisorio José Ernesto Pérez Robles

Figura 3. 17 Mostrando mediante TCT el autómata MAQUINA12.

El diagrama de transición de estados de la planta generada mediante la


sincronización realizada, se presenta en la figura 3.18.

Figura 3. 18 Panta a controlar (sincronización de MAQUINA1 con MAQUINA2).

La planta generada hasta este momento representa todas las posibles evoluciones
de estados y eventos que se pueden presentar al juntar las dos máquinas (sin
control). Sin embargo, cuando se desea que la planta se comporte de acuerdo a
ciertas especificaciones dadas, es necesario, agregar un controlador, la manera
de realizar esto se presenta a continuación.

En primer lugar se debe de definir un comportamiento deseado: “especificación”,


el cual lo definiremos de manera verbal como:

54
CAPÍTULO 3 Ejemplos básicos de autómatas y control supervisorio José Ernesto Pérez Robles

Especificación: “La máquina dos siempre deberá arrancar primero que la


máquina uno, sin perder este ciclo, es decir las máquinas deben trabajar en ese
orden, primero la máquina dos y luego la máquina uno.

El autómata construido que representa la especificación preliminar establecida


anteriormente se presenta a continuación en la figura 3.19, cabe mencionar que se
creó de la misma manera cómo se crearon los autómatas: “MAQUINA1” y
“MAQUINA2”.

Figura 3. 19 Especificación preliminar.

En el autómata “especificación preliminar”, generado anteriormente, se puede


apreciar el complimiento de la especificación. Sin embargo al recordar las
operaciones matemáticas necesarias en la generación del controlador (definidas
en el capítulo dos), nos podemos dar cuenta de que si se mantiene así la
especificación, el controlador no permitirá la evolución de los eventos “0” y “2”
debido a que no forman parte del alfabeto de la especificación, en este caso en
particular, no se desea eso, además que son eventos no controlables los cuales
sería imposible evitar. Por tal motivo, al autómata se le deberán agregar los “self-
loops” correspondientes, una manera fácil de agregar los self-loops
correspondientes a los eventos que no forman parte del alfabeto de la
especificación, es declarar un autómata que contenga un sólo estado, sobre el
cual se agreguen todos los eventos del alfabeto de la planta y sincronizarlo con la
especificación preliminar creada. En este caso llamaremos “all” al autómata
generado con un sólo estado y todo el alfabeto.

55
CAPÍTULO 3 Ejemplos básicos de autómatas y control supervisorio José Ernesto Pérez Robles

Figura 3. 20 Autómata All.

Sincronizando “all” con el autómata “especificación preliminar” se obtiene por fin


el autómata que representará la “especificación final” y se muestra en la figura
3.21.

Figura 3. 21 Autómata “Especificación Final”.

Como se puede apreciar en la figura 3.21 a los dos estados de la especificación


se le generaron, los self-loops correspondientes. Esta estrategia, de crear un
autómata “all”, es de gran ayuda sobre todo en autómatas más complejos.

Una vez que ya se tiene la planta y la especificación deseadas, se procede a crear


el controlador, para esto dentro del menú principal del TCT se teclea la opción 5,
es decir: “SUPCON”, y de misma manera en que se han venido trabajando las
demás funciones del TCT, se teclea primero el nombre de la planta en este caso
“MAQUINA12”, posteriormente el nombre de la especificación “ESPECIFICACION”
y para finalizar se le asigna el nombre al controlador, en este caso
“SUPERVISOR”. En la figura 3.21 se puede apreciar lo descrito en este párrafo y
en la figura 3.22 el sistema ya bajo la acción de este supervisor.

56
CAPÍTULO 3 Ejemplos básicos de autómatas y control supervisorio José Ernesto Pérez Robles

Figura 3. 22 Autómata del controlador: “SUPERVISOR”.

Figura 3. 23 Planta bajo control

La mayoría de las veces, es necesario, además de conocer el autómata del


supervisor, conocer al acciones de control que éste realiza, para generar estos
datos mediante el TCT se utiliza la opción 7 (“CONDAT”) en la cual se teclea
primeramente el nombre de la planta, posteriormente el nombre del controlador y
finalmente se le asigna un nombre a los datos generados. Para verificar estos
datos se teclea dentro del menú principal del TCT la opción “SA” y el nombre del
archivo de los datos de control en este caso “CONDAT” y aparecerá una pantalla
que nos señalara si el sistema es controlable y los eventos que el supervisor
deshabilitará en cada estado para poder cumplir con la especificación requerida.

57
CAPÍTULO 3 Ejemplos básicos de autómatas y control supervisorio José Ernesto Pérez Robles

En la figura 3.24 se muestra como la generación de los datos de control en TCT.

Figura 3. 24 Generando los datos de control del sistema.

Figura 3. 25 Datos de control generados mediante la opción CONDAT.

En la figura 3.25, se muestra que el sistema es controlable, también se ve que


todos los eventos que son deshabilitados por el controlador son eventos nones, es
decir controlables, lo cual es correcto y al seguir el diagrama de transición de
estados se verifica que el sistema cumple con la especificación solicitada.

58
CAPÍTULO 3 Ejemplos básicos de autómatas y control supervisorio José Ernesto Pérez Robles

Hasta este punto es importante notar que las especificaciones no tienen que ser
“literalmente” un subconjunto exacto del autómata de la planta, esto quiere decir
que las especificaciones no son necesariamente un recorte exacto de diagrama de
transición de la planta, si no que tienen una interpretación propia. Por último, es
necesario recordar que de acuerdo a la teoría presentada en el capítulo dos, lo
realizado anteriormente se refiere a un controlador monolítico, sin embargo la
creación de controladores modulares en el TCT es muy parecida a la realizada
hasta ahora, al grado que se vuelve intuitiva, por tal motivo no se presentará en
este texto.

3.2 Ejercicios de Control Supervisorio Mediante Supremica

Con la finalidad de enriquecer la TCS con nuevos ejemplos, se propone un


ejemplo a desarrollar, el cual también servirá para presentar el software
“Supremica”, cuyo manual básico se presenta en la sección de anexos.
Información detallada acerca de Supremica es presentada en [18] y [19].

El ejemplo que se propone a continuación mostrará el uso de supervisores


modulares y también proveerá una modelación de máquinas con un poco más de
detalle. Es decir, presentará estados de carga y descarga de cada máquina, los
cuales no se presentaban en el ejercicio anterior realizado en TCT. Esto no quiere
decir que dicha modelación sea mejor ni peor, sólo que el nivel de detalle de la
modelación dependerá de lo que se requiera para una situación en particular.

Presentación del ejercicio

Una planta está formada por dos máquinas independientes “M1” y M2” las cuales
son cargadas y descargadas por un “Robot”, los autómatas que modelan estas
máquinas y el robot se presentan en la figura. 3.26

59
CAPÍTULO 3 Ejemplos básicos de autómatas y control supervisorio José Ernesto Pérez Robles

Figura 3. 26 Autómatas de la maquina 1, maquina 2 y el robot.

Recordemos que ahora se realizará todo el proceso de síntesis de supervisores en


Supremica, otra gran herramienta de modelación de autómatas, y por lo tanto
cambiarán algunos aspectos, en cuanto a sintaxis se refiere. El signo de
admiración a la izquierda de los eventos se refiere a que son eventos no
controlables. La interpretación de los estados se presenta en la tabla 1.

Tabla 1 Estados y eventos con su interpretación

ESTADO INTERPRETACIÓN EVENTOS INTERPRETACIÓN


R1 Reposo Máquina 1 RC1/RC2 Realizar Carga de Máquina 1/2
C1 Carga de Máquina 1 RM1/RM2 Realizar Maquinado en Máquina 1/2
M1 Maquinando Máquina1 RD1/RD2 Realizar Descarga de Máquina 1/2
D1 Descarga de Máquina 1 FD1/FD2 Finaliza Descarga de Máquina 1/2
R2 Reposo Máquina 2 FC1/FC2 Finaliza Carga de Máquinas 1/2
C2 Carga de Máquina 2
M2 Maquinando Máquina2
D2 Descarga de Máquina 2
RR Reposo Robot
CM1 Cargando Máquina 1
CM2 Cargando Máquina 2
DM1 Descargando Máquina 2
DM2 Descargando Máquina 3

60
CAPÍTULO 3 Ejemplos básicos de autómatas y control supervisorio José Ernesto Pérez Robles

Para poder generar el modelo de la planta en Supremica, se deben sincronizar los


autómatas presentados en la figura 3.25.Es decir, realizar la operación de
composición paralela entre ellos. Para llevar cabo la sincronía de estos autómatas,
una vez creados conforma lo presentado en el anexo, nos colocamos en la
sección del analizador, se seleccionan los tres autómatas que se desean
sincronizar y se elige la opción “Analyze  Synchronize”. Esto genera la planta
deseada. Nótese que en Supremica todos los autómatas generados dentro del
menú del analizador no se guardarán a menos que se le indique. La planta
deseada se presenta en la figura 3.28, la cual pose en total 27 estados, 48
transiciones y ningún “dead-lock”, esto se puede checar mediante la opción de
“estadísticas” dentro del menú de “Analyze”. El resultado se muestra en la figura
3.27.

Figura 3. 27. Estadísticas de la planta creada

Como se pretende utilizar supervisores modulares, se definirán dos


especificaciones. Una va a asegurar de que la máquina uno no empiece a trabajar
hasta que el robot haya finalizado la carga de dicha máquina. La segunda se
encargará del mismo proceso pero aplicado a la máquina dos. Las
especificaciones quedan modeladas como se muestra en la figura 3.29.

61
CAPÍTULO 3 Ejemplos básicos de autómatas y control supervisorio José Ernesto Pérez Robles

Figura 3. 28 Planta generada mediante las dos máquinas y el robot.

62
CAPÍTULO 3 Ejemplos básicos de autómatas y control supervisorio José Ernesto Pérez Robles

Figura 3. 29 Especificación 1 para el supervisor 1.

Los supervisores generados mediante la especificación uno y la especificación dos


de realizan mediante la opción “Analyze  Synthesize”, el resultado de estos se
presentan en la Figura 3.30 y la Figura 3.31.

Si se selecciona la planta y el supervisor uno, se puede mediante la opción de


“estadísticas”, verificar que el sistema es controlable, que posee veinticuatro
estados alcanzables y cuarenta y una transiciones. Es decir eliminó tres estados
de la planta original y siete transiciones. Y como es de esperarse, debido a que las
especificaciones son simétricas el supervisor dos al igual que el supervisor uno
posee el mismo número de estados y transiciones, con la única diferencia que
estos eventos están enfocados en el control de los estados de la máquina dos.

Aprovechando este ejemplo se puede ver el funcionamiento de los dos


supervisores trabajando juntos al sincronizarlos. La otra opción para lograrlo es
sincronizar las especificaciones y generar un supervisor monolítico con la
especificación resultante. El resultado del supervisor general se presenta en la
figura 3.32.

63
CAPÍTULO 3 Ejemplos básicos de autómatas y control supervisorio José Ernesto Pérez Robles

Figura 3. 30 Supervisor de la especificación 1.

64
CAPÍTULO 3 Ejemplos básicos de autómatas y control supervisorio José Ernesto Pérez Robles

Figura 3. 31 Supervisor de la especificación 2.

65
CAPÍTULO 3 Ejemplos básicos de autómatas y control supervisorio José Ernesto Pérez Robles

Figura 3. 32 Supervisor general.

Es importante notar en la figura 3.32 que en vista de que las especificaciones no


se oponen entre sí, tampoco lo hacen los supervisores (propiedad de “non
conflict”) y esto genera un sistema controlable con veintiún estados (tres
eliminados por el supervisor uno y tres por el supervisor dos) con todo y sus
transiciones. Una forma manual de comprobar el correcto funcionamiento del
sistema es seguir diferentes palabras de eventos a lo largo del diagrama de
transición de estados de la planta, esto se hará para la validación de la solución de
los problemas del capítulo cuatro.

66
CAPÍTULO 3 Ejemplos básicos de autómatas y control supervisorio José Ernesto Pérez Robles

3.3 GRAFCET e implementación de supervisores discretos en un PLC

El GRAFCET o “GRAphe de comande Etape Transition”, es un lenguaje de


programación de PLCs que proviene de un esfuerzo entre personal académico y la
industria por ayudar al programador y/o usuario a lograr una mejor representación
y entendimiento del control de los SED, incluyendo su programación. También es
conocido como el lenguaje de programación SFC (Sequential Function Chart).

Este lenguaje de programación es un grafo o diagrama funcional normalizado, que


permite hacer un modelo del proceso a automatizar, contemplando entradas,
acciones a realizar, y los procesos intermedios que provocan estas acciones.
Inicialmente fue propuesto para documentar la etapa secuencial de los sistemas
de control de procesos de eventos discretos. En la actualidad aún no tiene una
amplia difusión como lenguaje, puesto que algunos de los PLCs no pueden
programarse directamente en este lenguaje y por la costumbre de la industria de
programar en diagramas de escalera debido a su parecido con los diagramas
eléctricos de escalera antes utilizados.

El GRAFCET o SFC, es un diagrama funcional, el cual tiene una directa


representación con los SED que hemos estado tratando. Ejemplos que apoyan
este tipo de lenguaje como una buena herramienta de implementación para los
SED se muestran en [30]. La presentación de un diseño estructurado de control
lógico reconfigurable mediante SFC se aprecia en [31] a través de la ejecución
sincronizada de SED utilizando SFC. En [32] y [33] se hace uso de SFC, la TCS y
la herramienta de modularidad en una celda automatizada de ensamble, entre
otros. Por lo tanto, en esta sección se menciona a grandes rasgos algunas
características principales de este lenguaje de programación, que nos facilitará la
implementación de nuestros autómatas un PLC, además de los trabajos citados en
este párrafo existe mucha más información que habla más del propio lenguaje que
de sus aplicaciones, y si bien es cierto es mucha de esa información es algo
antigua sigue siendo válida en la mayoría de los casos. También se pueden
consultar los manuales que provee cada fabricante de PLCs.

67
CAPÍTULO 3 Ejemplos básicos de autómatas y control supervisorio José Ernesto Pérez Robles

Condiciones y eventos en GRAFCET

En GRAFCET, una etapa está definida por su estado interno y el estado de sus
salidas. Es decir, en cada etapa del GRAFCET se pueden ejecutar o detener
acciones (salidas), o cuestiones internas como memorias, temporizadores, entre
otros. Las condiciones o eventos representan la información que define el
comportamiento del controlador lógico. Es decir, los eventos son la condición
necesaria que se deberá cumplir para que el GRAFCET evolucione de una etapa
a otra. El estado de un SED siempre puede ser definido por valores booleanos, es
decir los eventos continuos pueden ser discretizados usando variables discretas.

La ocurrencia de un evento, que no tiene duración fija, provoca un cambio en el


estado del sistema. La notación utilizada para indicar que un evento ha ocurrido
con una transición positiva es: ↑ x1 y para una transición negativa es:↓ x1 .

Definiciones importantes en el álgebra de eventos.

En el álgebra de eventos de Grafcet existen algunas definiciones importantes


como lo son:

 Dos eventos 𝑒1 y 𝑒2 son independientes si no existe ningún evento 𝑒𝑖 que


los relacione.
 Se denomina 𝑒1 = ∅ si 𝑒1 es un evento que no puede ocurrir.
 Si 𝑒1 = 𝑒2 entonces los dos eventos suceden SIEMPRE al mismo tiempo.
 El producto de un evento y una condición es un evento.
 La probabilidad de que los dos eventos independientes sucedan al mismo
tiempo es CERO.
 Los teoremas del álgebra booleana se aplican en los SED

68
CAPÍTULO 3 Ejemplos básicos de autómatas y control supervisorio José Ernesto Pérez Robles

Principios básicos de programación en GRAFCET

Para realizar un programa en GRAFCET, se deberán tener en cuenta los


siguientes principios básicos:

 Se descompone el proceso en etapas que serán activadas una tras otra.


 A cada etapa se le asocia una o varias acciones que sólo serán efectivas
cuando la etapa esté activa.
 Una etapa se activa cuando se cumple la condición de su transición.
 El cumplimiento de una condición de transición implica la activación de la
etapa siguiente y la desactivación de la etapa precedente.
 Nunca puede haber dos etapas o dos condiciones consecutivas, siempre
deben de ir colocadas manera alternante.

Elementos de programación

Para programar un autómata en GRAFCET es necesario conocer cada uno de los


elementos propios de los cuales consta este tipo de programación. En la tabla 2 se
muestran los más comunes.

Para el caso de estudio de esta tesis con los elementos mostrados en la tabla 5
bastará para la implementación de la solución presentada, como se podrá
observar estos elementos de programación generan diagramas muy similares a
los generados anteriormente en la modelación de nuestros autómatas, por lo tanto
gráficamente también los modelos tendrán un parecido con los programas
implementados y eso servirá como herramienta de validación en la
implementación.

Cabe mencionar, que la programación en GRAFCET en algunos PLCs, se lleva a


cabo en tres etapas: preliminar, GRAFCET y posterior, el uso de estas etapas
dependerá del programador y del dispositivo que se esté utilizando

69
CAPÍTULO 3 Ejemplos básicos de autómatas y control supervisorio José Ernesto Pérez Robles

Tabla 2 Elementos de programación en GRAFCET.

Símbolo Nombre Descripción

Indica el comienzo del esquema GRAFCET y se


Etapa inicial activa al poner en RUN el autómata. Por lo general
suele haber una sola etapa de este tipo.

Su activación lleva consigo una acción o una


Etapa
espera.

Las uniones se utilizan para unir entre sí varias


Unión
etapas.

Condición para desactivarse la etapa en curso y


Transición activarse la siguiente etapa, Se indica con un trazo
perpendicular a una unión.

Indica la activación de una u otra etapa en función


Direccionamiento
de la condición que se cumpla primero.

Proceso Muestra la activación o desactivación de varias


simultáneo etapas a la vez.

Cabe mencionar, que además de los elementos mostrados en la tabla 2, existen


otras herramientas muy útiles dentro de lo que es GRAFCET, como lo son: las
macro acciones, macro etapas, etc. Dichas herramientas son de gran ayuda para
la programación en GRAFCET, sobre todo al crecer la cantidad de etapas en los
autómatas. Sin embargo, esas otras herramientas no se presentarán en este
trabajo debido a que no serán necesarias en nuestra implementación y no son el
caso de estudio de esta tesis.

70
CAPÍTULO 3 Ejemplos básicos de autómatas y control supervisorio José Ernesto Pérez Robles
Implementación de los modelos de autómatas en un PLC

Como se mencionó al inicio de este trabajo, uno de los objetivos de esta tesis es
disminuir la distancia que hay entre la academia y la industria, y para lograr esto
se presentará de manera detallada como es el paso de la modelación de nuestros
autómatas a un programa en GRAFCET.

Una vez que ya hemos visto como se modelan los autómatas, sus fundamentos
teóricos y que elementos forman parte de la programación en GRAFCET, se
procederá a realizar un ejemplo básico de implementación para lograr una
completa transparencia desde la modelación hasta la implementación.

Consideremos en primer lugar dos pistones neumáticos de los cuales nos interesa
modelar sus estados de “ocio” y “trabajo”. Además, nos interesa que mediante un
programa de control estos pistones trabajen alternadamente, es decir primero el
primer pistón (máquina 1) y después el segundo pistón (máquina dos) y así
sucesivamente.

La planta física simulada en Automation Studio (AS) se presenta a continuación en


la figura 3.33.

Figura 3. 33 Equipo neumático simulado en Automation Studio.

Con todos mencionados se procederá a modelar en Supremica los autómatas que


formarán nuestro sistema. En primer lugar se modelarán los pistones (figura 3.34).

71
CAPÍTULO 3 Ejemplos básicos de autómatas y control supervisorio José Ernesto Pérez Robles

Figura 3. 34 Modelos de las máquinas

Los modelos de las máquinas presentados en la figura 3.34 son los que se deben
implementar en el PLC una vez probado el sistema media Supremica. La primera
prueba que se hace es sincronizar estos autómatas para ver cuáles son las
posibles combinaciones de estados que existen y ver si alguna cumple con los
requerimientos solicitados. En la figura 3.35 se muestra la sincronización de los
autómatas M1 y M2.

Figura 3. 35 Todos los posibles estados que genera la planta sin control.

72
CAPÍTULO 3 Ejemplos básicos de autómatas y control supervisorio José Ernesto Pérez Robles
Como se puede apreciar un la figura 3.35, existes “caminos” o palabras que se
pueden ejecutar que violan lo que se había solicitado anteriormente. Es decir, la
planta sin control permite que cualquiera de los cilindros trabaje en el orden que
sea y pueden trabajar en forma consecutiva. Por lo tanto, la especificación que se
va a modelar para probarla en el modelo y después implementarla en el PLC es la
que se presenta en la figura 3.36, es decir debe trabajar primero la máquina uno y
estas se deben de ir alternando.

Figura 3. 36 Especificación para controlar los cilindros neumáticos

Figura 3. 37 Planta bajo la acción del supervisor

73
CAPÍTULO 3 Ejemplos básicos de autómatas y control supervisorio José Ernesto Pérez Robles
En la figura 3,37 se puede observar la planta bajo la acción del supervisor, la cual
cumple con las especificaciones establecidas. Al ser el autómata de la figura 3.37
relativamente pequeño, el correcto funcionamiento del sistema se puede verificar
de manera manual al seguir las diferentes trayectorias del grafo, aunque también
se pueden usar las herramientas de Supremica para verificar la controlabilidad del
sistema.

Una vez comprobado el correcto funcionamiento del sistema se procede a realizar


la implementación del mismo, mediante GRAFCET, en un PLC. Lo primero que se
debe implementar es los autómatas de la planta, figura 3.38. Como se puede
observar la relación entre estados de los autómatas y etapas de GRAFCET no
siempre es uno a uno, sin embargo lo que es importar es que mantengan el mismo
significado. En este caso en particular, las etapas 1 y 4 de los GRAFCET
representan el estado de ocio de M1 y M2, respectivamente. Las etapas 2 y 3
representan al estado “trabajando” en la primera máquina, es decir el trabajo del
cilindro se representa mediante su extensión y retracción por tal motivo abarca
esas dos etapas y lo mismo sucede con las etapas 5 y 6 para el cilindro 2.

Figura 3. 38 GRAFCETS de las máquinas en AS.

74
CAPÍTULO 3 Ejemplos básicos de autómatas y control supervisorio José Ernesto Pérez Robles

Hablemos ahora de los eventos en los autómatas de la figura 3.38. Los eventos
“Start1” y “Start2” son representados por el botón de arranque de cada cilindro (en
este ejercicio por simplicidad se usa un solo botón y dejará accionado para el
trabajo de las máquinas en automático) y el sensor que indica que cada uno de
ellos está en reposo antes de iniciar su trabajo. Como se puede observar al ser un
botón éstos eventos son controlables, sin embargo los siguientes eventos no los
son, debido a que simplemente son sensores de inicio y fin de carrera de cada
cilindro sobre los cuales no se tienen ningún control. En el caso de la figura 3.33
los sensores s1 y s3 que indican que el cilindro uno y el cilindro dos han llegado su
posición de reposo, respectivamente. Por lo tanto, estos sensores representan los
eventos !End1 y !End2 respectivamente.

Hasta este momento ya se tiene implementada la planta. Es decir, al haber


declarado ya las acciones (extender y retraer), en las etapas de cada uno de los
cilindros y al haber definido sus transiciones estos son capaces de comenzar a
moverse figura 3.38. Sin embargo, al arrancar la planta sin haber implementado la
especificación esta no seguirá un comportamiento deseado, es decir podrá entrar
en todos los estados presentados en la figura 3.35 sin importar si algunos de ellos
son deseados o no. Por lo tanto es necesario implementar la especificación que se
encargará de controlar a los cilindros, la implementación de dicha especificación
se muestra en la figura 3.39.

Figura 3. 39 Especificación implementada

75
CAPÍTULO 3 Ejemplos básicos de autómatas y control supervisorio José Ernesto Pérez Robles

Como se puede apreciar en la figura 3.39, en cuanto al grafo se refiere, éste es


muy similar al presentado en la figura 3.36, lo cual es normal. Esto sucede debido
a que las especificaciones no realizan acciones, su trabajo es ir monitoreando las
evoluciones que le corresponden y por tal motivo su relación entre estados y
etapas sí es uno a uno. A manera de comprobación se puede observar que
ninguna de las etapas del GRAFCET de la especificación presenta acciones, a
diferencia de las etapas de los cilindros. En cuanto a los eventos que posee
evidentemente son los mismos que presentan los autómatas como “Start1” y
“Start2” porque así había sido modelada. Ahora lo único que resta es establecer la
acción de control dentro de la planta. Como ya se mencionó anteriormente las
acciones de control de los supervisores discretos solo consisten en activar o
desactivar, eventos controlables. Para lograrlo en la implementación es necesario
añadir a los eventos controlables de la planta que estén incluidos en la
especificación la condición de que la especificación deba estar en el estado
correcto para que se permita la evolución. En el caso del cilindro uno en la
condición que representa el “start1” se le agrega la condición “X7.X” mediante un
“AND”. Es decir ese evento solo provocará una transición si la especificación esta
en el estado 7. De manera análoga, se realiza el mismo procedimiento para la
máquina dos. En la figura 3.40 se muestra la planta con las acciones de control
implementadas, es muy importante notar la diferencia entre la figura 3.40 y la 3.38.

Figura 3. 40 Planta con la acción de control implementada.

76
CAPÍTULO 3 Ejemplos básicos de autómatas y control supervisorio José Ernesto Pérez Robles

Por último se muestra en la figura 3.41 la planta funcionando bajo control


implementada en AS.

Figura 3. 41 Funcionamiento de la planta bajo control.

Se puede concluir entonces que la implementación debe hacerse con mucho


cuidado y sin perder de vista los modelos generados. Por otra parte, es importante
remarcar que aunque en la modelación es importante analizar el autómata de la
planta y el supervisor que generamos, en la implementación solo se programan los
autómatas de las máquinas y la especificación.

77
CAPÍTULO 4. SÍNTESIS DE SUPERVISORES Y SU IMPLEMENTACIÓN

4.1 Solución del problema basado en un proceso real

Muchos de los problemas de automatización en la industria, se resuelven de una


manera eficiente mediante el uso de PLC’s, implementando en éstos los
programas de control que se necesiten para el correcto funcionamiento del
sistema. Sin embargo, dentro de estos programas se incluye tanto el programa de
control, como la planta, sin establecer una diferencia entre estos. Es ahí cuando
toma ventaja la teoría de autómatas y control supervisorio en el marco de
Ramadge-Wonham (R-W), aprovechando sus diferentes modalidades con
controladores monolíticos, modulares y locales modulares.

Ahora bien, existen ejemplos resueltos como los presentados en los primeros
capítulos y otros más cuyo buen funcionamiento se ha reportado en artículos de
distintos autores: [5], [9], [6], [4], [18], [10], [11], [19], [20], [21] y [22], entre otros.
En esos ejemplos se puede observar que el uso de la teoría de control
supervisorio mejoró ampliamente el desempeño de varios sistemas. Sin embargo,
una de las principales desventajas que se presentan en la teoría de SED, en
cuanto a la complejidad se refiere, es precisamente que los autómatas generados
crecen exponencialmente con el incremento de estados y transiciones en los
autómatas modelados. Debido a que muchas veces los autómatas modelados
necesitan ser un poco elaborados y no verse tan limitados en el uso de estados y
eventos, algunos autores han propuesto el uso de supervisores modulares y
modulares locales en [4], [25], [24], [11] y [33] como métodos que ayudan a
disminuir la complejidad de los mismos. Por otro lado, cuando se requiere el uso
de contadores o memorias, los autómatas crecen inevitablemente, por ejemplo en
los casos donde se trabaja con buffers de capacidad uno, y solo se modelan
estados de vacío y ocupado, se vuelve un autómata muy simple de dos estados,
pero conforme aumenta la capacidad del buffer y se precisa el conocimiento total
del mismo, los autómatas aumentan estados, es decir, un autómata con capacidad
dos aumentará a tres estados, uno de capacidad tres, aumentará a cuatro
estados, y así sucesivamente, lo mismo ocurre con el uso de memorias. Esto
provoca, que los grafos resultantes sean intratables en la mayoría de los casos.
CHAPTER 4.SÍntesis de supervisores y su implementación José Ernesto Pérez Robles

Para evitar el aumento de complejidad en algunos modelos industriales,


simplemente se implementan programas mediante eventos que dan prioridad a las
acciones a realizar, y esto en la mayoría de los casos ha dado un muy buen
resultado. Un ejemplo de esto es la programación de un sistema automático de
almacenamiento y retiro materiales (ASRS), por sus siglas en inglés, donde se
puede decidir que cada pieza que llegue al lugar de almacenamiento, sea
depositada en el espacio más cercano que este desocupado. En estos sistemas,
este tipo de especificación es muy eficiente. Sin embargo, existen situaciones
donde este tipo de especificaciones no es precisamente lo más que se requiere,
un ejemplo de estas especificaciones es el que se planteará a continuación con la
finalidad de presentar una solución genérica a ese tipo de problemas.

El problema que se presentará en esta sección está basado en un sistema real y


muy complejo que se encuentra funcionando hoy en día, por cuestiones de
confidencialidad se omitirán más detalles. Este sistema funciona adecuadamente
mediante la priorización en la atención de máquinas, sin embargo se podría
mejorar su funcionamiento e incrementar su robustez al implementar una nueva
solución como se presenta a continuación.

El sistema, en su parte más compleja consta principalmente de cinco máquinas las


cuales interactúan con tres robots, cada una de las máquinas necesita interactuar
primero con el robot uno, después con el robot dos y finalmente el robot tres retira
el producto terminado de dicho proceso, un operario inicia el proceso de las
máquinas (solo una a la vez), después de verificar el correcto estado de la misma.

Lo complejo del sistema es que todas las máquinas trabajan en paralelo y en que
en caso de que una falle el sistema deberá funcionar con las máquinas que
quedan trabajando, (aunque fallen varias máquinas, el sistema deberá funcionar si
al menos una máquina está trabajando). Todo este sistema ya se encuentra
funcionando y lo hace en la mayoría de los casos correctamente, sin embargo el
hecho es que lo ideal sería que cada robot atendiera a cada máquina en el orden
en que éstas están listas, para evitar problemas. Hasta el momento sólo se les da
un orden de atención prioritario.

79
CHAPTER 4.SÍntesis de supervisores y su implementación José Ernesto Pérez Robles

Cabe mencionar que el tiempo de proceso de cada máquina es el mismo y


recordar que es un operario quién inicia el proceso de cada máquina. Si el
operario inicia las máquinas en el orden en que está programada la atención de
las mismas, entonces se cumple el hecho de que la primera que esta lista es la
primera que se atiende. Sin embargo, en caso de haber algún retardo del robot o
alguna falla en la máquina, se puede dar la situación de que al restablecerse el
robot, ya estén más máquinas listas y no precisamente atienda a la que estuvo
lista primero, recordemos que el proceso es cíclico. Se habla de un robot debido a
que es el mismo caso para los tres robots y se comienza a hacer uso del concepto
de la modularidad del sistema. Para entender mejor el sistema se presenta el
siguiente ejemplo.

Ejemplo: (se habla de un robot debido a que es el mismo caso para los tres
robots)

 El robot atenderá las máquinas en orden ascendente. Es decir, primero


atenderá la máquina uno y al final la máquina cinco y recomenzará el ciclo.
 El operario habilitará las máquinas en ese mismo orden.

Imaginemos ahora que el robot sufre un retardo al momento de estar atendiendo


la máquina cuatro y mientras se repara la falla, quedó lista la máquina cinco, y
después la máquina uno. Entonces, al momento el robot listo de nuevo, como
tiene listas la máquina uno y la cinco y como éste está programado de acuerdo
con la especificación de prioridad que se mencionó anteriormente lo que hará es
atender la máquina uno. Y la situación se agrava si en ese momento se alistan en
orden las demás máquinas, pues va a dejar hasta lo último la cinco, pudiendo
inclusive llegarse a dar el caso de que mientras atendió de nuevo a la cuatro,
aunque esta vez lo haga sin retardo, la uno pueda estar de nuevo lista debido a
que el operario después de la cuatro atendió a la uno, ya que la cinco ya estaba
lista desde el ciclo anterior. Son casos que podrían darse y en estos quedaría
ignorada la máquina cinco por más de un ciclo completo y al momento de llegar el
robot a atender dicha máquina, debido al tiempo que transcurrió, es posible que se
produzcan algunos daños en la pieza actual y/o en la que siguiente.

80
CHAPTER 4.SÍntesis de supervisores y su implementación José Ernesto Pérez Robles

Si el daño no se presenta en la pieza de producción actual, es posible que se


presente en la siguiente, como se mencionaba anteriormente. Esto debido a que el
tiempo influyó principalmente en el cambio de temperatura de la máquina y al
momento de recibir la ésta la nueva pieza, ya no está a la temperatura adecuada.
Lo importante es este ejemplo es notar que cualquier falla que ocurra, ya sea que
se pueda solucionar sin la perdida de alguna pieza o con la pérdida de algunas, el
proceso se ve afectado en su nivel de producción debido al tiempo que se tardaría
en arreglar dicha falla, más interesante aún es el hecho de poder evitar esas fallas
mediante una programación eficiente sin necesidad de invertir más dinero en
hardware y solamente son el diseño e implementación de supervisores modulares.

Como se pudo apreciar en el ejemplo anterior, una especificación del tipo


prioritaria, de ese estilo. Es decir, prioridad en el orden de atención de cada
máquina, en algunos casos puede no ser la solución más eficiente, para estos
casos será conveniente utilizar memorias que indiquen qué máquina se está
atendiendo, cuales máquinas están en espera y cuál debe ser atendida primero,
contemplando además que este proceso es cíclico y que pueden ocurrir ciertas
fallas en las máquinas. El objetivo entonces es plantear una solución genérica
basada en la síntesis de supervisores modulares locales que contemple una
correcta especificación para cada supervisor sin que éste se vuelva intratable al
sistema. Al menos para la mayoría de los SFM que existen hoy en día.

Empezaremos suponiendo que sólo existen dos máquinas, y un robot que


necesita atender a la máquina que esté lista primero.

Cada una de las dos máquinas se modela mediante un autómata de cuatro


estados y cinco transiciones mostrado en la figura 4.1.

Los estados de cada autómata son: Ii, Wi, Di y Ri de i=1,2. Donde cada uno de
esos estados representa el estado de reposo (IDLE), el estado de trabajo
(WORKING), el estado de falla (DOWN) y el estado en el cuál la máquina esta
lista (READY), en este último estado la máquina ya terminó su proceso y esta lista
para ser atendida por el robot y comenzar de nuevo su ciclo.

81
CHAPTER 4.SÍntesis de supervisores y su implementación José Ernesto Pérez Robles

Los eventos controlables del sistema son: (la negrita solo es para diferenciar las i
de la numeración con la i de la palabra “repair”).

Starti, endi y Repairi de i=1,2. Donde el significado de los eventos es: comienza a
trabajar la máquinai, termina la máquinai (incluyendo la operación del robot) y se
repara la falla de la máquinai, El evento endi aparece como controlable ya que no
es posible que ocurra otro endi antes de terminar la acción actual.

Los eventos no-controlables del sistema son:

breaki, Readyi i=1,2. Donde el significado de los eventos es: ocurre la falla de la
máquinai y por último esta máquina está lista para que el robot la haga su trabajo
en ella.

Figura 4. 1 Autómata de la máquina.

En la figura 4.1 se puede observar cómo se modeló cada máquina del sistema.
Cabe mencionar que al modelar las máquinas de esta manera, se está haciendo
uso de la teoría de supervisores en sus modalidades “local y modular” [4], esto es
porque realmente cada máquina posee varios READY. Es decir, esta lista la para
operación de cada uno de los robots, sin embargo a cada robot, el cual tendrá su
propio supervisor (haciendo uso de la propiedad de modularidad), solo le interesa
su propio evento READY, por lo tanto, solamente ve la parte que le interesa de la
totalidad de la planta a controlar (aplicando aquí la teoría de supervisores
modulares locales [4]). Resultando en autómatas más simples y fáciles de
entender e implementar.

82
CHAPTER 4.SÍntesis de supervisores y su implementación José Ernesto Pérez Robles

Una vez que se tienen los autómatas de las plantas, se definirá la especificación
del robot la cuál es, en palabras:

“El robot deberá atender a la máquina que termine primero.”

Quedando la especificación de la siguiente manera:

Figura 4. 2 Especificación del robot

Si modelamos estas dos máquinas y la especificación del robot, y además


realizamos la síntesis del supervisor, podemos comprobar que el sistema es
controlable, no presenta bloqueo y funciona de acuerdo a lo requerido. En
conclusión la especificación de la figura 4.2 es simple y funciona muy bien para el
caso específico de dos máquinas, debido a que si termina primero la máquina uno,
y mientras ésta aun está siendo atendida por el robot, se da el caso de que
termine otra máquina, es obvio que ésta última es la dos, y viceversa. Además
contempla el caso en el que si sólo una de las máquinas (cualquiera que esta sea)
está trabajando el robot puede estar trabajando únicamente con esa máquina.

Sin embargo si hubieran más de dos máquinas en el sistema el problema no se


resuelve tan fácil, esto es porque no se puede obviar una segunda decisión dentro
de la especificación, por ejemplo si fueran al menos tres máquinas, una vez que la
primera pidió ser atendida, pueden pasar varios casos distintos con las dos
restantes el tiempo transcurrido. Es decir, la combinación de casos crece
exponencialmente. Por tal motivo es importante un buen diseño de la
especificación para mantener una solución correcta e implementable.

83
CHAPTER 4.SÍntesis de supervisores y su implementación José Ernesto Pérez Robles

Como se explicó anteriormente al introducir una máquina más al sistema la


solución crece inevitablemente, aunque puede seguir siendo tratable si se diseña
apropiadamente. A continuación se propondrá la solución genérica para un
sistema con tres máquinas debido a que es suficiente para ejemplificar cómo
funcionan las especificaciones que necesitan memoria, y una vez comprendida
esta especificación, fácilmente se podrá escalar y utilizar con un sistema de cinco
máquinas (lo cual es el número de máquinas del sistema real). Se presentará un
modelo de especificación para un supervisor que trabaja, como ya se dijo con tres
máquinas. El resultado del sistema completo ya con su síntesis te supervisores y
validado correctamente mediante simulación se implementará en una de las
estaciones de control lógico industrial del Instituto Tecnológico y de Estudios
Superiores de Monterrey Campus Monterrey.

Simulación y validación del problema

Las máquinas se modelan de la misma manera como se presentó en el ejemplo


anterior, es decir cómo se muestra en la figura 4.1, resaltando el uso de propiedad
de localidad en estos modelos.

Recordando que se pretende crear supervisores locales modulares, la


especificación que se propone para solucionar este problema se presenta en la
figura 4.3, y es la especificación que deberá cumplir el supervisor de cada robot
para las tres máquinas. Como el proceso es semejante en cada robot se
presentará solo una especificación. En esta especificación se puede apreciar
primeramente, el crecimiento exponencial que tuvo con respecto a la
especificación para el caso de dos máquinas, en segundo lugar se puede observar
la modularidad local del sistema desde el punto de vista en que esta
especificación solo abarca el proceso de un robot en forma individual. La robustez
se logra mediante la red de memorias que recuerdan el orden en que ocurrieron
los eventos, ya que esto evita la incertidumbre en casos de máquinas en espera.

84
CHAPTER 4.SÍntesis de supervisores y su implementación José Ernesto Pérez Robles

Figura 4. 3 Especificación del robot para la planta de tres máquinas.

En Supremica se modelaron los autómatas de las tres máquinas que forman la


planta del sistema, las cuales se muestran en la figura 4.4.

Figura 4. 4 Autómatas de las tres máquinas que forman la planta.

85
CHAPTER 4.SÍntesis de supervisores y su implementación José Ernesto Pérez Robles

Una vez modelados los autómatas de la planta y la especificación del robot se


sintetiza nuestro supervisor, que en este punto parecerá como un supervisor
monolítico debido a que con el uso de la modularidad local y la semejanza entre
los procesos de las máquinas y el robot, se presenta solo una parte de la planta, y
por tal motivo el supervisor trabajará sobre todos los autómatas.

Para validar que el sistema sea controlable, que no exista bloqueo y que se esté
trabajando de manera completa con el lenguaje del mismo, se hace uso de las
herramientas de Supremica que lo verifican y los resultados se presentan en las
figuras 4.5, 4.6 y 4.7.

Figura 4. 5 Validación de la controlabilidad del sistema mediante Supremica.

Figura 4. 6 Validación del no bloqueo del sistema mediante Supremica.

Figura 4. 7 Validación de la total inclusión del lenguaje del sistema mediante Supremica.

86
CHAPTER 4.SÍntesis de supervisores y su implementación José Ernesto Pérez Robles

Si además de los resultados de la síntesis del supervisor se desean conocer las


estadísticas de control del sistema, esto también se puede realizar mediante
Supremica y el resultado se muestra en la figura 4.8.

Figura 4. 8 Estadísticas de control mediante Supremica.

Hasta este momento hemos comprobando mediante Supremica el correcto


funcionamiento de nuestro sistema. Sin embargo antes de proceder a su
implementación en un PLC es necesario comprender más acerca del significado
de los eventos en nuestra planta en la tabla 3 se presenta dicha información.

Tabla 3 Eventos y su interpretación de acuerdo al sistema.

EVENTOS INTERPRETACIÓN Tipo


Start1/Start2/start3 Arranca cada una de las máquinas. Controlables
M1R/M2R/M3R Máquinas listar para ser atendidas el robot. No controlables
End1/End2/End3 Atención de máquinas por el robot. Controlables
Break1/Break2/Break3 Falla en las máquinas. No controlables
Repair1/Repair2/Repair3 Reparación de las fallas. Controlables

Conociendo la interpretación de los eventos en nuestra planta, se pueden generar


ciertos strings de eventos representativos, simular su evolución y verificar que se
produzca el comportamiento deseado. Para no tener que hacer el seguimiento de
los strings directamente en el diagrama de transición de estados, debido a que
éste es demasiado grande, como se podrá inferir en base a la figura 4.8, se puede
utilizar la herramienta de explorador de estados de Supremica.

87
CHAPTER 4.SÍntesis de supervisores y su implementación José Ernesto Pérez Robles

Se generaran los strings de prueba para seguir validando el sistema antes de su


implementación en un PLC. Si se usa el explorador de estados de Supremica se
podrá verificar que estos strings son válidos en la planta bajo la acción del
supervisor, también al comparar con la planta sin control, se puede observar los
eventos que el supervisor deshabilita para lograr el comportamiento deseado.

Caso 1:

Probará que al terminar cada máquina de manera individual y sin empalmarse


ésta sea atendida. Éste caso es el más simple y es solucionado inclusive sin
necesidad de la aplicación estricta de la TCS.

Por lo tanto ejemplo de strings válidos son: (las flechas se añaden para separar
claramente los eventos.)

String1=Start1 !M1R  End1

String2=Start 2 !M2R  End2

String3=Start 3 !M3R  End3

Caso 2:

Probará que aunque las tres máquinas terminen en diferente orden y estén
esperando ser atendidas las tres, el supervisor indicará el orden correcto.

Orden normal 1, 2, 3:

Start1  Start 2  Start 3 !M1R  !M2R  !M3R  End1 End2 End3

Orden invertido 3,2 y1:

Start3  Start 2  Start 1 !M3R  !M2R  !M1R  End3 End2 End1

En desorden:

Start1  Start 3  Start 2 !M1R  !M3R  !M2R  End1 End3 End2

Start3  Start 1  Start 2 !M3R  !M1R  !M2R  End3 End2 End2

88
CHAPTER 4.SÍntesis de supervisores y su implementación José Ernesto Pérez Robles

Caso 3

En estos casos las máquinas arrancan en un orden y se alistan para ser atendidas
en otro. Y el robot las atenderá conforme estén listas, NO conforme al orden de
arranque.

Start1  Start 2  Start 3 !M2R  !M1R  !M3R  End2 End1 End3

Start1  Start 2  Start 3 !M2R  !M1R  !M3R  End2 End1 End3

Caso 4

Es estos strings se comprobará que el control es tolerante a fallas en las


máquinas. Es decir, arrancan las tres máquinas en orden, sin embargo ocurre una
falla en la máquina uno, termina la dos y luego la tres, y entonces el robot atiende
a la máquina que esté lista primero y además en todo momento después de la
falla, habilita en este caso el evento Repair1, que se encarga de la reparación de
dicha máquina y la deja lista para arrancar de nuevo.

Start1  Start 2  Start 3 !Break1  !M2R  !M3R  End2 End3

Caso 5

Aquí se presentará un ejemplo de caso cíclico, es decir cuando son atendidas las
máquinas y vuelven a arrancar y estar de nuevo listas para ser atendidas.

Start1  !M1R Start 2  !M2R  Start 3 !M3R  End1 Start1  !M1R 


End2 End3

Ahora que se ha verificado de distintas maneras el correcto funcionamiento del


sistema se puede proceder a su implementación en el PLC y probar si funciona
adecuadamente con elementos de hardware.

89
CHAPTER 4.SÍntesis de supervisores y su implementación José Ernesto Pérez Robles

Implementación

En esta sección se implementará en el PLC el supervisor con base en la


especificación mostrada anteriormente y llevarán a cabo las pruebas
experimentales necesarias para comprobar el buen desempeño de los modelos y
validar la eficiencia de la TCS implementada.

Descripción del controlador

En la figura 4.9 se muestra el PLC TSX-3705 de la marca modicon-telemecanique,


que se usará para la implementación de los supervisores.

Figura 4. 9 PLC a programar.

Las características eléctricas de este PLC son:

 Tarjeta de 16 entradas y doce salidas binarias.


 Voltaje de operación es de 24 Volts VCD para las entradas y salidas.
 Voltaje de alimentación es de 127 VCA a 60 Hz.
 Batería de respaldo tipo capacitiva.

90
CHAPTER 4.SÍntesis de supervisores y su implementación José Ernesto Pérez Robles

El software que se utiliza en este PLC para llevar a cabo su programación es el


PL7 Pro de la misma marca que el PLC, y sus requerimientos son los siguientes:

 Plataforma Windows 95 en adelante.


 Capacidad de 200Mb disponibles en disco duro.
 Memoria RAM mínima de 32 Mb.
 Puerto serial disponible.

Este PLC junto con su computadora de programación se encuentran instalados en


la estación de control lógico de los laboratorios del departamento de mecatrónica y
automatización del ITESM campus Monterrey.

Descripción de los actuadores y sensores a utilizar

En la figura 4.10 se muestra la estación de control lógico industrial ya con las


conexiones hechas para la demostración del funcionamiento de los autómatas
propuestos. Dentro de esta estación solo se utilizará la parte derecha que compete
al uso del PLC (la parte donde aparecen los cables conectados) y la primera parte
de la izquierda que son tres pistones neumáticos de doble efecto y uno más de
simple efecto, cada uno de los cuales tiene instalado sensores para detectar si el
pistón esta retraído o extendido.

Figura 4. 10 Estación de control lógico del ITESM.

91
CHAPTER 4.SÍntesis de supervisores y su implementación José Ernesto Pérez Robles

Descripción del funcionamiento de la implementación

De manera didáctica, cada uno de los pistones de doble efecto simulará una
máquina, cuando éste esté extendido significará que la máquina está trabajando,
para simular el tiempo de proceso de cada máquina se implementará un
temporizador para cada una, de manera que al llegar al tiempo deseado indicará
que la máquina ha terminado su proceso y está lista para ser descargada. En
cuanto al robot se refiere, éste se simulará mediante el pistón de simple efecto.
Además mediante las luces indicadoras: verde, amarilla y roja se dará a conocer la
máquina a la que el robot está atendiendo, en este caso se encenderá la luz
verde, amarilla o roja si se está atendiendo la primera, segunda o tercera máquina,
respectivamente. También se simulará el botonazo de arranque de cada máquina,
el cual es dado por el operario, esto mediante el botón pulsador verde, el switch
selector B y el switch selector C, localizados debajo el PLC de la estación, de tal
manera que éstos serán el arranque de la primera, segunda y tercera máquina
respectivamente. De manera adicional se simulará falla en cada una de las
máquinas de la misma forma como se simularon los arranques pero con los
botones da la parte central de la estación, es decir, el botón pulsador verde, el
selector B y el selector C representarán las fallas en cada una de las máquinas en
el orden dado anteriormente, cabe mencionar que esta falla estará presente
mientras el botón o los selectores estén activos, al deshabilitar éstos significará
que se reparó la falla, es decir, ocurrió un evento de reparación. Las fallas del
robot no se simulan debido a que en el sistema real cualquier falla, en cualquiera
de los tres robots, provoca el paro total del sistema para su reparación.

La programación del PLC será mediante el lenguaje GRAFCET, por lo tanto


importante asegurarse que al programar en GRAFCET los autómatas modelados,
éstos mantengan una congruencia con los modelados en Supremica, es decir que
se implemente el mismo sistema, es posible que los autómatas luzcan diferentes
por cuestiones de implementación. Sin embargo, es necesario que el sistema sea
el mismo para lograr el correcto funcionamiento obtenido en la simulación.

92
CHAPTER 4.SÍntesis de supervisores y su implementación José Ernesto Pérez Robles

Conexión del PLC

Las conexiones realizadas en la implementación del sistema se presentan en la


siguiente tabla.

Tabla 4 Conexiones asignadas

Entradas Salidas
I1.0 Paro de emergencia Q2.0
I1.1 Cilindro 1 en reposo Q2.1 Avanza cilindro 1
I1.2 Cilindro 1 extendido Q2.2 Retrocede cilindro 2
I1.3 Cilindro 2 en reposo Q2.3 Avanza cilindro 2
I1.4 Cilindro 2 extendido Q2.4 Retrocede cilindro 2
I1.5 Cilindro 3 en reposo Q2.5 Avanza cilindro 3
I1.6 Cilindro 3 en extendido Q2.6 Retrocede cilindro 3
I1.7 Cilindro 4 en reposo Q2.7 Avanza cilindro 4
I1.8 Cilindro 4 extendido
I1.9 Falla cilindro 1 Q2.9 Atendiendo cilindro 1
I1.10 Falla cilindro 2 Q2.10 Atendiendo cilindro 2
I1.11 Falla cilindro 3 Q2.11 Atendiendo cilindro 3
I1.12 Arranca cilindro 1
I1.13 Arranca cilindro 2
I1.14 Arranca cilindro 3

En la figura 4.11 se pueden apreciar las conexiones realizadas a la tarjeta de


entradas al PLC de acuerdo a la información presentada anteriormente, y para
respaldar completamente la información presentada en dicha tabla se presenta
también en la figura 4.12 la cual muestra claramente las conexiones que se
realizaron a partir de las salidas del PLC.

93
CHAPTER 4.SÍntesis de supervisores y su implementación José Ernesto Pérez Robles

Figura 4. 11 Conexiones de las entradas al PLC.

Figura 4. 12 Conexiones de las salidas del PLC.

94
CHAPTER 4.SÍntesis de supervisores y su implementación José Ernesto Pérez Robles

Programación del PLC

Como se mencionó anteriormente el lenguaje de programación que se utilizará


para la implementación en el PLC es GAFCET. En la etapa preliminar se
programó que al ocurrir un arranque en frío, en caliente (bits S0 yS1 para el caso
particular del PLC en cuestión) o al presionar un paro de emergencia se
regresaran los pistones a su posición inicial y que cada grafcet implementado se
regresará a su etapa inicial (bobina set de S21), esto se aprecia en la figura 4.13.

Figura 4. 13 Conexiones de las salidas del PLC.

También en esta etapa nos aseguramos de que al ocurrir algún arranque en frio,
en caliente o algún paro se apaguen las memorias que se ocupan en el programa,
dándole con esto un grado mayor de robustez y seguridad al sistema. Cabe
mencionar que las memorias que se usan guardan el valor de un bit.

Figura 4. 14 Segunda parte de la etapa preliminar

95
CHAPTER 4.SÍntesis de supervisores y su implementación José Ernesto Pérez Robles

En cuanto a la etapa GRAFCET se refiere, se implementaron primeramente los


modelos de las máquinas siguiendo el modelo de Supremica mostrado en la figura
5.16 quedando como se muestra en la figura 4.15.

Figura 4. 15 Implementación de las tres máquinas en el PLC

Como se puede observar al comparar las figuras 4.4 y 4.15, estas son muy
similares y eso es un buen indicador, ya que es prueba de la transparencia que
debe de haber entre la modelación y la implementación. En esta implementación
fue posible representar los autómatas en forma casi idéntica debido a la
simplicidad del problema. Es decir, las acciones de los estados consisten solo el
extender o retraer un cilindro, sin embargo hablando del problema industrial se
podrían usar macro etapas para representar los autómatas de una forma similar.
Otra opción es que los grafcet de las máquinas funcionen como observadores de
los diagramas de escalera ya implementados en la industria y que estos
interactúen con el supervisor para lograr el control de todo el sistema.

Lo que resta ahora es implementar la especificación del robot en el PLC, de nuevo


se sigue el mismo proceso tratando de conservar el modelo implementado en
Supremica, en las figuras 4.16 y 4.17 se puede observar la implementación de
dicha especificación la cual es similar al presentado en la figura 4.3 es decir la
especificación modelada en Supremica.

96
CHAPTER 4.SÍntesis de supervisores y su implementación José Ernesto Pérez Robles

Figura 4. 16 Especificación del robot, primera parte.

Figura 4. 17 Supervisor Segunda parte

Para concluir esta sección se presentará lo programado en la etapa posterior del


GRAFCET. Cabe mencionar, que se programó de esta manera (Usando etapas
preliminar, GRAFCET y posterior) porque, desde mi punto de vista, es más simple
debido a que se no se necesita ir declarando directamente sobre las etapas del
grafcets las acciones de a realizar en cada una de ellas.

97
CHAPTER 4.SÍntesis de supervisores y su implementación José Ernesto Pérez Robles

Figura 4. 18 Acciones de la máquina 1

En la primera parte de la programación de la etapa posterior se establece el


funcionamiento de las máquinas. Como en el problema planteado todas las
máquinas son iguales, sólo se presentará como se hizo para la máquina uno. En
la figura 4.18 se pueden ver las acciones de la máquina uno y un temporizador
(TM1), que simula el tiempo de proceso de cada máquina, para fines prácticos se
establecieron temporizadores diferentes a cada máquina en caso de querer
simular diferentes procesos en cada una de ellas. Sin embargo, para que el
sistema representara de una mejor manera al real se establecieron tiempos
iguales a cada temporizador, porque en el sistema real las cinco máquinas
realizan el mismo proceso en el mismo tiempo. En la segunda etapa de la parte
posterior se procede a establecer las acciones del robot, figura 4.19.

Figura 4. 19 Robot en reposo

98
CHAPTER 4.SÍntesis de supervisores y su implementación José Ernesto Pérez Robles

En la figura 4.20 se muestra la acción del robot al atender la máquina uno, en este
caso es representada por la memoria M1 y un indicador de luz, en este caso la luz
verde. Para la atención de las demás máquinas se hará lo mismo, obviamente
cada una con una memoria luz indicadora propia. Al final de esta sección posterior
se le asigna la acción de extender el cilindro que representa al robot para indicar
que éste está trabajando.

Si alguna parte de la implementación no se alcanza a apreciar correctamente o se


desea verificar todo el programa, anexo a este documento se incluye el programa
utilizado, para usos que al lector le convenga. El archivo lleva como nombre
“ProgramaTesis.stx”.

Figura 4. 20 Acción del robot al atender la máquina 1.

La solución funcionó de acuerdo a lo esperado, es decir el sistema es controlable


no presenta bloqueos y cumple con las especificaciones requeridas. Los
resultados se pueden apreciar mejor en el video anexo, las conclusiones finales se
presentarán en una sección posterior.

99
CHAPTER 4.SÍntesis de supervisores y su implementación José Ernesto Pérez Robles

4.2 Solución del rompecabezas “Cruzar el Rio”

Existen problemas cuya solución consiste únicamente en la correcta modelación


de los autómatas, que formarán la planta y las especificaciones, y la aplicación de
la TCS mediante simulación, es decir no se necesita una mayor implementación
en algún PLC o algún otro dispositivo de control. Un tipo de estos problemas son
los rompecabezas, que además de ser divertidos, nos ayudan a aumentar nuestra
capacidad de resolver problemas reales. Como además es uno de mis
pasatiempos favoritos, a continuación se presentará la solución de un problema
que me llegó hace varios años a mi correo electrónico y lo guarde sin saber que
hoy lo podría resolver mediante la teoría de SED y la TCS. Cabe mencionar, que
el problema no fue inventado por mí, ni la animación que se anexa en ésta tesis:
“Cruzar el río.pps”, lo que se realizó fue la modelación y simulación del sistema
hasta obtener las soluciones del rompecabezas. Al resolver el rompecabezas se
pretende además, motivar a los jóvenes mediante este tipo problemas amenos,
que no requieren una inversión de hardware, a involucrarse en el estudio de los
SED, la TCS y las demás áreas científicas relacionadas.

Planteamiento del rompecabezas

En esta sección se aplicará la TCS sobre los SED que modelen el comportamiento
de cada uno de los componentes del sistema. El sistema, en este caso, se refiere
al conjunto de elementos que forman parte del rompecabezas, puntualmente: la
mamá, el papá, los dos hijos, las dos hijas, el ladrón, el policía y la balsa. Se
modelaran también las especificaciones que representen las restricciones del
rompecabezas para sintetizar los primeros supervisores, los cuales nos llevaran a
establecer una especificación óptima final, que nos muestre todas las opciones
para que todos los elementos pasen el río en el menor tiempo posible. A
continuación se presenta formalmente el enunciado de ésta famosa prueba de
inteligencia.

100
CHAPTER 4.SÍntesis de supervisores y su implementación José Ernesto Pérez Robles

La prueba de inteligencia consiste en lograr que una familia de 6 personas (Padre,


Madre, 2 hijos y dos hijas), un policía y un ladrón crucen un río en una balsa.

Se tienen las siguientes restricciones:

 Sólo 2 personas pueden cruzar al mismo tiempo.


 El Padre no puede estar con ninguna de las dos hijas si la Madre no está
presente.
 La Madre no puede estar con ninguno de los dos hijos si el Padre no está
presente.
 El ladrón no puede estar con ningún miembro de familia sin la presencia del
Policía.
 Sólo el padre, la madre y el policía saben cómo funciona la balsa.

Figura 4. 21 Personas que necesitan cruzar el río.

101
CHAPTER 4.SÍntesis de supervisores y su implementación José Ernesto Pérez Robles

Modelación del sistema

Aplicando los conocimientos adquiridos hasta este momento se modelan los


nueve autómatas que representan cada uno de los elementos del sistema. Con
esto se tiene un total de nueve autómatas independientes, uno para cada uno de
los integrantes de la familia (seis), uno para el policía, uno para el ladrón y un
último para la balsa. Por otra parte, se tienen cinco especificaciones diferentes que
deben ser cumplidas, las cuales se describieron anteriormente como las
restricciones del sistema. En la figura 4.21 si ilustra de una manera gráfica el
ambiente en el que se lleva a cabo el problema y cada uno de los individuos que
necesitan cruzar el río.

En la tabla 5 se presenta el alfabeto del sistema y su significado. Los nombres de


los eventos cobran sentido si se piensan en el idioma inglés por ejemplo: “father,
mother, daugther, son, thief y policeman” para nombrar a los personajes, la B y la
H representan las palabras “Back” y “Hits” respectivamente. Cabe hacer notar, que
siempre que esta la H en un evento, este es no controlable. Es decir, los golpes se
producirán sin poder ser evitados en ese punto.

Los autómatas modelados se implementaron en Supremica con la finalidad de


aprovechar una herramienta que tiene este programa, cuya función es encontrar el
camino más corto desde un estado inicial al estado marcado. Esta herramienta es
la que nos ayuda para obtener la especificación del supervisor monolítico óptimo.
Para el uso de esa herramienta es importante definir los estados marcados en
nuestros autómatas. Recordando lo mencionado en el capitulo dos, estos estados
representan un estado de interés especial o la culminación de alguna tarea, por tal
motivo en este caso se marcarán los estados que representen que cada elemento
del sistema está del lado derecho del río.

102
CHAPTER 4.SÍntesis de supervisores y su implementación José Ernesto Pérez Robles

Tabla 5 Alfabeto del problema de cruzar el rio

Eventos Tipo Significado


F/FB Controlable Padre cruza el rio hacia adelante / de regreso
FD1/FD1B Controlable Padre e hija 1 cruzan el río hacia adelante / de regreso
FD2/FD2B Controlable Padre e hija 2 cruzan el río hacia adelante / de regreso
FHD1L/FHD1R No controlable Padre golpea a la hija 1 del lado izquierdo del río / del lado derecho
FHD2L/FHD1R No controlable Padre golpea a la hija 2 del lado izquierdo del río / del lado derecho
FM/FMB Controlable Padre y madre cruzan el río hacia adelante / de regreso
FP/FPB Controlable Padre y policía cruzan el río hacia adelante / de regreso
FS1/FS1B Controlable Padre e hijo 1 cruzan el río hacia adelante / de regreso
FS2/FS2B Controlable Padre e hijo 2 cruzan el río hacia adelante / de regreso
FT/FTB Controlable Padre y ladrón cruzan el río hacia adelante / de regreso
M/MB Controlable Madre cruza el rio hacia adelante / de regreso
MD1/MD1B Controlable Madre e hija 1 cruzan el río hacia adelante / de regreso
MD2/MD2B Controlable Madre e hija 2 cruzan el río hacia adelante / de regreso
MHS1L/MHS1R No controlable Madre golpea al hijo 1 del lado izquierdo del río / del lado derecho
MHS2L/MHS2R No controlable Madre golpea al hijo 2 del lado izquierdo del río / del lado derecho
MP/MPB Controlable Madre y policía cruzan el río hacia adelante / de regreso
MS1/MS1B Controlable Madre e hijo 1 cruzan el río hacia adelante / de regreso
MS2/MS2B Controlable Madre e hijo 2 cruzan el río hacia adelante / de regreso
MT/MTB Controlable Madre y ladrón cruzan el río hacia adelante / de regreso
P/PB Controlable Policía cruza el rio hacia adelante / de regreso
PD1/PD1B Controlable Policía e hija 1 cruzan el río hacia adelante / de regreso
PD2 Controlable Policía e hija 2 cruzan el río hacia adelante / de regreso
PS1/PS1B Controlable Policía e hijo 1 cruzan el río hacia adelante / de regreso
PS2/PS2B Controlable Policía e hijo 2 cruzan el río hacia adelante / de regreso
PT/PTB Controlable Policía y ladrón cruzan el río hacia adelante / de regreso
THD1L/THD1R No controlable Ladrón golpea a la hija 1 del lado izquierdo del río / del lado derecho
THD2L/THD2R No controlable Ladrón golpea a la hija 2 del lado izquierdo del río / del lado derecho
THFL/THFR No controlable Ladrón golpea al padre del lado izquierdo del río / del lado derecho
THML/THMR No controlable Ladrón golpea a la madre del lado izquierdo del río / del lado derecho
THS1L/THS1R No controlable Ladrón golpea al hijo 1 del lado izquierdo del río / del lado derecho
THS2L/THS2R No controlable Ladrón golpea al hijo 2 del lado izquierdo del río / del lado derecho

Los autómatas que representan al sistema se muestran a continuación:

Para el caso de los dos hijos, y las dos hijas, los autómatas son muy similares,
debido a que son básicamente los mismos grafos pero con eventos propios de
cada personaje, por lo cual se mostrará solo uno de ellos de manera gráfica. Con
el alfabeto mostrado en la tabla 5 será más fácil su compresión.

103
CHAPTER 4.SÍntesis de supervisores y su implementación José Ernesto Pérez Robles

Figura 4. 22 Autómata que representa al hijo 1.

En la figura 4.22 se muestra el modelo del autómata del hijo uno, como se podrá
observar, son solamente dos estados, los cuales representan que el hijo uno se
encuentra del lado izquierdo o del lado derecho del río, y esto es válido para todos
los autómatas de los personajes.

Para el caso de los autómatas del padre, la madre y del policía, de nuevo tenemos
autómatas semejantes. Simplemente que cada uno posee los eventos propios del
personaje, es decir, eventos similares pero que precisan la presencia del
personaje en cuestión. Estos son semejantes debido a que son los únicos, que
según las especificaciones del problema, pueden manejar la balsa para cruzar el
río. En la figura 4.23 se muestra el autómata que representa al padre.

Figura 4. 23 Autómata que representa al padre.

104
CHAPTER 4.SÍntesis de supervisores y su implementación José Ernesto Pérez Robles

Para terminar con los autómatas de los personajes se presentará el autómata del
ladrón que es relativamente diferente a los demás. Éste se muestra en la figura
4.24. Hasta este punto hemos definido casi todos los autómatas que al
sincronizarse formarán nuestra planta, solo queda por definir el autómata que
representará la balsa el cual es importante para que funcione bien el sistema.

Figura 4. 24 Autómata que representa al ladrón.

El autómata que representa la balsa se muestra en la figura 4.25, en el que es


importante remarcar que también tiene como objetivo (estado marcado) el estar
del lado derecho del rio.

Figura 4. 25 Autómata que representa la balsa.

105
CHAPTER 4.SÍntesis de supervisores y su implementación José Ernesto Pérez Robles

Para obtener el modelo completo de la planta, se realiza la operación de


composición paralela entre los nueve autómatas que componen al sistema. Para
esto se utiliza la herramienta “Synchronize” de Supremica. La planta resulta con
un total de 448 estados, un alfabeto de 62 eventos y 4288 transiciones. Como se
puede observar es una planta muy extensa. Por lo tanto, no es práctico
representarla de un manera gráfica lo importante es comenzar a definir las
especificaciones que nos ayudarán a resolver el rompecabezas.

Diseño de las especificaciones

Las especificaciones se definen y se construyen en base a las restricciones que se


presentaron en la descripción del problema. Primero, se presentan las
especificaciones individuales, las cuales se utilizarán posteriormente para la
síntesis de los supervisores modulares.

Nota: A diferencia de lo documentado en el capítulo tres acerca de la definición


del los “selfloops” que se necesitan agregar dentro de TCT para permitir la
evolución de los eventos no declarados en el autómata, en Supremica no se
necesitan añadir dichos “selfloops”, es decir permite los eventos que estén en el
alfabeto total siempre y cuando estos no estén “bloqueados”. Es decir se tienen
que bloquear los eventos que no se quiere permitir su evolución, esto es muy
importante tomarlo en cuenta al momento de modelar los autómatas y realizar las
diferentes operaciones de composición. Hasta este momento ya se ha presentado
la manera de realizar la composición paralela mediante Supremica, sin embargo si
necesitáramos realizar la operación producto se debe usar la misma herramienta.
Es decir, ““Synchronize” pero lo importante es que los autómatas deben incluir la
lista de eventos bloqueados. Esto tiene sentido, si se comprende en qué consiste
las cada de las operaciones de composición entre autómatas, explicadas de
manera clara en el capitulo dos de este trabajo de tesis.

106
CHAPTER 4.SÍntesis de supervisores y su implementación José Ernesto Pérez Robles

Especificación 1. El padre no puede quedarse con ninguna de las hijas si la


madre no está presente. Si esto ocurre el papá golpea a las hijas, por tal motivo la
especificación uno queda definida como se muestra en la figura 4.26.

Figura 4. 26 Especificación 1

Especificación 2. La madre no puede estar con ninguno de los hijos si el padre


no está presente. Si esto pasa la madre golpea a los hijos, para evitar eso la
especificación 2 queda ilustrada en la figura 4.27.

Figura 4. 27 Especificación 2.

Especificación 3. El ladrón no debe quedarse con ningún miembro de la familia si


no está presente el policía. Esto se representa en la figura 4.28.

Figura 4. 28 Especificación 3.

Por otra parte, para la síntesis del supervisor monolítico, se verifica que no exista
conflicto entre las especificaciones y como en este caso no lo hay debido a que ni
siquiera se repiten los alfabetos de las especificaciones entre sí. Debido a la
simplicidad de la especificación monolítica que resultaría, se usará un supervisor
monolítico. Aun así se presentaran resultados de los supervisores modulares.

107
CHAPTER 4.SÍntesis de supervisores y su implementación José Ernesto Pérez Robles

La especificación para el supervisor monolítico se obtiene mediante la sincronía de


las tres especificaciones, el resultado de esta operación se muestra claramente en
la figura 4.29.

Figura 4. 29 Especificación general.

Síntesis de supervisores

Supervisores Modulares

Para la síntesis de los supervisores modulares, se utiliza la herramienta


“Synthesize”, entre cada una de las tres especificaciones individuales y el modelo
de la planta.

Se obtuvieron los siguientes resultados:

Tabla 6 Resultados de los supervisores

Especificación 𝑸 𝜮 →
Especificación 1 256 62 1648
Especificación 2 256 62 1648
Especificación 3 226 62 1244

108
CHAPTER 4.SÍntesis de supervisores y su implementación José Ernesto Pérez Robles

Donde:

Q : número de estados.

Σ : alfabeto.

→ : número de transiciones.

Utilizando la herramienta Verify, se aseguró que el sistema es controlable con


cada uno de los supervisores modulares independientes, esto quiere decir que el
problema tiene solución, la cual es la intersección de estos supervisores, dicho de
otra manera, es el cumplimiento de todas las especificaciones mediante los
supervisores planteados.

De nuevo es válido comentar que anexo a esta tesis se encuentran los archivos de
Supremica implementados para la solución de este problema, para que el lector
comprenda de una mejor manera lo dicho hasta este momento. El archivo lleva
por nombre cruzar el rio.wmod

Supervisor Monolítico

Para la síntesis del supervisor monolítico, se utilizó la especificación total o


general mostrada en la figura 4.29. El supervisor monolítico obtenido en base a
esta especificación posee las siguientes características: Q = 76, Σ = 62 y
→ = 160. Al realizar la verificación para controlabilidad, se obtuvieron los
resultados desplegados por Supremica en la figura 4.30.

Figura 4. 30 Resultados del sistema con el supervisor monolítico.

109
CHAPTER 4.SÍntesis de supervisores y su implementación José Ernesto Pérez Robles

Como se puede observar, el sistema es controlable, lo cual, en palabras, nos


quiere decir que el problema tiene solución. Sin embargo, existe un gran número
de posibles soluciones, por lo tanto es necesario encontrar una solución óptima a
dicho problema, eso es de lo que trata la siguiente sección.

Obtención de un supervisor óptimo

Para la obtención del supervisor óptimo que nos defina la ruta más corta para
llegar del estado inicial al estado marcado, se utilizó la herramienta de Supremica

llamada: “Trace States” . Con base en los fundamentos especificados en la


en el capitulo dos, sabemos que el estado marcado de la planta es el estado en el
que todos los autómatas, que forman parte de ésta, coinciden con la marcación de
sus estados. En palabras, para este problema, el único estado marcado es el
estado que tenemos como objetivo es decir cuando todos los elementos están del
lado derecho del río.

La herramienta Trace States se encuentra en el cuadro de diálogo del menú


“Explore States”. y al utilizarla nos arroja el siguiente resultado:

Como se puede ver es un resultado óptimo, sin embargo no es único, aunque la


herramienta de Supremica está limitada en este aspecto a sólo mostrar una ruta
óptima, al analizar el problema se observa que éste es simétrico y por lo tanto
podemos, en base a esta ruta óptima, construir una especificación ideal que
incluya todas las posibles soluciones óptimas que resuelvan el rompecabezas
presentado.

La especificación obtenida que abarca todas las posibles soluciones óptimas se


muestra en la figura 4.31.

110
CHAPTER 4.SÍntesis de supervisores y su implementación José Ernesto Pérez Robles

En la figura 4.31 se puede observar que hay dos ramificaciones principales, una
donde primero se cruza a los hijos al otro lado, y otra donde se cruzan a las hijas
primero. A su vez, en cada ramificación, existen algunas transiciones que poseen
dos eventos, ya que puede pasarse a cualquiera de los/las hijos(as) en cualquier
orden, esto comprueba la simetría del problema e indica el correcto diseño de la
especificación.

Al sintetizar el supervisor utilizando la especificación final, se obtienen los


siguientes resultados: Q = 40, Σ = 62 y → = 44. Como se puede observar, en
la figura 4.32, el supervisor obtenido es de menor tamaño la planta, ya que
restringe al sistema a tomar solamente las rutas más cortas. Se recomienda ver el
video anexo de la solución, el archivo se llama CRUZANDO EL RIO.wmv

111
CHAPTER 4.SÍntesis de supervisores y su implementación José Ernesto Pérez Robles

Figura 4. 31 Especificación óptima.

112
CHAPTER 4.SÍntesis de supervisores y su implementación José Ernesto Pérez Robles

Figura 4. 32 Supervisor óptimo

113
CAPÍTULO 5. CONCLUSIONES Y TRABAJOS FUTUROS

Como se pudo observar a lo largo del desarrollo de la tesis, es muy grande la


variedad de problemas que se pueden resolver utilizando la teoría de control
supervisorio. Aunque aquí el enfoque es principalmente en dos tipos: los que
están relacionados con sistemas flexibles de manufactura y los que involucran la
solución de rompecabezas, por lo tanto se concluirán de manera independiente
estas dos aportaciones.

5.1 Conclusión en base a los resultados obtenidos en la solución del


problema de tipo industrial.

La solución presentada al problema de la interacción eficiente entre robots


presentó intrínsecamente varios puntos importantes de lo que es la teoría de
control supervisorio. En primer lugar, se hizo uso de la modularidad local desde
el punto de vista de que cada robot estaba limitado a operar con todas las
máquinas sólo en los eventos que a este le incumbían y además este no era
capaza de ver todos los demás eventos que producía la planta completa. El mejor
ejemplo de esto se vio, al mencionar que sólo se iba a modelar un robot pero que
esto era suficiente ejemplificar el funcionamiento de todo el sistema debido a esta
propiedad de modularidad local.

Otro resultado importante que se obtuvo fue el uso intrínseco de la teoría de colas,
donde se iban moviendo los eventos en forma de una red de memorias para no
perder el orden en que las máquinas deben de ser atendidas. También es
importante notar la robustez del supervisor en el hecho de que si todas las
máquinas se le juntan a un robot para ser atendidas, no importando el orden en
que éstas se hayan presentado, el robot siempre sabrá el orden que debe seguir.
Además, bajo las condiciones de pruebas aquí realizadas, este tipo de modelación
del sistema mostró una tolerancia a las fallas en las máquinas. Por lo tanto, el
sistema podría seguir trabajando a pesar de que las máquinas fallen, siempre y
cuando al menos una máquina este funcionando.
CHAPTER 5.Conclusiones y trabajos futuros José Ernesto Pérez Robles

Otro resultado importante fue que se obtuvo un modelo viable de solución para
lograr una mejora los procesos industriales. Es decir, no se necesita implementar
un nuevo hardware para la solución propuesta, los cambios en los programas que
se tendrían que hacer son relativamente simples debido a que si ya se tienen los
programas en diagrama de escalera los autómatas aquí generados podrían
funcionar como meros observadores, con la única finalidad de lograr el buen
desempeño del supervisor y por último este cambio se puede diseñar y realizar
fuera de línea y solo parar el proceso para cargar los nuevos programas. Con esto
se cumple hasta cierto punto el objetivo planteado inicialmente de ir disminuyendo
el espacio tan grande que existe entre la academia y la industria.

5.2 Conclusión en base a la solución del rompecabezas de cruzar el río

La solución presentada al famoso rompecabezas que ha circulado por la red es un


ejemplo de que la teoría de control supervisorio puede ayudar a resolver una gran
variedad de problemas. Fue un ejemplo claro del uso de supervisores modulares y
un supervisor monolítico. Además, a diferencia de los problemas industriales, en
este tipo de problemas la modelación del sistema y el diseño del correcto
supervisor son la solución al problema, ya que no existe la necesidad de
implementar nada en algún dispositivo de control. Este tipo de rompecabezas
ayuda a ejercitar la mente de tal manera que se pueda contemplar un panorama
amplio de soluciones a situaciones aparentemente imposibles de resolver, lo que
eventualmente ayudará en la toma de buenas decisiones.

Desde mi punto de vista fue muy divertido trabajar en mi tesis con este tipo de
problemas ya que es uno de los pasatiempos que más disfruto. Creo también, que
es posible, con estos acertijos amenos, llamar la atención a jóvenes y amantes de
los rompecabezas a involucrarse en el camino de la ciencia.

115
CHAPTER 5.Conclusiones y trabajos futuros José Ernesto Pérez Robles

5.3 Trabajos Futuros

Con base a los resultados obtenidos y al alcance logrado en esta tesis se


proponen los siguientes trabajos a futuro.

 Modelación y control de nuevos sistemas flexibles de manufactura


aplicando la teoría de control supervisorio.
 Emigración directa de las herramientas de modelación como SUPREMICA
a diagramas de escalera, GRAFCET o algún otro tiempo de lenguaje de
programación de PLCs.
 Añadir a los sistemas de eventos discretos información estadística, de
manera que se puedan evaluar mediante Cadenas de Markov u otras
herramientas, para soluciones de problemas estocásticos.
 Implementación de estas técnicas de control en nuevos dispositivos
tecnológicos diferentes a un PLC.
 Realizar comparaciones de las soluciones de los problemas aquí resueltos
y soluciones propuestas mediante redes de Petri.

116
Bibliografía

1. Efficient Analysis of Large Discrete-Event Systems with Binary Decision Diagrams. Arash Vahidi,
Bengt Lennartson, Martin Fabian. Seville, Spain : IEEE, 2005. Proceedings of the 44th IEEE
Conference on Decision and Control, and the European Control Conference.

2. VAHIDI, ARASH. Efficient Analysis of Discrete Event Systems. 2004.

3. W.M., Wonham. Supervisory Control Of Discrete Event Systems. Toronto : s.n., 2008.

4. Cassandras, Christos G y Lafortune, Stéphane. Introduction to Discrete Event Systems. Second.


New York : Springer, 2008. págs. 50-70.

5. Steering of Discrete Event Systems: Control Theory Approach. Arvind Easwaran, Sampath
Kannan, Oleg Sokolsky. Philadelphia, USA : Elsevier B.V., 2006. Electronic NotesIn Theoretical
ComputerScience.

6. Synthesis and Implementation of a Local Modular Supervisory Control for a Manufacturing Cell.
Cury, Max H. Queiroz and J.E.R.

7. Supervisory control of modular systems with global specification languages. J. Komendaa, J.H.
van Schuppen, B. Gaudin, H. Marchand. s.l. : Elsevier Ltd., 2008. Automatica.

8. Exploiting Modularity For Synthesis And Verification Of Supervisors. K. Akesson, H. Flordal, M.


Fabian. Barcelona, Spain : s.n., 2002. 15th Triennial World Congress.

9. The Control of Discrete Event Systems. Ramadge, P y Wonham, W. 1989, Proceedings of the
IEEE, Vol. 77, No. 1.

10. Encyclopedia Americana.

11. Webster´s Dictionary.

12. IEEE Standard Dictionaryof Electrical and Electronic Terms.

13. Supervisor Control of a Flexible Manufacturing System Used in Spinning Mills. Dan Ungureanu-
Anghel, Dan Lucian Mihaescu. 2004.

14. Christos G.Cassandras, Stéphane Lafortune. Introduction to Discrete Event Systems.


Introduction to Discrete Event Systems. 2008, págs. 2-5.

15. Control of discrete-event systems with modular or distributed structure. Jan Komendaa, Jan H.
van Schuppen. s.l. : Elsevier B.V., 2007. Theoretical Computer Science.

16. Dealing with Blocking in Supervisory Control. Lafortune, Enke Chen and Stéphane. Tampa,
Florida : s.n., Diciembre, 1989.

17. Robust and adaptive supervisory control of discrete event systems. Lin, F. s.l. : IEEE, 1993.
Bibliografía José Ernesto Pérez Robles

18. Model uncertainty in discrete event systems. Garg, S. Young and V. K. 1995.

19. Concurrency and discrete event control. Heymann, M. 1990.

20. Supervisory control of nondeterministic systems with driven events via prioritized
synchronization and trajectory models. Kumar, M. A. Shayman and R. 1995.

21. Nonblocking supervisory control of nondeterministic systems via prioritized synchronization.


Shayman, R. Kumar and M. A. 1996.

22. Robust and Nonblocking Supervisor for Discrete-Event Systems with Model Uncertainty under
Partial Observation. Seong-Jin Park, Jong-Tae Lim. 2000. IEEE TRANSACTIONS ON AUTOMATIC
CONTROL.

23. Modular supervisory control of an experimental automated. M. Nourelfatha, E. Niel. s.l. :


Elsevier Science Ltd, 2004. Control Engineering Practice.

24. Control Supervisorio Modular Y Multitarea De Sistemas Compuestos. Queiroz, Max Hering de.
Florianópolis : s.n., 2004.

25. TCT: A Computation Tool for Supervisory Control Synthesis. Lei Feng, W.M. Wonham.
Michigan, USA : s.n., 2006. Proceedings of the 8th International.

26. Supremica in a Nutshell – Draft. Knut Akesson, Martin Fabian, Hugo Flordal. 2007.

27. Supremica – A Tool for Verification and Synthesis of Discrete Event Supervisors. Knut A kesson,
Martin Fabian, Hugo Flordal, Arash Vahidi. Chalmers : s.n.

28. Structured Design of Reconfigurable Logic Control Functions through Sequential Functional
Charts. E. Carpanzano, A. Cataldo, D. Tilbury. s.l. : IEEE, 2004.

29. Synchronised Execution of Discrete Event Models Using Sequential Function Charts. Anders
Hellgren, Martin Fabian, Bengt Lennartson. 2000.

30. On the Execution of Sequential Function Charts. Anders Hellgren, Martin Fabian, Bengt
Lennartson. 2002.

31. Modular Implementation of Discrete Event Systems as Sequential Function Charts Applied to an
Assembly Cell. Anders Hellgren, Martin Fabian, Bengt Lennartson. 2001.

32. Incremental System Verification and Synthesis of Minimally Restrictive Behaviours. B. Brandin
and R. Malik, P. Dietrich. s.l. : AACC, 2000. Proceedings of the American Control Conference.

33. Modeling, Simulation and Control of Flexible Manufacturing Systems a Petri Nets Approach.
Meng Chu Zhou, Kurapati Venkatesh. 1999.

118
Bibliografía José Ernesto Pérez Robles

34. Hierarchical Interface-based Supervisory Control of a Flexible Manufacturing System. R.J.


Leduc, M. Lawford, and P. Dai. 2005.

35. Automated synthesis of Ladder automation circuits based on state-diagrams. S. Manesis, K.


Akantziotis. Patras : Elsevier Ltd., 2005. Advances in Engineering Software.

36. Implementarion Of Local Modular Supervisory Control For A Pneumatic System Using PLC.
Tolga Hasdemir, Salman Kurtulan, Leyla Gören. 2004.

37. MODULAR CONTROL OF COMPOSED SYSTEMS. Max H. de Queiroz, Jose E. R. Cury. Chicago,
Illinois : AACC, 2000. Proceedings of the American Control Conference.

38. Diccionario de la Real Academia De la Lengua Española.

39. Uma abordagem metodológica para o desenvolvimento de sistemas automatizados e


integrados de manufatura. MARCO ANTONIO BUSETTI DE PAULA, EDUARDO ALVES PORTELA
SANTOS. 2008. Produção.

40. Ambiente computacional para o suporte a implantação de sistemas automatizados de


manufatura. Joana Cross Fonseca, Eduardo Titze, Marco Antonio Busetti, Eduardo Alves Portela
Santos. Fortaleza,Brasil : ENEGEP, 2006.

41. Hierarchical Interface-Based Supervisory Control—Part I: Serial Case. Ryan J. Leduc, Bertil A.
Brandin, Mark Lawford, W. M. Wonham. s.l. : IEEE, 2005. TRANSACTIONS ON AUTOMATIC
CONTROL.

42. Modeling of Discrete Event Systems using Finite Automata With Variables. Markus Sköldstam,
Knut Akesson, Martin Fabian. New Orleans, LA, USA : IEEE, 2007. Proceedings of the 46th IEEE
Conference on Decision and Control.

43. Implementing supervisory control maps with PLC. Mohammad Moniruzzaman, Peyman
Gohari. New York City, USA : IEEE, 2007. Proceedings of the 2007 American Control Conference.

119
Anexos José Ernesto Pérez Robles

ANEXOS

GUÍA RÁPIDA PARA EL USO DE SUPREMICA

Como instalar Supremica

El Software Supremica se puede descargar del siguiente link:


http://www.supremica.org/.

Ilustración 1 Página de inicio

Una vez en la página de inicio mostrada en la figura 1, se sigue el vinculo


“Download” y dependiendo el sistema operativo que se posea se bajara el archivo
correspondiente.

Nota: En el caso de Windows Vista funciona la opción para Windows XP.

120
Anexos José Ernesto Pérez Robles

Se deberá guardar el archivo correspondiente en la computadora y de ahí


proceder a la ejecución del mismo y seguir los pasos solicitados para la instalación
del programa.

Si el programa se instaló correctamente, al ejecutarlo deberá aparecer la pantalla


que se muestra en la ilustración 2.

Ilustración 2 Ventana de confirmación de una correcta instalación.

El icono del programa para un acceso directo desde el escritorio se muestra en la


ilustración 3.

121
Anexos José Ernesto Pérez Robles

Ilustración 3 Icono Supremica

Como crear un nuevo autómata

Para crear un nuevo autómata se siguen el vínculo mostrado en la ilustración 4.

Ilustración 4. Creando un nuevo autómata.

Después se deberá definir si lo que se va a crear va a ser un una planta, una


especificación, una propiedad o un supervisor y asignarle un nombre al mismo,
como se muestra en la siguiente ilustración.

122
Anexos José Ernesto Pérez Robles

Ilustración 5.Creando la especificación para la máquina 1.

Una vez que se ha creado el autómata independientemente del tipo que sea, es
decir planta, especificación, etc. Se procede a crear los nodos o estados del
mismo con la herramienta que se muestra señalada en la ilustración 6, cabe
mencionar que en caso de querer generar más de un estado por vez se puede
usar el icono que se encuentra inmediatamente a la derecha del mostrado.

Ilustración 6. Herramienta para crear estados.

Con cada click izquierdo sobre la cuadrícula se anexará un nuevo estado, si


queremos renombrar cada uno de los estados, basta con dar doble click izquierdo
en el estado que se desea renombrar, si se desea de agregar estados se puede
escoger nuevamente el puntero en forma de flecha blanca. En la ilustración 7 se
muestran los estados creados para la especificación de la máquina 1 que hemos
venido manejando como ejemplo.

123
Anexos José Ernesto Pérez Robles

Ilustración 7. Los dos estados de creados para el autómata especificación de la máquina 1.

Una vez que se tienen los estados en la cuadrícula, hace falta unir estos estados
mediante la declaración de eventos, para esto se selecciona la herramienta que se
muestra en la ilustración 8, se da un click izquierdo sobre el estado de salida del
evento y se mantiene oprimido mientras se arrastra el ratón hasta llegar al estado
de llegada del evento. Si se desea curvear las flechas basta con dar un click
izquierdo sobre la flecha que se desee y arrastrar la flecha hasta que quede de la
forma deseada.

Ilustración 8. Herramienta para unir los estados mediante eventos.

124
Anexos José Ernesto Pérez Robles

Una vez creadas las flechas es necesario relacionarlas con eventos, para esto con
la misma herramienta que se muestra en la ilustración 8, se coloca sobre la flecha
deseada y se le da un click derecho para elegir la opción de crear un nuevo
evento, esto se muestra la ilustración 9.

Ilustración 9.Creando un nuevo evento

Cuando se haya seleccionado esta opción se desplegara la ventada ilustrada en


seguida, en la cual se deberá asignar un nombre al evento y escoger las opciones,
controlable, no controlable, etc. Que correspondan al evento que se pretende
crear.

Ilustración 10. Asignando el nombre al evento y el tipo del mismo.

125
Anexos José Ernesto Pérez Robles

Vista rápida a la interfaz de Supremica

Hasta el momento se ha señalado como crear un autómata, ahora es tiempo de


familiarizarnos de manera general con todas las herramientas dentro de la
pantalla, una vista rápida se muestra a continuación y se comenta brevemente las
partes más importantes.

Ilustración 11. Pantalla principal dentro de la opción de componentes del menú editor.

En la siguiente ilustración se muestra la pantalla principal pero ahora dentro del


menú del analizador, en este punto es importante notar que se habilita la opción
“Analyze” y se deshabilita la opción de “create”. Por lo tanto es aquí donde se
puede analizar el autómata de forma más completa mediante operaciones de
composición entre otros.

126
Anexos José Ernesto Pérez Robles

Ilustración 12. Pantalla principal en el menú del analizador.

Por último cabe mencionar que en la opción “analyze” se encuentran las


principales operaciones que se pueden realizar con los autómatas como los son:
Sincronizar, cortar, verificar, minimizar, etc.

Una vez que se lleva acabo alguna de las operaciones mencionadas se muestra el
autómata resultante y en la parte de debajo de la pantalla alguna información
relevante de la operación, un ejemplo de sincronización se muestra en la siguiente
ilustración.

127
Anexos José Ernesto Pérez Robles

Ilustración 13. Autómata resultante de la sincronización de los tres autómatas.

Cabe mencionar que existen algunos otros menús dentro de Supremica que son
fáciles de entender una vez que se ha seguido este manual y se tiene
conocimiento de la teoría se sistemas de eventos discretos. Debido a que se
extendería mucho este manual si se documentaran todos los menús y sus
submenús, y a la facilidad con la que los presenta Supremica, no se incluirán
todas las opciones de Supremica en este manual.

“Éxito”

128
Anexos José Ernesto Pérez Robles

GUÍA RÁPIDA PARA LA GENERACIÓN DE IMÁGENES DE


AUTÓMATAS MEDIANTE GRAPHIZ

Lo primero que se necesita hacer es utilizar el programa tct2any.exe para convertir


el archivo de la extensión DES a la extensión .dot, está última extensión sirve
para convertirla a au vez en .jpeg con el graphviz. Al darle doble click al programa
txt2any.exe aparece la pantalla que se muestra en la siguiente figura, en ella hay
que indicarle la ruta donde se encuentra el archivo con extensión DES y darle
enter, después hay que indicarle la ruta donde se va a guardar el archivo con
extensión DO.

Ubicación del
archivo a convertir

Ubicación donde el archivo se


guardará

Ilustración 14 Pantalla del ejecutable TCT2ANY.

Nota 1: en caso de que haya un error el mismo programa le indicará qué está mal.

Nota 2: en caso de que la operación de conversión haya sido exitosa entonces el


programa se cerrará automáticamente.

Una vez que se haya realizado la conversión del archivo de la extensión .DES a la
extensión .do, entonces se procede a convertir dicho archivo a la extensión .jpeg
para lo cual es necesario usar el programa, GRAPHVIZ, a continuación se dará la
descripción breve de cómo realizar la operación de conversión.

129
Anexos José Ernesto Pérez Robles

En Primer lugar se instala el programa se ejecuta el archivo GVedit.exe

Ilustración 15 Pantalla inicial del GRAPHVIZ

Una vez que hubo iniciado el programa Graphviz seleccionar la opción Fileopen
y abrir el archivo “.do” generado mediante tct2any.

130
Anexos José Ernesto Pérez Robles

Ilustración 16 Seleccionando el archivo .do

Se selecciona el archivo deseado y le damos abrir, lo que nos presentará la


siguiente ventana.

Ilustración 17 Archivo deseado

131
Anexos José Ernesto Pérez Robles

Seleccionar la opción de run, que se puede hacer dando click en el dibujo de una
silueta humana corriendo, el cual está señalado con la flecha en la figura anterior.

Como siguiente paso seleccionar las opciones siguientes.

Ilustración 18 Configuraciones.

Y al darle ok.

El resultado final será algo como lo que se muestra en la ilustración 19.

132
Anexos José Ernesto Pérez Robles

Ilustración 19 Resultado final desado.

El archivo será un archivo .jpg guardado en la carpeta seleccionada.

LISTA DE ENTREGABLES

 Documento de Tesis
 Instalador del TCT.
 Instalador del Graphviz
 Manual básico de Supremica.
 Ejecutable del TCT2ANY
 Manual básico del TCT.
 Manual básico del Graphiz.
 Programa en Grafcet para el PLC.
 Video del funcionamiento del programa en el PLC.
 Video de la solución del rompecabezas.
 Archivo en Supremica del modelo del problema industrial.
 Archivo en Supremica del modelo del rompecabezas.

133

También podría gustarte