Formalización de un modelo de referencia para Integración empresarial desde el enfoque de los Sistemas Holónicos de Manufactura

DIEGO ARMANDO CHECA ROJAS

Formalización de un modelo de referencia para Integración empresarial desde el enfoque de los Sistemas Holónicos de Manufactura

Tesis presentada a la Facultad de Ingeniería Electrónica y Telecomunicaciones de la Universidad del Cauca para la obtención del Título de

Magíster en: Automática

Director: Oscar Amaury Rojas Alvarado PhD. Ciencias Aplicadas, área Automatización industrial

Popayán 2014

Para mi madre, mi hermana y mi familia Gracias por confiar en mí

Agradecimientos

Gracias a Dios por darme la oportunidad de avanzar profesionalmente. A mi familia por su constante apoyo y acompañamiento en todas las situaciones que se me presentaron en esta etapa de mi vida. A mi director de grado, docentes y demás funcionarios de la Universidad del Cauca por su conocimiento y colaboración. A mis amigos y compañeros gracias por compartir conmigo esta experiencia de vida.

Resumen estructurado

Antecedentes: Los sistemas holónicos de manufactura son un paradigma relativamente nuevo como alternativa para lograr una automatización con mayor flexibilidad y una mejor respuesta ante disturbios en el sistema de producción. Se considera necesario disponer de una base de conocimiento que unifique los futuros esfuerzos en investigación y desarrollo.

Objetivos: Se definieron 3 objetivos fundamentales para el trabajo: 

Establecer una descripción formal de la

conceptualización

y las

características de los Sistemas Holónicos de Manufactura. 

Especificar una ontología que facilite la representación de un Sistema Holónico de

Manufactura, la cual proporcione la interpretación de los

términos, las relaciones y las funciones del modelo. 

Evaluar el modelo de referencia en un caso de estudio.

Método: Se realizó una investigación bibliográfica sobre el tema para posteriormente realizar una unificación de términos y relaciones, siguiendo los pasos que se definen en Methontology.

Resultados: Se obtuvo una ontología de aplicación que unifica el conocimiento sobre HMS-UP a un nivel detallado basado en términos, sus relaciones y los flujos de información que éstos conforman.

Conclusiones: La ontología obtenida permitirá compartir el conocimiento sobre

HMS-UP para los interesados en el tema y será una fuente de información para futuras investigaciones en la unidad de producción.

Palabras clave: HMS-UP, Ontología, Sistemas Holónicos, Unidad de producción, Methontology, Protégé,

Structured Abstract

Background: The holonic manufacturing systems are a relatively new paradigm as an alternative to achieve greater flexibility and automation with superior response to disturbances in the production system. It is considered necessary to have a knowledge base that unifies future efforts in research and development.

Objectives: 3 key objectives for work were defined: 

Establish a formal description of the concept and the characteristics of the Holonic Manufacturing Systems.



Specify an ontology that facilitates the representation of a holonic system Manufacturing, which provide the interpretation of the terms, relationships and model functions.



Evaluate the reference model in a case study

Method: A bibliographic research was conducted on the subject later to make a unification of terms and relations, following the steps defined in Methontology.

Results: An application ontology that unifies knowledge about HMS-UP at a detailed level based on terms, relationships and information flows that they make up was obtained.

Conclusions: The ontology obtained will share knowledge about HMS-UP for those interested in the subject and will be a source of information for future

research in the production unit.

Key words: HMS-UP, Ontology, Holonics Systems, Production Unit, Methontology, Protégé,

Contenido

1.Lista de figuras ................................................................................................................... iv 2.Lista de tablas ..................................................................................................................... vi 1.Introducción ....................................................................................................................... vii 1.Conceptos generales........................................................................................................... 9 1.1.

El concepto del holón ............................................................................................................. 9

1.2.

Sistemas holónicos de manufactura. .................................................................................... 10

1.3.

Arquitecturas de referencia para sistemas holónicos. .......................................................... 14

1.3.1.

PROSA (Product-Recurse-Order-Architecture) .............................................................. 14

1.3.2.

ADACOR ........................................................................................................................ 16

1.4. 1.4.1. 1.5.

Sistemas Holónicos de Manufactura basado en la unidad de producción (HMS-UP) ......... 18 Estado del arte sistemas holónicos .................................................................................. 28 Intercambio de información. ................................................................................................ 29

1.5.1.

Arquitecturas de intercambio de información ................................................................. 29

1.5.2.

Sistemas Distribuidos ...................................................................................................... 31

1.6.

Lenguajes de comunicación ................................................................................................. 31

1.7.

El intercambio de conocimiento y ontologías ...................................................................... 33

2.Definición de Ontologías ................................................................................................... 35 2.1.

Proceso para la creación de Ontologías ............................................................................... 36

2.2.

Alcance ................................................................................................................................. 37

2.3.

Criterios para el diseño de una ontología ............................................................................. 38

2.4.

Ciclos de vida ....................................................................................................................... 39

2.5.

Métodos para la creación de ontologías ............................................................................... 40

2.5.1.

On-to-knowledge ............................................................................................................. 40

2.5.2.

Methontology .................................................................................................................. 42

2.5.3.

Metodología CyC ............................................................................................................ 44 i

2.5.4. 2.6.

Metodología Uschold y King .......................................................................................... 45 Lenguajes para el desarrollo de ontologías .......................................................................... 46

2.6.1.

XML (eXtensible Markup Language) ............................................................................. 47

2.6.2.

RDF (Resource Description Framework) ........................................................................ 47

2.6.3.

DAML+OL ...................................................................................................................... 48

2.6.4.

OWL (Web Ontology Language) .................................................................................... 48

2.7.

Herramientas para la implementación de una ontología ...................................................... 49

2.7.1.

Ontolingua ....................................................................................................................... 50

2.7.2.

Protégé ............................................................................................................................. 50

2.7.3.

Ontosaurus ....................................................................................................................... 51

2.7.4.

WebOnto .......................................................................................................................... 51

2.7.5.

WebODE.......................................................................................................................... 52

3. Creación del modelo de referencia .................................................................................. 55 3.1.

Creación de la ontología....................................................................................................... 56

3.1.1.

Propósito de la ontología ................................................................................................. 56

3.1.2.

Metodología a seguir ....................................................................................................... 56

3.1.3.

Alcance ............................................................................................................................ 58

3.1.4

Tarea 1. Lista de términos ............................................................................................... 59

3.1.5

Tarea 2. Taxonomía de los conceptos .............................................................................. 65

3.1.6

Tareas 3. Relaciones Binarias .......................................................................................... 67

3.1.7

Tarea 4 Diccionario de conceptos.................................................................................... 74

3.1.8

Tarea 5 Descripción relaciones ........................................................................................ 77

3.1.9

Tarea 6. Descripción de atributos de instancia. ............................................................... 77

3.1.10

Tarea 7 Descripción de atributos de clase ....................................................................... 79

3.1.11

Tarea 8 Descripción de las constantes ............................................................................. 83

3.1.12

Tarea 9 Definición de axiomas formales ......................................................................... 83

3.1.13

Tarea 10 Definición de reglas .......................................................................................... 85

3.1.14

Tarea 11 Descripción de instancias. ................................................................................ 85

4. Formalización .................................................................................................................... 87 4.1

Representación en UML ........................................................................................................... 87

4.1.4

Funcionamiento operativo ............................................................................................... 88

4.1.5

Negociación y toma de decisiones .................................................................................. 89

4.1.6

Autosimilaridad ............................................................................................................... 90 ii

4.1.7

Actividades administrativas............................................................................................. 90

4.1.8

Reactividad ...................................................................................................................... 92

4.1.9

Concepto meta en la unidad de producción. .................................................................... 93

4.2

Representación con Protégé ...................................................................................................... 95

4.2.4

Representación de conceptos........................................................................................... 97

4.2.5

Representación de las relaciones ..................................................................................... 98

4.2.6

Representación de atributos........................................................................................... 100

4.2.7

Representación de instancias ......................................................................................... 101

4.3

Finalización del proceso ......................................................................................................... 101

4.3.4

Representación gráfica .................................................................................................. 102

5. Validación y resultados obtenidos ................................................................................ 105 5.1

Resultados generales ............................................................................................................... 105

5.2

Validación de la ontología....................................................................................................... 107

5.2.4

Coherencia ..................................................................................................................... 107

5.2.5

Extensibilidad ................................................................................................................ 110

5.2.6

Claridad ......................................................................................................................... 111

5.2.7

Mínimo compromiso ontológico y codificación parcializada. ...................................... 111

5.2.8

Resultado de la validación conceptual .......................................................................... 112

5.2.9

Validación modelo de referencia ................................................................................... 113

5.2.10

Resultado validación caso de estudio ............................................................................ 120

6. Conclusiones y recomendaciones ................................................................................ 123 Bibliografía .......................................................................................................................... 125 Anexo A ............................................................................................................................... 131

iii

1. Lista de figuras Figura 1.1Un holón es un todo y parte a la vez.

10

Figura 1.2 La jerarquía tiene una estructura dinámica.

11

Figura 1.3 Mapa de datos y funciones que cumple cada uno de los holones.

16

Figura 1.4 Estructura de organización holónica en ADACOR.

18

Figura 1.5 Cadena de valor

19

Figura 1.6. Representación de la unidad de producción

20

Figura 1.7. Modelo estructural de la unidad de producción.

21

Figura 1.8. Unidad de producción holónica

27

Figura 2.9 Tipos de ontologías por su alcance.

37

Figura 2.10 Fases de la metodología CYC.

41

Figura 2.11 Ciclo de vida de la ontología por Methontology

43

Figura 3.12 Tareas propuesta por Methontology para la fase conceptualización

57

Figura 3.13 Relación taxonómica de la clase Recurso

66

Figura 3.14 Relación taxonómica clase Actividad

66

Figura 3.15 Relación taxonómica clase Rol

67

Figura 3.16 Representación gráfica de una relación binaria

68

Figura 4.17 Descripción de la vista operativa de una UP

89

Figura 4.18 Negociación y toma de decisión

90

Figura 4.19 Autosimilaridad de la unidad de producción

90

Figura 4.20 Actividades administrativas

91

Figura 4.21 Reactividad en la unidad de producción

92

Figura 4.22 Concepto Meta en la unidad de producción

94

Figura 4.23 Descripción de la ontología

97

Figura 4.24 Agregando los conceptos en la pestaña Entities

98 iv

Figura 4.25 Creación de las relaciones binarias

99

Figura 4.26 Representación de las variables de clases e instancias

100

Figura 4.27 Representación general de la ontología por medio de ontograf

102

Figura 4.28 Representación en OWL generada por Protégé

103

Figura 5.29 Menú para iniciar el razonador de Protégé

108

Figura 5.30 Comparación de las taxonomías

109

Figura 5.31 Representación de la taxonomía con OWLwiz

110

Figura 5.32 Cadena de valor proceso sacos de fique

114

Figura 5.33 Registro de la información de la unidad de producción

120

v

2. Lista de tablas Tabla 3.1 Ficha técnica parcial de la ontología en desarrollo ................................................... 58 Tabla 3.2 Encabezado formato de tablas para la representación de relaciones ......................... 68 Tabla 3.3 Relaciones unidad producción ................................................................................... 70 Tabla 3.4 Relaciones del método de producción ....................................................................... 71 Tabla 3.5 Conjunto de relaciones de dominio ........................................................................... 74 Tabla 3.6 Diccionario de conceptos .......................................................................................... 77 Tabla 3.7 Ejemplo descripción de atributos de instancia .......................................................... 77 Tabla 3.8 Descripción de atributos de instancia ........................................................................ 79 Tabla 3.9 Ejemplo descripción de atributos de clase................................................................. 80 Tabla 3.10 Descripción atributos de la clase actividad ............................................................. 82 Tabla 3.11 Descripción atributos de clase Actor ....................................................................... 82 Tabla 3.12 Descripción de atributos de la clase recurso............................................................ 83 Tabla 3.13 Ejemplo de descripción de axiomas ........................................................................ 84 Tabla 3.14 Descripción de los axiomas de la ontología ............................................................ 85 Tabla 5.15 Código OWL parcial ............................................................................................. 106 Tabla 5.16 Resultado de la validación ..................................................................................... 112 Tabla 5.17 Ficha técnica final de la ontología ......................................................................... 113 Tabla 5.18 Descripción básica de equipo Hiladora ................................................................. 115 Tabla 5.19 Método de producción simplificado ...................................................................... 116 Tabla 5.20 Orden de producción ............................................................................................. 119 Tabla 5.21 Respuesta ............................................................................................................... 119

vi

1. Introducción

Las nuevas necesidades de un mercado variante, competitivo y con mayor grado de personalización en productos y servicios, requiere de sistemas complejos, flexibles y, especialmente, eficientes. Tales características hacen que las empresas busquen nuevas soluciones y modelos que permitan optimizar la relación costo-beneficio de su negocio. Los sistemas de integración empresarial se muestran como una de las soluciones más atractivas para dichos problemas en la empresa. Uno de los enfoques que ha ganado terreno como estrategia de integración en los procesos de manufactura son los sistemas de control distribuido. En este tipo de sistemas, el control del proceso se divide en problemas más pequeños, los cuales se controlan por medio de componentes inteligentes especializados en cada uno de ellos. La división del proceso conlleva a una mayor modularización del sistema de producción, facilita las tareas de control pero aún es estático, es decir, su estructura siempre es la misma, lo cual dificulta cumplir con la característica de flexibilidad. En ese sentido, se busca que la empresa tenga una estructura dinámica, que pueda cambiar la forma de producción de manera flexible pero controlada. La característica de la auto-organización es soportada por los nuevos conceptos en inteligencia artificial aplicados a la industria tales como los sistemas holónicos y los sistemas multiagentes. La aplicación de dichos conceptos permite disponer de elementos inteligentes que poseen una gran especialización en sectores o funciones específicas del proceso productivo, fuera de la capacidad de comunicarse y colaborar entre sí para lograr un objetivo común. Existen gran cantidad de soluciones tanto a nivel teórico como a nivel comercial. Cada una de ellas posee características que ofrecen ventajas de implementación, así como también limitaciones o desventajas. vii

En el presente trabajo se usa la teoría de los sistemas holónicos como base para la obtención de un modelo de integración. El proyecto se enfoca en analizar el estado actual de los sistemas holónicos basados en la unidad de producción o HMS-UP para proponer una conceptualización que defina, de manera clara y precisa, cada uno de los conceptos necesarios para integrar una empresa desde el enfoque holónico. Para la formalización se diseña una ontología de aplicación sobre HMS-UP. Una ontología es un modelo conceptual que se realiza en un dominio o área del conocimiento para registrar la definición de términos, reglas, relaciones de conceptos, entre otros, con el fin de que los actores (sean personas o dispositivos hardware) de un proceso, comprendan el dominio de la misma manera y puedan establecer una comunicación precisa para facilitar el proceso de integración. Con el objetivo de que la ontología pueda ser implementada, se diseña una guía de implementación. El documento guía se compone de una serie de acciones y sugerencias, divididas en fases, que al ser tomadas en cuenta en un proceso real, implícitamente aproximan a dicho proceso hacia un sistema integrado. La guía de implementación junto a la ontología conforman el modelo de referencia, el cual es el objetivo principal del proyecto. En este documento se describe el aporte realizado dividido en capítulos. El capítulo 1, contiene información general sobre el holón, los sistemas holónicos y algunas consideraciones relacionadas con el intercambio de información. En el capítulo 2, se describen las características de una ontología y su aporte en el modelado de sistemas. El capítulo 3, corresponde a la descripción del proceso de análisis y diseño del modelo de referencia, la ontología y la guía de implementación (Anexo A). Posteriormente, en el capítulo 4 se realiza el proceso de formalización usando a UML como lenguaje de representación. En el capítulo 5 se evalúa si el modelo de referencia contiene los conceptos necesarios que representan a HMS-UP (ontología) y una descripción de implementación (guía de implementación) adecuada para ser considerado como una herramienta útil en la aproximación de un proceso real a un sistema integrado. Finalmente, se describen las conclusiones luego del trabajo de investigación y validación.

viii

Capítulo 1 1. Conceptos generales En el presente capítulo se abordarán los temas de relevancia para la los sistemas holónicos de manufactura.

1.1. El concepto del holón Holón es un concepto creado por el científico Arthur Koestler al observar a los grupos vivos, a sus organizaciones internas y a sus interacciones sociales. Koestler, pudo notar que dichos grupos tenían estructuras definidas, que estaban a su vez organizadas en grupos más pequeños que trabajaban en equipo para alcanzar un objetivo común. Así, desde la perspectiva de un observador externo, solo es posible apreciar los resultados globales del trabajo en equipo pero no las interacciones de sus integrantes. Cada grupo puede ser parte de un grupo mayor, uniendo sus esfuerzos con otros integrantes (otros grupos posiblemente) y así contribuir con un objetivo global. Este comportamiento llamó la atención de Koestler, ya que un grupo era el todo para sus integrantes pero, también podía ser parte de un grupo mayor. El término que uso para describir a este tipo de grupos fue Holón. Este término proviene de las palabras griegas “holos” que significa todo y “on” que significa parte [1], [2], [3].

10

1.Conceptos generales

1.2. Sistemas holónicos de manufactura. Las ventajas que puede brindar la aplicación del concepto holónico a los sistemas de manufactura son muy grandes, además permiten obtener todo un nuevo paradigma de organización y estructuración empresarial [3]. Una de dichas ventajas, es la capacidad de descentralizar el proceso, como también disminuir la complejidad de todo un sistema por medio de la creación de pequeños componentes que resuelvan problemas menores. Dichos componentes (holones), son elementos autónomos, los cuales pueden tomar decisiones y realizar acciones por sí mismos, dotándolos con la capacidad de tener bajo control a cualquier proceso que tengan a su cargo.

Figura 1.1Un holón es un todo y parte a la vez. Fuente propia Figura 1.1: Unen holón es un todoun y parte a lacomplejo: vez. De este modo, es posible dividir varias partes sistema cada parte es controlada por uno o varios holones de manera autónoma, robusta y estable, los cuales interaccionan de forma coordinada para lograr el control total del sistema al cual pertenecen [3]. La organización o estructura que toman los holones para llevar a cabo el control de

1.2 Sistemas holónicos de manufactura.

11

un proceso, es similar a una jerarquía convencional la cual contiene un coordinador para cada uno de sus niveles. Sin embargo, en los sistemas holónicos existe una característica que permite gran flexibilidad: las jerarquías son temporales. Esto significa que uno o varios holones pueden tomar diferentes posiciones dentro de la jerarquía de acuerdo a las necesidades del sistema, incluso, los holones pueden componer otra estructura totalmente diferente a la anterior. Al comportamiento de crear y eliminar estructuras jerárquicas de manera dinámica se le denomina holarquía [3], [4]. El paradigma holárquico permite modificar la estructura de una empresa de acuerdo a las necesidades. Esto significa flexibilidad en la producción y adaptación a los nuevos requerimientos de los clientes o a la evolución de los productos ofrecidos.

Figura 1.2 La jerarquía tiene una estructura dinámica. Fuente propia El uso de sistemas holónicos aplicadostiene a losuna procesos de manufactura, surge en la Figura 1.2: La jerarquía estructura dinámica. década del 90, con el programa IMS (Inteligence Manufacture System) como una solución para soportar las nuevas necesidades de los sistemas de producción. En este programa se establecieron características que deberían cumplir el concepto de sistemas holónicos [4], [5]: Holón: Es un bloque autónomo y cooperativo de un sistema de manufactura el

12

1.Conceptos generales

cual transporta, transforma, organiza y valida tanto la información como los objetos físicos. Autonomía: Capacidad de una entidad de crear y controlar la ejecución de sus planes o estrategias. Cooperación: Un proceso donde un conjunto de entidades crean y ejecutan planes. Holarquía: Sistema de holones que puede operar para lograr un objetivo. Sistemas de manufactura holónica: Una holarquía, donde se integra el rango total de actividades de manufactura desde la orden hasta el mercadeo, pasando por el diseño y la producción. Con desarrollos posteriores se han adicionado conceptos y características que los sistemas holónicos deberían cumplir. En realidad, las siguientes características provienen de los sistemas multiagentes, pero dada la similitud con el concepto de holón también se consideran [6], [7]. Racionalidad: Un holón puede razonar acerca de datos percibidos y de calcular una solución óptima. Habilidad social: Los holones son capaces de interactuar con otros holones (humanos o no) a través de un lenguaje. Reactividad: Los holones son capaces de percibir estímulos del entorno y estos estímulos guían las acciones del holón. Proactividad: Los holones no son sólo entidades que reaccionan a estímulos, sino que también deben tener un carácter emprendedor y pueden actuar guiados por sus propios objetivos. Adaptabilidad: Esta característica está relacionada con el aprendizaje que un

