MODELO DE HOLONES RECURSO EN SISTEMAS HOLÓNICOS DE MANUFACTURA

Por

Rubén Darío Vásquez Salazar

Ingeniero de Control

Trabajo de grado presentado como requisito parcial

Para optar al título de

Magíster en Automatización Industrial

Director

I.E., M.Sc. Germán Darío Zapata Madrigal

UNIVERSIDAD NACIONAL DE COLOMBIA

Facultad de Ingeniería y Arquitectura

Área Curricular Eléctrica, Electrónica, Automatización y Telecomunicaciones

Sede Manizales

2009

DEDICATORIA

AGRADECIMIENTOS

A Germán Zapata, por su acompañamiento y dirección durante todo el transcurso de esta investigación.

A la Universidad Nacional de Colombia, por el enriquecedor conocimiento transmitido y la experiencia compartida durante los últimos 8 años.

A Colciencias, por el apoyo económico brindado mediante el proyecto Jóvenes Investigadores e Innovadores.

MODELO DE HOLONES RECURSO EN SISTEMAS HOLÓNICOS DE MANUFACTURA

AUTOR

Rubén Darío Vásquez Salazar

Ingeniero de Control

DIRECTOR

I.E., M.Sc. Germán Darío Zapata Madrigal

Maestría en Ingeniería – Automatización Industrial

Facultad de Ingeniería y Arquitectura

Área Curricular Eléctrica, Electrónica, Automatización y Telecomunicaciones

Universidad Nacional de Colombia - Sede Manizales

Palabras clave: Sistemas Holónicos de Manufactura, controlabilidad, observabilidad, Sistema de Eventos Discretos. Resumen: Los Sistemas Holónicos de Manufactura – HMS por sus siglas del Inglés Holonic Manufacturing Systems - han sido ampliamente estudiados a nivel mundial debido a las grandes ventajas que traen a los sistemas de manufactura, comparado con otros paradigmas existentes. En los campos de la automatización y el control, es de especial interés el estudio del Holón Recurso (HR), debido a que la implementación de este nuevo paradigma, los HMS, trae consigo cambios en el diseño de controladores y supervisores para los recursos físicos. En este trabajo se realiza un estudio de los esquemas de supervisión y los nuevos elementos que acompañan al recurso físico. Uno de estos nuevos elementos es el sistema de toma de decisiones que se integra al HR. Actualmente no existe gran claridad sobre el comportamiento preciso de este holón, por lo que se propone un modelo que represente su comportamiento, validado mediante simulación y además evaluación de propiedades fundamentales como controlabilidad y observabilidad. Finalmente, un ejemplo de aplicación ilustrará el correcto funcionamiento del sistema.

TABLA DE CONTENIDO

1. INTRODUCCIÓN ............................................................................................... 10

1.1. Planteamiento del problema ........................................................................ 12

1.2. Objetivos ..................................................................................................... 13

1.2.1. Objetivo General ................................................................................... 13

1.2.2. Objetivos Específicos ............................................................................ 13

2. SISTEMAS DE MANUFACTURA ...................................................................... 14

2.1. Automatización Integrada ............................................................................ 14

2.1.1. Concepto CIM ....................................................................................... 15

2.1.2. Norma ISA-95 ....................................................................................... 16

2.1.3. Sistemas de Manufactura Flexible (FMS) ............................................. 17

2.2. Paradigmas en los sistemas de manufactura .............................................. 17

2.2.1. Arquitectura Centralizada ..................................................................... 17

2.2.2. Arquitectura Jerárquica ......................................................................... 18

2.2.3. Arquitectura Heterárquica ..................................................................... 18

2.2.4. Arquitectura Holónica ............................................................................ 18

3. SISTEMAS DINÁMICOS A EVENTOS DISCRETOS ........................................ 25

3.1. Conceptos básicos ...................................................................................... 25

3.1.1 Clasificación de los DEDS ..................................................................... 25

3.1.2. Lenguajes ............................................................................................. 26

3.1.3 Operaciones en lenguajes ..................................................................... 27

3.2. Teoría de Control Supervisorio .................................................................... 28

3.3.1. Controlabilidad ...................................................................................... 30

3.3.2. Observabilidad ...................................................................................... 31

3.3. Formalismos de modelamiento ................................................................... 32

3.3.1. Autómatas de estados finitos ................................................................ 32

3.3.2. Gráfico de red de Petri .......................................................................... 34

3.3.3. Red de Petri marcada ........................................................................... 35

3.3.4. Red de Petri Jerárquica (HPN) ............................................................. 36

3.3.5. Red de Petri Coloreada (CPN) ............................................................. 37

4. MODELO DEL HOLÓN RECURSO ................................................................... 41

4.1. Dinámicas .................................................................................................... 45

4.1.1. Anuncio de nuevas órdenes de trabajo ................................................. 46

4.1.2. Ejecución de órdenes ........................................................................... 49

4.1.3. Monitoreo y adaptación ......................................................................... 52

4.1.4. Otras dinámicas .................................................................................... 55

4.2. Construcción del Modelo ............................................................................. 56

4.3. Verificación de atributos holónicos .............................................................. 58

4.4. Evaluación de controlabilidad ...................................................................... 59

4.4.1. Evaluación de K1 .................................................................................. 61

4.4.2. Evaluación de K2 .................................................................................. 61

4.4.3. Evaluación de K3 .................................................................................. 61

4.4.4. Evaluación de K4 .................................................................................. 62

4.4.5. Evaluación de K5 .................................................................................. 62

4.5. Evaluación de observabilidad ...................................................................... 62

4.5.1. Evaluación de K6 .................................................................................. 63

4.5.2. Evaluación de K7 .................................................................................. 63

5. EJEMPLO DE APLICACIÓN ............................................................................. 65

5.1. Menú principal ............................................................................................. 68

5.1.1. Continuar .............................................................................................. 69

5.1.2. Generar nueva solicitud ........................................................................ 69

5.1.3. Aceptar propuesta hecha previamente ................................................. 69

5.1.4. Consular agenda .................................................................................. 69

5.1.5. Programar mantenimiento .................................................................... 69

5.1.6. Cancelar una orden .............................................................................. 70

5.1.7. Ejecutar órdenes sin fallas .................................................................... 70

5.1.8. Ingresar una falla .................................................................................. 70

5.1.9. Generar modo degradado ..................................................................... 70

5.1.10. Recibir restricciones de otro recurso ................................................... 70

5.1.11. Salir ..................................................................................................... 70

5.2. Simulación ................................................................................................... 71

5.2.1. Negociación de solicitud 1 .................................................................... 71

5.2.2. Ejecución (etapa 1) ............................................................................... 72

5.2.3. Negociación de solicitud 2 .................................................................... 73

5.2.4. Ejecución (etapa 2) ............................................................................... 74

5.2.5. Falla durante ejecución ......................................................................... 75

5.2.6. Ejecución (etapa 3) ............................................................................... 75

5.2.7. Modo degradado de 10 segundos ........................................................ 76

5.2.8. Ejecución (etapa 4) ............................................................................... 76

5.2.9. Negociación de la solicitud 3 ................................................................ 77

5.2.10. Ejecución (etapa 5) ............................................................................. 77

5.2.11. Modo degradado de 160 segundos .................................................... 78

5.2.12. Ejecución (etapa 6) ............................................................................. 78

6. CONCLUSIONES .............................................................................................. 80

TABLAS

Tabla 1. Equivalencia (no exacta) entre arquitecturas holónicas ........................... 20

Tabla 2. Comparativo entre formalismos de modelamiento ................................... 39

Tabla 3. Tipos de dato de los colores .................................................................... 45

Tabla 4. Eventos y estados para la interface intra-holón ....................................... 50

Tabla 5. Direccionamiento en el PLC ..................................................................... 51

FIGURAS

Figura 1. Pirámide de la Automatización ............................................................... 15

Figura 2. Niveles en el estándar ISA-95 ................................................................ 16

Figura 3. Estructuras de Control (adaptada de [13]) .............................................. 18

Figura 4. Holones básicos de un HMS y sus relaciones (Adaptada de [16]) ......... 20

Figura 5. Intercambio de información en un holón (Adaptada de [20]) .................. 21

Figura 6. Arquitectura general del holón (Adaptada de [24]) ................................. 22

Figura 7. Arquitectura de supervisión (Adaptada de [20]) ...................................... 22

Figura 8. Supervisión del sistema (Adaptada de [20]) ........................................... 23

Figura 9. Clasificación de sistemas (Tomada de [26]) ........................................... 26

Figura 10. El ciclo de toma de decisiones (Adaptada de [20]) ............................... 28

Figura 11. Esquemas de supervisión (centralizado y holónico) ............................. 29

Figura 12. Comportamiento dinámico del HR ........................................................ 42

Figura 13. Orden de producción en diagrama Gantt .............................................. 43

Figura 14. Representación en CPN del anuncio de una tarea ............................... 47

Figura 15. Interface intra-holón .............................................................................. 50

Figura 16. Interface intra-holón en lenguaje ladder ................................................ 52

Figura 17. Modelo del HR en CPN ......................................................................... 57

Figura 18. Perilla para cajones (Referencia A). ..................................................... 66

Figura 19. Balaustre para juguetes (Referencia B). ............................................... 67

Figura 20. Ocurrencia de eventos de entrada al HR .............................................. 71

10

1. INTRODUCCIÓN

Las empresas, en especial las del sector de la fabricación necesitan volverse más competitivas en un ambiente que constantemente está en cambio y las obliga a adaptarse a él para que su rentabilidad se mantenga o se incremente. Para ello, se utiliza comúnmente la implementación de nuevas tecnologías para mejorar su producción, exigiendo soluciones que se implementen fácilmente con el menor riesgo y que proporcionen funcionalidad avanzada.

En [1] se han analizado algunos de los problemas más críticos que el mercado del siglo XXI trae a las empresas, incluyendo:

• La necesidad de personalización masiva, en el caso de ‘make-to-order’ en vez de ‘make-to-stock’, lo cual sugiere la producción basada en pedidos y no en existencias.

• Combinación híbrida de volumen y variedad de producción en un único piso de planta.

• La necesidad de los clientes para tener sus productos específicos en un tiempo corto.

• La necesidad de tener cadenas de suministro estrechamente integradas y contar con almacenes con mínima existencia.

Los Sistemas Holónicos de Manufactura (HMS) traen consigo innumerable cantidad de ventajas, entre ellas la solución a los problemas antes mencionados.

Aunque los HMS han sido ampliamente investigados enfocados hacia la automatización, su procedencia tiene asociado un concepto filosófico cuando, mediados de los sesentas, Koestler concluyó que las partes o los todos no existen en el dominio de la vida y propuso la palabra “Holón” [4] para representar esta naturaleza híbrida, como una combinación de la palabra griega holos, la cual significa todo, y el sufijo on, el cual significa partícula [5].

Mundialmente hay grupos e investigadores trabajando en los Sistemas Holónicos de Manufactura (Holonic Manufacturing Systems – HMS), paradigma que va en sintonía con las tendencias antes mencionadas. Entre otros, están los siguientes grupos:

En la Universidad de los Andes, Venezuela, el doctor Edgar Chacón trabaja en Sistemas Híbridos, Sistemas Jerárquicos, Automatización Integrada LaSDAI.

En Katholieke Universiteit Leuven, Bélgica, el grupo PMA Holonic Manufacturing Systems Group (GOA/HMS), a cargo de Paul Valckenaers, Hendrik Van Brussel.

11

En Universidad de Cambridge, el grupo Agent Oriented Software Group, a cargo de Duncan McFarlane.

The HMS Consortium [2], cuyo objetivo es lograr en la fabricación, los beneficios que las organizaciones holónicas proveen a las sociedades y organismos vivientes.

Además, “Industrial Applications of Holonic and Multi-Agent Systems – HoloMAS” [3] es una conferencia internacional que se realiza periódicamente.

En los desarrollos hechos por grupos investigadores en este campo se proponen holarquías compuestas por diferentes tipos de holones, por ejemplo: Holón Misión, Orden, Recurso, Ingeniería, Método, Staff y Supervisor, etc. Existen similitudes y diferencias en las propuestas, pero al hacer una minuciosa revisión en el Holón Recurso (HR) es donde parece haber menos diferencias.

El HR representa recursos físicos en las empresas y por tanto es de especial interés en el área de la automatización y el control. El paradigma holónico podría sugerir cambios en los controladores actuales o bien, en el mejor de los casos, permitiría la adición de los atributos holónicos sin perjudicar las configuraciones existentes.

En las propuestas existentes para sistemas holónicos, específicamente el HR, se ha identificado que no se ha abordado desde la teoría del control, se ha estudiado poco sobre su naturaleza dinámica, no se cuenta con variedad de modelos que ilustren su comportamiento y tampoco se ha realizado validación formal de estos modelos desde la teoría.

El estudio del comportamiento dinámico del HR permitiría conocer en profundidad su comportamiento y obtener un modelo que lo represente, para lo cual se hará una revisión minuciosa pretendiendo reunir las principales dinámicas que rigen su comportamiento, con el fin de construir un modelo que las reúna y poder hacer así una evaluación de sus propiedades.

La construcción del modelo se realiza a partir de la selección de la teoría más adecuada para las dinámicas encontradas, teoría que servirá además para hacer la validación del modelo a partir de la evaluación de propiedades: controlabilidad y observabilidad.

La evaluación de observabilidad permite determinar si es posible ver u observar los eventos que ocurren al interior del sistema, en este caso el HR. La observabilidad de un evento es una propiedad directamente relacionada con la controlabilidad del mismo, ya que la no observabilidad implica directamente no controlabilidad.

12

Así, la osbervabilidad y la controlabilidad de los eventos y del sistema en general afectan considerablemente el desempeño del HR. Un análisis de estas dos propiedades puede arrojar resultados sobre la viabilidad de llevar el sistema a estados deseados evitando caer en los no deseados, factor importante en sistemas de producción porque podría generar incumplimientos y retrasos en las entregas.

1.1. Planteamiento del problema

En las investigaciones realizadas sobre los HMS se han planteado tres tipos de holones básicos: Misión, Ingeniería y Recurso. El holón recurso (HR) es de especial interés porque este representa recursos físicos y con la implementación de HMS se cambia el paradigma del sistema de control de estos recursos.

El HR está a su vez dividido en tres partes principales: Parte física, interface intra-holón y toma de decisiones. El nivel de decisión del RH presenta un comportamiento con dinámicas discretas, las cuales, integradas se pueden interpretar como un problema de control, en el cual se controla un proceso mediante estas decisiones y a la vez tiene un comportamiento en lazo abierto controlado por otro holón.

Este problema de control necesita primero que todo ser modelado para poder ser analizado, evaluado y controlado. El modelo que actualmente se tiene diseñado en la literatura alcanza un nivel conceptual, explicando el funcionamiento de las dinámicas y algunas de las interacciones entre ellas. El modelo que se propone es obtenido a partir de la interacción de sus dinámicas representadas por una metodología formal de modelamiento que permitan alcanzar un nivel operativo. La evaluación de este modelo va enfocada a análisis de propiedades que garanticen su correcto funcionamiento como sistema dinámico.

Algunas de las propiedades de los Sistemas de Eventos discretos (SED) pueden ser evaluadas fácilmente como la ciclicidad, alcanzabilidad, vivacidad, etc, las cuales no son de interés de investigación por su fácil evaluación con plataformas informáticas. Sin embargo existen algunas propiedades teóricas de interés para los sistemas como la controlabilidad y la observabilidad, las cuales sí se analizarán en la presente investigación.

Con esta finalidad es posible plantear la siguiente hipótesis: Es posible, a partir de la teoría de DES, disponer de una metodología formal de modelamiento para el comportamiento del nivel de decisión del RH que posibilite el análisis de controlabilidad y observabilidad.

13

1.2. Objetivos

1.2.1. Objetivo General

Construir un modelo del holón recurso que represente el comportamiento y permita la evaluación de propiedades como sistema dinámico.

1.2.2. Objetivos Específicos

• Seleccionar el formalismo de modelado a utilizar. • Representar las dinámicas en el formalismo elegido. • Evaluar la controlabilidad y observabilidad en el modelo propuesto. • Ilustrar el comportamiento del modelo en un ejemplo.

14

2. SISTEMAS DE MANUFACTURA

La manufactura es el uso de herramientas, máquinas y mano de obra con el fin de fabricar productos. Los sistemas de manufactura consisten en realizar cambios de la materia prima en productos terminados a gran escala, los cuales son útiles para la fabricación de nuevos productos más complejos que serán adquiridos por usuarios finales o consumidores. Estos sistemas cada vez buscan sustituir más la mano de obra humana por equipos mecánicos, eléctricos, electrónicos o sistemas a través de la automatización, con el fin de optimizar el uso de los recursos existentes y la continuidad de los procesos.

La automatización debe proveer una infraestructura que permita cubrir todas las fases y aspectos del proceso productivo con el fin de lograr un incremento de la producción, manteniendo o reduciendo los costos, por esta razón en los sistemas de manufactura se encuentran presentes las actividades inherentes de la automatización: Optimización, Planificación, Supervisión y Control.

En función del proceso industrial, se organizan e integran dichas actividades definiendo diferentes arquitecturas jerárquicas, heterárquicas e inclusive hibridas [6].

Inicialmente, la automatización solo ocurría a nivel de máquinas y supervisión, siendo incorporada posteriormente al proceso de planificación y optimización, lo cual dio paso al concepto de automatización integrada.

2.1. Automatización Integrada

La necesidad de maximizar los beneficios y minimizar los costos de una empresa, que le permita competir en el mercado actual conduce a la automatización integrada de la misma. Esta integración debe permitir la interconexión entre sistemas y procesos de una manera eficiente y flexible ofreciendo mejores tiempo de respuesta ante las exigencias del mercado actual o ante cambios que puedan ocurrir en el mismo. Por otro lado, el incremento que ocurre día a día de nuevas tecnologías que permiten de una u otra manera reducir tiempos y costos de procesamiento, hace necesario que dicha integración facilite la incorporación de estas nuevas tecnologías de la manera más rápida y sencilla.

La automatización integrada de procesos requiere de un proceso de automatización jerárquico con funciones específicas en cada nivel de la jerarquía. Para permitir la integración de todo el sistema, se requiere que exista comunicación interna en cada nivel y comunicación entre niveles, además, cada nivel de disponer de toda la información necesaria para llevar a cabo sus tareas.

15

Además, se requiere integrar las funcionalidades de cada sistema y/o proceso que conforman todo el proceso de la empresa, coordinar y planificar todas las tareas de producción, optimización, gestionar los negocios de la empresa, etc. [7]. Algunos conceptos han surgido para la automatización integrada, la mayoría de ellos jerárquicos.

2.1.1. Concepto CIM

El concepto de Manufactura Integrada por Computador, cuyas siglas CIM provienen del inglés Computer Integrated Manufacturing. Uno de sus aportes más significativos fue la pirámide de la automatización (Figura 1), la cual muestra cómo se relacionan jerárquicamente los diferentes niveles del sistema de manufactura, desde los dispositivos físicos, hasta el gerencial a través de un sistema de control supervisorio y adquisición de datos (SCADA por sus siglas en inglés, Supervisory Control and Data Acquisition).

Figura 1. Pirámide de la Automatización

Este concepto ha sido una solución que puede mejorar algunos de los problemas de los sistemas de manufactura, por ejemplo, brindar más flexibilidad en los procesos productivos, aumentar la agilidad en el sistema de producción, obtener respuestas más rápidas y lograr la integración de componentes de software y hardware [8],[9]. Sin embargo, estos mecanismos de planificación, programación y control centralizados y secuenciales cada vez son menos flexibles y ágiles para responder a estilos de producción cambiantes y variaciones altamente dinámicas en los requerimientos de los productos. Más aún, su construcción siempre pone en riesgo los requisitos de gran inversión y la generación de sistemas rígidos debido a su gran tamaño y centralización. Los controles en el nivel de las máquinas físicas se implementan típicamente usando grandes plataformas de hardware comúnmente costosas, que soportan aplicaciones de control computarizado monolítico. Como resultado, cuando el sistema de control está instalado, los cambios adicionales son comúnmente complejos y difíciles [11].

16

2.1.2. Norma ISA-95

ISA-95 contiene modelos y terminología, los cuales pueden ser usados para determinar qué información se debe intercambiar entre los diferentes sistemas, como los sistemas de ventas, finanzas, logística, producción, mantenimiento y calidad. Esta información se estructura en modelos en Lenguaje Unificado de Modelamiento (UML, por sus siglas en Inglés, Unified Modeling Language), que son la base para el desarrollo de interfaces estándar entre sistemas de Planificación de Recursos de la Empresa y de Ejecución de la Manufactura (ERP, por sus siglas en Inglés Enterprise Resource Planning y MES, Manufacturing Execution System).

El estándar ISA-95 puede usarse para varios propósitos, por ejemplo como guía para la definición de requerimientos de usuario, para la selección de proveedores y como una base para el desarrollo de sistemas MES y bases de datos.

ISA-95 soluciona el problema existente del mal funcionamiento entre los sistemas de negocio y los de manufactura, por lo tanto no define implementación sino terminología y requerimientos funcionales [11].

De forma similar al concepto CIM, el estándar ISA-95 proporciona una organización jerárquica del sistema de manufactura, que va desde los procesos físicos, bien sean por lotes, continuos o no, hasta el nivel más alto llamado de Logística de Negocio (Figura 2).

Figura 2. Niveles en el estándar ISA-95

A nivel industrial es común ver cada vez más la producción de lotes más pequeños que contienen partes de producto personalizadas. Esto debido a que cada vez más los productos tienen a ser más especializados y su producción no se requiere de forma masiva. Para obtener lotes de este tipo es necesario contar

17

con sistemas más flexibles, que permitan obtener una gran gama de productos sin necesidad de hacer cambios significativos en su infraestructura.

2.1.3. Sistemas de Manufactura Flexible (FMS)

El concepto de fabricación flexible se ha desarrollado simultáneamente con el desarrollo de tecnología de informática en las áreas de diseño y fabricación de piezas, así como la tecnología de control y servo-mecanismos.

La fabricación de piezas mecánicas sometidas a varios procesos, involucran complejos sistemas de control y producción, tales como, proveer materias primas, materiales, órdenes de trabajo, entre otros. Uno de los principales problemas consiste en el cambio y ajuste de herramientas de trabajo, lo que evidentemente imposibilitaba poder obtener altos índices de productividad, debido a los tiempos de recambio de piezas, cambios de formato de maquinas, ajuste y reprogramación de proceso de máquina. Los FMS solucionan estos problemas, trayendo con sí algunas ventajas, como:

- Una marcada tendencia en la reducción de los costos de fabricación, al eliminar operaciones innecesarias, transporte materiales y producto terminado, desperdicio de materiales y disminución efectiva de piezas defectuosas.

- Un incremento sustancial de los indicadores de productividad, al incrementar los volúmenes de fabricación significativamente.

- Un grado significativo de calidad del producto terminado. - Mejora del grado de satisfacción del cliente, al proporcionársele un producto

de alta calidad en corto tiempo. - Reducción significativa del espacio necesario o área de trabajo para la

operación de equipo y maquinaria. - Fácil integración con el sistema Justo a Tiempo (JIT de sus siglas en inglés

Just In Time) lo que puede eliminar o disminuir significativamente las áreas de almacenamiento de producto terminado y materias primas.

Algunos otros términos relacionados con los conceptos de manufacutra flexible e integrada por computador son: Computer Aided Design – CAD, Computer Aided Manufacturing – CAM, Computer Numerical Control – CNC [12].

2.2. Paradigmas en los sistemas de manufactura

2.2.1. Arquitectura Centralizada

La arquitectura centralizada (Figura 3) fue la primera en ser usada. Se caracteriza por un único nodo de decisión, donde se concentran todas las funciones de información de procesamiento y planeación [13]. Esta arquitectura tiene la ventaja

18

de una mejor optimización del control, sin embargo presenta algunas desventajas importantes, en términos de velocidad de respuesta, complejidad del control, tolerancia a fallas y capacidad de expansión, especialmente para sistemas grandes.

Figura 3. Estructuras de Control (adaptada de [13])

2.2.2. Arquitectura Jerárquica

En la arquitectura jerárquica, un problema complejo es descompuesto en varios más pequeños. Esta arquitectura se caracteriza por la existencia de algunos niveles de control, distribuidos en una estructura de árbol, permitiendo la distribución de la toma de decisiones entre estos niveles jerárquicos. Las relaciones entre los niveles jerárquicos se basan en el concepto maestro-esclavo. Las principales ventajas de esta arquitectura con la robustez, la predictibilidad y la eficiencia que son mejores que en arquitecturas centralizadas. Sin embargo, la aparición de perturbaciones en el sistema reduce significativamente su desempeño [14].

2.2.3. Arquitectura Heterárquica

En el área de la computación, se ha utilizado la estructura por medio de agentes (heterárquica), siendo ésta completamente opuesta a la jerárquica, ya que la autonomía para cada uno de los agentes es completa, es decir, todos pertenecen al mismo nivel (sistema distribuido) y sus decisiones no deben ser consultadas o autorizadas por un nivel superior.

Una arquitectura heterárquica posee gran flexibilidad y buen desempeño ante perturbaciones, además la adición de nuevos elementos al sistema es muy fácil. La principal desventaja es que la optimización global se ve afectada, debido a que la toma de decisiones es local y autónoma ya que cada agente se concentra únicamente en el logro individual de sus objetivos.

2.2.4. Arquitectura Holónica

La arquitectura holónica combina los atributos positivos de las 2 anteriores, heterárquica y jerárquica. Toma de la jerárquica la eficiente operación en condiciones normales y utiliza la autonomía para reaccionar a las perturbaciones.

19

Los holones combinan el todo y la parte, siendo simultáneamente todos auto-contenidos a sus partes subordinadas y partes dependientes cuando son vistas desde niveles superiores (efecto Janus). La propiedad que cada holón puede ser parte de otro holón, permite dividir un holón en varios, inclusive estos se pueden dividir entre otros, permitiendo así la descomposición de la complejidad [14].

Los holones que componen el sistema no son todos iguales, incluso, los hay de diferentes tipos. Se han identificado varias arquitecturas propuestas por grupos de investigación, las cuales sugieren distintos nombres para los tipos de holones básicos.

En [15] se propone una arquitectura compuesta por Unidades de Producción (UP), en la cual se definen tres componentes principales del HMS:

Misión: Las decisiones se toman teniendo en cuenta el estado de los recursos de producción y el mejor método de producción para obtener el objetivo.

Recursos de producción: Un sistema holónico conoce y maneja los recursos de producción.

Aspectos ingenieriles de producción: El uso óptimo de los recursos para alcanzar una misión se obtiene por medio del conocimiento de los métodos de producción.

Cada uno de estos componentes se redefine como un tipo de holón con el fin de formar un HMS: Holón Misión (HM), Holón Recurso (HR) y Holón Ingeniería (HI).

En [16] se afirma que tres holones básicos forman un conjunto necesario, por cuestiones de división e independencia de objetivos, y suficiente con el que se cubren funciones críticas tales como programación de operaciones, control de niveles de inventarios, coordinación de máquinas para ejecutar operaciones, planificación del mantenimiento, monitoreo, desarrollo de procedimientos de control, planificación de procesos, diseño de productos, control de calidad, etc [17], [18].

Los 3 holones básicos propuestos en PROSA (Figura 4) son: Orden, Producto y Recurso.

20

Figura 4. Holones básicos de un HMS y sus relaciones (Adaptada de [16])

En [19] también se han identificado sistemas holónicos compuestos por 3 holones básicos. Las funciones son similares con algunas variaciones funcionales, pero finalmente se puede obtener una equivalencia no exacta en sus nombres (Tabla 1). En la presente investigación se tomará la arquitectura de la UP.

Tabla 1. Equivalencia (no exacta) entre arquitecturas holónicas

UP Misión Ingeniería Recurso

PROSA Orden Producto Recurso

ADACOR Tarea Producto Operacional

Koestler también identificó dos características importantes de un holón [5], autonomía, donde la estabilidad de los holones resulta de su habilidad para actuar autónomamente en caso de circunstancias impredecibles, y la cooperación, la cual es la habilidad que tienen de cooperar, transformando estos holones en componentes efectivos de todos más grandes.

Un HMS contiene varios sistemas de toma de decisiones, debido a que este mismo está compuesto por varios holones, cada uno con su propio sistema, los cuales intercambian información (Figura 5).

21

Figura 5. Intercambio de información en un holón (Adaptada de [20])

El objetivo es obtener en los sistemas de manufactura los beneficios que la organización holónica tiene para los organismos vivientes, es decir, estabilidad en la presencia de perturbaciones, adaptabilidad y flexibilidad en la presencia del cambio y uso eficiente de los recursos disponibles.

Teniendo en cuenta este objetivo de los HMS y las dos características importantes definidas por Koestler, se puede afirmar que para que un holón sea definido como tal, debe tener al menos dos atributos, autonomía y cooperación, propiedades definidas en [21]:

Autonomía: Es la capacidad de una entidad de crear y controlar la ejecución de sus propios planes y/o estrategias.

Cooperación: Es un proceso donde un conjunto de entidades desarrolla mutuamente planes aceptables y los ejecuta.

Un holón puede representar una actividad física o lógica, tal como un robot, una máquina, una orden, un sistema de manufactura flexible, o incluso un operador humano [22]. El holón tiene información acerca de sí mismo y el ambiente que lo rodea, por lo cual contiene una parte de procesamiento de información y una parte de procesamiento físico cuando el holón representa un dispositivo físico [23].

La división del holón en estas 2 partes, física y de procesamiento de información, sugiere una arquitectura (Figura 6a), primera aproximación a la arquitectura del holón.

22

Figura 6. Arquitectura general del holón (Adaptada de [24])

En esta arquitectura, se sugiere que el holón está básicamente compuesto por:

• Procesamiento físico • Control Físico • Toma de decisiones: Está a su vez sirviendo de interfaz del holón con

humanos y otros holones.

En [24] se propone una arquitectura similar (Figura 6b), pero en este caso existe explícitamente un interface interna, ubicada justo entre las partes de control físico y toma de decisiones.

La naturaleza dinámica del sistema que representa la parte física del holón puede ser continua o discreta. En [20] se plantea la forma de implementar supervisores para unidades de producción holónicas, compuestas por proceso, recursos, productos, método de producción, supervisor e integrador, sugiriendo una arquitectura para el supervisor (Figura 7).

Figura 7. Arquitectura de supervisión (Adaptada de [20])

23

La familia de controladores se encarga de mantener comportamiento correcto del sistema dentro de una región operacional y mover el sistema de un punto de operación a otro.