1.2 Sistemas holónicos de manufactura.

holón puede lograr y con su capacidad comportamiento basado en este aprendizaje.

13

para

cambiar

su

propio

Movilidad1: Es la capacidad de un holón para moverse a través de una red. Veracidad: Un holón no puede comunicar información falsa de manera deliberada. Benevolencia: un holón está dispuesto a ayudar a otros holones si esto no está en contra de sus propios objetivos. Los conceptos iníciales han sido modificados con algunas restricciones en consideración de los tipos de entorno a los cuales son sometidos los sistemas holónicos y los sistemas multiagentes. Una de las principales diferencias es el concepto de movilidad. En los agentes esta característica es posible porque son un componente software, condición que permite al agente desplazarse a través de las redes de comunicaciones. Los holones en cambio, poseen componentes físicos que impiden esta característica. Otra diferencia, pero en un contexto informal, es la inteligencia. Aunque de ninguna manera se ha limitado la habilidad para tomar decisiones en los holones, estos poseen menos inteligencia en la práctica, dado que los sistemas de manufactura, son variables, pero tienen una cantidad limitada de eventos posibles. En cambio, los agentes se consideran elementos con gran inteligencia, diseñados para estar en un entorno altamente variable, impredecible y con gran cantidad de información a procesar. El objetivo del presente trabajo es aportar a la integración de los sistemas manufactura, y aunque los agentes podrían ayudar en dicho objetivo, se seleccionado a los sistemas holónicos como arquitectura base para la ejecución proyecto, dado sus características y, principalmente, su especialización en 1

de ha del los

Los holones normalmente tienen asociados además del componente de información, recursos

físicos. Esta característica impide el concepto de movilidad en los holones.

14

1.Conceptos generales

sistemas de producción.

1.3. Arquitecturas de referencia para sistemas holónicos. Teniendo en cuenta los grandes aportes que un sistema holónico puede ofrecer, se inició con la búsqueda de una arquitectura de referencia que permitiera aplicar de manera ordenada y sistemática los conceptos de la teoría de holones en los sistemas de producción. Uno de los primeros avances en este sentido se denominó PROSA.

1.3.1.

PROSA (Product-Recurse-Order-Architecture)

El grupo de investigación de la Universidad Católica de Leuven, que estuvo a cargo del desarrollo de PROSA, inició sus estudios clasificando qué tipo de problemas se encuentran en las empresas de producción de manera general. Por medio de dicho análisis se llegó a la conclusión que, a grandes rasgos, existen 3 tipos de problemas [8]: Administración y gestión de la maquinaria de la planta, es decir, encontrar un ritmo de producción óptimo, el cual permita encontrar un nivel de producción sostenible para maximizar la capacidad de producción. Relación que existe entre los productos y los procesos. Por ejemplo, las operaciones que se deben realizar para obtener un producto de buena calidad. La respuesta del proceso ante la demanda de productos y los tiempos de entrega. Con los anteriores problemas como punto de partida, el grupo de investigación liderado por Brussel [8], definió 3 clases de holones donde cada uno cubre cierta parte del proceso de producción. Existe también un holón opcional, el cual, podía brindar asistencia a los otros tres. Los tipos de holones son los siguientes [8], [9],

1.2 Sistemas holónicos de manufactura.

15

[10]: Holón Recurso: Contiene una parte física, llamada recurso de producción de un sistema de manufactura y una parte de procesamiento de información que controla el recurso. Éste ofrece capacidad de producción como funcionalidad al entorno holónico; además, provee el método para localizar el recurso de producción, al igual que el conocimiento y procesamiento para organizar, usar y controlar el recurso. Un holón recurso, es una abstracción de un medio de producción tal como una fábrica, una planta, máquinas, tuberías, componentes, materia prima, etc. Los sistemas holónicos de manufactura (HMS) no separan el sistema de manufactura de su respectivo control, por tanto contiene a las dos partes. Holón producto: Contiene la información del proceso y del producto para producirlo correctamente y con suficiente calidad. Este holón contiene información consistente y actualizada del ciclo de vida del producto: requisitos, diseño, planes de proceso, lista de materiales. También, se desempeña como un servidor de información para otros holones del sistema de manufactura. Holón Orden: Representa una tarea en los sistemas de manufactura. Este holón es responsable de desempeñar el rol que permite la asignación del trabajo de manera correcta y en el tiempo preciso. Además, administra tanto el producto físico, que está siendo construido, así como el modelo de estado del producto y toda la información logística de procesamiento relacionada con el trabajo asignado. Un holón orden puede provenir de la solicitud de un cliente, o de la necesidad de aumentar el stock. Holón Staff: Es usado como una entidad que entrega mayor información del proceso pero a modo de “consejo”; los holones básicos (los tres tipos anteriores), siguen teniendo autonomía dentro de sus procesos; sin embargo, pueden requerir más información para resolver problemas complejos y en ese momento se pueden apoyar del Holón Staff. Este tipo de holón no se encuentra dentro de la jerarquía y se considera del tipo adicional.

16

1.Conceptos generales

Figura 1.3 Mapa de datos y funciones que cumple cada uno de los holones. Fuente [8]. Figura 1.3: Mapa de datos y funciones que cumple cada uno de los holones. 1.3.2. ADACOR La sigla ADACOR proviene de ADAptive holonic COntrol aRchitecture for Distributed Manufacturing Systems. Es una arquitectura que se enfoca en el desempeño del control de sistemas en escenarios estocásticos, lo que permite incrementar la agilidad y la flexibilidad de la empresa. Esta arquitectura holónica se construye alrededor de un conjunto de holones autónomos, cooperativos y auto-organizados, que representan el modelo de manufactura. En ADACOR, existen 4 clases de holones para modelar los sistemas de manufactura. Estos son: Holón Producto (HP), Holón Tarea (HT), Holón Operacional (HO) y Holón Supervisor (HS)[11], [12]. Holón Producto Este holón representa cualquier producto que puede ser diseñado en la planta. Es un puente entre los niveles de planeación y programación con respecto al nivel donde se encuentran los equipos y máquinas físicas, es decir, el nivel de planta.

1.2 Sistemas holónicos de manufactura.

17

Holón Tarea (Task) Cada orden de producción enviada a la planta es representada por un holón tarea; este sistema contiene información dinámica sobre la orden enviada y es responsable de administrar su ejecución. Holón Operacional Permite representar los recursos físicos disponibles en la planta, como robots y máquinas de control numérico, gestionando su comportamiento de acuerdo a los objetivos del recurso y sus habilidades. Permite además, coordinar la lista de órdenes enviadas a manufactura para que sean ejecutadas. Holón Supervisor Un supervisor es responsable por la coordinación de grupos de holones y su evolución en el tiempo. Existe un registro de la información de cada Holón que se encuentra en el grupo supervisado denominado “Lista de Habilidades”. Cuando un holón supervisor ofrece los servicios del grupo de holones que está administrando, se basa en la lista de habilidades para mostrar las capacidades del grupo de manera global. En la figura 1.4, se puede apreciar un esquema de distribución de los holones en un proceso de manufactura. Siempre que se necesite manejar un grupo, se usa un holón supervisor SH a la cabeza de dicho grupo. Los holones producto, operacional y tarea son muy similares a los holones de PROSA producto, recurso y orden, respectivamente [11], [12]; sin embargo, la gran novedad en ADACOR es el holón supervisor, el cual, no tiene relación con el holón staff de la arquitectura PROSA. El supervisor se encarga de coordinar las tareas de los holones que están un nivel por debajo de él, logrando organizar nuevas jerarquías que serán más adecuadas para los objetivos del sistema de producción. Además, permite la creación de sistemas más complejos y dinámicos [11], [13].

18

1.Conceptos generales

Figura 1.4 Estructura de organización holónica en ADACOR. Fuente [11] Figura 1.4: Estructura de organización holónica en ADACOR. Los holones ADACOR son representados de manera formal utilizando redes de petri de alto nivel. Esta técnica permite establecer la secuencia de acciones a ejecutar por el holón, cada vez que sea necesario. Es más, este tipo de representación facilita el trabajo al holón supervisor que está a cargo de cada uno de los grupos [13].

1.4. Sistemas Holónicos de Manufactura basado en la unidad de producción (HMS-UP) El Sistema Holónico de Manufactura basado en la Unidad de Producción, ha sido desarrollado por el grupo de investigación de la Universidad de los Andes [14] como propuesta para alcanzar un nivel de integración más alto, comparado con las aproximaciones de arquitecturas anteriores. La particularidad de HMS-UP es que no contiene varios tipos de holones por cada área a cubrir en el proceso, por el contrario define un tipo de holón (Unidad de producción) que contiene las características y las

1.2 Sistemas holónicos de manufactura.

19

funciones necesarias para representar al proceso integrado. Además, HMS-UP se basa en el concepto de la cadena de valor, el cual está más relacionado con el proceso y no con las funciones que se deben encontrar para soportar un sistema flexible. Para el presente trabajo, la unificación de los tipos de holones y la relación directa con el proceso a modelar se considera como una ventaja frente a las otras arquitecturas citadas anteriormente. Motivo por el cual se ha elegido como arquitectura de trabajo.

Figura 1.5 Cadena de valor Fuente [3] 1.5: Cadena de valor. En la figura 1.5 se muestra Figura el concepto de cadena de valor agregado; cada bloque representa una etapa donde se realiza un proceso. La unión de ellas de manera ordenada y consecutiva permite transformar la materia prima en productos finales. Sin embargo, una etapa puede contener en su interior otras etapas, tal como se puede apreciar en la parte inferior la figura 1.5 [15]. Cada uno de los procesos y subprocesos pueden ser representados por una unidad de producción. Dichas unidades son autónomas y autocontroladas siguiendo la filosofía del enfoque holónico. Una unidad de producción es parte de un sistema, pero también puede estar compuesta por otras partes, incluso, otras unidades de producción [3], [15]. Para comprender mejor el concepto de unidad de producción, en la siguiente sección se describe su comportamiento interno. Una unidad de producción (UP) es un holón, es decir, es autónoma, autocontenida y posee la capacidad de interactuar con otras unidades para lograr un objetivo común.

20

1.Conceptos generales

Como se puede ver en la figura 1.6, una UP es descrita, de manera general, mediante un bloque funcional con sus respectivas entradas y salidas. En la parte inferior del bloque funcional, se aprecia la entrada de “Energía y otros servicios”. Este flujo de entrada representa los elementos externos que permiten el funcionamiento de la UP. Los desechos son los materiales no útiles que se generan en el proceso de manufactura como sobrantes de materia prima o materiales que ya sufrieron una transformación química.

Figura 1.6. Representación de la unidad de producción Fuente [3] Figura 1.6: Representación de la unidad de producción. En la parte superior de la figura 1.6 se muestra una entrada denominada Metas. Por medio de las metas es posible asignar órdenes de producción a cada una de las unidades. De igual manera, una UP debe enviar su estado de progreso con respecto a la tarea asignada a un nivel superior en la holarquía para que sea tenido en cuenta en la actividad de planeación y programación. Los dos flujos descritos anteriormente tienen relación directa con los recursos físicos asociados a la UP; estos pueden ser máquinas y equipos de fabricación. Por otra parte, el tercer flujo, está directamente relacionado con la sección Decisión e Información.

1.2 Sistemas holónicos de manufactura.

21

El estado de una unidad de producción es un vector que contiene información de diferentes partes de la UP tales como avance de la misión o como se está cumpliendo la meta; variables de estado del proceso, las cuales describen la evolución del proceso de producción; estado de los recursos, de los equipos y hasta de las personas involucradas en el proceso; Por último, el estado de la acción de control, la cual supervisa el proceso. En la sección izquierda de la figura 1.7 se describe el proceso de producción contenido en la UP. Dicho proceso, permite la creación de un tipo de producto siguiendo las instrucciones de un método de producción. El método de producción contiene especificaciones técnicas en cuanto al tipo de operaciones, parámetros de control y cantidad de material necesario para la creación de un tipo de producto en particular. Una unidad de producción puede contener varios métodos de producción, un método por cada tipo de producto.

Figura 1.7. Modelo estructural de la unidad de producción. Figura 1.7: Modelo estructural de la unidad de producción. Fuente [3].

22

1.Conceptos generales

Fuente [3]

En la parte central de la figura 1.7 se observa la misión de la unidad de producción. Ésta representa la cantidad de productos que debe crear una UP en un tiempo específico. A esta definición se le denomina Meta la cual, está divida en requerimientos más detallados que son ejecutados por los recursos asociados a la unidad de producción o por las unidades de producción que están contenidas dentro de esta. Por su parte, la capacidad de la producción es la porción de rendimiento más alta que puede ser alcanzada por la UP para obtener un tipo de producto en condiciones ideales de operación. La capacidad de producción puede verse afectada por la presencia de cambios en las condiciones de los recursos y por lo tanto, cualquier modificación en las configuraciones o en el estado de los recursos, pueden llevar a nuevas capacidades de producción para la Unidad de Producción. La producción, la meta y la capacidad de producción son supervisadas por medio del Estado de la unidad de producción. Como se dijo anteriormente, el estado de una UP resulta de la composición de los estados parciales relacionados con el comportamiento de cada uno los elementos que constituyen la unidad de producción. En la figura 1.7 se muestra cada uno de los siguientes estados: 

El estado de la misión.



El estado del proceso, el cual describe la evolución del proceso de producción interno.



El estado de los recursos.



La actual ley de control, reflejada en el estado del supervisor

El estado de una unidad de producción es una característica fundamental dentro de la arquitectura HMS-UP. Un coordinador puede asignar metas o tomar decisiones proactivas de acuerdo a los estados de cada una de las UP que conforman la holarquía. Negociación Parte indispensable en la conformación y funcionamiento de holarquías es la

1.2 Sistemas holónicos de manufactura.

23

cooperación que existe entre cada uno de sus integrantes. Para cumplir con esta característica se agrega el concepto de negociación. Mediante ésta los integrantes de una estructura holárquica pueden establecer objetivos comunes o dar una respuesta ante una falla en el sistema[60] Una negociación inicia entre una unidad de producción, ejecutando la actividad de coordinación, que envía órdenes de producción a través de la red multicast. Las unidades que son clientes en la negociación procesan la orden y definen su nivel de competencia. En caso de cumplir con los requisitos de la orden, envían una contraoferta a la unidad coordinadora, en ese momento se establece una negociación hasta llegar a un acuerdo o a un rechazo. Las unidades procesan la orden basadas en la actividad de planeación y programación de la producción donde se realiza el registro de la secuencia de procesos por ejecutar por cada uno de los recursos de la unidad de producción. La negociación cuenta con los siguientes pasos importantes para llevarse a cabo [60] y se resumen en: 

Evaluación de solicitudes: Cada UP establece su capacidad y su disponibilidad de producción de acuerdo a las características propias. La orden es evaluada y se envía una contraoferta, el proceso se repite hasta que la unidad que contraoferta llega a un acuerdo o rechaza la orden.



Régimen de operación normal: Momento en el cual se agrega una orden de producción al cronograma de la UP.



Manejo de disturbios: En el caso de una falla la unidad de producción evalúa si se compromete el cumplimiento de la meta y envía una orden incompleta para que sea recibida por la unidad coordinadora.



Programación reactiva: Debido a las diferentes fallas que se pueden presentar en un sistema integrado, las unidades de producción deben estar en la capacidad de reprogramar las actividades a realizar.

24

1.Conceptos generales



Seguimiento de actividades: La constante supervisión de las tareas desarrolladas frente a las metas de producción, permite a la unidad de producción su nivel de avance frente a una unidad de producción.

Modelo de actividades En la unidad de producción se han definido una serie de Actividades, las cuales son realizadas para la administración, supervisión y control de los procesos de producción. A continuación se describe las funciones que cumplen cada una de ellas. Actividades de control: Cada unidad de producción contiene, por definición, un recurso asociado que debe ser controlado para el correcto funcionamiento. La teoría de los sistemas holónicos permite la existencia de un holón netamente informativo; sin embargo, para HMS-UP se determina que una UP siempre debe tener un recurso de producción asociado. En este sentido, las actividades de control representan la forma física de controlar el comportamiento de los recursos, es decir, las acciones de los dispositivos y algoritmos de control más básicos sobre las máquinas y equipos de producción [3]. Actividad de supervisión: El objetivo principal de la actividad de supervisión es el control y monitoreo de las operaciones realizadas en la actividad de control. La actividad de supervisión se encarga de iniciar, mantener y finalizar los posibles estados de las actividades de control dentro de lo definido en un sistema de eventos discretos. En [16], [17] se define la forma en cómo diseñar un supervisor usando las redes de petri y los posibles estados del proceso. La identificación de los estados de la unidad de producción se realiza por medio de la lectura de eventos. Dichos eventos pueden ser de dos tipos principalmente, eventos controlables y no controlables. Los primeros son eventos esperados tales como señales de inicio o terminación de operaciones, cambios en la configuración de los controladores o cambio en la meta de producción, incluso un plan de mantenimiento programado. Por otra parte, los eventos no controlables son excepciones al flujo

1.2 Sistemas holónicos de manufactura.

25

encontrado en el proceso normal, tales como la no disponibilidad de un recurso o la presencia de una falla. El supervisor diseñado debe contener una respuesta para cada uno de los posibles eventos que puede ocurrir durante el proceso de producción. En caso de no disponer de una respuesta definida para el procesamiento de un evento, el sistema debería entrar en un estado de emergencia [3] Actividades de coordinación: En un nivel más alto se encuentra la actividad de coordinación, la cual permite controlar la ejecución de un proceso de tipo batch y los recursos existentes de la unidad de producción. Esta actividad permite la creación de holarquías por medio de la cooperación entre las unidades de producción. Las funcionalidades que se puede encontrar en este nivel pueden ser: inicio y finalización de procesos de producción batch; control y supervisión de los proceso de cooperación entre unidades de producción o establecimiento. En las tareas de cooperación el coordinador de la holarquía es el encargado de realizar la negociación entre las unidades de producción para crear las jerarquías temporales que permiten la ejecución de los procesos de producción. El concepto negociación es un mecanismo sumamente importante que permite administrar la relación existente entre las unidades de producción y los tiempos de ejecución. Cuando se realiza una orden de producción a una UP esta determina su estado en recursos y disponibilidad, de acuerdo a estas mediciones realiza una oferta, los componentes de la unidad de producción sugieren cambios en la oferta con el fin de llegar a un acuerdo. Este proceso se lleva a cabo las veces que sean necesarias hasta llegar a un acuerdo o establecer que definitivamente no es posible lograr un acuerdo de cooperación. Administración de la información de Producción: Esta actividad es la encargada de adquirir, almacenar, analizar el desempeño del sistema de producción y de la creación de reportes de la información de la producción. La función de adquisición y almacenamiento de información también permite

26

1.Conceptos generales

correlacionar y gestionar dicha información, que es obtenida a través de la lectura del estado de la UP, que contiene parámetros de los recursos, así como información de la meta de la UP y la ley de control, entre otros. El análisis del desempeño de la producción corresponde al conjunto de acciones que analizan la información relacionada con los tiempos de cada ciclo en la unidad de producción, el uso y desempeño de los recursos y la eficiencia de los procesos de producción. El análisis continuo del desempeño de la producción permite optimizar los procesos de negocio y el uso de los recursos existentes en la unidad. Administración del método de producción: Actividad encargada de la creación, almacenamiento y gestión de la información relacionada con la forma adecuada de obtener los productos. Esta actividad permite obtener la base de conocimiento de los métodos de producción que servirán como información relevante en las actividades de planeación, programación, supervisión y control del sistema de producción. La administración del método de producción es la base para soportar los procesos de negociación de la UP. Para cumplir con dicha característica se deben realizar las siguientes funciones: 

Gestionar la información relacionada con los métodos de producción.



Obtener la información de métodos de producción para la elaboración de nuevos productos.



Manejar los cambios en los métodos de producción para obtener nuevas definiciones.

Planeación y programación de la producción: Esta actividad conforma un grupo de acciones encargadas de analizar las órdenes de producción, descomponer dichas órdenes en una secuencia de operaciones de producción, ordenar las solicitudes para el cumplimiento de las metas. Es también la encargada de optimizar los recursos de producción por medio de la unión o división de las órdenes de producción dependiendo de la cantidad de producto solicitado.

1.2 Sistemas holónicos de manufactura.

27

Figura 1.8. Unidad de producción holónica Fuente [3] Figura 1.9: Unidad de producción En total se han definido 6 tipos de actividades dentroholónica. la arquitectura HMS-UP. Las actividades de control, supervisión y coordinación son de tipo operacional, encargadas directamente de la asignación, funcionamiento y control de los recursos. Por otra parte se encuentran las actividades administrativas que se encargan de registrar y analizar la información de productos, métodos de producción y planeación de producción [3].