En esta arquitectura, es clave observar la forma en que el sistema de decisión adquiere información del sistema controlado y su familia de controladores, a través de una imagen o proyección discreta de los procesos reales, obteniendo de ellos únicamente una representación suficiente para conocer su estado. Así, el concepto holónico es aplicable a recursos de cualquier naturaleza, bien sea continua, híbrida o discreta.

Una arquitectura de control para lograr un sistema de supervisión (Figura 8) está compuesta de:

• Procesos y controladores: Definidos anteriormente en la arquitectura de supervisión.

• Proceso compuesto: Se obtiene a partir de la composición de unidades de producción elementales.

• Supervisor: El cual se encarga de la toma de decisiones de la unidad de producción. Este supervisor toma el nombre de “supervisor local” cuando pertenece a una UP elemental o “supervisor global” cuando está en un nivel de jerarquía mayor por pertenecer a procesos compuestos.

Figura 8. Supervisión del sistema (Adaptada de [20])

Así, un proceso está compuesto finalmente por: Proceso, controlador, interface intra-holón y supervisor.

24

El proceso junto con el controlador se entenderá como parte física, debido a que existen como tal en los sistemas de manufactura reales. Su comportamiento se adquirirá a través de una proyección discreta de sus estados de cualquier naturaleza.

Esta parte física estará supervisada a través de un supervisor local, el cual se comporta como un SED [20].

Sin embargo, este Holón Recurso tiene partes del supervisor en otros niveles, por ejemplo en el Holón Misión (HM), el cual hace parte de la jerarquía. El HM compone todos los procesos que involucran la misión que él representa y añade componentes de supervisión a cada uno de sus recursos a cargo.

La afirmación que el supervisor local o parte de toma de decisiones tenga naturaleza discreta, abre puertas a investigaciones apoyadas en la teoría formal de los SED, utilizada ampliamente en las áreas de control y automatización. El análisis más a fondo del comportamiento se convierte entonces en el primer paso necesario para lograr un punto de vista del holón desde estas áreas.

25

3. SISTEMAS DINÁMICOS A EVENTOS DISCRETOS

En las últimas décadas, la rápida evolución de los computadores y las telecomunicaciones ha traído consigo la proliferación de sistemas dinámicos “nuevos”, comúnmente de alta tecnología y altamente complejos. Los ejemplos están a nuestro alrededor: Redes de internet, sistemas de manufactura automatizados, sistemas de control de tráfico aéreo, sistemas de información, monitoreo y control de edificios o automóviles, sistemas de transporte inteligente, sistemas de software distribuido, etc.

Una porción significativa de la “actividad” en estos sistemas, algunas veces toda, se gobierna por reglas operacionales diseñadas por humanos; estas dinámicas se caracterizan entonces por la ocurrencia asíncrona de eventos discretos, algunos controlados (como presionar una tecla, encender un equipo, enviar un mensaje) y otros no (como falla espontánea de equipo o pérdida de paquetes), algunos observados a través de sensores y otros no. Estas características los convierten en sistemas a eventos discretos.

El arsenal matemático centrado en las ecuaciones diferenciales que ha sido utilizado en la ingeniería de sistemas y de control para modelar y estudiar los procesos gobernados por las leyes de la naturaleza es inadecuado o simplemente inapropiado para los sistemas a eventos discretos [26].

3.1. Conceptos básicos

Un sistema dinámico a eventos discretos (DEDS) se define entonces como un sistema de estados discretos cuya evolución depende completamente de la ocurrencia asíncrona de eventos discretos sobre el tiempo.

Muchos sistemas a nuestro alrededor son DEDS; incluso si no es el caso, tener una vista de estados discretos del sistema complejo es muy útil para muchas aplicaciones [26].

3.1.1 Clasificación de los DEDS

Los DEDS están clasificados como sistemas:

Dinámicos: Debido a que la salida depende de los valores anteriores de la entrada.

Invariantes en el tiempo: Debido a que su comportamiento no varía con el tiempo.

26

No lineales: Porque no cumple el principio de superposición, además, funciona como un sistema suicheado al cambiar entre estados discretos, generando no linealidades.

En la Figura 9 se muestra esta clasificación de una forma más general.

Figura 9. Clasificación de sistemas (Tomada de [26])

Un análisis más detallado de su comportamiento lógico se puede realizar por medio de la teoría de lenguajes y sus operaciones, las cuales permiten analizar las secuencias de eventos que pueden ser representadas por un DEDS y abren la puerta a la teoría de control supervisorio, elemento indispensable para esta investigación.

3.1.2. Lenguajes

Existen dos lenguajes de especial interés para analizar en un DEDS, estos son el lenguaje generado y el marcado. La importancia del primero de ellos radica en el hecho que este especifica todas las cadenas que se pueden representar por medio de éste; el segundo de ellos, el marcado, especifica únicamente las cadenas que llevan a un estado final deseado o marcado. A continuación se presentan las definiciones formales de estos lenguajes:

Una función de transición es una función :f X x E X→ , por ejemplo ( , )f x a y= indica que si el DES se encuentra en el estado x y se produce el evento a entonces habrá una evolución del sistema al estado y .

27

Cerramiento de Kleene: Para un conjunto E de eventos, *E se define como el conjunto de todas las cadenas finitas de elementos de E .

Lenguaje generado: Un lenguaje generado se define como *

0( ) : { : ( , ) }L G s E f x s está definido= ∈

Lenguaje marcado: Un lenguaje marcado se define como 0( ) : { ( ) : ( , ) }m mL G s L G f x s X= ∈ ∈ .

3.1.3 Operaciones en lenguajes

Cerramiento en prefijos: Para un lenguaje *L E⊆ se define como * *: { : ( )}L s E t E st L= ∈ ∃ ∈ ∈ .

Composición paralela: Para dos sistemas 1G y 2G se define como:

1 2 1 2 1 2

1||2 01 02 1 2

|| : ( ( , ,......, , , ( , ), ))m m

G G Ac G X xX E Ef x x X xX

= = ∪Γ

Donde:

1 1 2 2 1 1 2 2

1 1 2 1 1 21 2

1 2 2 2 2 1

( ( , ), ( , )) ( ) ( )( ( , ), ) ( ) \

(( , ), ) :( , ( , )) ( ) \

f x e f x e si e x xf x e x si e x E

f x x ex f x e si e x Eindefinido de lo contrario

∈Γ ∩Γ ∈Γ = ∈Γ

Concatenación: Para dos lenguajes ,

Conceptualmente, la concatenación uv de dos cadenas u y v es la nueva cadena que consiste de los eventos en u inmediatamente seguidos de los eventos en v. La cadena vacía ε es el elemento identidad de la concatenación: uε = εu = u para cualquier cadena u.

Proyección natural: Se denota con P y se define como la función * *: oP E E→ con:

*

( ) :

( ) :

( ) : ( ) ( ) ,

o

o

Pe si e E

P esi e E

P se P s P e para s E e E

ε ε

ε

=

∈= ∉= ∈ ∈

28

3.2. Teoría de Control Supervisorio

La toma de decisiones, además de negociación de tareas, está directamente relacionada con el monitoreo constante del estado del mismo recurso y el control que él mismo ejerce autónomamente. El esquema (Figura 10) permite observar este comportamiento reactivo, relacionando la toma de decisiones del holón.

El proceso es medido y dichas observaciones se comparan con los objetivos o referencias. Dicha diferencia es obtenida y se convierte en acciones de control para corregirla. Esto finalmente se ve reflejado en un actuador que modifica el estado del proceso.

Figura 10. El ciclo de toma de decisiones (Adaptada de [20])

La teoría de control realimentado consiste en modificar el comportamiento de una planta a través de la detección de sus estados, comparación con el comportamiento deseado o referencia y la posterior acción para lograr la menor diferencia entre estos comportamientos. Desde este punto de vista, la relación del ciclo de toma de decisiones y la teoría antes mencionada se hace evidente.

El DEDS es modelado por G, con un conjunto de eventos E. G modela el “comportamiento no controlado” del DEDS. Este comportamiento no es satisfactorio y se debe modificar con el control, es decir, restringir el comportamiento a un subconjunto de L(G). Para lograr esto se introduce un supervisor S.

El lenguaje L(G) originalmente contiene cadenas que no son aceptables, es decir, violan condiciones que se quieren imponer al sistema. Por ejemplo, cuando

29

algunos estados de G son no deseables o deberían ser evitados. Estos estados pueden ser donde G se bloquea o estados físicamente inadmisibles.

Algunas cadenas en L(G) podrían contener subcadenas no permitidas, las cuales podrían violar un orden deseado de ciertos eventos. Entonces, se deben considerar sublenguajes de L(G) que representan el comportamiento legal y admisible del sistema controlado:

( )r aL L L G⊂ ⊆

Donde el objetivo es restringir el comportamiento del sistema dentro del rango delimitado por rL y aL . aL se interpreta como el comportamiento máximo admisible y rL el comportamiento mínimo requerido.

La mayor importancia del control supervisorio es definir la forma en que S interactúa con G. En este caso, S ve (u observa) algunos o todos los eventos que G ejecuta, luego, S restringe en G los eventos que pueden disparar o no, es decir, S tiene la capacidad de deshabilitar algunos eventos de G. Es importante considerar que S está limitado en términos de observar los eventos ejecutados por G y que S también está limitado en términos de deshabilitar eventos de G. Así, se deben tomar los eventos observables de E – aquellos que S puede observar – y los eventos controlables en E – aquellos que S puede deshabilitar.

Los paradigmas actuales sugieren un esquema de supervisión centralizado en un único supervisor global para todas las diferentes entidades (Figura 11a), mientras que en los sistemas holónicos cada entidad cuenta con uno local (Figura 11b), lo que descentraliza y divide el sistema de toma de decisiones, reduciendo el problema de la complejidad. Además este supervisor global hace las veces de coordinador.

(a) (b)

Figura 11. Esquemas de supervisión (centralizado y holónico)

En realidad, las entidades o, en este caso, recursos, cuentan con un único supervisor. Sin embargo, este supervisor está dividido en muchas partes. Una de

30

estas partes consiste en el nivel de toma de decisiones. Otras partes de este supervisor están contenidas en el HM y otros holones organizados en niveles más superiores.

En el caso que una UP sea vista como un recurso para un sistema más grande, el HR indivisible (recurso físico) tendrá una parte de su supervisor en los holones pertenecientes a ese sistema.

En el caso de esta investigación, se hará una evaluación detallada de la parte de toma de decisiones, y es esta parte la que se tomará como objeto de evaluación de propiedades, como la controlabilidad y la observabilidad.

3.3.1. Controlabilidad

La evaluación de esta propiedad permite conocer qué estados se pueden alcanzar a partir del estado inicial de un sistema. Se debe conocer además qué estados son alcanzables incluso ante la presencia de eventos no controlables.

Con el fin de analizar estos eventos no controlables es necesario dividir el conjunto de eventos E en dos subconjuntos, así:

c ucE E E= ∪ (1)

Donde:

cE es el conjunto de eventos controlables, es decir, que se puede prevenir su ocurrencia por medio de un supervisor.

ucE es el conjunto de eventos no controlables, es decir, su ocurrencia no se puede prevenir o controlar.

Teorema de Controlabilidad

Considérese un sistema G, donde ucE E⊆ es el conjunto de eventos no controlables. Sea ( )K L G⊆ , donde K ≠ ∅ . Entonces existe un supervisor S tal que ( / )L S G K= si y sólo si:

( )ucKE L G K∩ ⊆ (2)

En otras palabras, si esta propiedad se cumple quiere decir que se puede hallar un supervisor S que haga que el sistema compuesto genere únicamente cadenas incluidas en el lenguaje K.

31

3.3.2. Observabilidad

Intuitivamente, observabilidad significa:

“Si no se puede diferenciar entre dos cadenas, entonces estas cadenas deberían requerir la misma acción de control” [25].

Otra forma de enunciar esto, es desde el punto de vista de la deshabilitación:

“Si se deben deshabilitar un eventos después de observar una cadena, entonces para hacerlo ninguna cadena que aparezca en el comportamiento deseado se deberá deshabilitar” [25].

Estas ideas intuitivas se formalizan en el teorema de observabilidad:

Sean K y M M= lenguajes sobre el conjunto E . Sea cE un subconjunto de .E Sea oE otro subconjunto de E con P como la proyección natural correspondiente de *E a *

oE .

Se dice que K es observable con respecto a M , P y cE si para todo s K∈ y para todo cEσ ∈ .

1( ) ( ) [ ( )]s K y s M P P s Kσ σ σ−∉ ∈ ⇒ ∩ =∅ (3)

En este caso hay un pequeño abuso de notación, debido a que 1[ ( )]P P s σ− en realidad se refiere a 1[ ( )]{ }P P s σ− .

El término 1[ ( )]P P s Kσ− ∩ =∅ al lado derecho de 1( ) ( ) [ ( )]s K y s M P P s Kσ σ σ−∉ ∈ ⇒ ∩ =∅ (3) identifica todas las

cadenas en K que tienen la misma proyección que s y que permanece dentro de K después de la concatenación con el evento σ . Si este lugar no es vacío, es decir que K no es observable, significa que K contiene dos cadenas, s y 's tal que ( ) ( ')P s P s= , y donde s Kσ ∉ mientras 's Kσ ∈ . Si esto ocurre, no existe un supervisor P que pueda exactamente alcanzar el lenguaje K , ya que este supervisor no puede diferenciar entre s y 's , y estas cadenas requieren una acción diferente de control dependiendo del evento σ .

32

3.3. Formalismos de modelamiento

Previamente se ha concluido que se debe realizar un modelo del sistema de toma de decisiones y la interface intra-holón. Además, se ha especificado que estas dos partes se comportan como un SED, por lo cual se debe hacer uso de técnicas de modelamiento formales para este tipo de sistemas.

La metodología que se utilizará para seleccionar el formalismo más adecuado es partiendo de la técnica más básica de modelamiento, definiendo las exigencias que tiene el HR y verificando el alcance del formalismo. En caso de no ser suficiente se hará necesario aumentar el nivel y buscar una herramienta más poderosa.

Las exigencias que se le deben realizar al formalismo son:

• Almacenamiento de órdenes de producción, ya que el HR posee una agenda que posee todas estas órdenes programadas.

• Capacidad de modelar concurrencias y paralelismos, ya que el HR posee diversos grupos de dinámicas que se ejecutan de esta forma.

• Transporte de información: Es de vital importancia examinar si el formalismo debe ser capaz de transportar un número de marcas o si estas marcas deben poseer cierto tipo de información para alcanzar un nivel de modelamiento suficiente.

La técnica más utilizada y explicada en la literatura para SED se llama “autómatas de estados finitos”, por lo cual esta será la primera en evaluarse.

3.3.1. Autómatas de estados finitos

Se denotan por G , y son una tupla de 6 elementos 0( , , , , , )mG X E f x X= Γ donde:

X es el conjunto de todos los estados E es el conjunto finito de eventos asociados a las transiciones de G

:f X x E X→ es la función de transición : 2EXΓ → es la función de eventos activos. ( )xΓ es el conjunto de todos los

eventos para los cuales f ( , )f x e está definido y se llama el conjunto de eventos activos de G en x

0x es el estado inicial

mX X⊆ es el conjunto de estados marcados.

33

Estos autómatas no resultan ser muy adecuados para sistemas complejos, debido a la poca información que pueden manejar, es decir, sus estados no representan concretamente un estado del sistema, sino que están enumerados. El HR posee una gran cantidad de posibles estados, los cuales deben contener suficiente información para alojar una orden de producción.

En el HR existen sub-comportamientos que se deben ejecutar asíncronamente y en paralelo [19], es decir, actúan de forma concurrente. Las concurrencias se trabajan normalmente con lógica AND [27], en la que se verifican varios estados antes de poder evolucionar al siguiente estado por medio de una transición. Los autómatas, debido a que únicamente permiten un arco de entrada y uno de salida para cada lugar no permiten modelar concurrencias sin incrementar su complejidad y volverse de estados infinitos.

Una técnica de más alto nivel, capaz de modelar un rango más amplio de SEDs, son las Redes de Petri las cuales, al igual que los autómatas de estados finitos, sirven para el modelamiento de SEDs, pero tienen la ventaja adicional de proveer expresividad y complejidad de modelamiento incrementada.

Existen métodos para diseñar controladores basados en modelos de sistemas en autómatas, sin embargo, estos métodos frecuentemente incluyen búsquedas exhaustivas o simulaciones del comportamiento del sistema, haciéndolos imprácticos para sistemas con gran número de estados y transiciones que causan los eventos. Una forma de enfrentar estos problemas es modelar con Redes de Petri.

Las redes de Petri tienen una representación matemática simple que usa algebra de matrices lineales, haciéndolas particularmente útil para análisis y diseño [28],son normalmente más compactas que modelos basados en autómatas similares y son más adecuadas para la representación de sistemas con estructuras y flujos ordenados pero espacios de estados alcanzables grandes [26].

Los modelos en redes de Petri permiten la ocurrencia simultánea de múltiples eventos, sin sufrir de incremento de la complejidad, tienen más estructura en su representación de la función de transición. Los estados no son enumerados sino que la información de estados se distribuye entre un conjunto de lugares que capturan condiciones clave que gobiernan la operación del sistema.

Un autómata siempre se puede representar como una red de Petri, sin embargo, no todas las redes de Petri se pueden representar como autómatas de estados finitos. Así, las redes de Petri son la herramienta más adecuada para el modelamiento del HR, entonces se realizará un estudio más detallado de las posibles extensiones que pueden tener, permitiendo analizar sus ventajas y desventajas.

34

3.3.2. Gráfico de red de Petri

Un gráfico de redes de Petri (o estructura de redes de Petri) es una gráfica bipartita ( , , , )P T A w , donde:

P es el conjunto finito de lugares (un tipo de nodo en el gráfico)

T es el conjunto finito de transiciones (otro tipo de nodo en el gráfico)

( ) ( )A P x T T x P⊆ ∪ es el conjunto de arcos de lugares a transiciones y de transiciones a arcos en los lugares del gráfico.

: {1,2,3,...}w A→ es la función de peso de los arcos

Se asume que ( , , , )P T A w no tiene lugares o transiciones aislados.

Se puede ver que un gráfico de redes de Petri es un poco más elaborado que el diagrama de transición de estados de un autómata. Primero, los nodos del diagrama de transición de estado corresponden a estados de un solo conjunto X. En un gráfico de redes de Petri, los nodos son lugares seleccionados del conjunto P, o transiciones seleccionadas del conjunto T. Segundo, en un diagrama de transiciones de estado hay un único arco por cada evento que causa una transición de estado. En un gráfico de redes de Petri, se permiten múltiples arcos para conectar dos nodos, o equivalentemente, se asigna un peso a cada arco que representa el número de arcos. Por esta razón esta estructura se llama multigráficos.

Cuando se describe un gráfico de redes de Petri, es conveniente usar ( )jI t para representar el conjunto de lugares de entrada a la transición jt . Similarmente,

( )jO t representa el conjunto de lugares de salida para la transición jt . Así, se tiene:

( ) { : ( , ) }j i i jI t p P p t A= ∈ ∈ , ( ) { : ( , ) }j i j iO t p P t p A= ∈ ∈

Para dibujar gráficos de redes de Petri se necesita diferenciar entre dos tipos de nodos, lugares y transiciones. Se usan círculos para representar lugares y barras para representar transiciones. Los arcos que conectan lugares y transiciones representan elementos del conjunto de arcos A. Así, un arco dirigido del lugar ip a la transición jt significa que ( )i jp I t∈ . Más aun, si ( , )i jw p t k= , luego hay k arcos de ip a jt o equivalentemente un único arco acompañado de su peso k. Similarmente se puede hacer para el conjunto de lugares de salida ( )jO t . Generalmente, el peso de los arcos se representa mediante múltiples arcos en el

35

gráfico, pero si se tienen pesos altos es mucho más eficiente representar el peso mediante la escritura en un único arco.

Finalmente, es conveniente extender el dominio y co-dominio de la función de peso w y escribir:

( , ) 0i jw p t = cuando ( )i jp I t∉ y ( , ) 0j iw t p = cuando ( )i jp O t∉ .

3.3.3. Red de Petri marcada

Una red de Petri marcada [26] es una 5-tupla ( , , , , )P T A w x donde ( , , , )P T A w es un gráfico de red de Petri y x es un marcaje del conjunto de lugares P.

1 2[ ( ), ( ),..., ( )] nnx x p x p x p= ∈ es el vector columna asociado a x . Este vector

contiene el marcaje de todo el conjunto de lugares.

Sin embargo, este marcaje termina siendo un número real, representando el número de fichas o marcas que un lugar posee. Finalmente, una marca en un lugar no termina siendo más que eso, un número.

La función de transición de estado, : n nf x T → , de la red de Petri ( , , , , )P T A w x se define por la transición jt T∈ sí y sólo si ( ) ( , )i i jx p w p t≥ para todo ( )i jp I t∈ .

Esta condición asegura que la función de transición está definida únicamente para las transiciones habilitadas. Así, una transición habilitada es equivalente a un evento factible en un autómata, a diferencia que en este caso la función de transición de estados no es arbitraria, sino basada en la estructura de la red de Petri.

Si ( , )jf x t está definido, entonces se define ' ( , )jx f x t= donde '( ) ( ) ( , ) ( , ), 1,...,i i i j j ix p x p w p t w t p i n= − + =

De acuerdo a esta condición, si ip es un lugar de entrada de jt , este pierde tantas marcas como el peso del arco de ip a jt . Si es un lugar de salida, entonces gana tantas marcas como el peso del arco de jt a ip . Se puede presentar que ip es salida y entrada al mismo tiempo para jt , por lo cual ocurre que se remueven

( , )i jw p t marcas de ip e inmediatamente se adicionan ( , )j iw t p nuevas marcas.

Es importante notar que el número de marcas no necesariamente se conserva después del disparo de una transición en una red de Petri. Es claro que es enteramente posible que:

36

( , ) ( , )i i

j i i jp P p P

w t p w p t∈ ∈

>∑ ∑ o ( , ) ( , )i i

j i i jp P p P

w t p w p t∈ ∈

<∑ ∑

En los cuales, bien sea ' ( , )jx f x t= contiene más marcas que x o menos marcas que x . En general, es totalmente posible que después de muchos disparos de transiciones, el estado resultante sea [0,...,0]x = , o que el número de marcas en uno o más lugares crezca arbitrariamente grande después de un numero arbitrariamente grande de disparos de transiciones. Este último fenómeno es un factor diferenciador entre redes de Petri y autómatas, donde los autómatas de estados finitos tienen únicamente un número finito de estados por definición. En contraste, un gráfico de red de Petri finita puede resultar en una red de Petri con un número de estados no limitado.

Los siguientes casos pueden ocurrir en una red de Petri:

- La secuencia en la que las transiciones disparan no está pre-especificada en la red de Petri. En cualquier estado podrían disparar cualquiera de las transiciones habilitadas.

- No todos los estados en n se pueden alcanzar desde un estado inicial.

La función de transición f se puede extender del dominio n x T al dominio *n x T , de la misma forma que se tiene para la función de transición de los

autómatas:

( , ) :f x xε =

*( , ) : ( ( , ), )f x st f f x s t para s T y t T= ∈ ∈

Para la interface intra-holón, este formalismo resulta ser suficiente, debido a que sólo se necesita conocer en qué estado discreto se encuentra el sistema. Estos estados son: disponible, iniciando, en falla, en operación, en mantenimiento y apagado, los cuales representan la imagen discreta del proceso controlado real.

En el caso de la parte de toma de decisiones, es necesaria una capacidad de información mucho mayor. Por ejemplo, en el caso que al holón llega una solicitud de trabajo, ésta debe contener una cantidad mínima de información, tal como, cantidad de piezas, tiempos de entrega y, como en cualquier sistema de información, un remitente y un destinatario.

3.3.4. Red de Petri Jerárquica (HPN)

Una HPN [29] se define de la misma forma que una red de Petri marcada, pero se adicionan 2 elementos a la tupla:

37

( , , , , , , )P T A w x D η , donde:

D es el conjunto de fusión de lugares

η es una función que asocia las transiciones it con subredes ( )itη .

Este tipo de redes permite dividir un modelo complejo en subredes y módulos a través de dos métodos de jerarquización: la fusión de lugares y la sustitución de transiciones.

Entre las principales ventajas que tienen las HPNs están la reusabilidad y la modularización. La especialidad de la modularización es el problema de la complejidad en partes más pequeñas. La reusabilidad se concentra en la identificación de estructuras de secuencias similares dentro del modelo y lograr su repetitividad a través de una estructura genérica adaptable.

Sin embargo, para el HR, es más importante la capacidad de representación de información que la capacidad de dividir un modelo que contiene gran cantidad de estados y lograr así su simplificación. El marcaje en las HPN sería similar al de las redes marcadas, y no se identifica incremento en la capacidad de modelamiento a través de la utilización de alguno de los métodos de jerarquización.

3.3.5. Red de Petri Coloreada (CPN)

Las CPN [30] son un lenguaje orientado a gráficos para el diseño, especificación, simulación y verificación de sistemas. Es particularmente adecuado para sistemas en que es importante la comunicación, sincronización y existen recursos compartidos. Algunos ejemplos típicos son protocolos de comunicación, sistemas distribuidos, sistemas embebidos, sistemas de producción automatizados, etc.

El desarrollo de las CPN ha sido impulsado por el deseo de contar con un lenguaje de modelamiento fundamentado teóricamente pero lo suficientemente versátil para ser usado en la práctica en sistemas del tamaño y la complejidad que se encuentran típicamente en los proyectos industriales.

Una CPN está compuesta por [31]:

• Lugares: Los cuales describen el comportamiento del sistema. Representados por círculos o elipses.

• Transiciones: Las cuales describen las acciones. Representadas por rectángulos.

• Arcos: Conectan lugares con transiciones. • Expresiones de arco: Describen cómo el estado de una CPN cambia

cuando la transición ocurre. • Marcas o fichas: Son marcadores que los lugares contienen. En este caso,

las marcas llevan datos que pertenecen a un tipo.

38

Formalmente:

Una CPN es una tupla [32] ( ): , , , ,CPN C B V P T , donde:

C es un conjunto finito de colores (tipos de datos) c C∈

V es un conjunto de variables de colores c C∈ . Los colores y las variables se representan como declaraciones.

B es una bolsa de marcas (valores) de colores c C∈ , representadas cerca a algunos lugares.

P es un conjunto finito de lugares 1,... mp p P∈ , representadas por elipses. Cada lugar p contiene una bolsa pb B⊆ de marcas de color pc . Una bolsa pb del lugar p se representa usando notación punto . pp b y se llama el marcaje del lugar. Por

defecto, la bolsa pb está vacía.

T es un conjunto finito de transiciones representadas por cajas (o rectángulos). Cada transición es una tupla ( ), ,t It gt Ot= , donde

• It es un conjunto finito de arcos de entrada. Un arco de entrada _ , _ ,ip tk vt k t It∈ se dirige del lugar _ipt k a la transición t ( )0,1,...,k K= .

Un arco es un trio de lugar _ipt k P∈ , expresión de arco de entrada __ : ipt kvt k c del color del correspondiente lugar de entrada y la transición t .

• gt es una guarda de la transición t . Cada guarda es una función booleana: { }_ _1 ... _ _ ,gt c ipt x x c ipt k true false= → . Cada guarda tiene el valor true

por defecto. • Ot es un conjunto finito de arcos de salida. Un arco de salida

( ), _ , _t ft h opt h Ot∈ es un trio que contiene la transición t , el lugar _ , 0,1,...,opt h P h H∈ = y la descripción del arco _ft h la cual es una

función.

Comportamiento de una CPN:

La transición t de una CPN está habilitada si todos los lugares de todos los arcos de entrada contienen marcas que le den valor a las expresiones de entrada de t . Cada transición habilitada puede disparar.

Cuando la transición t se dispara:

39

• Para cada arco de entrada ( )_ , _ ,ip tk vt k t se evalúa su expresión de entrada _vt k por una marca del lugar _ipt k .

• Para cada arco de salida ( ), _ , _t ft h opt h se calcula su función de salida _ft h usando valores _vt k y el resultado se añade como marca al lugar

_opt h del arco de salida.

El comportamiento dinámico de una CPN es entonces muy similar al de una red de Petri marcada y ambas poseen similitudes con los autómatas de estados finitos. En la Tabla 2 se hace una comparación entre estos tres formalismos de modelamiento:

Tabla 2. Comparativo entre formalismos de modelamiento

CARACTERÍSTICAS COLOREADAS MARCADAS AUTÓMATAS

Es capaz modelar un DES a partir de arcos y estados

SI SI SI

El disparo de una transición ocasiona la evolución de marcas de un estado a otro

SI SI NO

Todos los lugares de la transición deben estar habilitados para que el disparo pueda ocurrir

SI SI NO

Posee expresiones de arco que permiten condiciones de evolución complejas

SI NO NO

Permite la transmisión de información a través de los estados, a partir de marcas que llevan datos.

SI NO NO

En relación al poder de modelamiento, la diferencia entre las redes coloreadas y las marcadas es análoga a la relación entre lenguajes de programación de alto nivel y el código ensamblador. En teoría, los dos niveles tienen el mismo poder computacional, sin embargo, en la práctica, los lenguajes de alto nivel ofrecen mucho más poder de modelamiento.

40

En el caso del nivel de decisión del HR, por ejemplo, un conjunto de color es la agenda, compuesta por colores como tipo de orden y lo tiempos que la componen. Este conjunto de color viaja por todo el modelo cambiando los valores de los colores de acuerdo a las reglas en las expresiones de arco.

Por lo tanto, por sus capacidades de transmitir información de estado en estado y por ser capaz de tener marcas de diferentes colores incluyendo información de órdenes de producción, las CPN resultan ser el formalismo de modelamiento más adecuado para realizar la representación del HR.

Conociendo ya el formalismo de modelamiento más apropiado para cada uno de los componentes del HR, se puede proceder a la construcción de cada uno de los modelos.

41

4. MODELO DEL HOLÓN RECURSO

Los modelos en ingeniería se han utilizado para obtener representaciones gráficas, conceptuales y matemáticas del comportamiento real de los sistemas dinámicos. Un modelo se puede entender como un abstracto de la realidad, que permite sustituir la medición o experimentación directa y además su ingreso en un programa de computador permite la simulación, visualización y predicción acerca del comportamiento del proceso real que representa.

En el área del control y la automatización es común la obtención de modelos de dinámicas continuas y discretas. Se ha concluido previamente que el HR posee dinámicas de naturaleza discreta y su modelo se obtendrá usando el formalismo de las redes de Petri coloreadas (CPN). La metodología a utilizar iniciará con la identificación de cada una de sus dinámicas y luego transformándolas en estados y condiciones de disparo para las transiciones entre estos estados.