28

1.4.1.

1.Conceptos generales

Estado del arte sistemas holónicos

Las ventajas que ofrecen los sistemas holónicos han impulsado investigaciones, desarrollos en el área y un interés creciente que ha generado eventos como HOLOMAS [18], el cual es una conferencia internacional donde los principales investigadores de sistemas holónicos y sistemas multiagentes se reúnen para mostrar sus avances y compartir sus ideas en pro del desarrollo de los sistemas distribuidos. Algunos trabajos como [19] muestra la tendencia de establecer modelos y prácticas para realizar la implementación de sistemas holónicos, en este caso lo realizan mediante la simulación de un sistema de fabricación y su control usando un sistema multiagente embebido en microcontroladores. Este tipo de prácticas permiten reducir los costos de diseño e implementación[20]. Adicional, se encuentran trabajos relacionados para modelar las habilidades sociales que tienen los holones y hasta cierto punto mejoradas. En [21] se detallan características sociales más amplias en busca de modelar sistemas más complejos. Existen trabajos que ya muestran la aplicación de un sistema holónico en células de producción [22]. Las arquitecturas PROSA y ADACOR tenían algunas limitaciones por ser de los primeros esfuerzos en definir los sistemas holónicos, pero nuevos trabajos muestran las extensiones que permiten mantenerlas vigentes. [23]. En el caso de ADACOR se plantea una nueva estrategia de comunicación para poder relacionar varios elementos inteligentes en pro de la consecución de objetivos comunes. En cuanto a ontologías se han realizado varias como elemento de formalización en diferentes investigaciones. Inicialmente se encuentra a PSL [24] la cual es una de las ontologías de dominio para el campo de fabricación. Se ha planteado desde 1996 y actualmente se encuentra en la versión 2.8. Es una ontología de dominio la cual intenta abarcar un sistema genérico de producción. Usando este tipo de conceptos en [24] se muestra el proceso de creación de una ontología. En [25] se indica que a pesar la gran cantidad de trabajos relacionados con los sistemas de producción, las ontologías desarrolladas para sistemas holónicos,

1.2 Sistemas holónicos de manufactura.

29

específicamente, no han surgido todavía como tales. En dicho trabajo, además, se realiza una aproximación de una ontología para los sistemas holónicos realizando esquemas preconceptuales, pero se considera que está muy limitada en cuanto a relaciones y contenido. Así, se encuentra que existe una gran cantidad de trabajo relacionado en distintas áreas sobre los sistemas holónicos de manufactura, sin embargo, se considera que no existen trabajos que aborden directamente la dinámica de formular un modelo de referencia para facilitar el trabajo de implementación de la metodología HMS-UP en un proceso real.

1.5. Intercambio de información. El intercambio de información es una actividad muy importante de los sistemas integrados. Es de vital importancia que cada actor de un sistema pueda interactuar con sus pares para lograr objetivos comunes. En esta sección se describen brevemente, tanto la arquitectura del intercambio de información, como el tipo de contenido de dicha información.

1.5.1.

Arquitecturas de intercambio de información

Integración mediante bases de datos Una de las ideas iniciales para solucionar el intercambio de información, es el uso de sistemas con una base de datos central. Está técnica es muy usada en la actualidad y consiste en disponer de un centro de datos común para todas las aplicaciones o dispositivos que requieran información del proceso. Gracias al uso de lenguajes como SQL (Structured Query Sentences), el cual es un estándar de facto para el acceso y modificación de las bases de datos, es posible que diferentes tipos de aplicaciones o dispositivos puedan interactuar con el sistema de datos central para, finalmente, obtener un sistema integrado [26], [27].

30

1.Conceptos generales

A medida que los sistemas integrados de este tipo van creciendo, es necesario crear reglas y protecciones de acceso a la información. Aunque un sistema central brinda la información a todos los componentes de dicha red, no significa que cada uno de ellos pueda disponer de un acceso total a toda la información del centro de datos[28]. Sin embargo, los métodos de intercambio de datos de este tipo son poco eficientes en sistemas grandes y complejos. Por otra parte, la seguridad de la información así como la consistencia de la misma puede verse afectada por la cantidad de usuarios y aplicaciones que tienen acceso. Existen varios métodos para restringir el acceso y brindar una mayor seguridad como firewalls o bloqueo de puertos, pero estos métodos conllevan a otros problemas de integración con otros centros de datos[27], [28], [29].

Middleware Orientado a Mensajes Middleware Orientado a Mensajes (MOM), es un enfoque de intercambio de información, en el cual no se realizan conexiones directas entre los actores de la arquitectura del intercambio de información; en cambio, se usan mecanismos de paso de mensajes que soportan interacciones asíncronas y sincrónicas [27], [30] . MOM, es una de las técnicas usadas para la comunicación de los sistemas distribuidos (Ver siguiente sección). El argumento principal es usar servidores que actúan como intermediarios en la comunicación. De esta manera, diferentes aplicaciones puede compartir información entre ellas usando un intermediario (middleware en inglés)[30]. Una gran ventaja de este tipo de sistemas es la posibilidad de disminuir la necesidad de una conexión permanente por parte de las aplicaciones debido a que los mensajes se guardan en cola y pueden ser procesados un tiempo después de que son enviados, es decir, cuando el receptor esté dispuesto a aceptar la información. [27], [29], [30]. En MOM los mensajes son autocontenidos, y significa que, además de identificarse y conocer a su receptor, pueden ser procesados de manera independiente de los otros mensajes recibidos.

1.2 Sistemas holónicos de manufactura.

31

Este tipo de arquitectura para el intercambio de información es eficiente, pero aún necesita de servidores centrales para su funcionamiento.

1.5.2.

Sistemas Distribuidos

Con la gran cantidad de información que se genera en un sistema productivo, se dificulta la administración y gestión de todos los datos en una solo fuente central. Como opción viable de arquitectura de integración, se encuentran los sistemas distribuidos. Dichos Sistemas buscan dividir la complejidad de un sistema central en pequeños centros de datos especializados que ofrecen sus servicios para determinadas áreas del sistema.

Un sistema distribuido se define como aquel que contiene componentes localizados en computadores, conectados en red, que comunican y coordinan sus acciones únicamente mediante el paso de mensajes. Para eliminar la dependencia de un servidor o sistema central, es necesario que cada uno de dichos componentes posea cierta inteligencia que les permita realizar actividades de manera autónoma [31]. Las grandes ventajas en cuanto a seguridad, manejo de fallos y la escalabilidad que puede tener un sistema distribuido también requiere de nuevas herramientas que soporten tales características; una de ellas es la necesidad de crear un mecanismo de comunicación entre los distintos actores del sistema y un lenguaje común que permita tener la seguridad de que el receptor y el emisor se pueden comunicar de manera adecuada y, especialmente precisa, para llevar a cabo acciones en conjunto [27], [29], [32].

1.6. Lenguajes de comunicación Además de los tipos de arquitecturas, también se han desarrollado varias herramientas que permiten el intercambio de información a nivel empresarial. Básicamente, se ha explorado en la forma de enviar mensajes y que estos sean

32

1.Conceptos generales

comprendidos por todo un sistema de la manera correcta. Una de dichas herramientas es XML(eXtensible Markup Language ), el cual es un metalenguaje para la descripción de lenguajes basados en etiquetas. Un metalenguaje es una herramienta que permite definir una gran cantidad de lenguajes a partir de unas reglas simples. XML propone enviar información en un formato que combina el contenido del mensaje, así como la descripción del mismo a través de etiquetas [33]. Esta herramienta es muy usada por su gran versatilidad y por la posibilidad que varias aplicaciones pueda compartir información en un formato común [34]. En muchos sistemas actuales ya no se intercambia únicamente información ahora es importante compartir, también, conocimiento. En el campo de los sistemas multiagentes se han desarrollado varios esfuerzos por definir estructuras para este tipo de intercambio de información. Los ACL (Agent Comunication Language) son lenguajes que contienen estructuras y primitivas que se adaptan para soportar los diferentes tipos de negociación, colaboración e intercambio de información requeridos en la interacción de agentes [35], [36]. Estos lenguajes están compuestos de estructuras complejas que, a su vez, se conforman de otros sublenguajes los cuales, además de enviar el contenido del mensaje, también permiten el envío de parámetros, tales como el transmisor y la ontología (ver siguiente sección Ontologías) para poder interpretar correctamente los mensajes [35]. Para compartir conocimiento en los sistemas multiagentes se pueden encontrar lenguajes como RDF o KIF (Knowledge interchange format), los cuales definen una estructura para el contenido del mensaje [37]. FIPA ACL o KQML, se preocupan más por la forma de intercambiar conocimiento [35], [37], [27]. El tipo de lenguaje usado para la comunicación no es el punto central. El objetivo de KQML o FIPA ACL es, brindar un protocolo de transporte para las reglas de conocimiento, básicamente, compartir los modelos mentales de los agentes. En muchos casos, este tipo de comunicación requiere el uso de ontologías. Varias son las organizaciones que constantemente trabajan en definir las mejores prácticas para el intercambio de información y conocimiento como KSE (Knowledge Sharing Effort)[38] y OMG, que especifican formatos, lenguajes y diferentes herramientas que se preocupan por el intercambio de información.

1.2 Sistemas holónicos de manufactura.

33

Existen muchas otras herramientas, estructuras o lenguajes que permiten el intercambio de información en ambientes empresariales que no se abordan en el presente proyecto por no ser de interés central en la investigación [37].

1.7. El intercambio de conocimiento y ontologías Los sistemas holónicos tienen habilidades interesantes como la capacidad de interactuar con sus pares y llegar a establecer metas conjuntas por medio de la negociación. Estas características permiten administrar sistemas complejos, por medio de la simplificación del proceso en tareas más pequeñas, controladas por unidades de producción que coordinan sus esfuerzos para alcanzar el objetivo global.

Sin embargo, estas características pueden estar limitadas si no se cuenta con herramientas necesarias para establecer una comunicación de manera directa y adecuada. En el apartado anterior se mostraron algunas herramientas y arquitecturas relacionadas con el intercambio de información. En esta parte se documenta qué es una ontología, su importancia y cómo influye en el proceso de compartir conocimiento, el cual es el objetivo principal del presente proyecto.

34

1.Conceptos generales

Capítulo 2 2.

Definición de Ontologías La palabra Ontología ha sido tomada del campo de la filosofía, en donde su significado se relaciona con el ser y su existencia en el mundo. Sin embargo, para las ciencias actuales, especialmente para la ingeniería y la inteligencia artificial, el concepto tiene un significado diferente La ontología se considera, de manera general, como una forma conceptual de describir un sistema. Se menciona en general, porque algunos autores definen diferentes formas de “conceptualizar” la información. Es por eso que el significado de ontología puede variar dependiendo del ámbito en el que se haga la discusión [39]. Gruber define una ontología como “una especificación de una conceptualización” [40]. Esta es la definición más aceptada por la comunidad. Sin embargo, para clarificar la lectura en los capítulos posteriores, se va a considerar la siguiente definición como la principal para el presente texto “Una ontología es una descripción formal de entidades y sus propiedades: Esto forma una terminología compartida para los objetos de interés en el dominio mediante definiciones para el significado de las palabras en la terminología”.

Generar una especificación a nivel de dominio o aplicación, implica una mejor comprensión del problema. Los beneficios se pueden encontrar de dos formas. El primero es la optimización sustancial del proceso gracias al mejoramiento en la comunicación y comprensión entre actores de un sistema productivo, permitiendo que el flujo de mensajes sea entendido de manera clara y precisa. Como segundo beneficio, se encuentra la unificación de los trabajos de desarrollo e investigación en el área, aportando ideas, avanzando en el dominio de una manera conjunta al

36

2. Definición de Ontologías

compartir tanto los términos y sus relaciones como el conocimiento del dominio por parte de las personas que interactúan con él. Normalmente, una ontología consta de una lista de términos establecidos y las relaciones entre ellos. Dichos términos se obtienen de un estudio preliminar del dominio para el cual se desea mejorar los procesos de comunicación e integración. De esta manera, cuando se requiera realizar una comunicación entre actores de un sistema integrado, tanto el transmisor como el receptor, procesan de la misma manera el mensaje, asegurando así que se tiene una comunicación eficaz que permitirá facilitar el logro de objetivos comunes[41]. Al conjunto de objetos que pertenecen al dominio de interés se le denomina “universo del discurso”[40].

Una ontología, además de establecer términos comunes, también permite transmitir conocimiento por medio de la creación de relaciones, reglas y axiomas. Las relaciones vinculan los conceptos encontrados en el dominio, estas relaciones se llevan a un diagrama (como UML) en donde se puede apreciar la dinámica del dominio modelado. Las reglas delimitan las acciones del dominio, muestran el camino a seguir ante los diferentes eventos o situaciones que se pueden presentar. Por su parte, los axiomas son proposiciones que siempre son verdaderas dentro del dominio, por lo tanto se aceptan completamente y no se refutan [39], [41] [42].

2.1. Proceso para la creación de Ontologías La creación de una ontología es un trabajo complejo. La organización del conocimiento que se obtiene de un dominio, se debe expresar de una forma clara y precisa. Teniendo en cuenta lo anterior, en la presente sección se describe el proceso ideal, desde sus inicios, para la creación de una ontología. Dicho proceso contempla las siguientes consideraciones: el alcance, los criterios de diseño, la selección de la metodología para la conceptualización, selección de un framework de desarrollo y un lenguaje de representación para su formalización.

2.1 Proceso para la creación de Ontologías

37

2.2. Alcance Una de las primeras consideraciones a tener en cuenta, al inicio de la creación de ontologías, es determinar su alcance y en [43] se realiza una clasificación según él, como se describe a continuación. Ontologías de Nivel Superior: De aceptación universal, común a todos los dominios. Los términos que usa son conceptos muy generales como tiempo y espacio. Ontologías de Dominio: Descripción de un dominio dado y sus componentes. Este tipo de ontologías son un poco más específicas que las anteriores, porque limitan su universo del discurso a un dominio en particular junto con sus componentes, reglas y relaciones. Ontologías de Tareas: Proveen un vocabulario sistemático de los términos usados para resolver problemas asociados con tareas particulares, ya sean dependientes o no del dominio. Ontologías de Aplicación: Contienen las definiciones necesarias para modelar el conocimiento requerido para una aplicación particular en un dominio dado. Describen conceptos que dependen tanto del dominio particular como de las tareas. Estas ontologías son especializaciones de las ontologías de dominio y de tareas.

Figura 2.9 Tipos de ontologías por su alcance.

Figura 2.1: Tipos de ontologías por su dependencia.

38

2. Definición de Ontologías

2.3. Criterios para el diseño de una ontología El siguiente punto importante a tener en cuenta es, establecer una serie de criterios de diseño que permitan guiar el proceso y, posteriormente, evaluar los resultados al emprender la creación de dicha ontología. A continuación se relacionan algunos criterios de diseño [40]: Claridad: Una ontología debería comunicar efectivamente el significado del término definido. Las definiciones deberían ser objetivas. Aunque la necesidad de una definición de término provenga de un contexto social o computacional, la definición no debería tener dicha relación. Coherencia: Una ontología debería ser coherente, es decir, debe evitar las inferencias que son inconsistentes con las definiciones. Por ejemplo, una inferencia hecha a partir de un axioma, no debería contradecir una definición de un término; si esto sucede la ontología es incoherente. Extensibilidad: Una ontología debería estar diseñada para anticipar la necesidad de incorporar nuevas definiciones para usos especializados, sin necesidad de modificar el vocabulario existente. Mínima codificación parcializada: La conceptualización debería especificarse a nivel de conocimiento sin la necesidad de usar una codificación en particular. La codificación parcial que se efectúa para facilitar la implementación o la notación, dificulta la aplicación de la ontología en diferentes ambientes. Mínimo compromiso ontológico: Una ontología debería requerir un compromiso ontológico mínimo, el cual sea suficiente para soportar las actividades previstas para compartir conocimiento. Una ontología debería contener pocas relaciones, como sea posible, acerca del entorno en el cual está siendo modelado. De esta manera, las partes comprometidas en la ontología tienen la libertad de especializar e instanciar la ontología según se necesite.

2.1 Proceso para la creación de Ontologías

39

En resumen los criterios de diseño definen las siguientes reglas: tener clara la definición de los términos; no relacionar el contexto, en el cual se diseña la ontología, con las definiciones de los términos (tecnicismos); permitir la especialización y reutilización de la ontología.

2.4. Ciclos de vida En los primeros desarrollos de ontologías no se contaba con un método específico para su construcción. Sin embargo, pronto surgieron propuestas básicas que definían una serie de etapas por las cuales se debería cruzar para alcanzar una ontología. Cada una de ellas contiene una serie de especificaciones y consideraciones que permiten transformar el documento de requisitos iníciales en una ontología coherente y formalizada. La transición por dichas etapas en que se puede encontrar una ontología durante su proceso de construcción se denomina “Ciclo de vida de la ontología”. De manera similar al proceso de creación de software especificado en el proceso de desarrollo unificado [44], se han definido una serie de estados en los cuales puede encontrase una ontología durante su vida útil. Los estados son los siguientes [45]: Especificación: En esta etapa se determina la necesidad y el tipo de formalidad que se requiere para la ontología. También se determinan los tipos de usuarios finales y la forma de representación en lenguaje formal o informal. Conceptualización: Durante esta etapa se realizan descripciones, tabulaciones y gráficas, si es necesario, para representar de manera conceptual el conocimiento del dominio. Básicamente, se definen los conceptos y sus relaciones, como también una estructura jerárquica de los conceptos. El principal objetivo de esta etapa es generar un resultado que puede ser comprendido, compartido y debatido por diferentes usuarios y expertos. Formalización: Es una etapa en la cual se usa una herramienta o un framework para

40

2. Definición de Ontologías

la especificación de la ontología en términos semicomputables. Implementación: Etapa donde se usan diferentes lenguajes formales implementación de ontologías para crear un versión computable de la misma.

de

Evaluación: Antes de compartir y divulgar los resultados es necesario evaluar. Para esta fase se definen algunos criterios de evaluación. Principalmente se verifica que se cumpla con los criterios de diseño mencionados anteriormente.

2.5. Métodos para la creación de ontologías Aún con una definición clara del alcance, los criterios de diseño y la definición del ciclo de vida, no es suficiente para realizar la creación de una ontología. Para solucionar esto se han desarrollado varios métodos que guían en el desarrollo del proceso.

2.5.1.

On-to-knowledge

On-To-Knowledge, es un proyecto desarrollado por la Comisión Europea, el cual desarrolla métodos y herramientas, además de emplear el poder del enfoque ontológico, para facilitar la administración de conocimiento [46].

2.1 Proceso para la creación de Ontologías

41

Figura 2.10 Fases de la metodología CYC. Fuente [47] Figura 2.2: la metodología CYC.son [47]: La metodología se compone de 4Fases fases de importantes, las cuales Estudio de factibilidad: Se hace un estudio preliminar sobre la necesidad, alcance y propósito de la ontología. Iniciar (Kickoff): En esta fase se inicia con la definición de la ontología usando el documento de Especificación de Requerimientos (ORSD), dicho documento permite, al desarrollador, tomar decisiones sobre qué términos y relaciones incluir o excluir en la conceptualización; además, se define la estructura jerárquica de los términos. El objetivo de esta fase es realizar una conceptualización del modelo, cuyo resultado semiformal esté compuesto por una serie de nodos descriptivos unidos por segmentos que muestren, gráficamente, la relación entre los términos identificados. Esta fase, termina cuando se considere que el proceso de conceptualización ha cubierto la dinámica del dominio de interés. Sin embargo, OnToKnowledge permite regresar a esta fase posteriormente en caso de necesitar incluir nuevos términos o corregir algunos ya descritos. Refinamiento: Durante esta etapa se hace una revisión de los conceptos y las relaciones entre ellos. La metodología determina dos formas de refinamiento una revisión desde arriba hacia abajo (top-down) o desde abajo hacia arriba (buttom-up).

42

2. Definición de Ontologías

Estás dos técnicas deben su nombre al sentido en el cual se hace la revisión y mejoramiento de la conceptualización. Si se hace desde los conceptos más generales hasta los más específicos, se denomina Top-down, si por el contrario, se inicia desde los conceptos más específicos hasta los más generales se denomina (bottom-up). Además, en esta fase se realiza el proceso de formalización cuyo objetivo es clasificar, por medio de una taxonomía, los conceptos definidos en la fase anterior y definir las relaciones entre ellos. El resultado de la fase de formalización, es una ontología. Evaluación: Finalmente, se cuenta con una fase que permite evaluar que la ontología construida en la fase anterior cumple con los requisitos iníciales especificados en el OSRD. Luego de las tres fases, el resultado final es: una ontología revisada y lista para el ambiente de producción de una empresa. OnToKnowledge es una metodología adecuada para la creación de ontologías, tiene las fases bien definidas, pero se considera que actualmente las características de las ontologías requieren de mayor detalle, superando las capacidades que brinda dicha metodología.

2.5.2.

Methontology

Methontology, es una metodología creada por el Grupo de Ingeniería Ontológica de la Universidad Politécnica de Madrid para la creación de ontologías. Las bases de dicha metodología son actividades del desarrollo de software propuesto por la organización IEEE y algunas otras metodologías de conocimientos [41]. Methontology ha sido diseñada con el propósito de crear ontologías desde cero, es decir, partiendo únicamente desde unos pocos requisitos iníciales. Su metodología parte desde lo más general hasta lo más específico [41], [45]

2.1 Proceso para la creación de Ontologías

43

Figura 2.11 Ciclo de vida de la ontología por Methontology Fuente [45] Figura 2.3: Ciclo de vida de la ontología por Methontology. En la figura 2.3 se observa las fases que sugiere Methontology para la creación de ontologías. En la metodología, se definen algunos conceptos importantes los cuales permiten especificar de manera más precisa la ontología [45]. Conceptos: El término “concepto” es muy similar al término “clase” en el proceso de desarrollo de software. Un concepto es una palabra muy significativa dentro del dominio. El diseñador tiene la potestad de elegir cuáles términos serán conceptos dentro de la ontología; sin embargo, se pueden encontrar algunas formas de saber si un término califica como un concepto o no, por ejemplo: 1. Si dicho término no es fácilmente descrito a partir de otros términos; 2. si el término es necesario para explicar de manera precisa otros términos. Relaciones: Las relaciones entre los conceptos de un dominio es la especificación de las conexiones que existen entre ellos. Estas relaciones describen situaciones

44

2. Definición de Ontologías

como “X contiene a Y” o “X envía información a Y”. Instancias: Es la definición de valores para los atributos que se describen en un concepto. Por ejemplo, un concepto es el término carro. Dicho concepto, define al objeto como un medio de transporte, pero una instancia de dicho concepto, sería un Lamborgini Diablo, ya que está definiendo tanto un tipo de carro en específico, como la cantidad de llantas, el color y demás características que lo hacen distinguible ante otras instancias (otros tipos de carros) del concepto. Constantes: Términos que representan valores que no cambian, o por lo menos no en el largo plazo. Atributos: Representan propiedades de un concepto. Son características que describen el concepto al cual se le atribuyen. Axiomas: Son expresiones lógicas que siempre son verdaderas, las cuales restringen la ontología. Reglas: Cada dominio tiene un conjunto de condiciones en cuanto a las situaciones que se puede presentar. Estas situaciones restringen el comportamiento de los actores dentro del proceso. A este tipo de condiciones y restricciones se le denominan reglas. Methontology es una metodología de código abierto que contiene una especificación clara y detallada en cuanto a las partes que deben componer una Ontología. Por otro lado, la gran cantidad de documentación y ejemplos de desarrollo que se encuentran en la red, la postulan como la herramienta de conceptualización más indicada para realizar el presente proyecto.

2.5.3.

Metodología CyC

Cyc es un proyecto ambicioso que busca acumular la mayor cantidad de conocimiento posible en muchas áreas. El objetivo principal de Cyc es crear un repositorio de conocimiento general, a través de una estructura extensible que permita la incorporación de nuevas ontologías [48]. Como metodología, Cyc propone

2.1 Proceso para la creación de Ontologías

45

unas etapas básicas que se deberían incluir en el desarrollo de una ontología. En primer lugar, se realiza una etapa de codificación del conocimiento, es decir, se especifica de manera detallada la dinámica del dominio y los comportamientos de los componentes del mismo. Como segundo, se sugiere hacer la descripción de los conceptos obtenidos usando herramientas sistematizadas para mayor formalización. El objetivo es representar los conceptos por medio de herramientas que permitan su representación y distribución en formatos aceptados. El proceso es similar a la fase de implementación que se especifica en la sección ciclo de vida. En la última fase se realiza una verificación de las fuentes de conocimiento y, en especial, la validez de la ontología. Es recomendado por la metodología que sean los actores humanos quienes hagan el proceso de revisión y verificación. Como se observa, es una metodología sencilla que básicamente cumple con los requerimientos iníciales de una ontología: conceptualización, formalización y evaluación. Sin embargo se considera que el concepto actual de ontologías requiere mayor especificación y funcionalidad que lo descrito en CYC.

2.5.4.

Metodología Uschold y King

Luego de ser parte del grupo de desarrollo de la ontología Enterprise, la cual es una ontología para el modelamiento de procesos de empresa, Uschold y King sintieron la necesidad de crear una metodología de desarrollo para definir una ontología. A continuación se describen los pasos propuestos en dicha metodología [49], [50]. Identificar el propósito: El objetivo es clarificar para qué se está construyendo la ontología y hacia qué público va dirigida. Construcción de la ontología: Esta etapa se define en tres partes: 

Captura ontológica: Se propone la identificación de los conceptos clave y las

46

2. Definición de Ontologías

relaciones en el dominio de interés. Los autores también establecen tres posibles estrategias para identificar conceptos: desde el más concreto hasta el más abstracto (bottom-up), desde el más abstracto hasta el más concreto (top-down), o desde el más relevante al más abstracto (middle-out) 

Codificación: Esto involucra explícitamente la representación del conocimiento adquirido en el paso anterior en un lenguaje de representación formal de ontología.



Integrar con ontologías existentes: Durante la captura o el proceso de codificación, se realiza la pregunta de cómo y en qué forma usar ontologías que ya existen.

Evaluación: Etapa en que se realiza una crítica técnica a la ontología creada utilizando como punto de referencia las especificaciones de requerimientos, preguntas técnicas o de relevancia general [43]. Documentación: La documentación recomienda que las guías sean establecidas para documentar ontologías, ya que posiblemente haya una diferencia del proceso de acuerdo al propósito de la ontología Al ser uno de los primeros avances en cuanto a metodologías para el desarrollo de ontologías, forma parte de los desarrollos y aportes posteriores en los procesos de conceptualización de dominios, pero ya no está tan vigente para la creación de las nuevas ontologías.

2.6. Lenguajes para el desarrollo de ontologías La elección de un lenguaje para la definición de una ontología es un paso importante dentro del proceso. Por medio de este lenguaje se comparte el resultado del trabajo de investigación, motivo por el cual merece especial atención.

2.1 Proceso para la creación de Ontologías

47

En primer lugar, se muestran algunos criterios importantes a tener en cuenta para la selección de un lenguaje de descripción de ontologías: 

El lenguaje debe poseer una sintaxis bien definida para poder leer con facilidad la ontología.



Debe tener una semántica específica para comprender perfectamente el funcionamiento de la ontología.



Debe tener suficiente expresividad para poder capturar varias ontologías.



Debe ser fácilmente traducible desde y hacia otros lenguajes ontológicos.



Debe ser eficiente a la hora de realizar razonamiento.

A continuación se describen algunos de los lenguajes más usados para hacer la representación de ontologías y de modelos de conocimiento.

2.6.1.

XML (eXtensible Markup Language)

XML es un meta-lenguaje propuesto por el W3C (World Wide Web Consortium) que permite la definición de lenguajes de marcado (con etiquetas) que pueden ser adaptados para usos específicos. XML es una manera flexible de crear formatos de información comunes a cualquier aplicación. La gran versatilidad que tiene XML como lenguaje de intercambio de información permite que se considere como lenguaje de descripción de ontologías. Sin embargo, XML no define primitivas ni tipos de datos para la representación de ontologías [34].

2.6.2.

RDF (Resource Description Framework)

RDF fue creado con la intención de representar metadatos en la web. A pesar de

48

2. Definición de Ontologías

permitir la codificación, intercambio y reutilización de metadatos estructurados, no contaba con un vocabulario definido para la creación de datos. Por tal motivo, se creó RDF Schema, el cual proporciona primitivas como clase, propiedades e instancias que si permiten una representación de una ontología [41]. El modelo de RDF está conformado por recursos y pares de atributos/valores. Cualquier entidad es representada por un recurso (objeto) que puede ser referenciado por un Identificador Único de Recursos (URI). Los atributos representan las propiedades de los objetos y sus valores son entidades tales como enteros, string y demás [43]. RDFS no posee características para la descripción semántica de los conceptos. Además, solo provee las instrucciones básicas para el modelado de ontologías pero no para definir axiomas. No es un lenguaje diseñado para la representación de ontologías de gran complejidad.

2.6.3.

DAML+OL

Es un lenguaje propuesto por la W3C para la representación de ontologías y metadatos. DARPA agent Markup Language (DAML) fue transformado a DAML+OIL a través de algunas características de OIL. DAML consiste en un formalismo que permite a los agentes de software interactuar entre ellos [51]. DAML+OIL se construye sobre RDF y RDFS, pero proporciona tipos de datos de representación más ricas, comúnmente encontrados en la lógica descriptiva. Algunas de las ideas basadas en marcos proporcionadas por OIL fueron eliminadas. [52] DAML+OIL soporta tipos de datos complejos, a diferencia de OIL que sólo soporta el tipo de dato string. Los tipos de datos utilizados provienen de XML Schema. El lenguaje tiene una semántica bien definida[34].

2.6.4.

OWL (Web Ontology Language)

Es un lenguaje de marcado semántico desarrollado por la W3C para publicar y compartir ontologías sobre el World Wide Web. Es una extensión del vocabulario de

2.1 Proceso para la creación de Ontologías

49

RDF y se deriva de DAML+OIL. OWL está diseñado para ser utilizado por aplicaciones que necesitan procesar el contenido de la información en lugar de sólo presentarla a las personas [53]. Ontologías descritas con OWL 2 consisten en las siguientes tres categorías sintácticas OWL [53]: 

Entidades, tales como clases, y objetos son identificados por IRI2. Estos conforman los tipos de términos de una ontología y constituye los elementos básicos de una ontología.



Expresiones representan nociones complejas del dominio que está siendo descrito. Por ejemplo, una expresión de clase describe un conjunto de objetos en términos de las restricciones de las características de los objetos.



Axiomas: Afirmaciones que siempre son verdaderas en el dominio descrito. Por ejemplo, usando un axioma de una subclase, se puede asegurar que una clase a:Estudiante es una subclase de la clase a:Persona.

OWL es un lenguaje de ontologías que permite hacer una descripción más específica al disponer de elementos adicionales a las clases, instancias y atributos. Teniendo en cuenta esto, para el presente trabajo se seleccionó a OWL como el lenguaje de representación para el resultado de la investigación.

2.7. Herramientas para la implementación de una ontología Adicional a los lenguajes de descripción de ontologías, también se encuentran las herramientas o frameworks que permiten implementar en un software los resultados 2

Sintaxis concretas, tales como la sintaxis funcional de estilo a

menudo proporcionan

características que no se encuentran en la especificación estructural, se uso IRI para abreviarlo.

50

2. Definición de Ontologías

del proceso de conceptualización de la ontología. En la siguiente sección se describen brevemente algunos de los frameworks más usados para la implementación de ontologías.

2.7.1.

Ontolingua

Se considera la primera herramienta creada para el desarrollo y divulgación de ontologías. Ontolingua es una herramienta de desarrollo para navegar, crear, editar, modificar, verificar, evaluar y usar ontologías. Contiene una librería de ontologías cuyas definiciones, axiomas y términos no-lógicos, pueden ser reutilizadas en la construcción de nuevas ontologías[33]. Ontolingua basa la construcción de ontologías en el principio de diseño modular. Esto permite que las ontologías de las librerías puedan ser reutilizadas de cuatro diferentes maneras: 

Inclusión: Una ontología A es explícitamente incluida en una ontología B.



Polimorfismo: Una definición de una ontología es incluida en otra y refinada.



Restricción: Una versión restringida de una ontología es incluida en otra



Inclusión de Ciclos: Situaciones como la siguiente se pueden dar, más no son recomendables: la ontología A se incluye en la B, la ontología B se incluye en la C y la ontología C se incluye en la A [43].

2.7.2.

Protégé

Protégé es un software libre de código abierto implementado en Java, desarrollado en la Universidad de Stanford, que permite la construcción de ontologías de dominio o aplicación. Es capaz de operar como una plataforma para acceder a otros sistemas basados en conocimiento o aplicaciones integradas, o como una librería que puede ser usada por otras aplicaciones para acceder y visualizar bases de conocimiento. La herramienta ofrece una interfaz gráfica que permite al desarrollador de ontologías

2.1 Proceso para la creación de Ontologías

51

enfocarse en el modelado conceptual sin que requiera de conocimientos de la sintaxis de los lenguajes de salida. El modelo de conocimiento de Protégé está basado en marcos (frames). Los tipos básicos o primitivas de representación en Protégé pueden ser modificados, permitiendo tener representaciones apropiadas para una variedad de lenguajes de ontologías. Los tipos básicos de representación (elementos de su modelo de conocimiento) proporcionan clases, instancias, propiedades que representan los atributos de las clases y de sus instancias, además, de definir restricciones que expresan información adicional sobre las propiedades. Protégé, valida el nombre de las clases impidiendo que existan dos con el mismo nombre [54]. Protégé puede ejecutarse como una aplicación o a través de una conexión con un servidor remoto. Las ventajas de tener un sistema web es la capacidad de navegar y editar las ontologías de manera colaborativa. Protégé ha sido utilizado como el ambiente de desarrollo primario para muchas ontologías, y se ha convertido en la herramienta más utilizada en el mundo para trabajar con OWL. La comunidad de usuarios de Protégé regularmente contribuye a mejorar la calidad del software y participa en grupos de discusión en línea dedicados a formular preguntas, realizar peticiones de nuevas características y cuestiones de soporte técnico.

2.7.3.

Ontosaurus

Ontosaurus consiste de 2 módulos: un servidor de ontología el cual usa Loom como su sistema de representación de conocimiento, y un explorador web para ontologías Loom y PowerLoom. La herramienta cuenta con traductores de Loom a Ontololingua, KIFF, KRSS y C++ están disponibles [55].

2.7.4.

WebOnto

WebOnto es una herramienta para la edición de ontologías de manera colaborativa. Se desarrolló junto a Tadzebao en 1997, en el instituto Knowledge Media. WebOnto es un editor de ontologías OCML. Su principal ventaja sobre las otras herramientas

52

2. Definición de Ontologías

es que soporta la edición de ontologías de manera colaborativa, permitiendo discusiones sincronizadas y asincrónicas acerca de las ontologías que están siendo desarrolladas [50]. La principal similitud entre los mencionados anteriormente es que cada uno tiene fuertes relaciones con un lenguaje especifico (Ontolingua, LOOM y OCML, respectivamente). Además, todos han sido creados para permitir explorar y editar fácilmente ontologías [56].

2.7.5.

WebODE

WebODE es el sucesor de ODE (Ambiente de diseño de ontologías) el cual permite a los desarrolladores de ontologías configurar el modelo de conocimientos a utilizar para la conceptualización de acuerdo con las necesidades de representación de conocimientos [57]. Actualmente, WebODE contiene un editor de ontologías que integra la mayor parte de los servicios ofrecidos por la plataforma, un sistema de gestión de conocimientos (ODEKM), un generador automático de portales Web semánticos (ODESeW), una herramienta de anotación de recursos Web (ODEAnnotate), y una herramienta de edición de servicios Web semánticos (ODESWS). Para el presente trabajo se usará la herramienta Protégé (la cual se describe en detalle en el capítulo 4). La selección del framework se realizó por las siguientes características. 

Protégé permite la representación de ontologías usando OWL, lenguaje que permite la descripción de una ontología de una manera más específica que las representaciones que usan sólo clases, instancias y atributos.



Protégé en la versión 4.1 permite hacer la evaluación automática de la ontología, funcionalidad indispensable para revisar la coherencia del resultado del presente trabajo.

2.1 Proceso para la creación de Ontologías





53

Este framework es de código abierto y cuenta con una gran documentación, además de apoyo de la comunidad, características que facilitarán su uso.

Protégé ofrece también soporte a Menthotonlogy que ha sido seleccionada como la metodología principal en el presente proyecto.

54

2. Definición de Ontologías

Capítulo 3 3.

Creación del modelo de referencia Un modelo de referencia es una conceptualización de un dominio a través de la definición de una taxonomía, relaciones de conceptos y descripciones funcionales del dominio. En [61] se ha diseñado un modelo de referencia para los sistemas multiagentes de una manera similar a la propuesta en el presente trabajo. La técnica usada para la recopilación de información en [61] es la ingeniería inversa en un conjunto de funcionalidades desarrolladas, para así definir un modelo que pueda ser común a todos. En los capítulos 3 y 4 se desarrolla un modelo de referencia de forma similar a la realizada y probada en [61]. La diferencia radica que para la definición del presente modelo se toma una ontología para agrupar los conceptos relacionados a HMS-UP y no la ingeniería inversa sobre lo que ya se ha implementado. El objetivo principal de crear un modelo de referencia de integración basado en HMSUP es para permitir, a las empresas y profesionales interesados, disponer de una fuente base para la implementación de un sistema holónico integrado. En el presente capítulo se realiza una conceptualización de la teoría sobre HMS-UP a través del desarrollo de una ontología de aplicación, esta herramienta permite definir los conceptos importantes, además de establecer relaciones aumentando el nivel de conocimiento sobre el dominio modelado. Por otra parte, se crea una especificación descriptiva, como parte del modelo, que define fases de implementación de acuerdo a las descripciones hechas en [58]. Estas fases facilitan la aplicación de los conceptos HMS-UP sobre un proceso real. El documento denominado Guía de implementación se define en el Anexo A que acompaña al presente trabajo.

56

3. Creación del modelo de referencia

3.1. Creación de la ontología En los dos primeros capítulos se describió de manera detallada acerca de los sistemas holónicos basados en la unidad de producción, las ontologías y su uso como herramienta de modelado y representación de conocimiento, además se indicó cual sería el proceso para desarrollar una ontología para HMS-UP. En el presente capítulo se inicia con el proceso de creación de la ontología desde la fase inicial.

3.1.1.

Propósito de la ontología

En el capítulo 2 se definió el concepto de ontología como herramienta fundamental para la representación conceptual de un dominio o área de conocimiento. Es un tipo de representación que puede ser comprendida por los actores humanos por medio de los diagramas y gráficos que representan la ontología, así como dispositivos electrónicos por medio de la especificación en lenguajes como OWL.

La ontología creada contiene una serie de conceptos y relaciones entre ellos, la unión de cada uno de estos elementos representan las características de la teoría HMS-UP de una manera más explícita, con mayor grado de detalle, y por consiguiente, facilidad en la comprensión.

3.1.2.

Metodología a seguir

Después de evaluar las características de las metodologías descritas en el capítulo 2, se ha seleccionado Methontology como la metodología base para el presente trabajo. Los criterios que se han considerado y que favorecen dicha elección son los siguientes: ● Es una metodología ampliamente usada para el desarrollo de ontologías. Existen numerosos trabajos e investigaciones de referencia que facilitan el uso

3.1 Creación de la ontología

57

y comprensión de la herramienta. ● Propone una guía muy detallada para la definición de ontologías, tiene en cuenta la definición de clases, instancias, atributos y relaciones, además de reglas y axiomas que permiten inferir conocimiento del dominio. ●

Especifica una serie de “tareas” que dividen la conceptualización en objetivos parciales más concretos, facilitando el proceso de creación.

Figura 3.12 Tareas propuesta por Methontology para la fase conceptualización Fuente [45] Methontology propone dividir el desarrollo de la fase de conceptualización en 11

58

3. Creación del modelo de referencia

tareas como se muestra en la figura 3.1. El seguimiento secuencial del proceso permite obtener una conceptualización bien definida, sin embargo, el proceso es diseñado para que pueda ser realizado mediante iteraciones sucesivas que permitan ampliar el número de conceptos, mejorar las relaciones e ir refinando la ontología de manera gradual.

Cada una de las tareas abarca la elaboración de un parte de la ontología. Se puede observar que el proceso inicia con la elaboración de una lista de términos, pasando por la definición de las relaciones binarias, hasta completar la especificación de las clases, instancias, atributos y axiomas. La ejecución de cada una de las tareas permite obtener una ontología bien definida. En la sección 3.3 se describe este desarrollo.

3.1.3.

Alcance

El objetivo principal es crear una ontología para los sistemas holónicos de manufactura basados en unidades de producción o HMS-UP. Esto significa que se busca crear una conceptualización específica de un área del conocimiento que pertenece al dominio de los sistemas de manufactura y, según la clasificación de ontologías descrita en [43] y citada en el capítulo 2 con respecto a su alcance, el resultado del presente trabajo se clasifica como una Ontología de Aplicación. Para fines de documentación se crea la ficha técnica de la ontología, a la cual se añadirá más características a medida que se avanza en el proceso de construcción. Ficha Técnica Ontología Nombre