El análisis y construcción de cada de las dinámicas del HR se hará combinando elementos de mapas conceptuales y diagramas de flujo (Figura 12), ilustrando el comportamiento de una forma general.

Las dinámicas del HR se dividen principalmente en 3 grupos, constituido cada uno por las que se ejecutan asíncronamente y en paralelo: Anuncio de nuevas órdenes de trabajo, ejecución de órdenes y monitoreo y adaptación (Figura 12).

Cualquiera de estos tres grupos requiere de formatos claramente definidos para comunicación con holones externos y transporte de información al interior del mismo holón.

42

Figura 12. Comportamiento dinámico del HR

43

La orden de producción (Figura 13), se define utilizando un diagrama de Gantt.

Figura 13. Orden de producción en diagrama Gantt

Donde:

Tre es el tiempo de precedencia. Otro HR puede estar realizando un proceso anterior y necesario para que el siguiente holón pueda realizar su propio proceso. Este tiempo de precedencia indica el momento en el cual el proceso anterior se terminará y el holón actual puede iniciar sus actividades en el producto.

Tini es el tiempo de inicio. Aunque con el tiempo de precedencia se tenía información sobre el momento en el cual se puede iniciar el proceso, no es necesario que Tini y Tre sean iguales. Este tiempo Tini indica el momento en el cual el holón programó autónomamente el inicio del procesamiento de la orden.

C es la cantidad de piezas. Una orden puede contener una única pieza o la cantidad requerida con las especificaciones dadas en la orden.

TP es el tiempo de pieza. De acuerdo al conocimiento que se tiene de cada recurso, este valor es constante y representa el tiempo que se demora una pieza en procesarse en este recurso. El producto de TP y C indica el tiempo total de procesamiento de la orden.

Tinc es el tiempo de incumplimiento. Este tiempo lo determina el HM y no necesariamente es igual al tiempo final de procesamiento de la orden. El HR tiene autonomía para retrasar la orden siempre y cuando la finalización de la misma no ocurra después de Tinc .

Sin embargo, esta definición no es suficiente para el envió de información entre holones y el transporte de la misma a nivel interno. Para ello se requiere definir un formato de la orden el cual hará las veces de “lenguaje” inter-holón e intra-holón, basado en la teoría definida anteriormente para las CPN.

El formato de la orden se define como un conjunto de colores complejo, formado a partir de otros conjuntos de colores:

( ): Ref ,C,TP,TRe,Tini,Tinc,Ti, Ant,Sig,Em, RecOrden =

44

Donde los conjuntos de colores son:

Ref es el proceso a realizar. Cada recurso es capaz de realizar una o varias referencias, por tanto en la orden debe contener cuál de estas referencias ejecutar. Los colores de este conjunto son: ( )A,B .

Tip es el tipo. Cuando un holón se comunica con otro holón debe indicar el tipo de información que está enviando. Los colores de este conjunto son: ( )A,B .

El color tipo puede tomar cualquiera de los siguientes valores: (Solicitud,Orden, Cooperación, Mtto, Acepta, rechazo... precedencia, norm, degr, fin_ok,fin_inc, falla, reneg)

Ant y Sig son los respectivos holones anterior y siguiente en el proceso. Los colores de este conjunto son: ( )HR1,HR2,HR3,HM1 .

Em y Rec . Como en todo tipo de comunicación, debe haber un emisor y un receptor. En la posición de Em irá la etiqueta del holón que envía la información y en la de Rec la del holón al que va dirigido el mensaje. Los colores de estos conjuntos son: ( )HR1,HR2,HR3,HM1 .

C,TP,TRe,Tini y Tinc ya han sido definidas anteriormente. Estos representan colores, ya que no contienen otros elementos.

Otros colores adicionales que se utilizarán más adelante son:

T el tiempo actual.

Reglas, las cuales dependen de cada recurso para programación autónoma de mantenimiento. Pueden ser programadas de acuerdo a las necesidades del recurso físico, dependiendo de los tiempos necesarios para su mantenimiento periódico.

Cact es la cantidad de piezas procesadas en el tiempo T.

Tfalla es el tiempo estimado de duración de falla.

Tao1es el tiempo de espera de renegociación del objetivo con el HM (timeout)

Tao2 es el tiempo de espera de solicitud de cooperación (timeout)

holgT es el tiempo de holgura, comprendido entre finalización de la orden actual e inicio de la siguiente.

45

sigTini es el tiempo de inicio de la orden siguiente en ejecución en el tiempo T .

Crest es la cantidad faltante en la orden

pTinc , qTinc ,…, zTinc es el tiempo de incumplimiento de los recursos p, q,…,z.

Tre t es el tiempo de retraso de mensaje de cooperación para una orden.

n-1 es el número de órdenes en la agenda en el tiempo T .

Cada color tiene un tipo, definido en la Tabla 3:

Tabla 3. Tipos de dato de los colores TIPO DE DATO COLORES

Cadena A , B ,Solicitud , Orden , Cooperaci nó ,Mtto , Acepta , rechazo , precedencia ,norm , degradado , fin _ ok , fin _ inc , falla, reneg , HR1, HR2 , HR3 , HM1

Numérico C , TP , TRe , Tini , Tinc , T , Reglas , Cact, Tfalla , Tao1, Tao2 , holgT , sigTini , Crest ,

nTinc , Tret

4.1. Dinámicas

El primer grupo de dinámicas a analizar será “Anuncio de nuevas órdenes de trabajo”, debido a que el caso en que un holón esté recientemente integrado a un HMS y su agenda se encuentre vacía, este grupo será el encargado de negociar las órdenes que el holón producirá en el futuro. Luego, se analizará el grupo “Ejecución de órdenes” porque se encarga de ejecutar las órdenes previamente negociadas y por último “monitoreo y adaptación” con el fin de realizar las tareas de seguimiento a los planes propios y toma de acciones correctivas en caso de ser necesarias.

Se debe aclarar que en esta tesis se hará un abuso de notación con las CPN, debido a que la información sobre el tipo de información que se transporta (expresión de arco) se especifica formalmente sobre cada uno de los arcos que componen el modelo. Sin embargo, en este caso se hará sobre cada uno de los lugares, entendiéndose que la expresión de cada arco de entrada a este lugar será la misma que de cada arco de salida. Además, no se especificará el marcaje en cada uno de los lugares porque se supondrá sin marcaje. El conjunto de color

46

para todos los lugares será el complejo “orden. Esta notación, con el fin de simplificar el gráfico final del modelo, ya que se cuenta con múltiples arcos con largas expresiones que complicarían su lectura e inclusión del gráfico en el documento. Un ejemplo de aclaración de la diferencia entre estas notaciones se hará más adelante.

Además, se tendrán en cuenta las siguientes convenciones:

• El holón actual que se está modelando se llamará HR1, con el fin de diferenciarlo de los otros.

• El HR1 es capaz de realizar dos tipos de referencias, tipo A y B. • La agenda del HR posee finita cantidad de órdenes. Para la evaluación de

espacios disponibles se verificarán dos órdenes j y j+1, j tomará valores entre 1 y n-2. Todos los elementos de la orden tendrán subíndice de acuerdo a su posición, si no lo tiene se refiere a la orden que actualmente se está evaluando.

• La función lógica OR se representará a través del símbolo “||”, • La función lógica AND se representará a través del símbolo “&&”. • La función lógica NOT se representará con una barra en la parte superior

de los eventos. Por ejemplo, para el evento e , su función lógica negada será e .

4.1.1. Anuncio de nuevas órdenes de trabajo

Es un proceso de negociación basado en el protocolo de redes de contrato (PRC) [33], el cual consiste básicamente en cinco pasos: Anuncio de la tarea por un administrador, contratistas potenciales evalúan anuncios de tareas de varios administradores, contratistas potenciales licitan en la tarea elegida, el administrador de la tarea adjudica el contrato a alguno de los contratistas licitadores y por último el administrador y contratista se comunican para ejecutar la tarea contratada.

Este protocolo puede aplicarse en el contexto de la manufactura en varias formas:

• Los administradores y contratistas son recursos que usan la subcontratación para distribuir la carga de trabajo.

• Los administradores son partes que ofrecen trabajo y los contratistas son recursos que licitan para que su trabajo les sea asignado.

• Los administradores son recursos que ofrecen capacidad y los contratistas pueden ser partes que licitan para usar sus capacidades.

Esto conlleva a un sistema simple y robusto ante fallas, debido a que ninguno de los agentes necesita información previa acerca de los otros [34], [35]. Como consecuencia, los cambios y las perturbaciones se pueden manejar fácilmente.

47

El administrador, o en adelante, el HM, anuncia la tarea por medio de la colocación de una marca en un lugar común en el modelo en CPN. Todos los HR tienen acceso a este lugar, el cual tiene el mismo formato que todos los lugares del modelo, tipo “Orden”, definido anteriormente.

Para que el HR1 dispare esta marca hacia el interior, deberá verificarse que este mensaje sí haya sido enviado hacia él. Esto se hace por medio de:

Rec=HR1||HR (4)

Se verifica que el receptor sea el HR1. En caso que Rec=HR significa que el anuncio fue enviado a todos los holones tipo recurso, por tanto también debe ser aceptado. La representación de esta dinámica se realiza usando CPN (Figura 14).

Figura 14. Representación en CPN del anuncio de una tarea

En la Figura 14a se muestra la representación utilizando la notación estricta de las CPN. En la Figura 14b se eliminaron los marcajes, los conjuntos de color de los lugares y las expresiones se ubicaron en los lugares, de acuerdo con la notación a utilizar en esta tesis con fines de simplificación gráfica explicada anteriormente.

Una vez el anuncio ha ingresado al holón, se deben tomar decisiones respecto a este:

Si es tipo orden, para el caso en el cual ya no es una solicitud por parte del HM sino una notificación de aceptación de una propuesta enviada anteriormente, y además la referencia solicitada está de acuerdo a las habilidades del HR1. En este caso se envía la información a la agenda para que sea programada en las actividades del holón.

Tip=orden (5)

Ref=A||B (6)

Si no es de ningún tipo conocido, como orden, solicitud o cooperación, debe expulsar.

48

Tip=solicitud (7)

Tip=cooperación (8)

O en el caso en que simplemente, la orden no contenga ninguna referencia compatible con el HR1, lo cual también genera una expulsión.

Ref=A&&B (9)

En estos dos últimos casos, se debe devolver la orden informando que ha sido rechazada por no cumplir las competencias del HR1. Se cambia el tipo de la solicitud y se notifica al emisor.

Tip=rechazo (10)

Si es de tipo solicitud y además la referencia solicitada está de acuerdo a las habilidades del HR1 se verifica (6)&&(7).

Si es de tipo cooperación y además la referencia solicitada está de acuerdo a las habilidades del HR1 se verifica (6)&&(8).

Antes de continuar la evolución del marcaje en estos dos últimos casos, se realiza un cambio en la expresión de arcos porque la información que contiene la marca dejará de ser una única orden porque se consulta con la agenda y por tanto el contenido de la marca será la programación actual del recurso más la nueva orden, bien sea de tipo solicitud o cooperación.

El siguiente paso es ingresar la orden a la agenda y verificar la disponibilidad con el fin de saber si es posible aceptar esta solicitud entrante. Esto se hace por medio del cumplimiento de las siguientes expresiones:

Cuando no hay ninguna orden programada:

n=1 (11)

Y el tiempo de inicio de la solicitud es mayor que el tiempo actual más el tiempo de alistamiento del recurso.

sol alistTini >T+T (12)

O cuando hay únicamente una orden programada:

n=2 (13)

Y la solicitud nueva puede ejecutarse al final

49

sol 1 alistTini >Tinc +T (14)

O la solicitud nueva puede ejecutarse al inicio

sol 1 alistTinc <Tini -T (15)

O finalmente cuando hay más de dos órdenes programadas:

n>2 (16)

Y cabe al inicio (12)&&(15)&&(16)

O cabe en medio de dos órdenes j y j+1:

sol j alistTini >Tinc +T (17)

sol j+1 alistTinc <Tini -T (18)

O cabe al final de la última orden:

sol n-1 alistTini >Tinc +T (19)

Si no se cumplen estas expresiones la solicitud será rechazada, en caso contrario será enviada una notificación de aceptación, incluyendo la propuesta.

Finalmente, para el caso de las órdenes tipo mantenimiento se deben generar unas reglas claras desde la configuración inicial del holón. Esto se hace por medio de una transición que genera las órdenes del holón autónomamente siguiendo estas reglas. Para el disparo de la transición se utiliza:

Tip=mantenimiento (20)

reglas=true (21)

4.1.2. Ejecución de órdenes

El primer paso que se requiere para ejecutar una orden es tomarla de la agenda. Para ello se debe verificar que el tiempo actual sea mayor que el tiempo de restricción y que, además, el tiempo de inicio de la orden ya se esté cumpliendo.

Tini>T (22)

En este punto se requiere una interacción entre dos partes del holón: la parte de toma de decisiones y la parte física. Esta parte se hace a través de la interface intra-holón (Figura 15), la cual obtiene los eventos generados en la parte física y

50

los procesa para información a la parte de toma de decisiones. Los eventos y estados de esta interface están relacionados en la Tabla 4.

.

Figura 15. Interface intra-holón

Tabla 4. Eventos y estados para la interface intra-holón

SÍMBOLO ETIQUETA TIPO

Apagado P1 Estado

Disponible P2 Estado

Iniciando P3 Estado

Operación P4 Estado

Falla P5 Estado

Mantenimiento P6 Estado

encender t1 Evento

iniciar t2 Evento

iniciación_lista t3 Evento

terminado t4 Evento

falla t5 Evento

reparar t6 Evento

mtto_terminado t7 Evento

apagar t8 Evento

51

La ejecución de la orden se realiza principalmente por la parte física y su propio controlador. Finalmente, si no hay fallas ni retrasos, se generará el evento de terminación de la orden al cumplirse la cantidad de piezas programada.

Cact=C (23)

La interface intra-holón también es útil para el grupo de dinámicas de monitoreo y adaptación, especialmente en los casos de detección de fallas y acciones correctivas. Esta interface representa en realidad el cambio lógico que se debe realizar al controlador instalado en el recurso físico. Esta es una adición necesaria para comunicar este controlador con la parte de toma de decisiones del HR. Debido a que es un SED se puede implementar en PLC.

La tabla de direccionamiento en PLC indica los símbolos utilizados y las direcciones en las áreas de memoria y de entradas (Tabla 5).

Tabla 5. Direccionamiento en el PLC

SÍMBOLO ETIQUETA TIPO DIRECCIÓN

Apagado P1 Estado M0.0

Disponible P2 Estado M0.1

Iniciando P3 Estado M0.2

Operación P4 Estado M0.3

Falla P5 Estado M0.4

Mantenimiento P6 Estado M0.5

encender t1 Evento I0.0

iniciar t2 Evento I0.1

iniciación_lista t3 Evento I0.2

terminado t4 Evento I0.3

falla t5 Evento I0.4

reparar t6 Evento I0.5

mtto_terminado t7 Evento I0.6

apagar t8 Evento I0.7

52

Uno de los lenguajes PLC más utilizados es el ladder, basado en la norma IEC 61131-3, la cual garantiza que una red de Petri basada en esta norma no posee ni ambigüedad ni aleatoriedad. La (Figura 16) muestra la generación de código en lenguaje ladder.