Ontología HMS-UP

Tipo de ontología

Ontología de Aplicación

Metodología

Methontology

Descripción

Ontología para la formalización de los conceptos de los sistemas holónicos de manufactura basados en el concepto de Unidad de Producción.

Tabla 3.1 Ficha técnica parcial de la ontología en desarrollo

3.1 Creación de la ontología

59

3.1.4 Tarea 1. Lista de términos El objetivo de esta tarea es identificar una lista de conceptos importantes para el área de conocimiento de interés y, de esta manera, asegurar que cualquier referencia al dominio pueda ser expresada usando los términos aquí descritos. La lista también incluye una descripción para cada uno de los términos para definir el uso correcto del concepto y facilitar el intercambio de conocimiento. Lista de términos: 

Actor: Usuario o sistema que desempeña un rol específico en un momento en dado.



Actividad: Acciones de control, supervisión y coordinación que afectan a una o más unidades de producción.



Activo: Recurso existente en una organización.



Actuador: Son todos aquellos mecanismos físicos y/o lógicos que permiten la modificación del estado de cualquier tipo de proceso.



Asignar: Establecimiento y definición de los recursos que son necesarios para la ejecución del programa de producción.



Atributo: Característica específica de un objeto que permite su descripción.



Autosimilaridad: Se refiere a un conjunto de objetos similares que conforman un objeto mayor, y este último posee las mismas características y funcionamiento de los objetos que lo componen.



Automatización: Es el proceso mediante el cual se materializa, en una aplicación específica, la capacidad de toma de decisiones autónomas soportadas en conocimiento

60

3. Creación del modelo de referencia



Cadena de valor: Esquema de descomposición horizontal basado en el flujo de conocimientos, productos, e informaciones entre las Unidades de Producción del mismo nivel de la empresa, los cuales deben estar orientados a satisfacer las necesidades del cliente y cumplir con los propósitos y las metas de la organización.



Cantidad: Porción de una magnitud



Capacidad de producción: Tasa de salida sostenible más alta que puede ser alcanzada con relación a los equipos, productos, servicios, recurso humano, materias primas, y unidades de producción que conforman la organización.



Configuración: Elemento dentro del sistema que permite modificar los atributos de los componentes de una unidad de producción.



Controlar: Acción de evaluación y seguimiento en el cumplimiento de los objetivos locales que deben ser cumplidos en el proceso de producción.



Controlador: Mecanismo de toma de decisiones que permite modificar el estado actual de un proceso físico y/o lógico a través de los actuadores para el cumplimiento de un objetivo



Coordinar: Actividad de sincronización de los recursos y las operaciones que se desarrollan en la organización con el objetivo de obtener una optimización global.



Despacho: Ejecución o ajuste al programa de producción en tiempo real.



Decisión e información: Parte virtual de la unidad de producción mediante la cual se agrupan las funcionalidades de toma de decisiones, control, supervisión y demás actividades que requieren inteligencia o funcionamientos no tangibles.



Disponibilidad: Atributo que permite establecer si uno o más recursos pueden

3.1 Creación de la ontología

61

ser tenidos en cuenta por la unidad de producción para satisfacer un objetivo. 

Empresa: Concepción de unidad de producción global que resulta de la composición de varias unidades de producción, las cuales deben operar de una manera coordinada para alcanzar los objetivos globales de la organización.



Energía: Recursos de entrada a la Unidad de Producción que son indispensables para realizar los procesos de transformación de la cadena de valor de la empresa.



Entrada: Recursos e información que requiere la unidad de producción para cumplir con el objetivo de obtener los productos exigidos con las características especificadas en un intervalo de tiempo definido.



Equipo: Corresponde a la descripción detallada de las funcionalidades que puede realizar un dispositivo que conforma una Unidad de Producción.



Especialidad: Descripción de todas las posibles operaciones que está en capacidad de realizar un Recurso Humano.



Estado: Comportamiento actual de un proceso o un recurso que está condicionado con la presencia de los eventos en los componentes de la unidad de producción.



Etapa: Fase en que se divide el proceso asociado a unidad de producción y que contienen un conjunto de operaciones que transforman la materia prima.



Desechos: Materiales no útiles para el proceso de producción que se generan en las operaciones de manufactura.



Detector de eventos: Entidad que lee los cambios en el estado de control o del supervisor, en busca de eventos importantes para notificarlos a un nivel superior.

62

3. Creación del modelo de referencia



Evento: Presencia u ocurrencia de un suceso en un instante de tiempo determinado.



Flujo: Intercambio de información, de trabajo y/o de producto que debe realizarse dentro y entre las Unidades de producción para cumplir con los objetivos de la organización.



Funcionalidad: Se refiere a la habilidad que tiene un recurso para realizar un tipo de operación dentro de un proceso de producción.



Histórico: Conjunto de estados registrados en archivos o bases de datos a través del tiempo que contienen información relacionada con el proceso de producción.



Holarquía: Conjunto de holones que se agrupan usando jerarquías temporales para alcanzar un objetivo común.



Holón: Entidad individual e inteligente que tiene la característica de trabajar de manera conjunta dentro de holarquías en búsqueda del cumplimiento del objetivo global. Por lo tanto, el holón es auto-contenido para sus partes subordinadas, y simultáneamente parte cuando es visto desde niveles superiores.



Indicador: Proposición que relaciona un estado observable con un hecho no observable, el cual sirve para sugerir la existencia de ciertas características de la gestión y/o la eficiencia de un proceso dentro de la organización.



Meta: Objetivo de producción que se asigna a una unidad de producción.



Método de producción: Conjunto de procedimientos que contiene sentencias para llevar a cabo una acción correspondiente a una actividad de producción, calidad, inventario y/o mantenimiento. El método contiene el conjunto de parámetros de entrada que regularán dicha acción y, el valor de salida correspondiente.

3.1 Creación de la ontología

63



Negociación: Intercambio de información entre una unidad de producción y un coordinador o supervisor de la holarquía, en donde se llega a un acuerdo en la meta a asignar para la UP teniendo en cuenta la capacidad de producción y la disponibilidad de la unidad, junto con las necesidades de producción del proceso.



Observador: Ente capaz de realizar la detección de eventos y/o mediciones indirectas de variables del sistema de producción para obtener información sobre el estado de dicho sistema.



Operación: Conjunto de acciones realizadas en una etapa de la cadena de valor que transforma la materia prima según las especificaciones de un método de operación.



Orden de producción: Petición realizada a la unidad de producción que especifica el tipo y cantidad de producto a construir, el tiempo de ejecución y la calidad del producto.



Plan de producción: Corresponde al resultado obtenido de la actividad de planificación de la producción, el cual contiene la información de la reserva a largo plazo de los recursos que componen la organización.



Planificación: Actividad dentro de la organización que tiene como objetivo realizar la descomposición de una orden en una secuencia de actividades, así como identificar el tipo de recursos necesarios para su posterior ejecución respecto a la disponibilidad existente en la Unidad de Producción.



Producto: Resultado de la transformación de materia prima por medio de un proceso de producción que sigue las instrucciones de un método de producción.



Programa de producción: Corresponde al resultado obtenido de la actividad de programación de la producción, el cual contiene la información del estado presente y futuro en la asignación de los recursos que componen la

64

3. Creación del modelo de referencia

organización. 

Programación: Actividad dentro de la organización que tiene como objetivo asignar las instancias de insumos, recurso humano, servicios y equipos para obtener la instancia de la Unidad de Producción que satisface el plan de producción.



Proveedor: Entidad que suministra un recurso (servicio, insumo, equipo).



Reactividad: Capacidad de tomar acción ante la ocurrencia de una evento.



Recurso: Materia prima, equipos o personas con que cuenta una empresa para cumplir con su objetivo de producir bienes y servicios.



Rol: Papel desempeñado por un actor en un proceso de negocio.



Salida: De información y/o producto, que está asociado a un flujo de cualquier tipo, como respuesta de un sistema.



Sensores: Dispositivos que detectan una señal física externa y lo convierte en una señal eléctrica



Servicios: Elementos como insumos o energía necesarios para la ejecución del proceso de producción.



Sistema holónico: Sistema en el cual se modelan los diferentes elementos que lo componen por medio de entidades autónomas denominadas holones.



Supervisar: Actividad referida al seguimiento procedimientos en el cumplimiento de una meta.



Unidad de producción: Desde el punto de vista holónico, una unidad de producción podría ser un Almacén, una Línea de Producción, una Célula de Trabajo, Taller, Zona, u otros.

de

un

conjunto

de

3.1 Creación de la ontología

65

3.1.5 Tarea 2. Taxonomía de los conceptos En Methontology se define una taxonomía como una forma de organizar los conceptos de acuerdo a características que los agrupan. Estás relaciones pueden resultar por tener un entorno común o porque son términos que depende el uno del otro para su definición. Los tipos de relaciones taxonómicas que pueden surgir han sido definidas en [1]. A continuación se describe cada una de ellas: Subclase: Un concepto “C1” es Subclase de otro concepto “C2” si y sólo si todas las instancias de “C1” son también instancias de “C2” . Descomposición disjunta: Una Descomposición-Disjunta de un concepto C es un conjunto de subconceptos de C que no tienen instancias comunes y que no cubren C, es decir, puede haber instancias del concepto C que no son instancias de ninguno de los conceptos que forman la descomposición. Descomposición Exhaustiva: Una Descomposción-Exhausitva de un concepto C es un conjunto de subconceptos de “C” que lo cubren, tal que no existe ninguna instancia de C que no sea instancia de al menos uno de los conceptos de la descomposición. Los conceptos que pertenecen a este conjunto pueden tener instancias y subconceptos comunes Partición: Una Partición de un concepto C es un conjunto de subconceptos de C que no tienen instancias ni subconceptos comunes y que cubren C. Descripción de la taxonomía. A través de diagramas de clase se muestran las relaciones taxonómicas entre los conceptos. Además, se agrega una descripción por cada diagrama para mayor comprensión.

66

3. Creación del modelo de referencia

Recurso

Figura 3.13 Relación taxonómica de la clase Recurso Fuente Propia La materia prima, equipo y los recursos humanos se consideran subclases del concepto recurso. Se declara como una descomposición disjunta dado que las subclases no tienen instancias comunes, además es posible que exista otra clase que se considere recurso en un futuro y se debe dejar la posibilidad de inserción. Las flechas indican la relación de herencia. En este caso equipo y servicios heredan de Recurso.

Actividad

Figura 3.14 Relación taxonómica clase Actividad Fuente Propia Las actividades son las funciones que se realizan dentro de la unidad de producción Figura 3.3: Relación taxonómica clase Actividad. para el control operacional y administrativo de la misma. En este caso existen 6

3.1 Creación de la ontología

67

actividades declaradas como descomposición disjunta, dado que es posible que en posteriores avances en la teoría se definan algunas otras. Rol

Figura 3.15 Relación taxonómica clase Rol Fuente Propia Diferentes roles que Figura influyen enRelación la dinámica de HMS-UP. Cada uno de ellos tiene 3.4: taxonómica clase Rol. funciones específicas dentro del dominio. Se modela como una descomposición disjunta considerando que pueden existir otros tipos de roles en el proceso

3.1.6

Tareas 3. Relaciones Binarias

Las relaciones binarias describen conexiones uno a uno que tienen los conceptos, sean de la misma o de diferente taxonomía. La vinculación de los diferentes conceptos del modelo permiten inferir la dinámica del proceso. La forma de representación de las relaciones puede realizarse mediante gráficas, tablas o figuras, lo relevante es que el formato escogido permita comprender rápidamente el significado de la relación. Para el presente trabajo se ha considerado el uso de tablas para representar las relaciones. El diseño que se ha dado a la tabla de la tarea 3 permite incluir las descripciones hechas en la tarea 5 “Descripción de relaciones”, motivo por el cual se han fusionado. A continuación se muestra y se explica el formato escogido para facilitar la comprensión de las siguientes partes del trabajo.

68

3. Creación del modelo de referencia

Relación

Concepto origen

Concepto destino

Relación inversa

Contiene a

X

Y

Es contenida por

Descripción de la relación

Tabla 3.2 Encabezado formato de tablas para la representación de relaciones .

La tabla 3.2 muestra la forma como serán representadas las relaciones. En este ejemplo, se ha representado la relación X Contiene a Y, donde X es el concepto origen y Y el concepto destino de dicha relación. Cada relación debe tener una relación inversa para hacer la ontología coherente, es por eso que en el último campo de la tabla se encuentra el campo relación inversa, es decir la relación redactada como si Y fuera el concepto origen. La relación quedaría Y es contenida por X.

Figura 3.16 Representación gráfica de una relación binaria

Relaciones unidad de producción. La unidad de producción es el centro de los sistemas holónicos de manufactura, por lo que tiene una relación directa casi con todos los elementos de la lista de términos. Sin embargo, no todas esas relaciones serán descritas directamente, muchas se harán a través de inferencias.

3.1 Creación de la ontología

69

Se puede apreciar que la tabla 3.3 no se especifica que una unidad de producción contenga materia prima, en su lugar se encuentra la relación con el concepto recurso, dado que una materia prima es un recurso (ver taxonomía de conceptos) se infiere que una unidad de producción contiene un materia prima.

Relación

Concepto origen

Concepto destino

Relación

inversa Contiene Unidad de producción Método de Es contenido producción por Una UP contiene uno o más métodos de producción que especifican las formas de crear productos.

Contiene

Unidad de producción

Recursos

Es contenido por Una UP contiene recursos asignados, los cuales pueden ser materia prima, equipos o maquinaria.

Contiene

Unidad de producción

Proceso

Es contenido por

Una UP contiene un proceso de producción

Alcanza

Unidad de producción

Meta

Es alcanzada por Una UP alcanza una meta, la cual especifica la cantidad y el tipo de producto a crear, además del tiempo.

Realiza

Unidad de producción

Actividad

Es realizada por Una unidad de producción realiza actividades de supervisión, control, coordinación o administración sobre ella misma u otras unidades de producción

70

3. Creación del modelo de referencia

Posee un

Unidad de producción

Estado

Es poseído por Una UP tiene un estado, el cual contiene varios estados parciales de los componentes internos de esta.

Debe enviar

Unidad de producción

Estado

Compone a

Unidad de producción

Empresa

Compone a

Unidad de producción

Obtiene

Unidad de producción

Debe ser enviado Una UP debe enviar su estado hacia el supervisor o coordinador de la holarquía, para hacer seguimiento y realizar negociaciones

Composición de Una o la unión de varias unidades de producción compone a la empresa. Unidad de producción Composició n de Una unidad de producción puede estar compuesta por otras unidades de producción Capacidad de Es obtenido producción por Una unidad de producción obtiene su capacidad de producción. Tabla 3.3 Relaciones unidad producción

Relaciones Método de producción. El método de producción es una especificación que guía al proceso en la forma de elaborar un producto diferente.

Relación Especifica

Concepto origen Concepto destino Relación inversa Método de Producto Es especificado producción por El método de producción contiene las especificaciones técnicas parta crear un producto

3.1 Creación de la ontología

71

Guía

Método de Proceso Usa producción El método de producción sirve de guía para que el proceso cree el producto deseado

Tabla 3.4 Relaciones del método de producción

El proceso de producción asociado a una unidad de producción, está compuesto por varias etapas, las cuales a su vez se componen de operaciones. En estas relaciones se considera que la operación transforma la materia prima y genera desechos. De esta manera, cuando se hace la inferencia se puede decir que un proceso genera desechos y transforma la materia prima, ya que las operaciones son parte de un proceso. Relación

Concepto origen

Concepto destino Relación inversa

Contiene

Proceso Etapa Un proceso está dividido en etapas

Es contenido por

Contiene Etapa Operación Es contenida por Las etapas de un proceso dividen sus funciones en operaciones Transforma

Operación

Materia prima

Es transformada por

En las operaciones se transforma la materia prima

Produce

Etapa

Subproducto

Es producido por

A la salida de cada etapa del proceso se entrega la materia prima transformada que se constituye en un subproducto.

72

3. Creación del modelo de referencia

Genera

Operación

Desecho

Es generado por

En las operaciones realizadas en cada una de las etapas se generan desechos

Modifica

Actuador

Proceso

Es modificado por

Un actuador afecta el estado de una o más variables del proceso y por ende modifica el comportamiento del mismo.

Mide

Sensor

Proceso

Es medido por

Los sensores capturan la información de cada una de las variables del proceso constantemente mientras se realiza la producción

Registra información

Estado del proceso

Sensor

Es registrado por

El estado del proceso obtiene la información del proceso por medio de los sensores

Lee

Controlador

Estado del proceso

Es leído por

Cada controlador del sistema tiene acceso de lectura de uno más sensores que detectan los cambios en la dinámica del proceso.

Envía referencia

Controlador

Actuador

Recibe referencia

Cada controlador procesa la información de los sensores y mediante un algoritmo de control genera una señal de control para el actuador

Mide

Estado ley de control

Controlador

Es medido por

Cada controlador tiene asignado un estado por medio del cual se puede identificar su comportamiento a través del tiempo

3.1 Creación de la ontología

Lee

Detector de eventos

73

Estado ley de control

Es leido por

Un detector de evento se encuentra constantemente leyendo el estado del controlador en busca de eventos importantes

Envía eventos

Detector de eventos

Supervisor

Recibe eventos

Cuando un detector de eventos encuentra un evento importante lo notifica al supervisor para que este último pueda tomar una decisión.

Envía referencia

Supervisor

Controlador

Recibe referencia

Un supervisor puede establecer una nueva referencia para un controlador

Envía evento

Detector de eventos

Coordinador

Recibe eventos

Cuando un detector de eventos encuentra un evento importante lo notifica al supervisor para que este último pueda tomar una decisión.

Envía referencia

Supervisor

Coordinador

Recibe referencia

El supervisor envía nuevas referencias de acuerdo a las necesidades que detecte el coordinador de la unidad de producción.

Alcanza

Etapa

Método de Es alcanzada por producción parcial

Una meta puede ser dividida en metas parciales para que sean alcanzadas a nivel de etapas

Está compuesta por

Meta

Meta parcial

Compone a

Una meta puede estar compuesta de metas parciales

74

3. Creación del modelo de referencia

Está compuesta por

Método de producción

Método de producción parcial

Compone a

Un método de producción puede dividirse en métodos de producción parciales que guían a nivel de etapas en los procesos.

Solicita

Método de producción

Funcionalidad

Es solicitad por

Un método de producción puede solicitar una funcionalidad de un equipo para el proceso de producción

Solicita

Método de producción

Especialidad

Es solicitad por

Un método de producción puede solicitar una especialidad

Solicita

Método de producción

Servicio

Es solicitad por

Un método de producción puede solicitar un servicio de un proveedor para el proceso de producción Tabla 3.5 Conjunto de relaciones de dominio

3.1.7

Tarea 4 Diccionario de conceptos

El diccionario de conceptos contiene todos los conceptos del dominio con sus respectivos atributos y relaciones. Mediante esta tabla se puede identificar rápidamente el papel desempeñado de un concepto en el dominio. A la derecha de cada concepto se encuentran las relaciones en las cuales se comportan como un concepto origen. También es necesario aclarar que los atributos asignados a cada concepto pueden estar presentes en varios de ellos sin que esto signifique una falta de coherencia. Methontology sugiere que en el diccionario de conceptos se describa las instancias

3.1 Creación de la ontología

75

de modelo. Pero en el presente caso no es posible dado que se está modelando un dominio teórico y no un proceso existente. Nombre de concepto Actividad Actor

Instancias

Atributos de clase Tipo de actividad Tipo de rol

Atributos de instancia

Relaciones

Id Nombre

Automatizació n Cadena de valor Id Nombre Ubicación

Empresa Energía

Proceso padre Id Nombre Operaciones Tipo de evento Id Fecha de evento

Etapa

Evento Flujo Gestión Holón Holarquía Instancia Integración Mantenimient o Método de producción Meta

Contiene Produce

Tipo de flujo

Tipo de producto Id Nombre Cantidad de

Especifica Guía

76

3. Creación del modelo de referencia

producto Tiempo Tipo de producto Etapa padre Nombre Transforma Id Genera Nombre id

Operación Orden Plan de producción

Nombre Id

Planificación Nombre Id Productos[] Etapas[]

Proceso

Contiene

Programa de producción Programación Producto Recurso

Tipo de recurso

Cantidad Nombre Descripción Disponibilidad Activo

Reporte Recursos Humanos

Especialidad Disponibilidad

Unidad de producción Estado

Capacidad de producción Disponibilidad

Contiene Produce Realiza Posee Debe enviar

3.1 Creación de la ontología

77

Compone Tabla 3.6 Diccionario de conceptos

3.1.8

Tarea 5 Descripción relaciones

Las descripciones de cada una de las relaciones ya han sido definidas en la tarea 3.

3.1.9

Tarea 6. Descripción de atributos de instancia.

El objetivo de esta tarea es describir detalladamente todos los atributos de instancia incluidos en el diccionario de conceptos. En la tabla 3.7 se muestra como se mostrarán la información de los atributos de instancia.

Atributo de instancia Nombre

Concepto Actor

Tipo de valor Cadena de texto

Rango de valores --

Cardinalidad (1,1)

Tabla 3.7 Ejemplo descripción de atributos de instancia

El formato de la tabla permite describir cuál es el nombre del atributo, a que concepto pertenece la instancia, el tipo de valor, un rango de valores posibles o permitidos para dicha variable y la relación de cardinalidad, es decir cuántos valores de este tipo tiene el atributo, en este caso tiene un solo nombre por cada instancia. A través de este formato se describe los atributos de instancia expuestos en el diccionario de conceptos. Atributo de instancia Nombre

Concepto Actor

Tipo de valor Cadena de texto

Rango de valores --

Cardinalida d (1,1)

78

3. Creación del modelo de referencia

Id

Entero

–

(1,1)

Nombre

Empresa

Cadena de texto

–

(1,1)

Id

Empresa

Entero

–

(1,1)

Ubicación

Empresa

Cadena de texto

–

(1,1)

Proceso padre Etapa

Entero

–

(1,1)

Id

Etapa

Entero

–

(1,1)

Nombre

Etapa

Cadena de texto

–

(1,1)

Operaciones

Etapa

Vector

–

(1,N)

Tipo de evento Evento

Entero

–

(1,1)

Fecha de evento

Evento

Fecha/Hora

–

(1,1)

Id

Evento

Entero

–

(1,1)

Tipo de producto

Método de producción

Entero

–

(1,1)

Id

Método de producción

Entero

–

(1,1)

Nombre

Método de producción

Cadena de texto

–

(1,1)

Cantidad de producto

Meta

Entero

–

(1,1)

Tiempo

Meta

Tiempo

–

(1,1)

Tipo de producto

Meta

Entero

--

(1,1)

Etapa padre

Operación

Entero

–

(1,1)

Nombre

Operación

Cadena de texto

–

(1,1)

Id

Operación

Entero

–

(1,1)

Id

Orden

Entero

–

(1,1)

Nombre

Orden

Cadena de texto

–

(1,1)

Id

Plan de producción

Entero

–

(1,1)

Nombre

Plan de producción

Cadena de texto

–

(1,1)

Nombre

Proceso

Cadena de texto

–

(1,1)

Id

Proceso

Entero

–

(1,1)

3.1 Creación de la ontología

79

Productos

Proceso

Vector

–

(1,N)

Etapas

Proceso

Vector

–

(1,N)

Cantidad

Producto

Entero

–

(1,1)

Nombre

Recurso

Cadena de texto

–

(1,1)

Descripción

Recurso

Cadena de texto

–

(1,1)

Disponibilidad Recurso

Entero

0-100%

(1,1)

Especialidad

Recursos humanos

Entero

–

(1,1)

Disponibilidad Recursos humanos

Entero

0-100%

(1,1)

Capacidad de Unidad de producción producción

Entero

--

(1,1)

Disponibilidad Unidad de producción

Entero

0-100%

(1,1)

Tabla 3.8 Descripción de atributos de instancia

3.1.10 Tarea 7 Descripción de atributos de clase Al igual que se describió los atributos de instancia, Methontology propone una forma de descripción de los atributos de clase. Para este tipo de descripción se usa un formato diferente mostrado en la tabla 3.9. Atributo de clase

Concepto

Tipo de valor

Cardinalidad

Valores

Tipo de Controlador actividad

[Control, Supervisión, (1,6) Coordinación, Administración MP, Administración info prod, Planeación y programación ]

Privado

Tipo de Supervisor actividad

[Control, Supervisión, (1,6) Coordinación, Administración MP,

Supervisión

80

3. Creación del modelo de referencia

Administración info prod, Planeación y programación ] Tabla 3.9 Ejemplo descripción de atributos de clase

En esta descripción, el concepto es la subclase que se crea cuando se asigna un valor al atributo. El tipo de valor es similar a la tabla de atributos de instancia, aunque en esta ocasión se muestra el conjunto de valores posibles que tiene el atributo. Finalmente, en la columna “valores” se selecciona el valor de cada uno. En la tarea 2 se definió la relación taxonómica que tenía el concepto actividad, ahí se indicaba que las subclases de actividad son control, supervisión, coordinación, administración del método de producción, administración de la información de producción y la actividad de planeación y programación de la producción. Si el atributo de clase “tipo de actividad” toma el valor “control” esta clase se convierte en la subclase “controlador”, la cual es el concepto que se muestra en la tabla 3.3 A continuación se muestran las descripciones para las variables de clase. Atributo de clase

Concepto

Tipo de valor

Cardinalidad

Valores

Tipo de Controlar actividad

[Control, (1,6) Supervisión, Coordinación, Administración MP, Administración info prod, Planeación y programación ]

Control

Tipo de Supervisar actividad

[Control, Supervisión, Coordinación, Administración

Supervisión

(1,6)

3.1 Creación de la ontología

81

MP, Administración info prod, Planeación y programación ] Tipo de Coordinar actividad

[Control, (1,6) Supervisión, Coordinación, Administración MP, Administración info prod, Planeación y programación ]

Tipo de Administración [Control, actividad del método de Supervisión, producción Coordinación,

Coordinación

(1,6)

Administración del método de producción

Tipo de Administración [Control, (1,6) actividad de la Supervisión, información de Coordinación, producción Administración MP, Administración info prod, Planeación y

Administración de la información de producción

Administración MP, Administración info prod, Planeación y programación ]

programación ] Tipo de Planeación y [Control, (1,6) actividad programación Supervisión, Coordinación, Administración MP, Administración info prod, Planeación y

Planeación y programación

82

3. Creación del modelo de referencia

programación] Tabla 3.10 Descripción atributos de la clase actividad

Atributo de clase Tipo de rol

Concepto Controlador

Tipo de valor [Controlador, Supervisor,

Cardinalidad (1,5)

Valores Controlador

Coordinador, Proveedor, observador] Tipo de rol

Supervisor

[Controlador, Supervisor, Coordinador, Proveedor, observador]

(1,5)

Supervisor

Tipo de rol

Coordinador

[Controlador, Supervisor,

(1,5)

Coordinador

Coordinador, Proveedor, observador] Tipo de rol

Proveedor

[Controlador, Supervisor, Coordinador, Proveedor, observador]

(1,5)

Proveedor

Tipo de rol

Observador

[Controlador, Supervisor, Coordinador, Proveedor, observador]

(1,5)

Observador

Tabla 3.11 Descripción atributos de clase Actor

3.1 Creación de la ontología

Atributo de clase

Concepto

83

Tipo de valor

Cardinalidad

Valores

Tipo de recurso Materia prima [Materia prima, (1,3) Equipo, Recurso Humano]

Materia prima

Tipo de recurso Equipo

Equipo

[Materia prima, (1,3) Equipo, Recurso Humano]

Tipo de recurso Recurso humano

[Materia prima, (1,3) Equipo, Recurso Humano]

Recurso humano

Tabla 3.12 Descripción de atributos de la clase recurso

3.1.11 Tarea 8 Descripción de las constantes Durante el proceso de modelado no se ha encontrado valores constantes dentro del dominio. Esto es posible dado que la ontología está basada en conceptos teóricos, es decir, no hay instancias reales que permitan identificar dichos valores.

3.1.12 Tarea 9 Definición de axiomas formales Los axiomas son predicados que siempre son verdaderos, además son de aceptación común y no se refutan. Los axiomas son importantes porque permiten establecer las bases de conocimiento del dominio.

Nombre

Descripción Expresión

Contiene

Proceso

Concepto

Relaciones

Variables

84

3. Creación del modelo de referencia

contiene Etapa Tabla 3.13 Ejemplo de descripción de axiomas

En la tabla 3.13 se muestran los campos usados para la representación de axiomas. Los campos nombre y descripción del axioma sirven para comprender la función de la relación. El campo expresión contiene una estructura lógica para poder hacer una descripción normalizada del axioma. En los siguientes campos se agrega los conceptos y relaciones que están incluidos en el axioma, además de la definición de las variables que se utilizaron para hacer la representación lógica, en este caso proceso corresponde a X y la etapa corresponde a Y (El concepto Y está en primer lugar en la columna concepto y X está también en primer en la columna variables, esto significa correspondencia). Nombre

Descripción

Los holones Todo holón contiene debe contener recursos un recurso asociado

Expresión

Concepto Relacione s Contiene Es contenido

X Y

Métodos de Por cada tipo producción de producto por cada existe al menos producto un método de producción

Método de Especifica producción Es Producto especifica do

X Y

Negociación

Negociació Requiere n

X Y

Supervisor Coordinado r

Z

Holarquías Se Holones componen Compone

X Y

Para realizar una negociación debe existir un supervisor o un coordinador

Composición Una holarquía de holarquías se componen de dos o más

Holón Recurso

Variables

3.1 Creación de la ontología

holones

85

n

Tabla 3.14 Descripción de los axiomas de la ontología

3.1.13 Tarea 10 Definición de reglas En la definición de reglas se busca especificar algunas situaciones comunes que suceden en el dominio de interés. Sin embargo, como la presente ontología no está representando un proceso físico sino la definición teórica de un área del conocimiento, no se han encontrado reglas que no hayan sido especificadas en la sección de relaciones ni tampoco como un axioma. En una futura aplicación de la ontología en un proceso real esta sección puede registrar varias reglas específicas.

3.1.14 Tarea 11 Descripción de instancias. Esta sección permite la descripción de las instancias de la ontología HMS-UP. Como se ha dicho nuevamente el proceso de modelado no comprende las instancias del dominio, solo se ha usado la teoría para la conceptualización. Por tal motivo esta sección no se realiza en el proyecto

86

.

3. Creación del modelo de referencia

Capítulo 4 4.

Formalización El seguimiento de la metodología de creación de ontologías permite definir con gran detalle los conceptos, relaciones y sus instancias. Hasta el momento se considera que se ha logrado un buen nivel de especificación, sin embargo, es necesario contar con una representación más fácil de comprender, la cual permita condensar la gran cantidad de tablas y relaciones definidas. Es por esto, que se continúa con la formalización. La formalización es la construcción de una representación de un modelo universal mediante un lenguaje que sea reconocido y comprendido por la comunidad en general. En el presente proyecto se ha seleccionado a UML como el medio de representación para la formalización, ya que es un lenguaje de modelado aceptado por la comunidad y que brinda la oportunidad de condensar gran cantidad de información en pocos diagramas. Adicionalmente, se hará una representación de la ontología por medio de Protégé. Esta herramienta también es muy reconocida a nivel académico y permite la representación en OWL, una utilidad muy interesante que mantiene el contenido de la ontología accesible a la comunidad por medio de internet.

4.1 Representación en UML A continuación se desarrollan diferentes vistas de la unidad de producción que

88

4. Formalización

pueden ser inferidas a partir de la conceptualización realizada en el capítulo anterior.

4.1.4

Funcionamiento operativo

En la figura 4.1 se describe la parte operativa de una unidad de producción. En ella se puede observar que cada unidad producción tiene un proceso asignado, y este a su vez está dividido en etapas. Cada uno de los procesos representa solo una parte de la cadena de valor. Las etapas se componen de operaciones, las cuales son las acciones ejercidas por los equipos sobre la materia prima. La secuencia y forma de ejecución de las operaciones esta descrita por el método de producción que está usando en ese momento la unidad de producción. El método de producción puede ser alternado en la unidad dependiendo del tipo de producto a construir. El método de producción contiene una serie de parámetros, secuencia de las operaciones y diferentes especificaciones relacionadas con el producto. Este método se divide, virtualmente, en métodos parciales facilitando el trabajo de configurar los equipos de producción de acuerdo a un conjunto de instrucciones más puntuales que el método total. Es importante observar que la gran cantidad de relaciones del proceso productivo se han asignado al concepto “operación”. Esto es así, porque de esa manera se puede inferir de la ontología que si una operación genera desechos entonces una etapa también genera desechos, ya que una operación es parte de una etapa.

4.1 Representación en UML

89

Figura 4.17 Descripción de la vista operativa de una UP Figura 4.1: Descripción vista operativa de una UP. 4.1.5

Negociación y toma de decisiones

La negociación es el centro para establecer una autonomía dentro de la unidad de producción. Existe una unidad de producción que realiza el rol de coordinador por medio de la actividad de Coordinación. Cuando una orden de producción llega a la holarquía el coordinador captura la orden y a través de la actividad de Planeación y programación de la producción, divide la orden recibida en un conjunto de órdenes parciales que son enviadas a través de la red de la holarquía. Las UP clientes verifican su competencia en la orden enviada a la red y establecen su disponibilidad y capacidad de producción, además verifican su estado. Si la UP posee las características necesarias esta envía una contraoferta al coordinador de la holarquía. Se inicia entonces un proceso de negociación entre el coordinador y la unidad hasta llegar a un acuerdo o un rechazo por alguna de las partes. Cuando una orden de producción es aceptada se convierte en la meta de la de UP, y esta registra dicha meta en su cronograma de producción,

90

4. Formalización

En la figura 4.2 se observa la representación UML del proceso de negociación.

Figura 4.18 Negociación y toma de decisión

4.1.6

Fuente propia

Figura 4.2: Negociación y toma de decisión. Autosimilaridad

La representación de la autosimilaridad es un formalismo en esta parte. Una unidad de producción posee un comportamiento definido a través de la conceptualización, pero también puede estar compuesta por otras UP con un comportamiento “similar”.

Figura 4.19 Autosimilaridad de la unidad de producción Fuente propia

4.1.7

Actividades administrativas

En la figura 4.4 se muestran las actividades administrativas en la unidad de producción. La actividad de Administración del Método de producción es la actividad

4.1 Representación en UML

91

que gestiona los métodos de producción de acuerdo al tipo de producto que se desea producir. Cada unidad debe estar en la capacidad de crear u obtener las partes del método de producción que están relacionadas con los recursos asignados a la UP. La actividad de planeación y programación está en la capacidad de gestionar las órdenes de producción que llegan a la unidad. En la descripción de la negociación se mencionó que a través de esta actividad la UP puede generar órdenes parciales que serán enviadas a la holarquía para establecer la cooperación en los objetivos comunes. La actividad de planeación y programación de la producción obtiene el estado de la UP, además de la secuencia de la metas de producción, para determinar su disponibilidad. Es posible que la misma actividad establezca un nuevo orden en la secuencia de metas de acuerdo a prioridades de producción establecidas o fallas del proceso que requieran una reprogramación

Figura 4.20 Actividades administrativas Fuente propia Figura 4.4: Por otra parte la administración de la información de producción se encarga de registrar un histórico del funcionamiento de la unidad de producción que es obtenido

92

4. Formalización

a través de la lectura constante del estado. Esta información es revisada y analizada posteriormente para determinar tiempos de trabajos reales, efectividad de operación y diferentes parámetros que pueden ser útiles para el mejoramiento del sistema integrado o calidad del producto.

4.1.8

Reactividad

Otro concepto interesante de la unidad de producción es la reactividad y puede ser inferido a través de las relaciones y conceptos consignados en la ontología. La reactividad se considera la capacidad de reacción de la unidad de producción ante los eventos que suceden en su interior. En el diagrama 4.5 se observa la estructura que permite relacionar a los eventos en tres niveles del proceso de producción, cada nivel corresponde con una de las actividades funcionales realizadas en la unidad de producción, las cuales son: control, supervisión y coordinación.

Figura 4.21 Reactividad en la unidad de producción Fuente Propia La acción de control se desarrolla directamente sobre el proceso físico. Cada sensor del sistema de producción mide las variables que intervienen en el proceso y envían la información a un controlador. Este último procesa la señal de los sensores y por

4.1 Representación en UML

93

medio del algoritmo de control genera una nueva señal, la cual es enviada a un actuador para que modifique el comportamiento del proceso y se mantengan las variables en los puntos deseados. Las reacciones en este nivel tienen relación con los cambios que se registran en las operaciones y las variables físicas que afectan directa con el proceso. El control realizado sobre un proceso también debe ser “controlado” desde un nivel superior. A través del “estado de control” un detector de eventos informa a un supervisor sobre el funcionamiento del proceso. El supervisor debe estar en la capacidad de decidir la acción a tomar de acuerdo al evento que se presentó y generar una nueva referencia para la actividad de control. La capacidad de reacción de este nivel es sobre acciones tales como iniciar o terminar la ejecución de una etapa de producción. El coordinador de la unidad de producción recibe la información del detector de eventos, que debería observar el estado del supervisor, sin embargo este estado no se encuentra establecido directamente dentro de HMS-UP, en su lugar se propone que a través del estado de la ley de control se refleje el estado del supervisor. Es por esto que en la figura 4.5 el detector de eventos se encuentra relacionado directamente con el coordinador y el supervisor. Se establece así que una unidad de producción tiene la capacidad de “reaccionar” ante los diferentes eventos que puedan surgir en una unidad de producción, tanto a nivel de máquinas o variables, a nivel de etapas o, incluso, de ciclos completos de producción.

4.1.9

Concepto meta en la unidad de producción.

Con respecto a la meta que debe alcanzar una unidad de producción hay algunos conceptos interesantes que se considera se debe señalar. Como se ha dicho anteriormente una unidad de producción recibe una orden de producción desde un nivel superior para que sea ejecutada, se establece una negociación, y de llegar a un acuerdo la UP registra la orden de producción como

94

4. Formalización

una meta a través de la actividad de planeación y programación de la producción. Cada meta contiene un tipo y cantidad de producto a construir, además del tiempo esperado para dicha producción y una relación con un método de producción. Como se muestra en la figura 4.6, la meta y el método de producción están conformados por metas y métodos parciales respectivamente, los cuales realizan la misma función de cada concepto establecido hasta el momento pero con un alcance más específico para cada una de las etapas del proceso.

Figura 4.22 Concepto Meta en la unidad de producción Fuente propia. En la misma figura se encuentra al método de producción parcial con una relación a los conceptos funcionalidad, especialidad y servicio. Aunque en principio se considera una inconsistencia con los conceptos mostrados en la figura 4.1, en donde se muestra que una operación hace uso de los recursos, en la figura 4.6 se muestra que el método de producción solicita los recursos de acuerdo a sus características, es decir, se tiene una relación a nivel de información. Según la especificación que realice el método de producción sobre los recursos necesarios para la producción el proceso hace uso de esos recursos. Los diagramas expuestos en la tarea 2 también hacen parte de estos resultados al

4.1 Representación en UML

95

ser diagramas que demuestran la herencia entre los conceptos. En el capítulo 5 se analizarán en mayor detalle todos los resultados obtenidos.

4.2 Representación con Protégé Representar una ontología mediante un lenguaje estructurado puede ser complicado si no se cuenta con la herramienta de desarrollo adecuada. Es por eso que se ha seleccionado el framework Protégé como la herramienta de representación, la cual facilita la agregación de los modelos, relaciones y atributos, también permite la exportación de los resultados en OWL. Tanto el framework como el lenguaje de representación han sido descritos en el capítulo 2 del presente trabajo. El proceso de modelado con el framework no tiene una metodología específica ni unos pasos estructurados a seguir. Sin embargo por motivos de organización se usará la misma secuencia de actividades propuesta por Methontology. La interfaz de Protégé puede parecer compleja en primera instancia debido a la gran cantidad de funcionalidades que posee, no obstante durante el desarrollo del presente capítulo se irán exponiendo algunos detalles importantes acerca del software. En la figura 4.7 se aprecia la interfaz del framework. En la parte superior se observa el menú de la aplicación con las opciones file, edit, etc. Una de las características más relevantes es la separación en pestañas de las interfaces que permite agregar cada uno de los componentes de la ontología. Active ontology: Indica cuál es la ontología que está activa en el framework. Por medio de active annotations es posible agregar información como la descripción general de la ontología. Entities y Clases: Estas dos interfaces son bastante similares, permiten agregar los conceptos de la ontología, pero en entities es posible crear tipos de datos. Los tipos

96

4. Formalización