Figura 16. Interface intra-holón en lenguaje ladder

4.1.3. Monitoreo y adaptación

La primera de las actividades de monitoreo es la verificación del tiempo de producción de la pieza. Si este es mayor al esperado, entonces el sistema evolucionará a un estado de modo degradado.

Tpieza>TP (24)

Si no se toman acciones correctivas en el modo degradado, el sistema corre grave riesgo de evolucionar al estado prohibido de incumplimiento, esto ocurrirá cuando se cumplan las siguientes dos condiciones:

T Tinc≥ (25)

Cact<C (26)

53

Una vez en este estado incumplimiento se expulsará la orden a través de la detección del evento:

Tip=fin_inc (27)

Si se analiza que, una vez en modo degradado, el sistema no podrá terminar la orden, se cumple la expresión:

T+(Cres-1)*TP+TP res Tinc≥ (28)

En este caso el sistema evolucionará a un estado que inicie una renegociación con el fin de evitar el incumplimiento.

Siempre existirán posibilidades que el sistema presente una falla, ya que el sistema físico está expuesto a daños, apagones o bloqueos, que finalmente generarán retrasos en la entrega de la orden. Estos eventos tipo falla son difíciles de detectar y más aún de diagnosticar debido a que no es posible considerar todos los escenarios de falla potenciales. En [36] se notó que ningún algoritmo puede predecir cada posible modo de falla de un sistema altamente complejo, ni se pueden diseñar estrategias correctivas para cada situación. Sin embargo, una estimación del tiempo de recuperación de falla permitirá hacer una reorganización de la agenda y determinar si se puede continuar con la orden actual o es necesaria una renegociación.

Para el caso que se puede continuar procesando la orden deberá cumplirse la siguiente condición:

T+Cres*TP+Tfalla+Talist<Tinc (29)

En caso contrario, deberá enviarse a un estado que inicie una renegociación del objetivo. Esta renegociación deberá hacerse inicialmente con el emisor de la orden.

Para enviar el mensaje al emisor se realizan varios cambios en la orden:

• Se cambia el receptor por el que emitió la orden y como nuevo emisor se utiliza el nombre propio, en este caso HR1. Em=HR1 (30)

• Se cambia el tipo de la orden, informando que en se quiere hacer renegociación.

Tip=reneg (31)

• Se informa la duración de la falla

54

Tinc=Tinc+Tfalla+Talist (32)

Una vez hecho este proceso se procede a esperar respuesta del respectivo receptor. Existen dos posibilidades una vez enviado este mensaje:

• Que se reciba una notificación aceptando la renegociación, para lo cual se verifica que el mensaje sea para el HR1 a través de (4) y que sea de tipo aceptación:

Tip=acepta (33)

En este caso se debe enviar la orden nuevamente a la agenda, incluyendo el tiempo autorizado de retraso.

• Que se reciba información de rechazo de solicitud de renegociación o que transcurrido un tiempo Tao2 no se reciba ninguna respuesta.

Tao1=true (34)

Para este último caso se debe realizar la acción de llevar el sistema a un estado que inicie una solicitud de cooperación.

Para el envío de mensaje a todos los HR se incluye la orden completa, incluyendo tiempo de incumplimiento y referencia, pero notificando la cantidad restante:

Crest=C-Cact (35)

De los recursos se recibirán notificaciones de aceptación o de rechazo, las cuales deberán evaluarse.

Para el caso de notificación de aceptación se reciben únicamente si se cumplen (33) y

Em=HR (36)

Caso en el cual deben analizarse todas las que cumplan y elegir la que tenga menor tiempo de finalización. Para ello se verifica, por ejemplo, que el recurso p hizo la mejor propuesta entre todos los recursos j que enviaron aceptación:

p jTinc <Tinc (37)

Se le notifica al HRp que su propuesta ha sido aceptada.

En caso de haber notificaciones de rechazo pero que incluyen propuesta, se debe consultar con el respectivo HM para determinar la decisión a tomar. Estas notificaciones se detectan mediante (10)&&(36) o

55

Tao2=true (38)

Finalmente se notifica al HM que la orden no pudo ser negociada bajo la cooperación y el HR cae en un estado no deseado, por haber incumplido la orden y no haber sido capaz de renegociarla.

Existe además otro grupo de dinámicas que no pertenece a ninguno de los tres anteriores.

4.1.4. Otras dinámicas

Una dinámica muy importante, que no se encuentra comprendida en ninguno de los grupos anteriormente explicados es la de cooperación en el sentido de intercambio de información de precedencias. Las precedencias se presentan principalmente cuando un conjunto de recursos realizan diferentes operaciones sobre un mismo producto o una misma pieza. Para este caso es necesario contar con un método de coordinación entre ellos, debido a que la programación de sus órdenes puede presentar cambios y sin cooperación no sería posible lograr el cumplimiento del objetivo común.

Para ello, desde la definición de la orden se estableció un tiempo de restricción llamado Tre . Este tiempo representa el instante de tiempo más temprano en que una orden puede iniciarse, pero a su vez, significa información sobre el instante de finalización programado para el recurso anterior en el proceso.

Por tal razón, cualquier recurso debe ser capaz de recibir información de los recursos anteriores, detectando un mensaje enviado por HR etiquetado como tal, haciendo las siguientes verificaciones:

• Mensaje con receptor HR1 mediante (4) • Tipo de mensaje

Tip=Precedencia (39)

• Verificación del emisor del mensaje

Em=Ant (40)

Para enviar el mensaje al holón posterior se requiere cambiar:

• El emisor que envía el mensaje por HR1, mediante (30) • El receptor por el recurso siguiente en el proceso

Rec=Sig (41)

• El tipo del mensaje enviado, mediante (39)

56

Finalmente, existen situaciones en las que es necesaria la expulsión de órdenes del recurso.

Cuando esta expulsión ha sido ordenada por un holón superior jerárquicamente. Este es el caso de una orden cancelada por el HM encargado, caso para el cual se verifica la llegada de un mensaje con las condiciones (4)&&(10).

Y que el emisor es un holón misión:

Em=HM (42)

Cuando se ha realizado un retraso autorizado en alguna orden de producción y ésta, al volver a ser incluida en la agenda, genera un conflicto con la orden siguiente. En este caso, la agenda verifica mediante la expresión:

j j+1Tinc >Tini (43)

Y la orden j+1 es expulsada.

4.2. Construcción del Modelo

Finalmente, se puede construir el modelo del HR utilizando CPN (Figura 17), el formalismo de modelamiento seleccionado.

57

Figura 17. Modelo del HR en CPN

58

4.3. Verificación de atributos holónicos

Es de interés evaluar los atributos holónicos en el modelo planteado, pues sólo si ellos existen se podrá asegurar que el sistema se comporta como un holón. Anteriormente se concluyó que para que un holón pueda ser considerado como tal debe poseer al menos los atributos de cooperación y autonomía. Adicionalmente, otros dos atributos se analizarán en este modelo: reactividad y proactividad.

La verificación se hará enunciando cada atributo y luego enumerando las dinámicas para las cuales el atributo se aplica al HR.

COOPERACIÓN:

• Recibe una solicitud del HM • Acepta una orden del HM • Comparte su agenda con los holones circundantes (misión, producto, otros

recursos) • Solicita ayuda a otros recursos similares • Informa al HM que tiene problemas • Informa sobre la finalización de una orden

AUTONOMÍA:

• Organiza su agenda autónomamente y ejecuta las órdenes de acuerdo a esta

• Monitorea su propio desempeño • Solicita cooperación cuando se hace necesario • Rechaza una orden que tenía asignada • Decide no ejecutar una solicitud de orden

PROACTIVIDAD:

• Toma decisiones que previenen el incumplimiento de la misión. • Renegocia sus órdenes antes de entrar en incumplimiento

REACTIVIDAD:

• Detecta una falla, aumenta la autonomía y la maneja • Baja la autonomía al recuperarse de una falla • Renegocia sus órdenes porque hay incumplimiento inminente • Detecta, diagnostica y maneja sus fallas

59

4.4. Evaluación de controlabilidad

La especificación del sistema (HRS) representa el comportamiento deseado, a partir de los estados finales o marcados. En este caso, la especificación está compuesta de todas las cadenas del HR que lleven a estados deseados y se eliminarán de la especificación aquellas que lo lleven a estados no deseados, un supervisor se encargaría de eliminar todas estas cadenas. La controlabilidad es la encargada de evaluar si esto es posible o no.

Inicialmente, se requiere definir los elementos que componen el teorema de controlabilidad (2), el cual, al aplicarse al HR se convierte en:

( )ucKE L HR K∩ ⊆ (44)

( )L HR se refiere al lenguaje generado por el HR. Este lenguaje consiste en todas las posibles cadenas que se pueden observar en el modelo, lleven o no a estados no deseados.

De ( )L HR surge un sublenguaje, el cual está compuesto únicamente por las cadenas de ( )L G que llevan a estados permitidos o marcados. Este lenguaje se llama el lenguaje marcado y se denota con ( )mL HR .

Un último elemento restante por definir para completar el teorema de controlabilidad es la especificación. La especificación se deriva de G , pero únicamente toma los estados deseados. Esta especificación se denota por RHS .

En (44) se requiere definir K , el cual se tomará de RHS , por lo cual se definirán diferentes nK , cada uno compuesto por una cadena de eventos de relevante importancia para el análisis de controlabilidad del HR.

1K está compuesto de las cadenas de eventos que llevan al sistema desde la llegada de una solicitud nueva hasta la expulsión por no ser de pertinencia para el HR1. Por tanto:

{ }1 4 9 1 0, 4 5 7 8 1 0K =

2K está compuesto por las cadenas que llevan al sistema desde la llegada de una solicitud nueva, pasando por la evaluación de las solicitudes y finalmente notificando sobre la aceptación de la solicitud. Para el caso de la notificación de rechazo de solicitudes es similar, por tanto no se hará la evaluación para estas cadenas.

60

2

4 6 8 1112, 4 6 8 13 14, 4 6 8 13 12 15,4 6 8 16 12 15, 4 6 8 16 17 18, 4 6 8 16 194 6 7 1112, 4 6 7 13 14, 4 6 7 13 12 15,4 6 7 16 12 15, 4 6 7 16 17 18, 4 6 7 16 19

K

=

3K está compuesto por cadenas que llevan el sistema desde la llegada de una solicitud nueva, pasando por el almacenamiento en agenda por ser de tipo orden, y llegando finalmente a la ejecución satisfactoria de la orden. También se incluirá la cadena que termina en la ejecución satisfactoria de la orden pero antes habiendo evolucionado al estado “modo degradado”.

{ }3 4 5 6 5 2 2 3 2 3, 4 5 6 5 2 2 3 2 42 42 3K t t=

4K está compuesto por cadenas que llevan el sistema desde la llegada de una solicitud nueva, pasando por el almacenamiento en agenda por ser de tipo orden, pero la ejecución no puede ser cumplida por haber evolucionado a modo degradado e incumplirse las condiciones para continuar. Además, se incluirá la presencia de falla durante ejecución que tampoco cumple las condiciones para continuar.

{ }4 4 5 6 5 22 3 24 28 30 31 32, 4 5 6 5 22 3 5 6 29 30 31 32K t t t t=

5K está compuesto por cadenas que llevan el sistema desde la llegada de una solicitud nueva, pasando por el almacenamiento en agenda por ser de tipo orden, habiendo finalmente llegado al estado que inicia la renegociación. En este caso se generan las siguientes cadenas: renegociación aceptada por HM e inclusión nuevamente en la agenda, renegociación rechazada por HM seguida por solicitud de cooperación rechazada o aceptada.

5

4 5 6 5 22 3 24 28 30 31 32 4 33,4 5 6 5 22 3 24 28 30 31 32 4 10 34 4 8 30 35 33 36 37

tK

t

=

Según (1), el conjunto de eventos se debe dividir en dos subconjuntos. Dicho conjunto está comprendido entre (4) y (43), por lo cual:

Los subconjuntos de eventos controlables y no controlables son:

{23,24,25,26,34,38, 4, 5, 7,}{4,5,6,7,8,9,10,11,12,1314,15,17,18,19,20,21, 1, 2, 3, 6,

22,27,28,29,30,31,32,33,35,36,37,39,40,41,42,43}

uc

c

E t t tE t t t t

==

61

El teorema de controlabilidad sugiere, en otras palabras, que: “Dada una cadena de eventos permitida en la especificación, se debe garantizar que la presencia posterior de un evento no controlable a esa cadena no llevará el sistema a estados indeseados”.

De esta frase se sugiere el siguiente procedimiento para evaluar la controlabilidad:

• Seleccionar la cadena tomada de RHS a evaluar. • Concatenar los prefijos de la cadena únicamente con los eventos no

controlables que hagan que esta concatenación siga perteneciendo a ( )L RH .

• Finalmente, verificar si esta concatenación está incluida en K .

Esto se debe hacer para cada uno de los conjuntos de cadenas nK .

4.4.1. Evaluación de K1

Siguiendo el procedimiento para { }1 4 9 1 0, 4 5 7 8 1 0K = se puede observar

fácilmente en el modelo que no existen eventos no controlables que se puedan concatenar con 1K o cualquiera de sus prefijos de modo que el conjunto

1 ( )ucK E L HR∩ no sea vacío.

4.4.2. Evaluación de K2

Siguiendo el procedimiento para 2K se obtiene un resultado similar, no existen eventos no controlables que se pueda concatenar con 2K o cualquiera de sus prefijos de modo que el conjunto 2 ( )ucK E L HR∩ no sea vacío.

4.4.3. Evaluación de K3

Siguiendo el procedimiento para { }3 4 5 6 5 2 2 3 2 3, 4 5 6 5 2 2 3 2 42 42 3K t t= se

encuentran varios casos, estos son:

La cadena de eventos 4 5 6 5 2 2 3t para la cual existe un evento no controlable con el que se cumple la condición 3 ( )ucK E L HR∩ ≠∅ . La cadena 4 5 6 5 2 2 3t concatenada con el evento no controlable 5t , genera

34 5 6 5 2 2 3 5 ( ) 4 5 6 5 2 2 3 5t t L G t t K∩ = ⊄ , por lo cual la condición de controlabilidad no se cumple.

Se puede concluir entonces sobre la cadena 3K que no es controlable, es decir, no existe un supervisor que pueda impedir la evolución a estados no deseados.

62

4.4.4. Evaluación de K4

En el numeral anterior se probó que la cadena 44 5 6 5 2 2 3t K⊆ no es controlable, por lo cual 4K tampoco lo es.

4.4.5. Evaluación de K5

De forma similar al numeral anterior, la cadena 54 5 6 5 2 2 3t K⊆ no es controlable, lo cual hace que 5K tampoco lo sea. Sin embargo, es interesante revisar las cadenas:

54 5 6 5 22 3 24 28 30 31 32 4 10t K⊆

54 5 6 5 22 3 24 28 30 31 32 4 10 34 4 8 30 35 10 36t K⊆

La cadena 4 5 6 5 22 3 24 28 30 31 32 4 10t se puede concatenar con un evento no controlable 34 , de modo que 54 5 6 5 22 3 24 28 30 31 32 4 10 34 ( )t L G K∩ ⊄ . Por tanto, esta cadena no es controlable.

La cadena 4 5 6 5 22 3 24 28 30 31 32 4 10 34 4 8 30 35t se puede concatenar con un evento no controlable 38 , de modo que