de datos permiten dar mayor detalle a la representación de los atributos de los conceptos, y disponer de la capacidad de crear nuevos tipos es una ventaja para una mejor formalización. Object Properties: La pestaña object properties permite crear las relaciones binarias descritas en la ontología. Data properties: Pestaña donde es posible agregar los atributos tanto de instancia como de clase. Individuals: Interfaz que permite la creación de instancias de los conceptos. OWLviz: Es una herramienta gráfica la cual muestra las relaciones taxónomicas de los conceptos. En otras palabras muestra los conceptos y las relaciones de herencia. DL Query: Permite usar sentencias de búsqueda entre los elementos de la ontología. Es una herramienta muy necesaria cuando se tiene una gran cantidad de conceptos e instancias. OntoGraf: Un panel donde se muestran las relaciones binarias entre los conceptos. Es posible observar varias relaciones binarias de un concepto, incluso de todo el dominio en la misma gráfica. Se especificará con más detalle cada una de las pestañas a medida que se utilicen en el proceso de formalización.

4.1 Representación en UML

97

Figura 4.23 Descripción de la ontología Fuente propia Figura 4.7: Descripción de la ontología. 4.2.4

Representación de conceptos

El primer paso consiste en agregar los conceptos de la lista de términos al framework. Este paso es indispensable ya que los conceptos son la base de la ontología, a los cuales luego se les asigna las relaciones, atributos y demás. Dentro de Protégé todo concepto que se desee agregar debe heredar de “algo” (thing en inglés), este se considera el concepto universal. Es por esta razón que todos los conceptos agregados en la ontología heredan de él, como se muestra en la figura 4.8. En misma figura también se muestra la herencia en un segundo nivel, es el caso del concepto “actividad” del cual heredan los conceptos controlar, coordinar y supervisar. De igual manera el concepto actor también tiene conceptos que heredan de él. Esto se puede evidenciar por el triángulo gris que se encuentra al lado izquierdo del concepto.

98

4. Formalización

Figura 4.24 Agregando los conceptos en la pestaña Entities Fuente propia. Figura 4.8: Agregando los conceptos la pestañaencontrados Entities. En esta sección se deben agregar cada uno de losenconceptos en la lista de términos de la ontología. La lista de términos establece el uso que se debe dar a cada término en el dominio, así que es el punto de partida de la formalización. Es posible que varios términos no tengan relación con otros de manera directa, en especial conceptos los cuales sirven como referencia o para ampliar el contexto. Aún esos conceptos deben ser agregados ya que cuando se realice la descripción en OWL estos términos tendrán peso en la interpretación de la ontología.

4.2.5 Representación de las relaciones En la fase de conceptualización se definieron varias relaciones que tenían los conceptos, se denominaron “binarias” ya que unen dos conceptos de manera específica. En Protégé se puede agregar la información de dichas relaciones a través

4.1 Representación en UML

99

de la pestaña denominada “Object properties”. La forma de agregar relaciones al framework es muy similar a la forma de agregar los conceptos. La única consideración a tener en cuenta es que cada relación que se desee agregar en la ontología debe heredar de la clase topObjectProperty. En la figura 4.9 se han definido tanto las relaciones directas como las relaciones inversas. Por ejemplo, la relación “alcanza” que tenía como concepto origen “Unidad de producción” y el concepto “Meta” como destino, tiene su contraparte denominada “es alcanzada por”.

Figura 4.25 Creación de las relaciones binarias Fuente propia F Creación de las relaciones La declaración de igura las 4.9: relaciones inversas es parte binarias. importante del diseño de ontologías para dar mayor consistencia. Para especificar que una relación es inversa de otra, se debe incluir como

100

4. Formalización

contraparte por medio del panel “description”, en la sección “inverse properties”. Protégé permite especificar qué tipo de datos pueden ser vinculados mediante una relación en especial, pero no es recomendado porque puede originar problemas de coherencia más adelante.

4.2.6

Representación de atributos

En el framework se especifican, en el mismo lugar, los atributos de instancia y de clase. Cada atributo posee una descripción y un tipo de dato asociado. La clasificación como atributo de clase o de instancia sucede cuando se asigna el atributo a una clase o instancia. Todos los atributos heredan de la clase topDataProperty, similar a las superclases especificadas por Protégé para la creación de conceptos y relaciones. Es posible que atributos hereden de otro atributo, pero esta característica no se ha agregado en el presente trabajo.

Figura 4.26 Representación de las variables de clases e instancias Fuente propia Figura Representación las la variables dede clases e instancias. En la figura 4.104.10: se muestra la interfazdepara creación atributos. Un atributo tiene varias características importantes que pueden ser configuradas mediante el panel

4.1 Representación en UML

101

derecho. Range es una de dichas características y permite definir el tipo de dato del atributo. Al lado derecho de la interfaz están las pestañas annotations y usage. En la primera se puede agregar una descripción básica sobre el tipo de atributo y su funcionalidad. En la otra pestaña se muestran los conceptos en los cuales ha sido “usado” este atributo. En las tareas de definición de los atributos de instancia se puede notar que existen muchas variables con el mismo nombre pero que son parte de diferentes tipos de conceptos. En la definición de la ontología solo se debe agregar una vez cada una de las variables, y por medio de la relación concepto atributo se puede definir a quien pertenece. Es por eso que la formalización contiene menos atributos de los que se muestran en la tarea de descripción de atributos de instancia y de clase en conjunto.

4.2.7

Representación de instancias

Como se mencionó en el capítulo anterior la conceptualización de HMS-UP tomó en cuenta, únicamente, los conceptos teóricos. Por tal razón no hay instancias que representar en Protégé.

4.3 Finalización del proceso La formalización es un proceso en el cual se debe ser cuidadoso de representar la ontología de la forma correcta. Sin embargo, con el uso de herramientas como Protégé el proceso se puede hacer de una manera rápida y con mayor seguridad. Del proceso de formalización de la ontología se pueden obtener varios resultados dependiendo del interés del usuario. Lo importante es realizar la representación en formatos aceptados por la comunidad en general y que sean fácilmente distribuidos. A continuación se muestra el resultado general del proceso de formalización a través

102

4. Formalización

de un diagrama y la descripción del modelo en OWL, métodos que sirven para la comprensión tanto de humanos (diagrama) como de máquinas (representación en lenguaje OWL).

4.3.4

Representación gráfica

El framework provee un plugin bastante interesante que permite representar de manera gráfica toda la ontología. Ontograf muestra tanto las relaciones taxonómicas como las relaciones binarias en un mismo lugar. En la figura 4.11 se puede observar dos paneles, el de la izquierda representa cada uno de los conceptos de la ontología (cuadros) y las relaciones que existen entre ellos (líneas curvas). En el de la derecha se encuentran cada uno de los nombres de las relaciones.

Figura 4.27 Representación general de la ontología por medio de ontograf Fuente propia Figura 4.11: Representación generalyde la ontología por medio de ontograf. El gráfico con la totalidad de conceptos relaciones es solo informativo. Es posible ocultar algunos términos y relaciones con el fin de hacer la representación más fácil

4.1 Representación en UML

103

de comprender. Además del gráfico, también se dispone de la representación de la ontología usando el lenguaje OWL. Esta representación permitirá a los dispositivos “comprender” e inferir información adecuada acerca del dominio modelado. Este resultado es la representación en lenguaje OWL. Como se mencionó anteriormente este tipo de resultado es bastante importante para pensar en sistemas inteligentes que entiendan la dinámica del modelo y también que puedan compartir el conocimiento. Además, a partir de la información descrita con el lenguaje es posible inferir información que no se ha especificado directamente. Los resultados mostrados hasta el momento se indican como prueba de que el proceso de formalización ha sido realizado, pero en el siguiente capítulo se realiza un análisis más detallado

Figura 4.28 Representación en OWL generada por Protégé Fuente propia Figura 4.12: Representación en OWL generada por Protégé.

104

4. Formalización

Capítulo 5 5.

Validación y resultados obtenidos En el presente capítulo se realiza un análisis de los resultados obtenidos al final del proceso de creación de la ontología, además de la validación de la ontología en términos de coherencia, fidelidad de la representación y su aplicación como herramienta de modelado en un proceso caso de estudio.

5.1 Resultados generales Cuando se emprendió con el proceso de creación de una ontología, se consideraba parte fundamental la representación precisa del conocimiento del dominio de forma tal que pudiera ser comprendida tanto por un usuario como por un sistema o dispositivo electrónico inteligente3. El desarrollo de la ontología utilizando la metodología Methontology permitió definir de manera precisa los conceptos y luego las relaciones entre ellos. Esta especificación da la posibilidad de comprender la dinámica del proceso de manera puntual, resolviendo dudas de conceptos o de alguna relación en específico. Durante la conceptualización de la ontología se avanzó un poco más allá de las posibilidades que Methontology brindaba, es así como se crearon los diagramas de resultado en el capítulo 4. Cada diagrama describe una vista o perspectiva de interés de la teoría de los sistemas holónicos de manufactura basados en la unidad de producción. Al tratar de encajar dichas gráficas por medio de los conceptos y relaciones de la fase de conceptualización, se detectaron vacíos en la especificación 3

A través de lenguajes como OWL.

106

5.1 Resultados generales

que luego fueron mejorados, añadiendo mayor valor y validez a la ontología. El hecho de condensar las relaciones en un gráfico aumenta la facilidad de comprensión del actor humano. Por otra parte, el proceso de formalización llevado a cabo por medio de Protégé generó varios resultados, que se analizarán en breve, uno de ellos es la representación en lenguaje en OWL. 1

Declaration(Class())

2

AnnotationAssertion( "Acciones de control, supervisión y coordinación que afectan a una o más unidades de producción."@es)

3

SubClassOf( owl:Thing)

4

SubClassOf( ObjectSomeValuesFrom( ))

Tabla 5.15 Código OWL parcial

En la tabla 5.1 se encuentra un pequeño ejemplo de la forma como se representa los componentes de la ontología en OWL. El script muestra la definición de la clase actividad, su descripción, herencia de la clase “thing” y la vinculación con la clase “unidad de producción” por medio de la relación “es realizada por”. El código muestra que el archivo es autodescriptivo, esto quiere decir que además de contener el valor de interés también define el tipo de información. Algo similar a la estructura de un archivo XML.

5. Validación y resultados obtenidos

107

También se aprecia que cada una de las líneas contiene una dirección web. Esto indica que el trabajo que se va realizando en el framework es instantáneamente publicado en internet para compartir los resultados del trabajo con otros grupos de investigación. Es así como el trabajo cumple a cabalidad con las expectativas iníciales, las cuales eran: generar una definición más precisa del proceso, entregar información relevante para los actores humanos (diagramas de relación) y los dispositivos electrónicos (descripción en OWL). A continuación, se describe el proceso de validación y análisis de los resultados obtenidos.

5.2 Validación de la ontología La validación de una ontología es un proceso que puede variar mucho en cuanto a los criterios seleccionados. En general, se considera que la validación se debe realizar por medio de la aplicación de los criterios de diseño los cuales se han indicado en la sección 2.2.2.

5.2.4

Coherencia

Se refiere a la capacidad de hacer inferencias del dominio que no contradigan una definición de un término u otra regla. En este aspecto Protégé brinda una funcionalidad excelente para realizar la prueba de coherencia llamada “Rasonner”.

Un razonador es una función de Protégé que infiere información a partir de los datos cargados en el programa. El razonador de Protégé deduce un modelo a partir de las relaciones y definiciones que se han agregado en el programa. Esta tarea de verificación puede ser realizada en todo momento durante la fase de formalización por parte del diseñador, el cual constantemente compara si la información cargada en el framework es exactamente igual a la información que el razonador dedujo. En el caso de que se encuentre una diferencia entre los modelos, significa que hubo un

108

5.1 Resultados generales

error en el momento de agregar la información o, en el peor de los casos, hay una inconsistencia en la conceptualización. Para iniciar el razonador se debe ingresar al menú Reasoner en la parte superior del programa y se debe seleccionar la opción Start reasoner como se muestra en la figura 5.1. Cada vez que se realice un cambio y se desee obtener la versión deducida de la ontología se ingresa al mismo menú y se pulsa sobre la opción Synchronize Reasoner. Con el razonador activo es posible realizar la comparación entre el modelo cargado y el modelo deducido comparando los resultados que aparecen en las pestañas Class hierarchy y Class Hierarchy(inferred) ubicadas en la pestaña de trabajo “Entities” Fuente propia.

Figura 5.29 Menú para iniciar el razonador de Protégé En la figura 5.2 se observa la herencia de objetos que Protége ha deducido a través Figura 5.1: Menú para iniciar el razonador de Protégé. de la información cargada en él. En este caso, se muestra un error intencional en donde el software ha inferido que el concepto actor hereda del concepto actividad. Durante el desarrollo de la prueba se encontraron varias inconsistencias que permitieron realimentar el proceso de conceptualización. Al final del proceso se pudo comprobar que la ontología, en cuanto a la taxonomía era coherente.

5. Validación y resultados obtenidos

109

Figura 5.2: Incoherencia del modelo. Fuente propia

Figura 5.30 Comparación de las taxonomías Fuente propia. Figura 5.3: Comparación de las taxonomías. En la figura 5.3 se puede apreciar el proceso exitoso de comparación. La ventana de la izquierda representa la taxonomía ingresada, la ventana de la derecha representa la taxonomía deducida. Se observa que las dos estructuras son similares, lo cual indica que la información de la conceptualización en cuanto a taxonomía es coherente. La segunda prueba se hace de manera visual usando OWLwiz y Ontograf. Por medio de estas dos herramientas es posible visualizar si las relaciones que el sistema infiere coinciden con las relaciones especificadas. En primer lugar se validará la ontología con OWLwiz, el cual sirve para observar gráficamente las relaciones taxonómicas de los conceptos tal como se muestra en la

110

5.1 Resultados generales

figura 5.4.

Figura 5.31 Representación de la taxonomía con OWLwiz Fuente propia Figura 5.4: Representación de la taxonomía con OWLwiz. La validación realizada es similar a la efectuada en la prueba anterior. Esta es una alternativa muy poderosa en la cual se puede ver fácilmente las relaciones taxonómicas. El resultado fue similar a la prueba anterior de coherencia, el modelo deducido representa fielmente la información agregada por el diseñador. El proceso de validación de coherencia de las relaciones se deja para la sección “Caso de estudio” en este mismo capítulo.

5.2.5

Extensibilidad

El criterio de extensibilidad se refiere a la posibilidad de especializar la ontología en un proceso que requiera la inclusión de nuevos conceptos. En este sentido se tuvieron en cuenta las siguientes consideraciones:

5. Validación y resultados obtenidos

111



La primera fue la definición de la mayoría de relaciones taxonómicas como disjuntas, esto significa que es posible que existan otras subclases no consideradas en el diseño inicial.



La segunda fue la consideración de algunos conceptos básicos dentro de la lista de términos. La definición de términos como atributo, evento, actuador, sensor, entre otros permiten disponer de una base para la inclusión nuevos conceptos a partir de ellos.

Aunque en principio se tuvo presente el criterio en el diseño, el cumplimiento de este puede ser muy subjetivo. Depende del nuevo dominio especializado en el cual se quiera usar y la similitud que tenga con respecto a la teoría actual de HMS-UP.

5.2.6

Claridad

Este criterio se refiere a una definición precisa y fácil de comprender de cada uno de los términos de la ontología. Se ha tenido especial cuidado de realizar definiciones convenientes para el usuario promedio, es decir, usuarios con algún conocimiento en los sistemas de manufactura pero no especializado en HMS-UP. En algunos casos, la definición de los conceptos requiere de otros conceptos más generales que podrían crear una confusión. En estas situaciones se ha optado por definir también dichos conceptos para disminuir la falta precisión.

5.2.7

Mínimo compromiso ontológico y codificación parcializada.

Los dos criterios tiene un enfoque similar: definir una ontología que pueda ser usada de manera general en áreas de conocimiento sobre los sistemas de manufactura. La ontología diseñada tiene una ventaja sobre el cumplimiento de estos dos criterios. Como el proceso de creación se hizo sobre la teoría de los sistemas holónicos basados en manufactura no contiene sesgos en cuanto a los tipos de información ni a una tecnología particular. Además, la descripción de cada una de las partes de la

112

5.1 Resultados generales

ontología se hizo por medio de lenguaje natural y comprensible. Se puede concluir que en cuanto a los criterios de diseño para el desarrollo de la ontología se obtuvo lo siguiente: Criterio

Cumplimiento

Claridad

Cumple

Coherencia

Cumple

Extensibilidad

Cumplimiento condicionado a la situación

Compromiso ontológico codificación parcializada

y Cumple

Tabla 5.16 Resultado de la validación

5.2.8

Resultado de la validación conceptual

Los resultados obtenidos en cuanto a validación son satisfactorios, la conceptualización aumento el nivel de detalle de la teoría, y este detalle fue puesto en la formalización. Se considera que se alcanzó una ontología útil, válida y en el formato adecuado para su distribución. Al final los resultados entregados son: 

Conceptualización detallada del conocimiento del dominio descrito en el capítulo 3.



Ontología formalizada mediante el proceso descrito en el capítulo 4 y se entrega documento descriptivo en OWL para fácil distribución de los resultados.

Ficha Técnica Ontología

Nombre

Ontología HMS-UP

Tipo de ontología

Ontología de Aplicación

Metodología

Methontology

5. Validación y resultados obtenidos

Descripción

Ontología para la formalización de los conceptos de los sistemas holónicos de manufactura basados en el concepto de Unidad de Producción.

Framework de desarrollo

Protégé 4.2

Lenguaje de descripción

OWL

Validación

Correspondencia con la teoría de sistemas holónicos de manufactura o HMS-UP

113

Tabla 5.17 Ficha técnica final de la ontología

5.2.9

Validación modelo de referencia

En la anterior sección se realizó la validación de la parte conceptual del modelo de referencia. En la presente sección se realiza un trabajo que demuestra dos puntos importantes. El primero es que la conceptualización posee información suficiente para abarcar la integración empresarial, esto significa que el contenido del modelo es completo. En segundo lugar, se usará la guía de implementación para realizar una aproximación del caso de estudio a un proceso integrado, a través del seguimiento de las sugerencias técnicas que esta contiene. Descripción del proceso caso de estudio. La planta de producción permite la elaboración de sacos de fique con medidas de 70cm x 95 cm de largo. La materia prima fundamental son las hojas de Fique de la cual se extraen y procesan las fibras con las cuales se tejen los sacos. El proceso está se encuentra dividido en 9 etapas básicamente, tal como se muestra en la figura 5.4. El proceso pasa inicia a través de la adquisición de la materia prima, de las hojas de fique. Luego de tomar las fibras de la planta, éstas deben ser fermentadas para liberar las impurezas y luego puestas al sol para secarlas y alcanzar un tono amarillo. Una vez clasificadas las fibras de acuerdo a características técnicas es necesario realizar una “peinado” para separar las fibras entre sí. Con ésta

114

5.1 Resultados generales

materia ya se pueden trenzar las fibras para crear fibras más resistentes que luego serán confeccionadas para dar forma a los sacos de fique.

Figura 5.32 Cadena de valor proceso sacos de fique Una vez conocido el proceso de la construcción de sacos de fique se dispone a realizar el seguimiento de los pasos descritos en la guía de implementación y el conocimiento captura en la ontología para integrar el proceso caso de estudio. Para la validación se limitará el proceso a la etapa de tejido.

Fase 1 Integración horizontal Para la integración horizontal se debe conocer el proceso y los equipos del proceso. En la figura 5.5 se muestra la cadena de valor de la producción de sacos de fique. El siguiente paso es la identificación de las características de los equipos que lo componen. Equipo usado El equipo usado para conformar hilos de fibra de fique se denomina “Hiladora”. Usando la tabla de la guía de implementación se logra obtener la siguiente información:

5. Validación y resultados obtenidos

115

Característica ID Nombre Tipo

Descripción HIL01 Hiladora Equipo que permite unir las fibras de fique para realizar los hilos.

Operaciones[] Estado[]

OP01 En

proceso,

Espera,

Detenida,

Terminado Hilo a procesar Coeficiente de torsión

20 – 40 mts/hr 2 – 10 (Tpp)

Tabla 5.18 Descripción básica de equipo Hiladora

En este caso se detecta que el equipo puede realizar la operación OP01 y tiene dos rangos de operación mediantes los cuales puede ser configurado. Definir los métodos de producción La identificación de las operaciones que se pueden ejecutar en el sistema permite diseñar los diferentes métodos de producción o viceversa. Cada producto puede requerir una cierta cantidad de operaciones para poder ser fabricado, o puede requerir las mismas operaciones pero con una secuencia diferente. El método de producción contiene más que solo un tipo de operaciones, también contienen los parámetros de entrada y salida de cada equipo para que realicen su trabajo, y el tipo de materia prima requerida. De la información especificada en el modelo solo es posible inferir el punto de operación. A manera de ejemplo se define un método de producción simple que podría existir de acuerdo a las características de los equipos que posee el proceso. La propuesta de la guía de implementación es realizar un archivo de XML para la descripción, sin