54 5 6 5 22 3 24 28 30 31 32 4 10 34 4 8 30 35 38 ( )t L G K∩ ⊄ . Por tanto, esta cadena no es controlable.

4.5. Evaluación de observabilidad

Para realizar la evaluación de observabilidad, siguiendo el teorema (3), se requiere definir cada uno de los elementos que lo componen:

( )mK L HR=

( )M M L HR= =

{ 5}uoE t=

Una de las finalidades con esta investigación es realizar la evaluación de observabilidad del lenguaje K, por su importancia al ser la especificación del sistema.

63

Sin embargo, no es necesario realizar la evaluación completa de observabilidad de todo el lenguaje, ya que únicamente se cuenta con un evento no observable 5t , el cual pone en peligro la observabilidad de todo el sistema.

Por este motivo, las únicas cadenas a las que se les hará evaluación de observabilidad serán:

6 {4 5 6 5 2 2 3 5}K t t=

7 {4 5 6 5 2 2 3 2 4 5}K t t=

4.5.1. Evaluación de K6

Para 6s Kε= ∈ no existe un evento controlable que extienda la cadena s en M pero no en 6K , por tanto la condición de observabilidad se satisface necesariamente.

Similarmente ocurre para:

44 54 5 64 5 6 54 5 6 5 2 24 5 6 5 2 2 34 5 6 5 2 2 3 5

ssssss ts t t

=======

.

Así entonces, la cadena K6 es observable.

4.5.2. Evaluación de K7

Para 7s Kε= ∈ no existe un evento controlable que extienda la cadena s en M pero no en 7K , por tanto la condición de observabilidad se satisface necesariamente.

Similarmente ocurre para:

64

44 54 5 64 5 6 54 5 6 5 2 24 5 6 5 2 2 34 5 6 5 2 2 3 2 44 5 6 5 2 2 3 2 4 5

ssssss ts ts t t

========

Así entonces, la cadena K7 es observable.

En conclusión, el HR posee cadenas que resultan no se controlables, que impiden que el sistema sea llevado a estados deseados de forma segura sin evolucionar a estados no deseados o prohibidos. Precisamente, algunas de estas cadenas representan procesos como cooperación, renegociación y fallas. En el caso de cooperación y renegociación se puede entender que el HR no tiene habilidades para garantizar que el proceso se llevará a cabo con éxito, ya que algunas de las dinámicas de este proceso no están bajo el control del HR. En el caso de las fallas, es comprensible que es un evento considerado en la literatura como uno de los ejemplos más claros de no controlabilidad, y en el HR se confirma esta afirmación.

La observabilidad se evaluó satisfactoriamente en el HR, arrojando como resultado la seguridad de conocer el estado del sistema en cualquier momento por parte de un supervisor o un holón superior jerárquicamente que haga sus veces.

Resulta entonces interesante orientar el estudio del HR hacia la implementación de su comportamiento dinámico, cuya simulación se convierte entonces en primer paso para lograrlo.

65

5. EJEMPLO DE APLICACIÓN

Para la simulación del ejemplo de aplicación se ha elegido MATLAB, conocido como el software de computación para ingenieros y científicos en la industria, el gobierno y la educación [39].

MATLAB es un lenguaje de alto desempeño para computación técnica que integra computación, visualización y programación en un medio fácil de usar donde los problemas y las soluciones se expresan en notaciones matemáticas familiares. Los profesionales técnicos alrededor del mundo cuentan con MATLAB para acelerar su investigación, reducir tiempo de análisis y desarrollo, minimizar los costos del proyecto y producir soluciones efectivas.

El código utilizado para la simulación en MATLAB, se encuentra disponible para descarga en la web [41].

El HR1, el cual es el objeto de estudio en esta investigación, cuenta con la capacidad de ejecutar órdenes de producción haciendo uso de sus atributos holónicos. Se simulará la negociación producción y renegociación de 3 órdenes, incluyendo perturbaciones como fallas, evolución a modo degradado, rechazos a solicitudes y negociaciones simultáneas a la ejecución, lo cual generará retrasos y el HR deberá reaccionar ante ellos, tomando las decisiones autónomamente con restricciones a esta autonomía.

El HR1 representa un recurso, el cual es un torno CNC con las siguientes características:

CENTRO DE TORNEADO PROLIGHT 3000

Marca: Intelitek

Torreta revólver

8 herramientas (4 externas y 4 internas)

Velocidad: 0 a 5000rpm en 12 segundos

Capacidad de bancada: 1.5 pulgadas

Sin contrapunta

Ajuste de mordaza: 19mm de diámetro

Sistema mecánico neumático

66

3 motores paso a paso

Torreta de trinquete

Husillo y torreta en giro horario

Tiempo de preparación: 1min:30seg (90segs)

El torno proLIGHT 3000 está ubicado en el laboratorio de manufactura integrada por computador CIM del Centro de Tecnología de la Manufactura Avanzada [38]. Este torno será capaz de procesar dos referencias de piezas, A y B.

La pieza A corresponde a una perilla sujetadora para cajones. Las dimensiones exactas en milímetros de esta perilla se muestran en la Figura 18:

Figura 18. Perilla para cajones (Referencia A).

La pieza B corresponde a un balaustre para juguetes. Las dimensiones exactas en milímetros del balaustre se muestran en la Figura 19:

67

Figura 19. Balaustre para juguetes (Referencia B).

Cada pieza de la referencia A tarda 8min:28seg (508segs) en realizarse, mientras que para la referencia B el tiempo de pieza es de 6min:14seg (374segs).

Las tres órdenes a ejecutar son:

ORDEN 1

Referencia: A

Cantidad: 3

Tiempo de restricción: 100

Tiempo de incumplimiento: 1850

Tipo de solicitud: solicitud

Holón Anterior: HR2

Holón Siguiente: HR3

Emisor de la solicitud: HM1

Receptor de la solicitud: HR1

ORDEN 2

Referencia: B

Cantidad: 2

68

Tiempo de restricción: 2000

Tiempo de incumplimiento: 2900

Tipo de solicitud: solicitud

Holón Anterior: HR3

Holón Siguiente: HR2

Emisor de la solicitud: HM1

Receptor de la solicitud: HR1

ORDEN 3

Referencia: A

Cantidad: 1

Tiempo de restricción: 2000

Tiempo de incumplimiento: 3500

Tipo de solicitud: solicitud

Holón Anterior: HR3

Holón Siguiente: HR2

Emisor de la solicitud: HM1

Receptor de la solicitud: HR

La simulación se realizará a partir del menú principal, el cual permite el ingreso a todas las funciones que tiene el algoritmo.

5.1. Menú principal

El menú principal contiene 11 opciones, las cuales permiten la simulación de todas las funciones incluidas en el modelo del HR de la Figura 17.

69

5.1.1. Continuar

Esta opción permite que el código principal se siga ejecutando. Es posible que el menú principal aparezca mientras se requiere que el código principal realice más ciclos. En este caso, la función continuar deberá seleccionarse cuantas veces sea necesario

5.1.2. Generar nueva solicitud

Cuando se quiera generar una nueva solicitud de producción al HR1 esta es la opción indicada. Una vez seleccionada esta opción, se preguntará en la simulación sobre la descripción de esta solicitud.

5.1.3. Aceptar propuesta hecha previamente

Generalmente esta función 2 se ejecuta inmediatamente después que la función 1. Esto debido a que la función 1 genera la nueva solicitud, el HR1 envía una notificación de aceptación o rechazo y la función 2 es la encargada de la notificación de aceptación, en caso que se quiera que esta solicitud sea aceptada.

5.1.4. Consular agenda

Esta opción se utiliza en cualquier momento que se desee ver la descripción de todas las órdenes programadas en forma de listado.

5.1.5. Programar mantenimiento

Aunque estas reglas podrían ser programadas automáticamente, esta opción permite la inserción manual de órdenes del tipo mantenimiento. Es importante tener en cuenta que la generación de estas órdenes puede afectar otras órdenes en la agenda, así que se recomienda primero verificar el estado de ésta y ubicar espacios disponibles.

70

5.1.6. Cancelar una orden

Esta opción permite simular una decisión de cancelación por parte del HM1. Se preguntará el número de la orden a cancelar y ésta será expulsada de la programación del HR1.

5.1.7. Ejecutar órdenes sin fallas

Una vez programadas las órdenes, se debe ingresar al subprograma “ejecución de órdenes”. Este ingreso se hace al seleccionar esta función. El tiempo de ejecución iniciará y se realizará la ejecución de acuerdo a lo programado en la agenda. En cualquier momento se podrá detener la ejecución a través de un botón “Pausar ejecución” incluido en la simulación.

5.1.8. Ingresar una falla

Con previa pausa de la ejecución, es posible ingresar una falla de la duración deseada a la orden en ejecución actual.

5.1.9. Generar modo degradado

Se podrá generar manualmente este modo para simular retrasos en la producción de las piezas. El sistema detectará este modo y hará las acciones necesarias para manejarlo, según las dinámicas explicadas en capítulos anteriores.

5.1.10. Recibir restricciones de otro recurso

Dado que es un sistema holónico, hay otros holones tipo recurso existentes, en este caso hay otros 2, HR2 y HR3. La cooperación con estos holones se realiza en dos formas: la solicitud de cooperación y la información de restricciones. La función 9 se utiliza para suponer que uno de estos holones tuvo retrasos en su producción e informó al HR1 sobre la finalización de la orden en tiempo posterior al esperado.

5.1.11. Salir

Esta función se utiliza únicamente en el caso que se quiera terminar la simulación. En caso que se quiera iniciar nuevamente se debe corre el algoritmo otra vez y las condiciones iniciales volverán a cero.

Las perturbaciones al sistema se ingresarán con los eventos 1e a 6e :

1e : Se ingresará la solicitud 1.

2e : Se ingresará la solicitud 2.

71

3e : Se ingresará un fallo en el recurso, con una duración de 100.

4e : Se ingresará un retraso en la producción de la pieza en ejecución, con una duración de 10.

5e : Se ingresará la solicitud 3 al sistema.

6e : Se ingresará un retraso en la producción de la pieza en ejecución, con una duración de 160.

Los tiempos para la ocurrencia de estos eventos se encuentran en la Figura 20.

Figura 20. Ocurrencia de eventos de entrada al HR

Todo está definido para la simulación, ahora se puede realizar utilizando el algoritmo en MATLAB.

5.2. Simulación

La simulación se realizará por partes, ingresando cada uno de los eventos e los tiempos definidos en la Figura 20.

El primer paso es, cuando 0t = ingresar la solicitud 1 para negociación.

5.2.1. Negociación de solicitud 1

Se realiza el ingreso de la solicitud 1, para lo cual la simulación muestra:

Solicitud nueva ha llegado

Receptor en la solicitud es compatible con HR1

El tipo y la referencia de la solicitud son compatibles

La solicitud ha sido enviada a evaluación de solicitud

La solicitud de trabajo se puede aceptar

Se ha enviado notificación de aceptación (incluyendo propuesta)

72

Informando respectivamente para cada una de las líneas:

Que ha entrado una nueva solicitud al HR1, se ha verificado que el receptor es compatible con el HR1 a través de (4), el tipo y la referencia son compatibles con las habilidades del holón y la solicitud ha sido enviada a evaluación de solicitud a través de (6) y (7), la solicitud de trabajo se puede aceptar y se ha enviado notificación de aceptación al cumplirse (11) y (12).

Una vez el HR1 ha enviado notificación de aceptación se debe esperar notificación de rechazo o aceptación por parte del emisor de la solicitud, en este caso el HM1. Se recibe notificación de aceptación a través de la función 2 y se almacena en agenda.

Ha llegado aceptación de solicitud

Orden nueva ha llegado

Receptor en la solicitud es compatible con HR1

El tipo y la referencia de la orden son compatibles

La solicitud es de tipo Orden, se ha guardado en la Agenda como Orden 1.

En este caso la solicitud vuelve a ingresar al holón, pero se detectan (5) y (6). Es una orden, es decir, ha llegado una aceptación de la solicitud.

5.2.2. Ejecución (etapa 1)

Se inicia ejecución de la orden. El tiempo inicial es 0t = , representado por la variable “cuenta” de la simulación.

cuenta = 1

El torno se ha encendido

El torno se está iniciando (cambio de herramienta y calentamiento)

cuenta = 91

El tiempo inicia su avance, se enciende el torno, termina iniciación 90 segundos después de haberse encendido.

cuenta = 100

Se ha seleccionado para ejecución la orden 1

Se ha iniciado operación en modo normal

73

Cuando 100t = se selecciona para la ejecución la orden 1, al detectarse los eventos (5) y (22).

Cuando 402t = se pausa la ejecución y se abre el menú principal.

cuenta = 402

MENÚ PRINCIPAL

En este instante de tiempo se desea hacer de forma paralela la negociación de la solicitud 2.

5.2.3. Negociación de solicitud 2

Se ingresa la solicitud 2 mediante la función 1 y la simulación muestra:

Solicitud nueva ha llegado

Receptor en la solicitud es compatible con HR1

El tipo y la referencia de la solicitud son compatibles

La solicitud ha sido enviada a evaluación de solicitud

La solicitud de trabajo se puede aceptar

Se ha enviado notificación de aceptación (incluyendo propuesta)

La evaluación de esta solicitud ocurre de forma similar al de la solicitud 1, a diferencia que se detectan los eventos (13) y (14) en vez de cumplirse (11) y (12).

Se recibe notificación de aceptación a través de la función 2 y se almacena en agenda. Se consulta la agenda para revisar las órdenes programadas, utilizando la función 3.

El número de órdenes en la Agenda es: 2

Orden 1

Referencia: A

Cantidad 3

Tiempo de restricción 100

Tiempo de incumplimiento 1850

Tiempo de inicio 100

Tipo o

74

Holón Anterior 2

Holón Siguiente 3

Emisor M

Receptor 1

Orden 2

Referencia: B

Cantidad 2

Tiempo de restricción 2000

Tiempo de incumplimiento 2900

Tiempo de inicio 2000

Tipo o

Holón Anterior 3

Holón Siguiente 2

Emisor M

Receptor 1

Se inicia nuevamente ejecución para terminar negociación y continuar con el procesamiento de la orden 1.

5.2.4. Ejecución (etapa 2)

La función 6 inicia la ejecución. Cuando 608t = el sistema informa sobre la finalización de una pieza, como era esperado que ocurriera.

cuenta = 608

Se ha terminado de producir una pieza para la orden 1

Número de piezas restantes 2

Cuando 623t = se detiene la simulación, para ingresar la falla representada por el evento 3e .

75

5.2.5. Falla durante ejecución

La función 7 se ingresa y permite la generación de la falla con duración de 10 segundos.

Ingrese el código: 7

Ingrese el tiempo de la falla: 100

5.2.6. Ejecución (etapa 3)

Se inicia ejecución con la función 6, el sistema detecta inmediatamente la falla.

cuenta = 623

Se ha detectado una falla en modo normal

Se ha iniciado mantenimiento

La falla permite continuar la ejecución de la orden

Se ha enviado la orden nuevamente a la agenda para ejecución

Se ha seleccionado para ejecución la orden 1

En este caso la falla no impidió continuar con la ejecución, porque se cumplió la expresión (29), ya que:

[ ]*

623 2*508 100 90 18501829 1850

T Cres TP Tfalla Talist Tinc+ + + <

+ + + <

<

Como la ejecución de la orden puede continuar sin sobrepasar el tiempo de incumplimiento, la orden fue enviada nuevamente a la agenda y el cumplimiento de los eventos (5) y (22) enviaron la orden nuevamente a ejecución.

Sin embargo la orden no se sigue ejecutando inmediatamente, primero se ejecuta el mantenimiento. Debido a la duración de la falla, el mantenimiento finaliza cuando 723t = y debe transcurrir el tiempo de iniciación del torno de 90 segundos.

cuenta = 723

Se ha terminado el mantenimiento

El recurso físico está disponible nuevamente

cuenta = 724

El torno se está iniciando (cambio de herramienta y calentamiento)

76

El tiempo de iniciación del torno es 90 segundos, así que primero transcurre este tiempo antes de estar listo para continuar la ejecución.

cuenta = 814

El torno ha terminado inicialización

Se ha iniciado operación en modo normal

Cuando 814t = inicia la ejecución de la pieza 2, se espera que se termine cuando 1322t =

Cuando 850t = se detiene la simulación, para ingresar el modo degradado representada por el evento 4e .

5.2.7. Modo degradado de 10 segundos

Para ingresar el modo degradado se recurre a la función 8.

Ingrese el código: 8

El tiempo normal de pieza para esta referencia es 508.

Ingrese el tiempo de pieza adicional para el modo degradado: 10

5.2.8. Ejecución (etapa 4)

Se continúa ejecución para observar resultados de simulación:

cuenta = 1322

El sistema ha ingresado a modo degradado

Debido al retraso en la producción de la pieza 2, cuando 1322t = y no se ha terminado la pieza se detectará el modo degradado. Ya que (28) no se cumple el sistema puede continuar su ejecución en modo degradado.

cuenta = 1331

Se ha terminado de producir una pieza para la orden 1

Número de piezas restantes 1

El sistema ha salido del modo degradado

El modo degradado duró 10 segundos y se terminó la pieza. Se continua ejecución de la última pieza restante.

cuenta = 1839

77

Se ha terminado de producir una pieza para la orden 1

Número de piezas restantes 0

Se ha terminado la orden 1

Se ha enviado notificación de finalización

cuenta = 1840

El torno se está iniciando (cambio de herramienta y calentamiento)

Con el torno listo para ejecución transcurre un tiempo de holgura porque ninguna orden está programada, se espera a llegar a 2000t = para seleccionar la orden 2.

cuenta = 2000

Se ha seleccionado para ejecución la orden 2

cuenta = 2001

El torno ha terminado inicialización

Se ha iniciado operación en modo normal

Cuando 2107t = se detiene la simulación para ingresar la solicitud 3.

5.2.9. Negociación de la solicitud 3

Se ingresa la solicitud 3 mediante la función 1 y la simulación muestra:

Solicitud nueva ha llegado

Receptor en la solicitud es compatible con HR1

El tipo y la referencia de la solicitud son compatibles

La solicitud ha sido enviada a evaluación de solicitud

La solicitud de trabajo no se puede aceptar

Se ha enviado notificación de rechazo

Esto debido a que no se cumplieron las condiciones necesarias para acepta la orden, especialmente no se cumple la expresión para aceptar la orden.

5.2.10. Ejecución (etapa 5)

La ejecución continúa normalmente y se detiene automáticamente cuando 2374t = , tiempo esperado para la terminación de la primera pieza de la orden 1.

78

cuenta = 2374

Se ha terminado de producir una pieza para la orden 2

Número de piezas restantes 1

La ejecución se detiene manualmente cuando 2604t = , para generar el modo siguiente modo degradado.

5.2.11. Modo degradado de 160 segundos

Para ingresar el modo degradado se recurre a la función 8.

Ingrese el código: 8

El tiempo normal de pieza para esta referencia es 374.

Ingrese el tiempo de pieza adicional para el modo degradado: 160

Se inicia ejecución.

5.2.12. Ejecución (etapa 6)

Iniciada la ejecución se detecta inmediatamente el modo degradado

cuenta = 2765

El sistema ha ingresado a modo degradado

El modo degradado generará incumplimiento de la orden

Se inicia manejo del modo degradado

Se ha iniciado proceso de renegociación

Propuesta de renegociación se ha enviado

¿Desea que el misión acepte solicitud de renegociación? (s/n):

Se desea, para el ejemplo de aplicación, que el HM1 no acepte la solicitud de renegociación, por lo cual se seleccionará la opción “n” en la pregunta realizada por la simulación.

¿Desea que el misión acepte solicitud de renegociación? (s/n): n

Ha llegado rechazo de propuesta de renegociación

Se ha enviado solicitud de cooperación a los holones recurso 2 y 3

79

Debido a que HR2 y HR3 no existen en esta simulación, deberán suponerse las propuestas enviadas por cada uno de ellos:

Se reciben propuestas de los holones 2 y 3

Respuesta de solicitud del holón 2.

Ingrese el tiempo de inicio propuesto: 2855

Ingrese si la propuesta fue aceptada (a/r): a

Se ha recibido una solicitud de cooperación aceptada

Respuesta de solicitud del holón 3.

Ingrese el tiempo de inicio propuesto: 2950

Ingrese si la propuesta fue aceptada (a/r): r

Se ha recibido una solicitud de cooperación rechazada

Se ha aceptado la propuesta

Se ha enviado notificación de aceptación al recurso y al Misión

En este caso se simuló que el HR2 aceptó la orden 2, imposible de realizar por el HR1 debido al modo degradado presente. El HR1 entregó la orden a través de la cooperación aceptada y evitó incumplir su misión.

En conclusión, esta simulación arrojó los resultados esperados al analizar la misma situación en el comportamiento dinámico. El HR es capaz de ejecutar las órdenes y posee autonomía limitada para solucionar sus propios problemas sin descuidar el objetivo global de todo el sistema.

Esta simulación muestra las ventajas y limitaciones de la implementación de Sistemas Holónicos de Manufactura en ambientes industriales y prueba que la combinación de los mejores aspectos de las arquitecturas jerárquicas y heterárquicas resulta en una nueva arquitectura mejorada que arroja los resultados esperados consignados en su teoría.

80

6. CONCLUSIONES

La naturaleza de las dinámicas que componen el comportamiento del HR es discreta. Es posible modelar este comportamiento mediante herramientas de SED incluyendo los beneficios de la organización holónica como estabilidad en la presencia de perturbaciones, adaptabilidad y flexibilidad en la presencia del cambio y uso eficiente del recurso.

Un HR básico está compuesto por 3 partes: toma de decisiones, interface intra-holón y física. La parte de toma de decisiones representa el supervisor local del recurso. La interface intra-holón sirve como canal de comunicación entre las otras dos partes y su estructura puede ser programada en un PLC debido a su naturaleza discreta y binaria. La parte física se compone del recurso físico como tal y su respectivo controlador convencional, lo que facilita la implementación de HMS al no hacerse necesario un cambio en los sistemas de control previamente instalados.

El formalismo más apropiado para el modelamiento del HR son las Redes de Petri Coloreadas (CPN) debido a diversas razones: Las expresiones de arco permiten modelar reglas de evolución complejas, ofrece más poder de modelamiento que otros formalismos estudiados y el transporte de información de un estado al otro es mucho mayor que una simple marca binaria, como es el caso de las redes de Petri ordinarias y jerárquicas.

La construcción del modelo en CPN arroja como resultado un sistema que contiene las propiedades de cooperación, autonomía, proactividad, y reactividad, superando los elementos más básicos que lo hacen un holón.

En el interior del HR existen cadenas de eventos no controlables debido a la posible presencia de eventos falla o negativas a la renegociación o cooperación. Existen sufijos que podrían llevar el sistema a un estado satisfactorio, evitando la evolución a estados no deseados, pero la presencia de este tipo de eventos siempre será posible y por tanto no será controlable. Paralelamente a esto, se probó que la observabilidad del holón no presenta problemas, y por tanto se puede conocer el estado del sistema en cualquier momento. Cabe resaltar, que la observabilidad y la controlabilidad, aunque están muy relacionadas no necesariamente se cumplen simultáneamente. La no observabilidad implica no controlabilidad, pero esta implicación no se cumple en forma inversa, como es el caso del HR.

81

Bibliografía

[1] Fletcher, M. (2002). Holonic Manufacturing Systems: Some Scenarios and Issues. Agent Oriented Software Ltd, Mill Lane, Cambridge, CB2 1RX, United Kingdom.

[2] HMS. (2004). Holonic Manufacturing Systems Consortium. Sitio web http://hms.ifw.unihannover.de.

[3] HoloMAS (2007). 3nd International Conference on Industrial Applications of Holonic and Multi-Agent Systems. September 3 - 5, 2007, Regensburg, Germany.

[4] Koestler, A. (1967). The Ghost in the Machine. London, U.K.: Arcan Books.

[5] HMS (2004). Holonic Manufacturing Systems Consortium web site. http://hms.ifw.uni-hannover.de.

[6] Durán, J. (2006). Técnicas emergentes para la automatización integrada de procesos industriales. Reportes técnicos 1 y 2 proyecto de investigación 2005000170 fonacit.

[7] Judith, D. (2004). Propuesta de una metodología para la automatización integrada de procesos de producción continua. Tesis de maestría. Universidad de Los Andes, Mérida, Venezuela. Octubre de 2004.

[8] K. Asai and S. Takashima (2004), Manufacturing Automation Systems and CIM. Factories. London, U.K.: Chapman & Hall.

[9] Rembold, U. and Nnaji,B. O. (1993). Computer Integrated Manufacturing and Engineering. Reading, MA: Addison-Wesley.

[10] Colombo, W. (2006). An Agent-Based Intelligent Control Platform for Industrial Holonic Manufacturing Systems. IEEE Transactions on Industrial Electronics, Vol. 53, No. 1, February 2006. [11] ANSI ISA - 95.00.01 - 95.00.02 - 95.00.03 - Enterprise - Control System Integration, Parts 1, 2 & 3. 2007.

[12] Carlos E. Flores R. Sistema de Fabricación Flexible: FMS. Facultad de Ingeniería - Universidad Rafael Landívar. Boletín Electrónico No. 03.

[13] Diltis, D., Boyd, N. y Whorms, H. (1991) The evolution of control architectures for automated manufacturing systems. Journal of manufacturing systems 10(1):63-79.

82

[14] Leitão, P. (2004). An Agile and Adaptive Holonic Architecture for Manufacturing Control. Department of Electrotechnical Engineering - Polytechnic Institute of Bragança, Portugal.

[15] Chacón, E., Besembel, E., Narciso, F., Montilva, C. y Colina, E. (2003). An Integration Architecture for the Automation of a Continuous Production Complex. Elsevier Preprint. September 2003. Universidad de los Andes. Venezuela.

[16] Van Brussel, H., Wyns, J. Valckenaers, P., Bongaerts, L. and Peeters, P. (1998). Reference Architecture for Holonic Manufacturing Systems: PROSA. Computers in Industri 37. 255-274. Katholieke Universiteit Leuven. Belgium.

[17] Biemans, F (1989). A Reference Model for Manufacturing Planning and Control. PhD thesis, University of Twente, Enschede.

[18] Rembold, U., Nnaji, B. & Storr, A. (1993). Computer Integrated Manufacturing and Engineering. Addison-Wesley.

[19] Leitão, P. (2004). An Agile and Adaptive Holonic Architecture for Manufacturing Control. Department of Electrotechnical Engineering - Polytechnic Institute of Bragança, Portugal.

[20] Chacón y Colmenares, W. (2002). A way to implement supervisors for Holonic production units. 15th Triennial World Congress, Barcelona, Spain.

[21] Valckenaers, P., Van Brussel, H., Bonneville, F., Bongaerts, L, & Wyns, J. (1994). IMS test case 5: Holonic Manufacturing Systems. Preprints of IMS'94, IFAC workshop, Vienna 13-15 June 1994

[22] Leitao, P. and Restivo, F. (1999). A Layered Approach to Distributed Manufacturing. In Proceedings of Advanced Summer Institute International Conference in Life Cycle Approaches to Production Systems: Management, Control and Supervision, Leuven, Belgium.

[23] Winkler, M. and Mey, M. (1994). Holonic Manufacturing Systems. European Production Engineering.

[24] McFarlane, D. Bussmann, S. (2003). Holonic Manufacturing Control: Rationales, Developments and Open Issues. Agent Based Manufacturing. Advances in the Holonic Approach. Springer.

[25] Lafortune, S. (2004). Lecture notes for EECS 661. Chapter 3: Supervisory Control of Discrete Event Systems. University of Michigan. Department of Electrical Engineering and Computer Science. October 2004.

83

[26] Cassandras, C. y Lafortune, S. (2008). Introduction to Discrete Event Systems. Springer Science+Business Media, LLC. 2nd Edition.

[27] Medina, G. y González, C. (2003). Modelamiento de controladores lógicos mediante el uso de redes de Petri temporizadas interpretadas por periferia.Trabajo de Grado de Ingeniería Eléctrica. Universidad Nacional de Colombia, Medellín.

[28] Moody, J. & Antsaklis, P. (1998). Supervisory Control of Discrete Event Systems Using Petri Nets. Series: The International Series on Discrete Event Dynamic Systems, Vol. 8. ISBN: 978-0-7923-8199-0.

[29] Zapata, G., Branch, J., Quintero, L., González, C. & Medina, C. (2005). Metodología para Generación de Código a Partir de Modelos en Redes de Petri Jerárquicas. Universidad Nacional de Colombia Sede Medellín – UNALMED.

[30] Jensen, K (1997). Coloured Petri Nets. Basic Concepts, Analysis Methods and Practical Use. Volume 1, Basic Concepts. Monographs in Theoretical Computer Science, Springer-Verlag, 2nd corrected printing 1997. ISBN: 3-540-60943-1.

[31] Jensen, K (n.d). A brief introduction to Coloured Petri Nets. Computer Science Department, University of Aarhus. Ny Munkegade, Bldg. 540, DK-8000 Aarhus C, Denmark

[32] Roubtsova, E. (2004). Property Specification for Coloured Petri Nets. 2004 IEEE International Conference on Systems, Man and Cybemetics. 0-7803-8566-7/04/$20.00© 2004 IEEE.

[33] Huang, B. Gou, H. Liu, W. Li, Y. Xie, M. (2002). A framework for virtual enterprise control with the holonic manufacturing paradigm. Computers in industry 49, 299-310.

[34] Duffie, N. y Piper, R. (1986). Nonhierarchical control of manufacturing systems, Journal of Manufacturing Systems 5, 137–139.

[35] Duffie, N. y Mou, C. (1988). Fault-tolerant heterarchical control of heterogeneous manufacturing system entities, Journal of Manufacturing Systems 7. 315–327.

[36] Hatvany, J. (1985) Intelligence and cooperation in heterarchic manufacturing systems, Robotics & Computer-Integrated Manufacturing, Vol. 2, No. 2, pp. 101-104.

[37] Letiao, P., Colombo, A., Restivo, F. (n.d.). A formal validation approach for Holonic Control System specifications. PRODEP III-5.3/2000

[38] SENA. Centro de Tecnología de la Manufactura Avanzada. http://tecnologia-manufactura-avanzada.blogspot.com/

84

[39] Matlab. The MathWorks - MATLAB and Simulink for Technical Computing. www.mathworks.com/.

[40] Chen, X., Xu, N., and Zhou, Z. (2003) A Methodology for SystemC Algorithmic Model Verification Applying MATLAB. 0--7803-7889-x/0. 2003© IEEE.

[41] Algoritmo para simulación del HR. http://rubenchov.googlepages.com/HR.m