116

5.1 Resultados generales

embargo para efectos de representación se realiza a través de un resumen en una tabla.

ID Producto

Id

Nombre de operación

Descripción

Parámetro

HILO01

OP01 Hilar

Construcción de los Largo de hilo hilos de fique

HILO02

OP01 Hilar

Construcción de los Coeficiente hilos de fique torsión

Punto de operación 30 de

4.5

Tabla 5.19 Método de producción simplificado

En la tabla 5.5 se ha resumido un método de producción, resaltando información relevante para el proceso de integración horizontal. En este caso se puede apreciar que el método tiene asociado un producción “ID producto”, el método está describiendo una operación y dos parámetros que son necesarios configurar. En este caso los parámetros que contiene el método de producción pueden ser ejecutados por el equipo descrito anteriormente, teniendo en cuenta los puntos de operación solicitados. Igualmente, una modificación en cualquiera de los puntos de operación podría resultar en las especificaciones de un nuevo producto.

Establecer el tipo de control

En este aspecto, en la guía se sugiere que los sistemas de control deben tener capacidades de configurarse a través de las redes de información. La selección del controlador es un trabajo que depende del tipo de equipo, variables a medir y las necesidades de control. En la fase de integración se realiza la información detallada de cada uno de los equipos que conforman el proceso. La anterior descripción se ha limitado a identificar el equipo, relacionarlo con una operación de un método de producción que tiene relación con un producto. Pudiera ser necesario establecer el tipo de actuadores,

5. Validación y resultados obtenidos

117

sensores, la interacción con los almacenes, etc.

Fase 2: Descripción del modelo de negocio

En esta fase se debe identificar la secuencia de operaciones que se pueden realizar en el sistema. Este tipo de comportamiento es modelado a través de una red de petri para establecer, de manera precisa, el comportamiento posible del sistema. Adicional a este modelo es posible agregar la información sobre límites de operación del sistema para realizar la supervisión del sistema. En la guía de implementación se describen 9 pasos para la identificación de la información que se debería incluir en el modelo de eventos discretos. Paso 1: Para el caso del hilado las acciones del operador no se encuentra en el funcionamiento normal. Para los eventos de falla, el operador humano es quien corrige las fallas en una operación y quien reinicia el proceso. Paso 2: Las variable de estado de la etapa se puede considerar como el coeficiente de torsión del hilo. Ésta representa una característica importante que se va a controlar durante el proceso. Paso 3: La identificación de la secuencia de arranque y parada, en principio, es bastante simple: El inicio luego de cargar la materia prima adecuada, una falla durante el proceso, el reinicio luego de una falla y el evento que indica que el proceso ha terminado satisfactoriamente. Paso 4: Las contingencias en el sistema no están identificadas en el proceso. Se agrega una acción de contingencia como parado de emergencia. Paso 5: Las condiciones que determinan una falla en el sistema se puede agregar como la falta de materia prima y una falla (general) que impide la ejecución del sistema.

118

5.1 Resultados generales

Paso 6: Los rangos de operación del sistema han sido indicados en las características de los equipos. El equipo Hiladora tiene dos parámetros configurados, pero solo uno, el coeficiente de torsión, se considera importante para la calidad del producto. En este caso se pueden establecer un nivel mínimo y máximo de la variable a manera de alarma en el sistema. Los pasos 7, 8 y 9 no se aplican por ser un proceso muy pequeño (paso 9) y por tener poca información para desarrollar los otros (7,8). Al final del análisis se encuentra la siguiente información. Operaciones: Hilar, Parada de emergencia. Eventos: Arranque, Falla, Reinicio, Termino, Falta de materia prima, Operación cercana al máximo o mínimo permitido. Estado: Coeficiente de torsión. Con esta información ya es posible crear una red de petri para el objeto de negocio hilar. Es importante aclarar que se debe realizar un modelo por cada uno de los objetos de negocio, éstos después se podrán unir para dar forma al modelo total del proceso.

Fase 3: Integración Vertical. En esta fase es importante asegurar que el sistema de producción cuenta con una forma de comunicar las necesidades de la empresa, a través de órdenes de producción, hacia la planta. En este aspecto la ontología cuenta con los conceptos orden de producción, meta, negociación, actividad de coordinación, administración del método de producción así como la planeación y programación de la producción. En primer lugar una orden de producción hacia la holarquía debe poder comunicar de manera precisa la necesidad de la empresa. La representación de la orden de producción se realiza de manera básica a través del siguiente registro.

5. Validación y resultados obtenidos

ID_ORDEN

119

ID_PRODUCTO

1

HILO01

CANTIDAD 400

FECHA ENTREGA 15/05/2014

Tabla 5.20 Orden de producción

Con este registro la holarquía puede determinar que existe una orden de producción, por otro lado el ID del producto permite conocer la cantidad de operaciones que necesita para su construcción a través del método de producción. El mismo método de producción define la cantidad de materia prima necesaria, de esta manera la UP puede establecer la cantidad de producto solicitado que puede ser construido. Finalmente la unidad de producción debe establecer si tiene disponibilidad de producción para entregar el producto en el tiempo solicitado. Una vez que la UP procesa la orden y determina que tiene la capacidad de ejecutar la orden, ésta envía una respuesta al nivel superior de la holarquía desde donde vino la orden indicando la siguiente información.

ID_UP

CANTIDAD

OPERACIONE FECHA INICIO S

UP01

300

OP01,OP02

TIEMPO DE PRODUCCIÓN

16/05/2014

2 DÍAS

Tabla 5.21 Respuesta

Esta respuesta por parte de la UP será procesada para finalmente aceptarla e iniciar el trabajo de la UP o rechazarla. Este tipo de proceso se realizaría por cada una de las unidades de producción de la holarquía, hasta cubrir la totalidad de la orden, en términos de cantidad de operaciones y producto, e iniciar el proceso a través de una holarquía configurada específicamente para el cumplimiento de la orden de producción.

120

5.1 Resultados generales

En la figura 5.6 se muestra el flujo de información que se realiza en la UP y los niveles superiores de la holarquía. En ella, se muestra la información a manera de registros relacionados a través de identificadores para el producto, método de producción, orden de producción, unidad de producción, materiales, operaciones y los equipos que lo pueden realizar, la información relacionado acerca más el modelo de referencia a un sistema implementado y funcional, ya que se está asegurando que los objetos del, el flujo de información y las relaciones existen físicamente.

Figura 5.33 Registro de la información de la unidad de producción Fuente Propia

5.2.10 Resultado validación caso de estudio Luego del seguimiento de la guía de implementación para implementar en un

5. Validación y resultados obtenidos

121

proceso el contenido de la ontología se advierte que el modelo de referencia cumple con las necesidades básicas de un sistema integrado. A continuación se realiza una lista con la descripción de los resultados obtenidos:

El sistema modelado tiene información relevante sobre los equipos que pertenecen al proceso de producción. De esta manera es posible determinar qué tipo de operaciones de operaciones son físicamente posibles de realizar, y por ende que tipo de productos.

La identificación del tipo de equipos permite una adecuada selección del tipo de control a realizar y los dispositivos necesarios para ejecutarlo.

La descripción de cada objeto de negocio en términos de eventos y operaciones permite que existan dispositivos como autómatas que pueden supervisar que el proceso se desarrolla con normalidad dentro de los parámetros especificados.

Una UP convierte en meta una orden de producción realizando una negociación, mediante la coordinación, generando así cambios en su cronograma a través de la planeación y programación de la producción.

La unidad de producción tiene la posibilidad de utilizar el mismo mecanismo de configuración del proceso a través de la creación de varios métodos de producción, los cuales deben poder ser administrados por la UP.

Finalmente, se describe básicamente la información que sería necesario gestionar en una base de datos para que las UP puedan realizar cruces de datos necesarios para tener un proceso integrado que podría ser desarrollado e incluso simulado.

122

5.1 Resultados generales

Capítulo 6 Conclusiones y recomendaciones La creación de la ontología ha sido exitosa. Se ha creado una representación del sistema holónico de manufactura basado en la unidad de producción (HMS-UP) que muestra claramente la dinámica del proceso y permite inferir conocimiento como se pudo constatar en el capítulo anterior. Durante el desarrollo de la ontología, se pudo comprobar que la búsqueda de precisión en la representación de la información del dominio hizo necesaria la definición de algunos conceptos no considerados inicialmente. Gradualmente fue necesario integrar nuevos conceptos y relaciones a la conceptualización, demostrando que el mismo proceso de desarrollo de la ontología crea la necesidad de especificar con más detalle la teoría, además de definir algunas situaciones que, aunque se encuentran claras en la teoría, la ontología las muestra de manera detallada. Los resultados obtenidos prueban que el seguimiento de la metodología Methontology es adecuada para emprender la definición de una ontología desde cero. Hecho que confirma, aún más, la gran importancia de esta herramienta en el campo de la representación del conocimiento de un dominio de interés. También se desataca a Protégé como una herramienta muy útil en el proceso de formalización de la ontología. Se recomienda en futuros procesos de creación de ontologías realizar el trabajo con el razonador activado y comparar constantemente los modelos deducidos por este, es más una práctica de depuración que de validación.

En el presente trabajo se definió a OWL como el lenguaje de representación de la ontología. Sin embargo, Protégé es una herramienta muy poderosa y con un simple cambio de configuración se puede alterar el tipo de documento a exportar. Ante dicha circunstancia la selección de un tipo de lenguaje de representación desde el principio de la ontología disminuye en importancia. A través del cumplimiento de las fases definidas en el documento de especificación los interesados en HMS-UP tienen un punto de partida que permite relacionar la teoría con un proceso real. El conjunto de especificaciones agrupadas en fases conforman, junto con la ontología, el modelo de referencia planteado como objetivo principal del proyecto. Por otra parte se considera que la similaridad de la solución para desarrollar un modelo de referencia como el desarrollado en Agent System Reference Modelo [61] es un componente que da más valor al trabajo realizado en este proyecto. Finalmente se resalta la completitud de los objetivos propuestos al principio del trabajo de grado. El primero de ellos era la consolidación de la teoría sobre sistemas holónicos de manufactura basados en la unidad de producción, y se cumplió por medio de la definición de cada uno de los conceptos y reglas binarias creadas para cumplir con la descripción de la ontología. En segundo lugar se propuso como objetivo la creación de una ontología para HMS-UP. Tal como lo demuestran el capítulo 3 y 4, este objetivo también se ha cumplido. Finalmente se define como satisfactoria la inclusión del documento de especificación como una guía de implementación que define que el modelo de referencia es apto para iniciar desde cero en la implementación de un sistema integrado basado en UP. De igual manera se demostró que el sistema obtenido con los conceptos de la ontología y la guía de aplicación cumple con los requisitos de un modelo integrado en términos generales. Como trabajo futuro se define aumentar el detalle de la guía de especificación para una implementación más directa del modelo HMS-UP. La ontología es una propuesta y como tal, está abierta a cambios y validaciones por parte de la comunidad en general.

124

Bibliografía [1]

[2] [3]

R. Babiceanu, “Holonic-Based Control System for Automated Material Handling Systems.” Virginia Polytechnic Institute and State University, 2005. S. Rodriguez, N. Gaud, and V. Hilaired, “Modeling Holonic System with a Organizational Approach.” 2005. O. Rojas and E. Chacon, “Conceptos generales de procesos batch desde el enfoque de sistemas holónicos de manufactura.” Universidad de los Andes, 2011.

[4]

[5] [6] [7] [8]

[9] [10] [11] [12]

[13] [14]

J. . Christensen, “Holonic manufacturing systems: initial architecture and standards directions.” First European Conference on Holonic Manufacturing Systems, Alemania, 1994. M. Fletcher, “Holonic Manufacturing Systems some Escenarios and issues.” Agent Oriented Software Ltd, 2003. V. Botti and A. Giret, “Aplicaciones industriales de los sistemas multiagentes.” Universidad Politécnica de Madrid, 1998. A. Giret, “Anemona: Una metodología multi-agente para sistemas holónicos de fabricación.” Universidad Politecnica de Valencia, 2005. P. Verstraete, B. Saint, K. Hadeli, P. Valckeanaers, and Van brussel Hendrik, “On applying the PROSA reference architecture in multi-agent manufacturing control applications.” Universidad de Leuven, 2007. D. Panescu, G. Varvara, and M. Sutu, “On holonic manufacturing systems design and implementation.” 2007. H. Van Brussel, P. Valckenaers, L. Bogaerts, and P. Peeters, “Reference architecture for holonic manufacturing system.” Univsersidad de Leuven, 1998. P. Leitao and F. Restivo, “ADACOR: A holonic architecture for agile and adaptative manufacturing control.” Computers in Industry 57, 2006. P. Leitao, A. Colombo, and F. Restivo, “Formal Specification of ADACOR Holonic Control System Coordination Models.” 44th IEEE Conference on Decision and Control, 2005. P. Leitao, A. Colombo, and F. Restivo, “On approach to the formal specification on holonic control systems.” Polytechnic Institute of Bragan ̧a, 2004. E. Chacón, I. Bembel, D. Rivero, and J. Cardillo, “Embedded holonics systems

[15] [16] [17]

[18] [19]

[20]

[21] [22]

[23] [24] [25]

[26] [27]

[28]

in production process: holonic unit of production.” Revista Técnica de la Facultad de Ingeniería Vol 32, Universidad del Zulia. Venezuela, 2009. A. Torrealba, “Desarrollo de un sistema de supervision para sistemas de producción continua.” Universidad de Los Andes. Venezuela, 2005. E. Chacon, “A way to implement a supervisor en holonic production.” 15th Triennial World Congress. España, 2002. G. Zapata, J. Cardillo, and E. Chacón, “Aportes Metodológicos para el Diseño de Sistemas de Supervisión de Procesos Continuos.” Información Tecnológica. Vol 22. Chile, 2010. “HOLOMAS 2013,” 6th International Conference on Industrial Applications of Holonic and Multi-Agent Systems, 2013. . F. Maturana and R. Staron, “Holonic Multi-agent System for Real Time Simulation of Control Systems.” 5th International Conference on Industrial Applications of Holonic and Multi-Agent Systems, 2011. M. Cap and J. Vorkinek, “Communication- and Computation- Bounded Agents in Multi-Agent Simulations.” 5th International Conference on Industrial Applications of Holonic and Multi-Agent Systems, 2011. C. Ciufuedan and C. Fillote, “Artificial Social Models for Holonic Systems.” Universidad “Stephan cel Mare”. Rumania, 2011. O. Roulet-Dubonnet and Y. Pai, “An Application of the Holonic Manufacturing System to a Flexible Assembly Cell.” Holonic and Multi-Agent Systems for Manufacturing Lecture Notes in Computer Science Volume 6867, 2011. J. Philips and P. Valckeanaers, “PROSA and Delegate MAS in Robotics.” Universidad de Leuven, 2011. Instituo Nacional de estandares y Tecnología, “Process Specification Language- PSL,” http://www.mel.nist.gov/psl/ontology.html, 2007. . A. Arboleda, “Transformación automática de requisitos representados en esquemas preconceptuales a modelos de interacción de sistemas holónicos.” Universidad Nacional. Colombia, 2010. R. Jaitly, “Implementation of Data Integration usign Distributed Systems: a Review.” Amritsar College of Engineering & Technology, 2011. J. Montilva, E. Chacón, C. Arévalo, and G. Urdaneta, “Automatizacion de Sistemas e Integración de Software en Empresas de Producción.” VI Congreso Automatización y Control. Venezuela, 2003. R. Agrewal, E. Alexandre, and R. Srikant, “Information Sharing Across Private 126

[29] [30] [31] [32] [33] [34]

[35] [36] [37] [38] [39]

[40] [41]

[42] [43]

[44]

Databases.” IBM Almaden Research Center, 2003. G. Hohpe, “Enterprise Integration Patterns.” PLoP 2002, 2002. E. Curry, “Message-Oriented Middleware.” National University of Ireland, Galway, Ireland, 2004. G. Cuoloris, “Sistemas Distribuidos, Conceptos y diseño.” Pearson AddisonWesley, 2001. J. L. Poza, “Revisión de los Sistemas de Comunicaciones más empleados en Control Distribuido.” Univsersidad Politécnica de Valencia. España, 2009. B. Farrimond, L. Parkinson, and F. Pogson, “Modeling History with XML.” DRH 2001, 2001. R. Kyusakov, H. Mäkitaavola, J. Delsing, and J. Eliasson, “Efficient XML Interchange in Factory Automation Systems.” University of Tecnology Lulea, 2011. B. Chaib-draa and F. Dignum, “Trends in agent communication language.” Computational Intelligence, Volume 18, Number 2, 2002. L. Amgoud, N. Maudet, and S. Parsons, “An Argumentation-based Semantics for Agent Communication Languages.” 2003. V. Vasudevan, “Comparing agent communication languages.” Object Services and Consulting, 1998. T. Gurber, “The Knowledge sharing effort public library.” Univsersidad de Stanford. EEUU., 1994. N. Guarino and P. Giaretta, “Ontologies and Knowledge Bases, towards a Terminological Clarification.” National Research Council, LADSEB-CNR. Italia, 1996. T. Gruber, “Toward Principles for the Design of Ontologies Used for Knowledge Sharing.” Stanford Knowledge Systems Laboratory, 1993. O. Corcho, M. Fernandez-Lopez, and A. Gomez-Perez, “Methodologies, tools and languages for building ontologies. Where is their meeting point?” Universidad Politécnica de Madrid. España, 2002. M. Al-Qasem, “The State of the Arts in the Ontologies for Legacy Systems.” DAKE Centre Keele University, 1995. R. Esmeralda and H. Nuñez, “Ontologías: Componentes, metodologías, lenguajes, herramienta y aplicaciones.” Universidad Central de Venezuela, 2007. Rational Software, “Rational Unified Process: Best Practice to sotftware 127

[45] [46] [47]

[48] [49] [50] [51]

[52] [53] [54] [55] [56] [57]

[58]

[59]

development teams.” Best Practices for Software development Teams, 2000. F. Mariano, G.-P. Asunción, and N. Juristo, “Methontology: From ontological art towards ontological engineering.” AAAI Technical Repor, 1997. Ontotext, “On-toKnowledge,” 2012. [Online]. Available: http://www.ontotext.com/research/otk. [Accessed: 24-Oct-2012]. F. Dieter, H. Frank, K. Michel, and A. Hans, “On-To-Knowledge: Ontologybased Tools for Knowledge Management.” Univsersidad Libre de Amsterdam. Holanda, 2000. R. Stephen and L. Douglas, “Mapping Ontologies into Cyc.” Cycorp. EEUU, 2001. F.-L. Mariano and G.-P. Asunción, “Overview and analysis of methodologies for building ontologies.” Univsersidad Politécnica de Madrid. España, 2002. U. Mike and K. Martin, “Towards a Methodology for Building Ontologies.” Univsersidad de Edimburgo. Reino Unido, 1995. S. Xiaomeng and I. Lars, “Using a Semiotic Framework for a Comparative Study of Ontology Languages and Tools.” Univsersidad Noruega de Ciencia y Tecnología., 2005. M. Deborah and F. Richards, “DAML+OIL: The ontology language for semantic web.” IEEE INTELLIGENT SYSTEMS, 2002. W3C, “OWL 2 Web Ontology Language Structural Specification and Functional-Style Syntax.” 2009. H. Florez, “Construcción de ontologías OWL.” Revista Vinculos 7. Colombia, 2007. “Ontosaurus,” Ontasaurus: Loom Web Browser. [Online]. Available: http://www.isi.edu/isd/ontosaurus.html. [Accessed: 26-Oct-2012]. D. John, “Tadzebao and WebOnto: discussing, browsing, and editing ontologies on the Web.” The open university. Reino Unido, 1998. A. Julio, C. Oscar, F.-L. Mariano, and G.-P. Asunción, “WebODE: a Scalable Workbench for Ontological Engineering.” Univsersidad Politécnica de Madrid. España, 2000. E. Chacon, J. M. Velasco, and O. Rojas, “Principios de una metodología para integración empresarial bajo un enfoque holónico.” Universidad de Los Andes. Venezuela, 2007. E. Chacón, I. Rondón, and O. Rojas, “Aplicación del Estándar ISA88 en el Modelado del Proceso de Producción de Azúcar en un Central Azucarero.” 7a 128

[60]

[61]

Confenrencia latinoamericana y del Caribe para Ingeniería y Tecnología, 2009. L. Quintero, G. Zapata, D. Ovalle y E. Chacón. “Comportamiento Autónomo del Holón Recurso basado en la Agenda de Producción” . Revista avances en Sistemas e Informática. 2008. I. Mayk and W. Regli. “Agent Systems Reference Model Release Versión 1.0a”. Universidad Drexel. 2006.

129