Embed Size (px)
Citation preview
TESIS
DOCTOR EN
MANUFACTURA AVANZADA
PRESENTA
M. en C. ISAÍAS SIMÓN MARMOLEJO
CIUDAD SAHAGÚN, HIDALGO, 13 DE OCTUBRE DE 2017.
MODELO DE CONOCIMIENTO EN SISTEMAS DE
MANUFACTURA EMPLEANDO EL PARADIGMA
HOLÓNICO
PARA OBTENER EL GRADO DE
ASESOR ACADÉMICO
M. en C. ISAÍAS SIMÓN MARMOLEJO
CIUDAD SAHAGÚN, HIDALGO, 13 DE OCTUBRE DE 2017.
MODELO DE CONOCIMIENTO EN SISTEMAS DE
MANUFACTURA EMPLEANDO EL PARADIGMA
HOLÓNICO
DR. LUIS ENRIQUE RAMOS VELASCO
ASESOR EN PLANTA
DR. OMAR LÓPEZ ORTEGA
I
DEDICATORIA
Los resultados del presente trabajo de investigación, fruto del esfuerzo de tres años,
están dedicados a mis padres Mario Simón y Cristina Marmolejo por creer en mí y por
brindarme aportes invaluables que servirán para toda mi vida.
En especial lo dedico a Leticia Flores por ser una esposa llena de gracia, paciencia y
amor. A mi hijo Yohan y al pequeño bebé “Hakim”, porque han hecho de mi vida un
caminar de alegría y felicidad.
Y al más importante, a Dios por las bendiciones que ha dado a -mi familia- y a mi vida.
II
III
AGRADECIMIENTOS
En primer lugar, me gustaría agradecer sinceramente a mis asesores de tesis: asesor
académico Dr. Luis Enrique Ramos Velasco y asesor de planta Dr. Omar López Ortega,
por su acompañamiento profesional, sus esfuerzos y dedicación.
Después de un año de no haber enfocado correctamente el rumbo de mi investigación,
ellos con sus conocimientos y habilidades, su estilo de trabajo de cada uno, su paciencia
y motivación, han resultado de gran valor en mi formación como investigador. Cada
uno a su manera, ha sido capaz de ganarse mi respeto y admiración, así como sentirme
en deuda con ambos por todo el tiempo que duro la estancia de investigación en el
Área Académica de Computación y Electrónica (AACyE) de la Universidad Autónoma
del Estado de Hidalgo (UAEH).
De igual forma, agradezco el apoyo recibido del Programa para el Desarrollo Profesional
Docente, para el Tipo Superior (PRODEP), por la beca otorgada en el transcurso de la
investigación. A profesores, administrativos y asesores del Centro de Tecnología
Avanzada (CIATEQ) que con sus aportes fortalecieron este proyecto.
Mi respeto y admiración, al Exdirector de la Escuela Superior de Cd. Sahagún de la UAEH,
el Ing. Martín Ortiz Granillo y al Exsecretario Académico de la misma, el Lic. Mario
Vigueras Melo, por confiar en que la educación profesional es una buena forma de
buscar estándares de calidad en beneficio de los alumnos de una institución.
IV
V
RESUMEN
Los sistemas holónicos de manufactura son integrados por componentes capaces de
comportarse de una manera autónoma, cooperativa, auto-organizada y reconfigurable
para adoptar dinámicamente estructuras distintas en condiciones de operación
normales y de emergencia. Dichos componentes, llamados holones, cuentan con las
siguientes características: (1) una representación del conocimiento del sistema en el que
operan, (2) una unidad de control distribuido y descentralizado, y (3) un módulo de
coordinación. En este contexto la representación del conocimiento referido a un
dominio específico radica en su potencial para ser compartido entre personas o
software. Una ontología es propuesta como solución para que un holón pueda describir
el mundo y para resolver el problema de compartir conocimiento, puesto que las
ontologías hacen explícitos los supuestos del conocimiento que se trate.
A esto, el principal objeto de interés de la presente investigación es la concepción de
una ontología unificada en el dominio de manufactura la cual provee una estructura
taxonómica explícita y dotada de formalismo para un sistema holónico, que sea
reutilizable, escalable y que respete plenamente las especificaciones de la normatividad
internacional de agentes inteligentes. A diferencia de los modelos ontológicos
encontrados en la literatura, el esquema de representación del conocimiento propuesto
integra roles y comportamientos, mismos que son validados mediante un caso de estudio
de una celda de manufactura que se encuentra en la Universidad Autónoma del Estado
de Hidalgo, haciendo al final una comparación con otras ontologías reportadas. Del
caso de estudio y de la comparación se observa que una ontología es necesaria como
un repositorio para la organización correcta del conocimiento puesto que permite el uso
de un vocabulario común y normado, y admite un lenguaje de comunicación
transparente y específico, lo que deriva en protocolos de comunicación eficientes entre
holones de semántica bien definida, creando condiciones cruciales para la
comunicación, misma que servirá para alcanzar ambientes adecuados para la
formación de holarquías, mecanismos de negociación y colaboración.
VI
Como un segundo objetivo lo aquí descrito busca sentar las bases que den pie a seguir
avanzando en modelos de acción complejos para cada holón u holarquía que cubran
las expectativas necesarias en el control de los sistemas de manufactura. Un paso difícil
en el desarrollo de una estructura holónica es crear un modelo operativo, de
negociación, con capacidad en actividades administrativas para la gestión de recursos,
y modelos que brinden a los recursos de producción la capacidad de reactividad ante
eventos inesperados, temas de interés futuros en la investigación.
VII
PUBLICACIONES
Como frutos del trabajo en el proyecto de investigación, se presenta los siguientes
productos:
Congreso internacional
Simón-Marmolejo, I.; López-Ortega, O.; Ramos-Velasco L.E. Desarrollo de una
Ontología de Acuerdo con el Paradigma de Sistemas Holónicos de Manufactura.
Engineering Innovations for Global Sustainability: Proceedings of the 14th Latin
American and Caribbean Conference for Engineering and Technology, Refereed
Paper: #328. 2016.
http://www.laccei.org/LACCEI2016-SanJose/meta/RP328.html
Revista
Simón-Marmolejo, I.; López-Ortega, O.; Ramos-Velasco, L.E.; Ortiz-Domínguez, M.
Ontología Unificada para un Sistema Holónico de Manufactura. RIAI - Revista
Iberoamericana de Automática e Informática Industrial. Elsevier B.V, factor de
impacto: 0.500. Estado: Aceptado. 2017.
https://doi.org/10.4995/riai.2017.8851
Simón-Marmolejo Isaías, López-Ortega Omar, Ramos-Velasco Luis Enrique, Cruz
René. Progresos en los sistemas de manufactura inteligentes según el paradigma
holónico. Revista de Aplicaciones de la Ingeniería. ECORFAN, revista indexada y
arbitrada. Estado: Publicado. 2017. Pp. 61-76.
http://www.ecorfan.org/bolivia/researchjournals/Aplicaciones_de_la_Ingenieria/v
ol4num13/Revista_Aplicaciones_de_la_Ingenieria_V4_N13.pdf
Simón-Marmolejo, I.; López-Ortega, O.; Ramos-Velasco, L.E. Implementation of a
Holonic System in a Flexsim Manufacturing System. Computers in Industry. Elsevier
B.V, factor de impacto: 2.691. Estado: En proceso de redacción.
VIII
IX
ÍNDICE DE CONTENIDO
DEDICATORIA I
AGRADECIMIENTOS III
RESUMEN V
PUBLICACIONES VII
ÍNDICE DE CONTENIDO IX
ÍNDICE DE FIGURAS XII
ÍNDICE DE TABLAS XIII
GLOSARIO DE TÉRMINOS XV
1. MOTIVACIÓN DE LA INVESTIGACIÓN 1
1.1 INTRODUCCIÓN 1
1.2 ANTECEDENTES 2
1.3 DEFINICIÓN DEL PROBLEMA 3
1.4 PROPUESTA DE SOLUCIÓN DEL PROBLEMA 4
1.5 JUSTIFICACIÓN 6
1.6 OBJETIVO GENERAL 7
1.7 OBJETIVOS ESPECÍFICOS 7
1.8 HIPÓTESIS 8
1.9 ALCANCES Y LIMITACIONES DE LA INVESTIGACIÓN 8
1.9.1. Alcances 8
1.9.2. Limitaciones 9
1.10 ORGANIZACIÓN DE LA TESIS 9
1.11 BIBLIOGRAFÍA 10
2. ESTADO DEL ARTE 13
2.1. INTRODUCCIÓN 13
2.1.1. Antecedentes en arquitecturas de enfoque holónico 14
2.2. NIVELES DE DISEÑO, DECISIÓN E INTERACCIÓN ENTRE HOLONES 17
2.3. COMUNICACIÓN INTER-HOLÓN 18
2.3.1. Importancia de la comunicación 18
X
2.3.2. Dispositivo de control de un holón ADACOR 20
2.4. COMENTARIOS 22
2.5. BIBLIOGRAFÍA 22
3. PROPUESTA DE ONTOLOGÍA UNIFICADA 27
3.1. INTRODUCCIÓN 27
3.2. ONTOLOGÍA UNIFICADA 28
3.2.1. Metodología empleada para el diseño de la ontología 29
3.2.2. Especificación 33
3.2.3. Conceptualización 33
3.2.4. Formalización 37
3.3. COMENTARIOS 52
3.4. BIBLIOGRAFÍA 52
4. RESULTADOS EXPERIMENTALES 55
4.1. INTRODUCCIÓN 56
4.2. CONDICIONES EXPERIMENTALES 56
4.3. IMPLEMENTACIÓN DE LA ONTOLOGÍA PROPUESTA 57
4.3.1. Celda de manufactura flexible de la UAEH 57
4.3.2. Integración y programación de ontología 60
4.4. PROTOCOLO DE COMUNICACIÓN 70
4.5. COMENTARIOS 75
4.6. DISCUSIÓN 76
4.7. BIBLIOGRAFÍA 77
5. ESTUDIO COMPARATIVO 79
5.1. INTRODUCCIÓN 79
5.2. ANÁLISIS COMPARATIVO DE ONTOLOGÍAS PARA HMS 80
5.1.1. Descripción de ontologías 80
5.1.2. Análisis comparativo 83
XI
5.3. COMENTARIOS 84
5.4. DISCUSIÓN 84
5.5. BIBLIOGRAFÍA 85
6. CONCLUSIONES Y TRABAJO A FUTURO 87
6.1. CONCLUSIONES 87
6.2. TRABAJO A FUTURO 88
XII
ÍNDICE DE FIGURAS
Figura 2.1. Diseño de un holón de bajo nivel [10]................................................................... 17
Figura 2.2. Modelo conceptual del Holón ADACOR [8]. ....................................................... 21
Figura 3.1. Methontology: Actividades en la concepción de una ontología [5, 6]. ......... 30
Figura 3.2. Conceptos. Orden superior. ................................................................................... 39
Figura 3.3. Ontología. Clases conceptuales de manufactura. ............................................ 40
Figura 3.4. Holones. Tipología de holones básicos y complementarios. ............................. 43
Figura 3.5. Holones básicos. Componentes y acciones. ....................................................... 44
Figura 3.6. Estado. Monitoreo por instantes de tiempo. ........................................................ 46
Figura 3.7. Un concepto es el atributo de otro concepto. ................................................... 47
Figura 4.1. Celda de manufactura de la UAEH. 1) Plano esquemático, 2) imagen de
toda la celda, y 3) imagen de la estación 2. .................................................................. 58
Figura 4.2. BOM. 1) MILL_TEST, 2) TURN_TST y 3) GAME-PRO ................................................... 59
Figura 4.3. Mapeo entre OWL y JADE para el modelo antológico propuesto [3]. ............ 61
Figura 4.4. Integración de la ontología en PROTÉGÉ ............................................................. 62
Figura 4.5. JADE. Programación de ontología. ....................................................................... 63
Figura 4.6. GUI. Definición de nuevos cliente y órdenes. ...................................................... 72
Figura 4.7. Protocolo de comunicación. AcquisitionHolon y OrderHolon. ........................ 73
XIII
ÍNDICE DE TABLAS
Tabla 2.1: Ontologías y protocolos de comunicación en arquitecturas holónicas. ......... 15
Tabla 3.1. Tipos de relaciones de los conceptos de la ontología con recursos del
dominio manufactura. ........................................................................................................ 37
Tabla 3.2. Ejemplo de clases y atributos. ................................................................................. 48
Tabla 4.1. Datos característicos de la materia prima, los componentes y los productos.
................................................................................................................................................ 60
Tabla 4.2. JADE. Código seccional del vocabulario usado. ................................................ 64
Tabla 4.3. JADE. Código seccional de la clase OntologyManufacturing. ........................ 65
Tabla 4.4. JADE. Código seccional del AcquisitionHolon. .................................................... 67
Tabla 4.5. JADE. Código seccional del OrderHolon. ............................................................. 68
Tabla 4.6. JADE. Método usado en el envío de mensajes. ................................................... 74
Tabla 5.1. Resumen de fortaleza y contribuciones de ontologías revisadas. .................... 82
Tabla 5.2. Evaluación de ontología propuesta. ..................................................................... 83
XIV
XV
GLOSARIO DE TÉRMINOS
Estado patológico
El término Patológico es de amplio uso en medicina y se refiere a algo que no es normal y pudiera estar siendo producido por
algún tipo de enfermedad. En manufactura, es el estado que guarda el sistema en condiciones normales de operación., 35
FIPA (Foundation for Intelligent Physical Agents)
Es una organización de normas “IEEE Computer Society” que promueve la tecnología basada en agentes y la interoperabilidad
de sus estándares con otras tecnologías. Las especificaciones de la FIPA representan una colección de estándares que
pretenden promover la interoperación de agentes heterogéneos y los servicios que pueden representar., 2
FIPA-ACL
Es actualmente el más usado y estudiado lengua de comunicación de agentes. Las principales características de FIPA-ACL son
la posibilidad de utilizar diferentes lenguajes de contenido y la gestión de conversaciones a través de protocolos de
interacción., 2
HMS (Sistemas Holónicos de Manufactura o Holonic Manufacturing Systems)
Es un paradigma que traduce los conceptos de los organismos vivos para las organizaciones sociales, el cual combina auto-
organización, jerarquías dinámicas y relaciones horizontales de un sistema de fabricación en particular y es constituido por
estructuras autónomas llamadas holones., 14
Perturbación
Una alteración de la función de un sistema biológico, inducida por mecanismos externos o internos., 36
UML (Unified Modelling Language)
Es un lenguaje gráfico para visualizar, especificar, construir y documentar un sistema. UML ofrece un estándar para describir
un "plano" del sistema (modelo), incluyendo aspectos conceptuales tales como procesos, funciones del sistema, y aspectos
concretos como expresiones de lenguajes de programación, esquemas de bases de datos y compuestos reciclados., 37
XVI
1. MOTIVACIÓN DE LA INVESTIGACIÓN
ESQUEMA DEL CAPÍTULO
1.1. INTRODUCCIÓN
1.2. ANTECEDENTES
1.3. DEFINICIÓN DEL PROBLEMA
1.4. PROPUESTA DE SOLUCIÓN DEL PROBLEMA
1.5. JUSTIFICACIÓN
1.6. OBJETIVO GENERAL
1.7. OBJETIVOS ESPECÍFICOS
1.8. HIPÓTESIS
1.9. ALCANCES Y LIMITACIONES DE LA INVESTIGACIÓN
1.10. ORGANIZACIÓN DE LA TESIS
1.11. BIBLIOGRAFÍA
El objetivo del presente capítulo es introducir al lector en los alcances, limitaciones y
novedades de la presente investigación.
1.1 INTRODUCCIÓN
La cuestión es
¿Qué tan importante es que un sistema de manufactura se adapte rápidamente a
las necesidades emergentes?
Esto ha dado lugar a la competencia y se ha convertido en uno de los elementos básicos
de la ventaja competitiva.
Esta tesis suscita el concepto de manufactura holónico desde el punto de vista
conceptual; describe, desarrolla y prueba un “Modelo Ontológico” para dar soporte a
la base de conocimiento (es aquí donde se registran los objetivos del holón, su estado y
1
Capítulo 1
2
la representación del mundo externo) e interacción entre holones característicos (de
nombre FIPA-ACL, Agent Communication Language definido por la Foundation for
Intelligent Physical Agents), y da pie al establecimiento de principios firmes para la
creación de un modelo de control inteligente, desarrollado según el paradigma
holónico, que puede ser programado para el control inteligente de sistemas de
manufactura flexibles. El modelo descrito, que contribuye con novedades recientes
sobre propuestas presentes en la literatura actual y que se describen en los siguientes
capítulos, busca muestrar los pasos del aspecto teórico de holones hacia la
implementación de una propuesta en particular.
Bajo estas circunstancias, la investigación es centralizada en la representación del
conocimiento referido al dominio manufactura el cual radica en su potencial para ser
compartido entre los integrantes de una holarquía, que dé pie al desarrollo de un sistema
de control inteligente holónico con capacidades de autonomía, cooperación e
inteligencia. Para ello, se ha propuesto una ontología unificada, la cual es simulada y
comparada en beneficio de una arquitectura holónica para una celda de manufactura
flexible que se encuentra en la Universidad Autónoma del Estado de Hidalgo.
En este orden y dirección de ideas, en el presente capítulo se plantean los antecedentes,
la definición y propuesta de la solución del problema, la justificación, objetivos e hipótesis
en un intento por introducir al lector en lo venidero.
1.2 ANTECEDENTES
Investigaciones recientes muestran que los sistemas de manufactura actuales enfrentan
a un entorno muy desafiante con dinámica y creciente complejidad de sus actividades
[1, 2], tratan con desafíos definidos por limitaciones altamente exigentes que van de la
fabricación en masa hacia la fabricación personalizada, nuevos métodos de
fabricación, precios cada vez más bajos, incremento en la calidad del producto y la
constante fluctuación de la demanda en el mercado [3, 4]. Asimismo, el avance tan
drástico en la tecnología provoca que la obsolescencia de productos y equipos sea un
hecho habitual [5], además de que esta nueva tecnología no sólo es cada vez más
compleja de controlar, sino que también presenta una serie de problemas de decisión,
MOTIVACIÓN DE LA INVESTIGACIÓN
3
por lo que a pesar de que el nuevo entorno ofrece nuevas capacidades también se
imponen nuevas restricciones en función de programación, que deben adaptarse en
consecuencia.
Es un hecho entonces que los sistemas de manufactura actuales, basados en estructuras
jerárquicas de control tradicionales y rígidas, ya no pueden hacer frente a estos
exigentes desafíos [6, 7], por lo que se requiere del uso de nuevos paradigmas de
producción que mejoren dichas limitaciones.
En este sentido, para responder de manera rápida y eficiente, nacen paradigmas
alternativos que proponen esquemas de gestión de la fabricación los cuales combinan
auto-organización, jerarquías dinámicas y relaciones horizontales [5]. Los Sistemas
Inteligentes de Manufactura (SIM), son capaces de proporcionar esta flexibilidad
incrementando el rendimiento. Pueden operar sistemas de fabricación altamente
complejos, así como diversos grados de funcionalidad de los productos, se pueden
mejorar los cambios de diseño de la manera más rápida posible para adaptarlos
fácilmente a los cambios en el mercado y satisfacer las necesidades del cliente, que son
como se dijo la mayor parte del tiempo, versátiles. En relación con esto último, los
avances en sistemas inteligentes de manufactura promueven el concepto de Sistemas
Holónicos de Manufactura (Holonic Manufacturing Systems, HMS) que establece una
línea de base para la fabricación de unidades autónomas, altamente flexibles, ágiles,
reutilizables y modulares. Es decir, estos sistemas están diseñados a través de módulos
autónomos, cooperativos, inteligentes, capaces de reconfigurar los sistemas de
manufactura de forma automática en respuesta a los nuevos requerimientos del sistema
o cambios ambientales [8].
Puntualmente la problemática de la presente descripción puede verse en el siguiente
apartado.
1.3 DEFINICIÓN DEL PROBLEMA
¿Cómo lograr que los sistemas de manufactura flexibles se adapten dinámicamente (en
términos de flexibilidad, agilidad y versatilidad) a las condiciones cambiantes de su
Capítulo 1
4
entorno; atendiendo nuevas necesidades (específicas e individuales) de los clientes,
fluctuación en la demanda e influencias del mercado, cambio en los planes de
producción, nueva tecnología y perturbaciones inesperadas afectivas a los recursos del
sistema?
Estos rápidos cambios en el ambiente, obligan a las empresas a mejorar el rendimiento
de sus operaciones en condiciones de incertidumbre. Para alcanzar niveles elevados de
competitividad, los sistemas de producción necesitan adaptarse a un ritmo cada vez
mayor tomando decisiones adecuadas y eficaces dentro de un sistema adaptable que
haga uso correcto de los recursos limitados. Un problema en particular que se presenta
en sistemas de manufactura avanzada es ¿cómo hacer que los recursos o entidades de
los sistemas se mantengan dinámicamente informados para actuar en consecuencia en
el logro de sus objetivos?
Con ello, nuevos paradigmas en sistemas de manufactura han surgido, de los cuales el
común denominador es la descentralización y distribución del potencial de
procesamiento, ejemplos de tales paradigmas son Sistemas de Manufactura
Reconfigurables [9], Sistemas de Múltiples Agentes [10], Sistemas de Manufactura
Biónicos [11], y algunos más recientes como los Sistemas de Producción Evolutivos [12] y
los sistemas holónicos [13].
Este trabajo de investigación se centra en los sistemas holónicos, tal como se presenta
en los siguientes apartados.
1.4 PROPUESTA DE SOLUCIÓN DEL PROBLEMA
En los sistemas en los que interviene la dimensión humana (por ejemplo: actividades
personales, vehículos, organizaciones, entre otros) cabe la posibilidad de que cada uno
de los componentes individuales del sistema tome cierta consciencia del fenómeno
emergente del que es causa parcial y que, como consecuencia de esta percepción
consciente, reaccione modificando su comportamiento. Este fenómeno —conocido
como emergencia de segundo orden [14], [15]— subyace tras la complejidad de
muchos sistemas que tienen atributos y comportamientos potencialmente complejos, los
MOTIVACIÓN DE LA INVESTIGACIÓN
5
cuales interactúan entre sí y con su medio ambiente a través del tiempo hacia el logro
de sus objetivos. Esto permite que el comportamiento de un agente dependa de los
estados actuales y pasados de su entorno, en lugar de actuar como un "guión". Este
comportamiento complejo puede ser descrito mediante el Modelado y Simulación
Basado en Agentes (ABMS, por sus siglas en inglés).
Esta situación fomenta la aparición de nuevos y novedosos paradigmas respectivos a
sistemas de producción que carecen de flexibilidad, adaptabilidad y robustez para
adoptar dinámicamente estructuras distintas en respuesta a sus necesidades o su
ambiente tanto en condiciones de operación normales como las caracterizadas por
fenómenos emergentes.
A este respecto y con la finalidad de crear nuevos modelos de producción sobre la base
de autonomía y cooperación, conceptos necesarios para crear un comportamiento
flexible y por lo tanto para adaptarse a las condiciones cambiantes de la producción,
ha sido posible diseñar e implementar entornos de manufactura inteligentes y distribuidos
[16]. En este entendido, los sistemas inteligentes de manufactura distribuida y los sistemas
de manufactura holónica se consideran importantes enfoques para el desarrollo de
sistemas de manufactura distribuidos [17].
Sin embargo, por la enorme cantidad de recursos y variables vinculadas a los sistemas
de producción, el desarrollo de un sistema de control inteligente de la producción
haciendo uso del paradigma de manufactura holónico resulta ser grande y complejo.
Razón por la que en primera instancia el proceso de desarrollo de un sistema semejante
tiene que ser guiado por el método científico y principios de alta ingeniería de software.
El presente proyecto de investigación discute el tema HMS; creando un modelo de
conocimiento sólido en dominio de sistemas de manufactura, como apoyo en la
tecnología de sistemas de múltiples agentes y en beneficio de la comunicación eficaz
entre diferentes holones característicos.
Capítulo 1
6
1.5 JUSTIFICACIÓN
Los Sistemas Holónicos de Manufactura (Holonic Manufacturing Systems, HMS) que
integra toda la gama de actividades de fabricación, desde la recepción de pedidos
hasta el diseño, producción y comercialización son creados y modificados
dinámicamente con el fin de adoptar estructuras distintas en condiciones de operación
normales y de emergencia (Botti and Giret, 2008). Este tipo de sistemas, son integrados
por holones capaces de comportarse de una manera autónoma, cooperativa, auto-
organizada y reconfigurable [18]. Los holones dotados de las habilidades antes
mencionadas, necesitan estar informados del conocimiento cambiante del ambiente
que los rodea y precisan de un mecanismo de comunicación para cooperar [5].
La cooperación hace necesarias estrategias de coordinación. La coordinación y la
auto-organización se implementan mediante clusters virtuales dinámicos. En un cluster
virtual dinámico los holones pueden participar dinámicamente en diferentes grupos
(holarquías) y pueden cooperar a través de dominios de cooperación. Los dominios de
cooperación se crean dinámicamente mediante la ejecución de los componentes
funcionales de los holones o su base de conocimiento [17].
Por consiguiente, en una holarquía son definidas reglas básicas para la cooperación y
coordinación entre holones, donde el componente comunicación, es responsable de la
interacción entre holones, soportando el intercambio de información local [19]. Con el
intercambio de información, los holones son capaces de conocer y manejar
descripciones del estado del mundo externo, las cuales consisten en una representación
dinámica del entorno, y de otros holones con quienes comparte dicho entorno [20].
A esto, la interoperabilidad en los HMS incrementa la necesidad de compartir ontologías
de manufactura apropiadas [21], que, sean acordadas previamente y que se expresen
en un lenguaje basado en la lógica que, en consecuencia, permitan hacer distinciones
detalladas, precisas, coherentes, sólidas y significativas entre las descripciones de la
representación del conocimiento [22].
Las ontologías son necesarias para definir los conceptos esenciales y el vocabulario
básico asociado con un dominio particular [20]. De esta forma, una ontología ofrece la
MOTIVACIÓN DE LA INVESTIGACIÓN
7
semántica y representación de datos que deriva de información sobre el
comportamiento de cada holón para la formación de holarquías, negociación y
colaboración [23]. El medio semántico es un contexto donde todos los conceptos
relevantes son importantes para la organización colaborativa. De esta manera, las
ontologías proporcionan un mapeo explícito entre conceptos (Uschold and Gruninger,
1996), haciendo posible que la representación formal del conocimiento facilite su
potencial para ser compartido e intercambiado [24].
Hechas las consideraciones anteriores, la presente investigación es centralizada en una
ontología unificada en beneficio del conocimiento dinámico del ambiente que rodea a
los holones y de la semántica de los mensajes intercambiados en un HMS, en la cual se
comentan características fundamentales y sus relaciones taxonómicas hasta la creación
de un ambiente virtual de protocolos de comunicación, donde un grupo de holones
locales interactúe con un “holón configuración” siendo estas entidades autónomas y
cooperantes en un entorno en el cual ciertas variables o fenómenos naturales
evolucionan siguiendo un enfoque de dinámica de sistemas.
1.6 OBJETIVO GENERAL
Haciendo uso de una metodología determinada, la propuesta busca especificar,
conceptualizar y formalizar una ontología unificada de dominio manufactura, para
garantizar los requisitos en el formalismo del modelo de conocimiento de un HMS y para
verificar que la semántica contenida es preservada durante el intercambio de mensajes
entre holones, garantizando un mayor grado de conciencia en estos últimos.
1.7 OBJETIVOS ESPECÍFICOS
A continuación, se dan los objetivos específicos concernientes a la presente
investigación:
1. Examinar arquitecturas holónicas y ontologías en dominio manufactura en la
literatura actual.
Capítulo 1
8
2. Formalizar una ontología unificada, reutilizable y escalable que dé soporte a los
holones inteligentes y respete plenamente las especificaciones FIPA (Foundation
for Intelligent Physical Agents).
3. Construir un sistema ejemplar de protocolos de comunicación basado en sistemas
de múltiples agentes bajo la plataforma JADE (Java Agent DEvelopment
framework).
4. Validar mediante la aplicación de un caso de estudio y comparar los resultados
de la ontología propuesta con respecto a otras reportadas en la literatura.
5. Sentar las bases para construir un sistema de control inteligente de manufactura
donde de manera virtual, un grupo de holones interaccionen en un entorno en el
que ciertas variables o fenómenos naturales evolucionen siguiendo un enfoque
de dinámica de sistemas.
1.8 HIPÓTESIS
Para validar la efectividad de la ontología propuesta, se ha planteado la siguiente
hipótesis:
Al tener una ontología sólida y holística se garantizará el uso de un vocabulario común,
representando coherentemente la base de conocimientos de cada holón y se mejorará
la interacción mediante protocolos de comunicación eficientes entre los elementos de
una holarquía que, a diferencia de los revisado en la literatura, intercambie, comparta y
recupere información, de manera simple, inequívoca y sin ambigüedades.
1.9 ALCANCES Y LIMITACIONES DE LA INVESTIGACIÓN
Los alcances de la investigación son generalizados en dos etapas, mientras que las
limitaciones se describen como un punto interesante por resolver:
1.9.1. Alcances
Primera etapa. La delimitación del proyecto radica en la especificación, concepción y
formalización de una ontología unificada en el dominio de manufactura para un sistema
holónico que permita describir el mundo de los holones de forma estandarizada, y que
MOTIVACIÓN DE LA INVESTIGACIÓN
9
a su vez resuelva el problema de compartir conocimiento de manera integral y
coherente en una holarquía, de manera simple, inequívoca y sin ambigüedades.
Segunda etapa. Para verificar y validar el modelo, se realizarán pruebas experimentales
de la ontología como otra contribución original del trabajo de investigación, donde se
compruebe que los holones en un entorno de manufactura distribuido están dotados de
una base de conocimientos, su estado y la representación dinámica del sistema en el
que habitan. El ejercicio admitirá protocolos de comunicación formales para integrar
holarquías en respuesta a condiciones de su entorno.
1.9.2. Limitaciones
La experimentación se efectúa de manera virtual debido a que no se cuenta con una
celda de manufactura real de software abierto que admita la experimentación con la
nueva arquitectura de control holónica.
1.10 ORGANIZACIÓN DE LA TESIS
A partir de lo antes descrito, el Capítulo 2 trata sobre el estudio del estado del arte de
investigaciones recientes sobre HMS y ontologías, con la intención de aportar a la
comunidad científica conceptos novedosos referidos a la presente propuesta. En el
Capítulo 3 es enfatizada la especificación, conceptualización y formalización de una
ontología unificada en dominio manufactura como una primera contribución en
beneficio de la base de conocimientos y la semántica de los mensajes intercambiados
entre holones. El Capítulo 4 muestra los resultados experimentales de la ontología
unificada como otra contribución original del trabajo de investigación. Para apreciar las
aportaciones a la investigación y validad la propuesta, el Capítulo 5 hace un estudio
comparativo de la ontología propuesta con la finalidad de ver las ventajas que se
presentan con respecto a otros trabajos de investigación, y se hace una discusión de los
resultados obtenidos y avances respectivos a la investigación. Finalmente, en el Capítulo
6, se dan las conclusiones y trabajos futuros de la investigación.
Capítulo 1
10
Por otro lado, al final de la tesis se integran cinco apéndices. El APÉNDICE A resalta
conceptos y definiciones sobresalientes de los sistemas holónicos. Por otro lado, el
APÉNDICE B busca hacer notar al lector la importancia que tiene una ontología para
dotar a los holones de conocimiento y admitir la comunicación entre los elementos de
una holarquía. El APÉNDICE C lleva al lector desde los sistemas de manufactura
tradicionales hasta la noción de sistemas holónicos. El APÉNDICE D ofrece al lector una
introducción general respecto a las características que definen a los agentes y las
tecnologías relacionadas, haciendo énfasis en los usos dados en aplicaciones de
carácter industrial. Y finalmente, el APÉNDICE E anexa los artículos que se tiene
concluidos a la fecha.
1.11 BIBLIOGRAFÍA
[1] LEITÃO, P.; RESTIVO, F. ADACOR: A Holonic architecture for agile and adaptive
manufacturing control. Computers in Industry. 2006, Vol. 57, No. 2, pp. 121–130.
[2] BRUSSEL, H.V.; WYNS, J.; VALCKENAERS, P.; BONGAERTS, L.; PEETERS, P. Reference
architecture for holonic manufacturing systems: PROSA. Computers in Industry.
1998, Vol. 37, No. 3, pp. 255–274.
[3] ELMARAGHY, H.; ALGEDDAWY, T.; AZAB, A; ELMARAGHY, W. Change in
manufacturing research and industrial challenges. En: ELMARAGHY H. A. (Eds.),
Enabling Manufacturing Competitiveness and Economic Sustainability. Montreal,
Canada: Springer Berlin Heidelberg, 2012, Vol. 1, pp. 2–9. ISBN 978-3-642-23859-8.
[4] WANG, F.; XU, D.; TAN, M.; WAN, Z. A Holonic architecture for reconfigurable
manufacturing systems. En: IEEE International Conference on Industrial
Technology. 2005, pp. 905–909.
[5] ARAUZOA, J. A.; DEL-OLMO-MARTÍNEZ, R; LAVIOS, J.J.; DE-BENITO-MARTÍN J.J.
Programación y control de sistemas de fabricación flexibles: un enfoque
holónico. RIAI - Revista Iberoamericana de Automática e Informática Industrial.
2015, Vol. 12, pp. 58–68.
[6] NAGEL, R.; DOVE, R.; GOLDMAN, S. 21st Century manufacturing enterprise
strategy. PREISS, Kenneth; LACOCCA Institute of Lehigh University; United States;
MOTIVACIÓN DE LA INVESTIGACIÓN
11
Department of Defense; Office of Managing Technology. LACOCCA Institute,
Lehigh University, Bethlehem, PA 18015, 1991. 58 p. ISBN: 0-9624866-3-9
[7] NATIONAL RESEARCH COUNSIL (U.S.), Visionary manufacturing challenges for
2020. National Academy Press, Washington, DC., 1998. 176 p. ISBN 0-309-06182-2
[8] BUSSMANN, S.; MCFARLANE, DC. Rationales for holonic manufacturing control. En:
BRUSSEL H. and VALCKENAERS P. (Eds.), Proceedings of the 2nd International
Workshop on Intelligent Manufacturing Systems. 1999, pp. 177–184.
[9] KOREN, Y.; HEISEL, U; JOVANE, F; MORIWAKI, T; PRITSCHOW, G; ULSOY, G.; VAN
BRUSSEL, H. Reconfigurable Manufacturing Systems. CIRP Annals - Manufacturing
Technology. 1999, Vol. 48, pp. 527–540.
[10] FERBER, J. Multi-Agent System: An Introduction to Distributed Artificial Intelligence.
Addison-Wesley Professional. The University of Michigan: Illustrated, 1999. 509 p.
ISBN: 0201360489.
[11] LEITÃO, P. Holonic Rationale and Bio-inspiration on Design of Complex Emergent
and Evolvable Systems. Hameurlain A et al. (Eds.). Transactions on Large-Scale
Data- & Knowledge-Centered Systems I, LNCS 5740. 2009, pp. 243–266.
[12] ONORI, M.; BARATA, J.; FREI, R. Evolvable Assembly Systems Basic Principles.
Information Technology for Balanced Manufacturing Systems. IFIP International
Federation for Information Processing. 2006, Vol. 220, pp. 317–328.
[13] BABICEANU, R.F.; CHEN, F.F. Development and applications of holonic
manufacturing systems: a survey. Journal of Intelligent Manufacturing. 2006, Vol.
No. 17, pp. 111–131.
[14] GILBERT, N. Varieties of Emergence. En: MACAL, C. & SALLACH, D. (Eds.), Social
Agents: Ecology, Exchange, and Evolution. Chicago: University of Chicago and
Argonne National Laboratory. Agent 2002 Conference, pp. 41–50.
[15] SQUAZZONI F. The Micro-Macro Link in Social Simulation. Sociologica. 2008, Vol. 1,
pp. 1–26.
[16] SHEN W.; NORRIE D. H. Agent-Based Systems for Intelligent Manufacturing: A State-
of-the- Art Survey. Knowledge and Information Systems, an International Journal.
1999, Vol.1, No. 2, pp. 129–156.
Capítulo 1
12
[17] BOTTI V.; GIRET, A. ANEMONA, A multi-agent methodology for holonic
manufacturing systems. Springer: Departamento de sistemas informáticos y
computación (DSIC). Valencia, Spain, 2008. 220 p. ISBN 978-1-84800-309-5
[18] CHRISTENSEN, J. Holonic Manufacturing Systems - Initial Architecture and
Standards Directions. At First European Conference on Holonic Manufacturing
Systems, Hannover, Germany, 1994.
[19] UNLAND, R. Industrial agents. En: LEITÃO, P., KARNOUSKOS, S. (Eds.), Industrial
agents: Emerging application of software agents in industry. 1st ed. Amsterdam,
Netherlands: Punithavathy Govindaradjane, 2015. p. 23–44. ISBN 978-0-12-800341-
1
[20] SHEN, W.; NORRIE, D.H.; BARTHÈS A. Multi-agent systems for concurrent intelligent
design and manufacturing. London EC4P 4EE: Taylor & Francis Group, 2001. pp.
30–47. ISBN 0-7484-0882-7
[21] BORGO, S; LEITÃO, P. Foundations for a Core Ontology of Manufacturing.
Ontology Handbook, Laboratory for Applied Ontology, ISTC-CNR, via Solteri 38,
38100 Trento, Italy. 2007, pp. 751–775.
[22] LUTHER, M. Ontologies. In: Berndt, H. (Ed.), Towards 4G Technologies. Services with
Initiative. John Wiley & Sons, Ltd., Chippenham, England, Ch. 7. , 2008, pp. 141–
164.
[23] KOPPENSTEINER, G.; GRABLER, R.; MILLER, D.; MERDAN, M. Virtual enterprises
based on multiagent systems. En: LEITÃO, P.; KARNOUSKOS, S. (Eds.), Industrial
agents: Emerging application of software agents in industry. 1st ed. Amsterdam,
Netherlands: Punithavathy Govindaradjane, 2015. p. 121–136. ISBN 978-0-12-
800341-1
[24] CORREA DA SILVA, F. S., et al. On the insufficiency of ontologies: problems in
knowledge sharing and alternative solution. Knowledge-Base Systems. 2002, Vol.
15, No. 3, pp. 147–167.
2. ESTADO DEL ARTE
ESQUEMA DEL CAPÍTULO
2.1 INTRODUCCIÓN
2.1.1 Antecedentes en arquitecturas de enfoque holónico
2.2 NIVELES DE DISEÑO, DECISIÓN E INTERACCIÓN ENTRE HOLONES
2.3 COMUNICACIÓN INTER-HOLÓN
2.3.1 Importancia de la comunicación
2.3.2 Dispositivo de control de un holón ADACOR
2.4 COMENTARIOS
2.5 BIBLIOGRAFÍA
En el Capítulo 1 se dio una introducción a las motivaciones de la presente investigación,
información necesaria para avanzar en el estado del arte del tema de interés. Por lo
tanto, el objetivo de este capítulo es introducir al lector en los antecedentes de las
arquitecturas de enfoque holónicas, la importancia de la comunicación entre holones y
el beneficio en la concepción de una ontología de manufactura.
2.1. INTRODUCCIÓN
Los principios (holones vistos como entidades constitutivas de ser tanto totalidad y parte
al mismo tiempo) que dan sustento a los sistemas holónicos fueron propuestos por
primera vez por Koestler en 1990 (más información se puede consultar en la Sección A.2.
del Apéndice A) [1]. Sin embargo, hoy en día el concepto está siendo empleado en el
área de manufactura inteligente, donde se define cada unidad de fabricación (por
ejemplo: productos, órdenes, recursos, etc.) con diferentes holones que pueden utilizar
distintos tipos de conocimiento [2, 3], a ello, el siguiente apartado amplia el tema.
2
Capítulo 2
14
2.1.1. Antecedentes en arquitecturas de enfoque holónico
Una arquitectura holónica es vista como una técnica para diseñar, proyectar y
construir HMS que buscan garantizar sistemas de control inteligentes con niveles
de rendimiento mínimo en el caso de circunstancias imprevistas [2], [3], [4], [5].
Ejemplos de éstas, que integran y representan una amplia gama de entidades
de un sistema de manufactura, el control empleado y la tecnología usada, son:
Product Resource Order Staff Architecture, “PROSA” [6]; Holonic Architecture for
Reconfigurable Manufacturing System, “RMS-HA” [7]; ADAptive holonic COntrol
aRchitecture for distributed manufacturing systems, “ADACOR” [8];
Manufacturing Execution Systems y conceptos holónicos, “MES-HMS”, [2];
“Arquitectura de Referencia en Capas” [9]; “Enfoque Holónico”, [10];
“ADACOR2” [11]; Estructura de sistemas de múltiples agentes organizada en dos
niveles y complementada con el concepto Radio Frequency Identification-
Information Management System, “MAS-DUO & RFID-IMS” [12]; Holonic Hybrid
Control Model, “H2CM” [13]; entre otras arquitecturas, las cuales proponen
novedosos métodos de toma de decisiones (Go-green Manufacturing Holons
[14]), comunicación (Wireless Holon Network (WHN) [15]) y control (Cyber-Physical
Systems (CPS) [16]).
En las propuestas de la literatura revisadas donde se hace notar la tecnología
empleada, los holones son construidos bajo tecnologías de sistemas de múltiples
agentes (Multi-Agent Systems, MAS) mediante un sistema middleware totalmente
distribuido de nombre “Java Agent DEvelopment framework” (JADE), donde es
posible la implementación de distintos tipos de holones como agentes JADE,
usando para ello la clase Agent proporcionada para tal efecto, librerías Java, y
en algunos casos se menciona que la propuesta es acorde con las
especificaciones de la “Foundation for Intelligent Physical Agents” (FIPA).
ESTADO DEL ARTE
15
Según se observa, para asegurar un correcto desempeño las aportaciones en
esta área en su mayoría son integradas por una arquitectura jerárquica y
heterárquica, además de que son inherentemente distribuidas y escalables
porque los holones pueden ser generados o eliminados si el sistema lo considera
necesario. Aquí, los holones se mantienen y modifican fácilmente según se
requiera, reaccionan rápidamente ante eventos inesperados tanto externos
como internos (disturbios) y se adaptan a las condiciones cambiantes (términos
también empleados por las referencias; [17] y [18]).
Respecto al uso de bases de conocimiento y a los protocolos de comunicación
empleados por los holones para compartir información, la Tabla 2.1 hace un
resumen analítico de las arquitecturas de interés para la investigación.
Tabla 2.1: Ontologías y protocolos de comunicación en arquitecturas holónicas.
Arquitectura
holónica
Ontologías Protocolos de Comunicación
PROSA [6], [19]. Ontologías simples. Protocolos de comunicación simples.
RMS-HA [7], [20]. Carece de una base de conocimientos
propia.
Es nula la descripción de protocolos de
comunicación.
ADACOR [8],
[3], [21].
En [21] se describe una de las ontologías
más completas y revisadas en la literatura.
Protocolos de comunicación simples.
MES-HMS [2]. Se muestra un diagrama de clases con
términos principales, sin dar más
información de bases de conocimiento.
No se dan detalles de protocolos de
comunicación.
Enfoque
Holónico [10].
No hay ontologías definidas. Se describen con suficiente detalle
ejemplos de protocolos de comunicación
adecuados entre holones básicos para
permitir acciones de negociación y
subastas.
ADACOR2 [11],
[22].
Pese a las aportaciones novedosas al
paradigma holónico y al amplio bagaje
de información tanto teórico como
práctico, el tema de ontologías no es
resaltado.
No hay información de protocolos de
comunicación.
Capítulo 2
16
H2CM [13]. Se introducen ontologías simples, sin
formalismo.
Protocolos de comunicación simples.
Go-green
manufacturing
holons [14].
Se hace hincapié en un modelo de toma
de decisiones que distingue entre
eficiencia y eficacia, pero no hay
información del conocimiento empleado.
No se menciona la necesidad de
comunicación entre holones.
WHN [15]. El sistema WHN tiene conocimiento
limitado. Puntualizando el tema como un
problema crítico para la investigación.
Utiliza un proceso de comunicación
inalámbrico.
La negociación se hace a través de un
mecanismo de nombre Call For Proposal
(CfP).
CPS [16]. No se menciona la base de
conocimientos usada.
Se hace mención del uso de la
comunicación/colaboración de los
agentes y de la comunicación inter-holón
sin dar más información.
A excepción de ADACOR, en las arquitecturas revisadas se carece de una
ontología de dominio manufactura que integre y clasifique de manera formal y
completa los conceptos de un sistema de producción en beneficio del sistema
holónico. Por otro lado, se indican las características y capacidades de los
holones, pero en la mayoría de los casos no se hace notar la base de
conocimientos necesaria para dotar a los holones con las características que los
definen. Respecto a la comunicación entre holones, en algunos artículos
(ADACOR, MES-HMS, Enfoque Holónico y ADACOR2) se indica que ésta se hace
a través de una red Ethernet, utilizando protocolos y un lenguaje de
comunicación específico. Sin embargo, la mayoría de los autores sólo
mencionan el tema sin hacer notar la importancia del mismo en los sistemas
holónicos.
Para referir los niveles de diseño de una arquitectura holónica y comprender de
manera general los niveles de decisión e interacción entre holones, el siguiente
apartado resume un caso de estudio particular.
ESTADO DEL ARTE
17
2.2. NIVELES DE DISEÑO, DECISIÓN E INTERACCIÓN ENTRE HOLONES
En la referencia [10] se indica que el desarrollo de un sistema holónico consiste
básicamente en la identificación de los holones, en el diseño e implementación
del software de cada holón y sus interacciones. Hace notar dos niveles de diseño:
uno de bajo nivel donde se específica el funcionamiento interno de cada holón,
y otro de alto nivel donde se concretan las relaciones entre holones. Los tres
componentes básicos que distinguen a los holones en un nivel de diseño bajo
son: (1) una base de conocimiento donde se registran los objetivos del holón, su
estado y la representación del mundo externo, (2) una unidad de control
distribuido y descentralizado, y (3) un módulo de coordinación mediante el cual
el holón interacciona con otros holones (Véase Figura 2.1).
Figura 2.1. Diseño de un holón de bajo nivel [10].
Las tres características antes descritas confieren a un holón suficiente capacidad
para integrarse a una comunidad u holarquía donde sea posible la interacción
entre diferentes holones. Sin embargo, pocos esquemas holónicos propuestos en
la literatura profundizan en el primer componente básico de los holones.
Una holarquía es una combinación de una jerarquía y una heterarquía donde los
holones se agrupan recursivamente a diferentes niveles en un modelo social con
Capítulo 2
18
la capacidad de cooperar y reconfigurarse para lograr una meta u objetivo [23].
A esto, y respecto al diseño de alto nivel, [10] define tanto a los diferentes tipos
de holones como la interacción entre éstos. La interacción busca coordinar los
objetivos de cada holón de forma que contribuyan al objetivo global del sistema.
La coordinación contempla:
Comunicación: dado que la información está distribuida en el sistema, es
necesario el intercambio de información entre los diferentes holones para
mantenerse informados.
Cooperación: procedimiento, voluntario o no, mediante el que las acciones
de cada holón se orientan hacia los objetivos globales.
Colaboración: cooperación voluntaria.
Negociación: mecanismo necesario para resolver los conflictos que surgen
cuando varios holones tienen intereses incompatibles.
Para ejemplificar lo dicho, la propuesta hecha por [10], hace mención de tres
niveles de interacción entre holones orden y holones máquina: (1) formación de
holarquías, a través de las que se forman asociaciones entre órdenes de
producción y máquinas; (2) negociación, mediante la que se realizan programas
que permiten la coordinación de actividades (operación a lanzar, la máquina, y
la fecha deseada de finalización); y (3) colaboración, que permite la asignación
final de operaciones a máquinas mediante acuerdos de ejecución. Para que
esto último sea posible, la interacción entre holones requiere de la comunicación
efectiva entre los mismos, tema revisado en el siguiente apartado.
2.3. COMUNICACIÓN INTER-HOLÓN
2.3.1. Importancia de la comunicación
Por otro lado, como se dijo en el apartado anterior (tema ampliado en el Apéndice A)
un conjunto de holones (vistos como una sociedad) que pueden cooperar y
ESTADO DEL ARTE
19
reconfigurarse para lograr una meta u objetivo constituyen una holarquía [23]. Una
holarquía es una combinación de una jerarquía y una heterarquía donde los holones se
agrupan recursivamente a diferentes niveles en un modelo social. Para que esto último
sea posible, las holarquías definen reglas básicas para la cooperación y coordinación
entre holones basadas en la comunicación. El componente comunicación es por tanto,
responsable de la interacción inter-holón, soportando intercambio de información local
de los holones distribuidos (holones que pueden o no ser parte de una holarquía: holón
producto, holon recurso, etc.), o bien, se da a través de un holón supervisor o
coordinador quien admite comunicación oficial, de semántica significativa y que
contribuye especialmente a la toma de decisiones [8] (véase Figura A.4 del Apéndice
A). De esta forma, la comunicación vertical (holón coordinador) se complementa con
la horizontal (holones distribuidos), sin embargo, ambas formas requieren estar separadas
de manera semántica entre sí para excluir las influencias negativas en los holones de
mayor nivel debido a la falta de información o la información obsoleta.
Para crear un ambiente de comunicación, los holones deben ser capaces de conocer
y manejar descripciones del estado del mundo externo, que consisten en una
representación dinámica del entorno en el que viven, y de otros holones con quienes
comparte dicho entorno. El modelo correspondiente del estado del mundo y el modelo
social pueden ser considerados como modelos estructurales, que eventualmente serán
completados por modelos de tareas o metas globales por alcanzar, e información sobre
el grado de logro [24].
Por lo tanto, la interoperabilidad requiere de un vocabulario común u ontología de
manufactura apropiada, que sea acordada previamente y que se exprese en un
lenguaje basado en la lógica, de modo detallado, preciso y consistente.
Una ontología ofrece la semántica y representación de datos que deriva de información
sobre el comportamiento de cada holón para la formación de holarquías, negociación
y colaboración [25]. La semántica de un modelo ontológico formal es definida con la
intención de facilitar el proceso automático del modelo para síntesis automático de las
funciones de un holón [26]. El medio semántico es un contexto donde todos los
conceptos relevantes son importantes para la organización colaborativa. De esta
Capítulo 2
20
manera, las ontologías proporcionan un mapeo explícito entre conceptos compartidos
partiendo del formalismo de diferentes sistemas [27], haciendo posible que los beneficios
de la representación formal del conocimiento se sitúen en su potencial para ser
compartido [28]. Información más amplia respecto a conceptos, definiciones, ventajas
y elementos de una ontología, pueden consultarse en el Apéndice B “IMPORTANCIA DE
UNA ONTOLOGÍA”.
2.3.2. Dispositivo de control de un holón ADACOR
En este mismo sentido, pero desde otro punto de vista, el modelo de concepción
de un holón genérico ADACOR [8] muestra un dispositivo de control lógico
(Logical Control Device, LCD) y un recurso físico capaz de realizar la operación
de manufactura. El dispositivo LCD es organizado en tres componentes
principales: comunicación (ComC), decisión (DeC) e interfaz física (PIC).
El componente comunicación es responsable de la interacción inter-holón
apoyando el intercambio de conocimiento local por los holones distribuidos. El
componente de decisión regula el comportamiento de cada holón (detección,
decisión, actuación y aprendizaje). Así, el holón está disponible continuamente
para tomar una decisión de acuerdo con los conocimientos disponibles y con la
técnica de toma de decisiones implementada. El conocimiento se adquiere
mediante la detección del medio ambiente y la llegada de mensajes de otros
holones. Después de tomar una decisión, las acciones seleccionadas, en forma
de comandos para actuadores, mensajes para otros holones o ejecución de
procedimientos, se envían y ejecutan. Se evalúan los resultados de las acciones
ejecutadas y se genera nuevo conocimiento. Conocimiento que debe ser
almacenado. Finalmente, el componente de interfaz física tiene como objetivo
proporcionar mecanismos para apoyar la integración de recursos basados en el
concepto de recursos virtuales y el modelo cliente-servidor. Más información al
aspecto puede consultarse en la referencia [8]. De lo anterior, el compartir
información entre holones, tanto de sus habilidades como del conocimiento del
ESTADO DEL ARTE
21
ambiente que lo rodea, le permite a éstos desarrollar sistemas de estructura
compleja estables y autosuficientes además de eficientes en el uso de recursos y
robustos ante perturbaciones tanto internas como externas [3], [29].
Figura 2.2. Modelo conceptual del Holón ADACOR [8].
Hecha la revisión del modelo conceptual de un holón, y de las arquitecturas antes
mencionados (en el Anexo A), se puede observar que éstas mismas abordan en su
mayoría conceptos teóricos respectivos a los términos; holón, HMS y sistemas de
manufactura, para posteriormente introducir al lector en propuestas de la tecnología
usada y los modelos conceptuales dados a las diferentes clases de holones creados. Por
ejemplo se presenta el conocimiento, las habilidades y la capacidad que éstos tienen
para razonar para tomar decisiones acerca de sus actividades resaltando en la mayoría
de los casos la necesidad de cooperación entre holones distribuidos con el fin de
soportar el intercambio de conocimiento local para alcanzar los objetivos planteados y
Capítulo 2
22
obtener información global sobre el sistema que se trate. Además, es resaltado el factor
“autonomía” que en muchos casos es usado para modelar dinámicamente el
comportamiento de un holón que se adaptará a los cambios del entorno en el que se
encuentre proponiendo, en la mayoría de los artículos, mecanismos innovadores de
auto-organización.
Pese a las aportaciones dadas en la literatura, sólo en algunos casos se hacen
comentarios respecto a que la interoperabilidad de los holones requiere de un
vocabulario común u ontología de manufactura apropiada que sea acorde a las
necesidades de cada holón.
2.4. COMENTARIOS
En este entendido, las ontologías ocupan un lugar destacado dentro de los holones, sin
embargo, lo antes mencionado requiere del dominio global que contengan los términos
para describir y representar una ontología unificada de los sistemas de producción. En
el caso particular, la ontología referida en el siguiente capítulo permitirá la captura de
la información necesaria para las aplicaciones JADE.
En pocas palabras, “el corazón de un sistema HMS eficaz es la ontología” puesto que
provee un núcleo de información de la lógica de operaciones necesarias en las distintas
fases del ciclo de producción de un modelo de producto apoyado por el soporte de
decisiones que tomen los holones involucrados. Para hacer notorio lo aquí descrito, en el
siguiente capítulo se refiere una ontología unificada como la principal propuesta de la
investigación sostenida por esta tesis, misma que integra roles y comportamientos de
holones en un caso de estudio particular.
2.5. BIBLIOGRAFÍA
[1] KOESTLER, A. The ghost in the machine. Arkana. 1967. 384 p. ISBN 9780140191929.
BOTTI, V.; GIRET, A. ANEMONA, A multi-agent methodology for holonic
manufacturing systems. Springer: Departamento de sistemas informáticos y
computación (DSIC). Valencia, Spain, 2008. 220 p. ISBN 978-1-84800-309-5
ESTADO DEL ARTE
23
[2
]
BLANC, P.; DEMONGODIN, I.; CASTAGNA, P. A holonic approach for
manufacturing execution system design: An industrial application. Engineering
Applications of Artificial Intelligence. 2008, Vol. 21, No. 3, p. 315–330.
[3] LEITÃO, P.; RESTIVO, F. Implementation of a Holonic Control System in a Flexible
Manufacturing System. IEEE Transactions on Systems, Man, and Cybernetics, Part
C (Applications and Reviews). 2008, Vol. 38, No. 5, p. 699–709.
[4] OUNNAR, F.; PUJOPULL, P. Pull control for job shop: holonic manufacturing system
approach using multicriteria decision-making. Journal of Intelligent
Manufacturing. 2012, Vol. 23, No. 1, p. 141–153.
[5] TARUN, K.J.; BIPRADAS, B.; SOUMEN, P.; BIJAN, S.; JYOTIRMOY, S. Dynamic
schedule execution in an agent based holonic manufacturing system. Journal of
Manufacturing Systems. 2013, Vol. 32, No. 4, p. 801–816.
[6] BRUSSEL, H.V.; WYNS, J.; VALCKENAERS, P.; BONGAERTS, L.; PEETERS, P. Reference
architecture for holonic manufacturing systems: PROSA. Computers in Industry.
1998, Vol. 37, No. 3, pp. 255–274.
[7] WANG, F.; XU, D.; TAN, M.; WAN, Z. A Holonic architecture for reconfigurable
manufacturing systems. En: IEEE International Conference on Industrial
Technology. 2005, pp. 905–909.
[8] LEITÃO, P.; RESTIVO, F. ADACOR: a Holonic architecture for agile and adaptive
manufacturing control. Computers in Industry. 2006, Vol. 57, No. 2, pp. 121–130.
[9] BRAVO, C; AGUILAR-CASTRO, J; RÍOS, A; AGUILAR-MARTIN, J; RIVAS, F.
Arquitectura basada en inteligencia artificial distribuida para la gerencia
integrada de producción industrial. RIAI-Revista Iberoamericana de Automática
e Informática Industrial. 2011, Vol. 8, No. 4, p. 405–417.
[10] ARAUZOA, J.A.; DEL-OLMO-MARTÍNEZ, R; LAVIOS, J.J.; DE-BENITO-MARTÍN J.J.
Programación y control de sistemas de fabricación flexibles: un enfoque
holónico. RIAI - Revista Iberoamericana de Automática e Informática Industrial.
2015, Vol. 12, pp. 58–68.
[11] BARBOSA, J.; LEITAO, P.; ADAM, E.; TRENTESAUX, D.; Dynamic self-organization in
holonic multi-agent manufacturing systems: The ADACOR evolution. Computers
in Industry. 2015, Vol. 66, pp. 99–111.
Capítulo 2
24
[12] DE LAS MORENAS, J; GARCÍA, A; MARTINEZ, F., P., G. Implementación del control
en planta de un centro de distribución automatizado mediante agentes físicos
y RFID. RIAI-Revista Iberoamericana de Automática e Informática Industrial. 2015,
Vol. 12, No. 1, pp. 25–35.
[13] INDRIAGO, C.; CARDIN, O.; RAKOTO, N.; CASTAGNA, P.; CHACÒN, E.; H2CM: A
holonic architecture for flexible hybrid control systems. Computers in Industry.
2016, Vol. 77, pp. 15–28.
[14] TRENTESAUX, D; GIRET, A. Go-green manufacturing holons: A step towards
sustainable manufacturing operations control. Manufacturing Letters. 2015, Vol.
5, pp. 29–33.
[15] PUJO, P; OUNNAR, F; POWER, D; KHADER, S. Wireless Holon Network for job shop
isoarchic control. Computers in Industry. 2016, Vol. 83, pp.12–27.
[16] WANG, L; HAGHIGHI, A. Combined strength of holons, agents and function blocks
incyber-physical systems. Journal of Manufacturing Systems. 2016, Vol. 40, pp. 25–
34.
[17] SUGI, M; MAEDA, Y; AIYAMA, Y; HARADA, T; ARAI, T. A holonic architecture for
easy reconfiguration of robotic assembly systems. IEEE Trans. on robotics and
automation. 2003, Vol. 19, No. 3, pp. 457–464.
[18] HUANG, X; WANG, Y; TAN, D; ZHAO, M; MENG, F. Theoretical analyze and
implementation method of reconfigurable assembly line based on agent and
holon. In: At 5th World Congress on Intelligent Control and Automation.
Hangzhou, P.R. China, 2004, Vol. 3, pp. 2830–2833.
[19] BRUSSEL, H.V. Reference Architecture for Holonic Manufacturing Systems: the key
to support evolution and reconfiguration. Katholieke Universiteit Leuven Faculteit
Toegepaste Wetenschappen Arenbergkasteel, B-3001, Heverlee, Belgium. 1999.
[20] REN, S. C; XU, D; WANG, F; TAN, M. Cyclic flow shop scheduling based on timed
event graph extended with disjunctive constraints. In: Industrial Technology, IEEE
International Conference. No. 8947197. Hong Kong, China. Dic. 2005, pp. 926–
931.
ESTADO DEL ARTE
25
[21] BORGO, S; LEITÃO, P. Foundations for a Core Ontology of Manufacturing.
Ontology Handbook, Laboratory for Applied Ontology, ISTC-CNR, via Solteri 38,
38100 Trento, Italy. 2007, pp. 751–775.
[22] TRENTESAUX, D.; PACH, C.; BEKRAR, B.; SALLEZ, Y.; BERGER, T.; BONTE, T.; LEITÃO, P.;
BARBOSA, J. Benchmarking flexible job-shop scheduling and control systems.
Control Engineering Practice. 2013, Vol. 21, pp. 1204–1225.
[23] CHRISTENSEN, J. Holonic Manufacturing Systems - Initial Architecture and
Standards Directions. At First European Conference on Holonic Manufacturing
Systems, Hannover, Germany, 1994.
[24] SHEN, W.; NORRIE, D.H.; BARTHÈS A. Multi-agent systems for concurrent intelligent
design and manufacturing. London EC4P 4EE: Taylor & Francis Group, 2001. pp.
30–47. ISBN 0-7484-0882-7
[25] KOPPENSTEINER, G.; GRABLER, R.; MILLER, D.; MERDAN, M. Virtual enterprises
based on multiagent systems. En: LEITÃO, P.; KARNOUSKOS, S. (Eds.), Industrial
agents: Emerging application of software agents in industry. 1st ed. Amsterdam,
Netherlands: Punithavathy Govindaradjane, 2015. p. 121–136. ISBN 978-0-12-
800341-1
[26] LEGAT, C.; SCHÜTZ, D.; VOGEL-HEUSER, B. Automatic generation of field control
strategies for supporting (re-)engineering of manufacturing systems. Journal of
Intelligent Manufacturing. 2014, Vol. 25, No.5, pp. 1101–1111.
[27] USCHOLD, M.; GRUNINGER, M. Ontologies: principles, methods and applications.
Knowledge Engineering Review. 1996, Vol. 11, No. 2, pp. 93–136.
[28] CORREA DA SILVA, F.S.; VASCONCELOS, W.W.; ROBERTSON, D.S.; BRILHANTE, V.;
DE MELO, A.C.V.; FINGER M.; AGUSTÍ, J. On the insufficiency of ontologies:
problems in knowledge sharing and alternative solution. Knowledge-Base
Systems. 2002, Vol. 15, No. 3, pp. 147–167.
[29] UNLAND, R. Industrial agents. En: LEITÃO, P., KARNOUSKOS, S. (Eds.), Industrial
agents: Emerging application of software agents in industry. 1st ed. Amsterdam,
Netherlands: Punithavathy Govindaradjane, 2015. p. 23–44. ISBN 978-0-12-800341-
1
Capítulo 2
26
3. PROPUESTA DE ONTOLOGÍA UNIFICADA
ESQUEMA DEL CAPÍTULO
3.1 INTRODUCCIÓN
3.2 ONTOLOGÍA UNIFICADA
3.2.1 Metodología empleada para el diseño de la ontología
3.2.2 Especificación
3.2.3 Conceptualización
3.2.4 Formalización
3.3 COMENTARIOS
3.4 BIBLIOGRAFÍA
En un intento por hacer realidad lo dicho hasta ahora, el objetivo de este capítulo es
mostrar una de las contribuciones de este trabajo de investigación. Para ello, es
enfatizada la especificación, conceptualización y formalización de una ontología
unificada en el dominio de la manufactura, en beneficio de la semántica de los
mensajes intercambiados entre holones, que garantice un lenguaje de contenido
universal.
El capítulo está organizado en las siguientes secciones: La Sección 3.1 se da una
introducción general al tema. En la Sección 3.2 se describe la metodología empleada
en el diseño de la ontología y se desarrollan las fases para la concepción de la misma, y
la Sección 3.3 proporciona comentarios del trabajo realizado.
3.1. INTRODUCCIÓN
Tal como se comentó en el Capítulo 2 y en el APÉNDICE B, en informática, una ontología
es una estructura completa de datos que contiene y esquematiza la definición de todas
las entidades relevantes y sus relaciones dentro del dominio (con la especificación de:
clase, relaciones, funciones, slots, individuos y axiomas), cuyo vocabulario se traduce en
3
Capítulo 3
28
un lenguaje de implementación usado para comunicar y compartir conocimiento. Por
lo que, las ontologías son necesarias para establecer el vocabulario básico y la
semántica del dominio [1]. Así, la base de conocimientos se escribe en términos de una
ontología adaptada en el dominio de la aplicación, que a su vez es la esencia del motor
de inferencia de los HMS.
Por otro lado, el intercambio y reutilización del conocimiento requieren de un marco
común para apoyar la interoperabilidad de las ontologías creadas de manera
independiente. Los resultados de la investigación muestran que existe una gran
diversidad en la manera en que se conciben las ontologías y en la forma en que
representan al dominio de manufactura. Al identificar las similitudes y diferencias entre
ontologías existentes, se vislumbra el rango de alternativas en la creación de un marco
estándar para el diseño de ontologías disponibles para HMS.
De esta manera, las ontologías de dominio son necesarias para definir los conceptos
esenciales y los vocabularios asociados con un dominio particular. Para tal fin, el
presente capítulo muestra metódicamente cómo las ontologías útiles se superponen
parcialmente a ontologías más genéricas (en particular aquellas que abordan
conceptos de sentido común) y se complementan con conceptos especializados, todos
ellos representados a través de un formato universal. Posteriormente, en el Capítulo 4 la
ontología se implementa y se utiliza como base para el desarrollo de un sistema basado
en conocimiento de una celda de manufactura y se vislumbra el hecho de comunicar
tanto a entidades de software (holones) como recursos humanos mediante una interfaz
gráfica de usuario.
3.2. ONTOLOGÍA UNIFICADA
Lo que se pretende en esta sección es mostrar una propuesta ontológica de dominio
que unifique el amplio bagaje de términos estandarizados en los sistemas de
manufactura, para tal caso, se parte de una metodología específica hasta alcanzar la
formalización de la misma.
PROPUESTA DE ONTOLOGÍA UNIFICADA
29
3.2.1. Metodología empleada para el diseño de la ontología
Para la creación de ontologías en la literatura se hallan diferentes metodologías, de
entre estas las usadas en dominio de manufactura se encuentran; Methontology [2],
Uschold and King’s Ontology [3], Ontology Development 101 [4], entre otras. Cada una
de estas propuestas describe las fases del desarrollo de una ontología a diferentes niveles
de conocimiento.
La presente aportación hace uso de una adaptación de la metodología
“Methontology” dada por [5]. Methontology es una metodología creada en el
Laboratorio de Inteligencia Artificial de la Universidad Politécnica de Madrid (UPM) para
la construcción de ontologías ya sea partiendo de cero, de la reutilización de ontologías
(como es el caso de la presente investigación), o de un proceso de reingeniería de
alguna ya existente. Las bases de dicha metodología son actividades del desarrollo de
software propuesto por la organización IEEE (Institute of Electrical and Electronics
Engineers) y algunas otras metodologías de conocimientos [5, 6].
El objetivo de la metodología es permitir crear una ontología desde unos pocos requisitos
iniciales, comenzando de lo más general hasta lo más específico, de manera planificada
[5, 6, 7]. La Figura 3.1 describe las actividades necesarias en el desarrollo de una
ontología. La metodología se subdivide en tres áreas: 1) Actividades de desarrollo (fases:
especificación, conceptualización, formalización, implementación y mantenimiento)
que implican diferentes niveles de conocimiento y que por el orden que siguen
conforman el “Ciclo de vida de la ontología”; 2) Actividades de soporte (fases:
adquisición del conocimiento, integración, evaluación, documentación y gestión de
configuración) las cuales son tareas que se realizan durante todo el ciclo de vida de la
ontología; y 3) Actividades de ejecución, las cuales son necesarias para la
programación, control y aseguramiento de la calidad de la ontología, en el caso
particular que se presenta en la tesis, las actividades se ejecutan en un ambiente virtual.
La metodología específica las técnicas utilizadas en cada actividad, los productos que
cada actividad produce y cómo deben ser evaluados. Las actividades de mayor interés
son las “actividades de desarrollo”, fases que se describen e integran en esta sección.
Capítulo 3
30
Los resultados de la fase de implementación son listados en el Capítulo 5, mientras que
las actividades que dan soporte a la concepción de la ontología no se pueden observar,
pero fueron totalmente necesarias para soportar tanto a las actividades de desarrollo
como de ejecución en distintos momentos. Para mayor información respecto a la
metodología usada, consulte las referencias [5, 6].
Figura 3.1. Methontology: Actividades en la concepción de una ontología [5, 6].
Las fases que integran la sección “actividades de desarrollo” mostradas en la Figura 3.1,
se pueden describir como sigue:
PROPUESTA DE ONTOLOGÍA UNIFICADA
31
1) Especificación
El proceso de construcción debe iniciar con la especificación de la ontología. Se
especifica el dominio y la cobertura para un área particular del dominio, el nivel de
formalismo, su propósito (por ejemplo: uso previsto, escenarios de uso, usuarios
finales, etc.) y su alcance o impacto.
2) Conceptualización
En esta fase se capturan y especifican los requerimientos de la ontología, se
identifican preguntas de competencia, se estudian ontologías potencialmente
reutilizables y se construye una primera versión preliminar de la ontología. Las
actividades por abordar son:
1. Definir conceptos. Cada término debe ser definido y cuidadosamente agregado
en la lista, evitando las incoherencias con las definiciones de otros conceptos.
2. Describir las relaciones taxonómicas (relaciones de herencia o tipo que tienen
algunos conceptos) en subclase, disjunta, disjunta exhaustiva y partición.
3. Hacer relaciones binarias (se representa que el término X contiene al término Y, o
el término Z es generado por el término W) y relaciones inversas (cada relación
posee otra en sentido contrario), por ejemplo: el término Y es contenido por el
término X, estas últimas son necesarias para dar consistencia a la ontología.
4. Hacer un diccionario de términos (resumen de la información de los puntos
anteriores). A través de una tabla, se muestra cada uno de los conceptos, su
concepto padre, relaciones encontradas con otros (directas e inversas) y sus
atributos. Estos últimos se dividen en atributos de clase y de instancia.
5. Además de las tareas desarrolladas, existen otras que permiten lograr un mayor
detalle en la ontología como las descripciones de relaciones, atributos y clases.
Éstas están ligadas con la implementación de la ontología.
6. Finalmente, se describen las reglas que siempre se cumplen en el dominio, es decir
se plantean los axiomas.
Capítulo 3
32
3) Formalización
La formalización de una ontología es la fase donde se representa la
conceptualización a través de un formato universal, comprensible por la comunidad
en general. Una herramienta de modelado usual es UML (Unified Modelling
Language) [8], debido a su gran uso y la descripción de relaciones entre actores y
entidades de manera gráfica.
1. Clase – Modelo operativo, parte del flujo de información que es el resultado de
analizar y agrupar las relaciones binarias obtenidas en la fase de
conceptualización, con lo que se conforman “vistas” de los diferentes flujos de
información.
2. Clase – Negociación es el centro para establecer la autonomía dentro de la
unidad de producción.
3. Clase – Actividades administrativas, se refiere a la actividad de gestión de un
recurso sobre otro para lograr un fin dado.
4. Clase – Reactividad, se considera como la capacidad de reacción de la unidad
de producción ante los eventos, internos o externos, que afectan su
funcionamiento y puede ser inferido a través de las relaciones y conceptos
consignados en la ontología.
4) Implementación
La ontología se prueba en un entorno de aplicación para garantizar los requisitos,
para ello, la implementación de la ontología requiere del uso de un entorno que
soporte la meta-ontología y las ontologías seleccionadas en la fase de integración.
El resultado de esta fase es la ontología codificada en un lenguaje formal como:
CLASSIC, BACK, LOOM, Ontolingua, Prolog, C++, etc. El desarrollo de esta actividad
puede observarse en el Capítulo 4.
PROPUESTA DE ONTOLOGÍA UNIFICADA
33
5) Mantenimiento
La ontología es retroalimentada con las observaciones de la fase de
implementación y bajo una dinámica de mejora continua según las propias
necesidades del sistema. Sin embargo, el tema no es relevante por el momento en
este documento.
Los siguientes temas muestran los resultados de las etapas antes mencionadas. Así, el
proceso de desarrollo de la ontología transforma el producto inicial (la necesidad que
tiene para construir la ontología) en un producto final (la ontología evaluada y
documentada, codificada en un lenguaje formal).
3.2.2. Especificación
Respecto al proceso de construcción, el primer paso se da al iniciar con la especificación
de la ontología. Para este caso, la cobertura de la ontología será el dominio de
manufactura bajo el enfoque de HMS. El propósito de ésta, es describir la dinámica en
el dominio, facilitando la rápida comprensión del modelo por los actores (holones), para
que los mismos hagan uso coherente de la información dada y ésta sea reproducible en
el control de Sistemas de Manufactura Inteligentes (SMI).
Aquí, las especificaciones de la ontología se vinculan a la capacidad para describir y
almacenar el conocimiento, donde los aspectos tratados: usabilidad, accesibilidad,
interoperabilidad (lo que implica la normalización), modularidad, extensibilidad y
univocidad, han sido temas tomados en cuenta en el desarrollo de la ontología
unificada.
3.2.3. Conceptualización
El segundo paso es la conceptualización misma que implica el hecho de investigar,
depurar y formular el amplio conocimiento del sistema de manufactura con la finalidad
de identificar, agrupar y describir conceptos y sus relaciones de un modo sistemático, y
de manera independiente al contexto del dominio tratado (es decir, los conceptos
comunes a toda ontología de orden superior, que podría ser escrito en este dominio, por
Capítulo 3
34
ejemplo: productos, recursos, operaciones, entre otros) para elaborar una ontología
superior. A esto, los siguientes dos temas (3.2.3.1 y 3.2.3.2) hacen aclaraciones pertinentes
de los principales conceptos de la ontología.
3.2.3.1. Descripción de las características y actividades internas de un SMT
Un SMT (obsérvese Sección A.2. “EVOLUCIÓN DE LOS SISTEMAS DE MANUFACTURA” del
Apéndice A) produce productos los cuales son ofertados a un mercado específico.
Dentro de las empresas, los productos son descritos por el modelo del producto que
contiene todos los datos técnicos y descripción de la estructura de un producto (por
ejemplo, lista de subproductos, partes de ensamble o materia prima que lo constituyen)
y por el modelo de proceso que define cómo procesar el producto. La materia prima
es una entidad adquirida fuera de la empresa y se utiliza durante el proceso de
producción, por ejemplo bloques de acero, tuercas y tornillos que no son producidos
internamente.
El modelo de proceso especifica el plan de procesos, que es una lista de operaciones
necesarias para producir una parte. En este contexto, una operación es un trabajo que
debe ser ejecutado en orden con el fin de producir el producto y es caracterizada por
un conjunto de información, como el tiempo estimado de procesamiento, la
descripción, la precedencia y los requisitos técnicos. Algunos ejemplos de operación
son: maquinados, ensambles, transporte, manipulación, mantenimiento y la inspección.
Al iniciar las actividades de la firma, un cliente interactúa con la empresa para ordenar
uno de los productos ofertados o incluso un nuevo producto. Esta orden, se conoce
como orden del cliente, la cual incluye la referencia hacia un producto, su calidad,
fecha de entrega y precio. Adicionalmente, el sistema de administración de la empresa
crea órdenes de pronósticos para anticipar la demanda del mercado. El plan
producción convierte los pedidos de los clientes y los pronósticos en órdenes de
producción, de ser posible se agregan varias órdenes de clientes y pronósticos en una
sola orden de producción, para obtener ventajas de volumen de producción y
transporte. Una orden de producción es indexada a un objeto producto y comprende
una lista de órdenes de trabajo. Una orden de trabajo es la descripción de una
PROPUESTA DE ONTOLOGÍA UNIFICADA
35
operación (o trabajo) y por lo tanto es parte de un plan de proceso. Las órdenes de
trabajo están destinadas a ser ejecutadas por recursos tales como fresadoras, tornos,
motores, robots, transportadores, entre otros. Cada recurso es una entidad que puede
ejecutar una determinada gama de trabajos, siempre y cuando esté disponible y no se
exceda su capacidad o cumpla con las propiedades necesarias. Una propiedad es un
atributo que caracteriza a un recurso o que se debe satisfacer para ejecutar una
operación.
El Shop Floor, o lugar de trabajo, se conforma por un grupo de recursos con diferentes
características (por ejemplo: lista de herramientas y pinzas, velocidad del husillo, carga
útil, tiempo de autonomía, volumen de trabajo, capacidad de repetición, etc.), cuyas
bondades combinadas permitirán ejecutar los trabajos específicos que requiera un
producto. El modelo de fábrica describe cada shop floor individual de recursos y los
organiza lógica y físicamente. La disponibilidad de un recurso está representada por la
lista de órdenes de trabajo asignadas al recurso a través del tiempo. En particular, el
programa comprende los intervalos de tiempo en el que el recurso esté disponible,
asignado para ejecutar órdenes, temporalmente fuera de servicio (por ejemplo, debido
a mantenimiento) o fuera de servicio (por ejemplo, debido a una interrupción en el
suministro de los elementos necesarios como el agua o potencial eléctrico).
3.2.3.2. Control de un SMT
Las principales funciones de un Sistema de Control de la Producción (SCP) son: la
planificación de procesos, la planificación de la asignación de recursos (scheduling), la
ejecución del plan, y la manipulación de estado patológico.
La producción de un producto implica tanto la configuración de los recursos (conjunto
de acciones necesarias con el fin preparar un recurso de manufactura para la
ejecución de una serie de operaciones), como la ejecución (según el diagrama de
prioridad) de los pasos definidos en el plan de proceso. A nivel de planificación de
procesos, el SCP lanza las órdenes de producción a la planta junto con un plan de
trabajo. Este último proporciona la secuencia necesaria de operaciones y el tipo de
maquinado, necesario para cada operación. Sobre la base de los recursos disponibles,
Capítulo 3
36
es posible crear secuencias de proceso alternativos (con el objetivo de lograr
flexibilidad), cada uno de ellos indican el recurso exacto necesario para ejecutar cada
operación.
A través de la planificación de la asignación de recursos, el SCP programa las
operaciones necesarias para producir las partes (incluyendo el procesamiento,
transporte, mantenimiento y operaciones de configuración), teniendo en cuenta los
planes de proceso, las limitaciones y capacidad de los recursos. El objetivo es producir
los productos reduciendo al mínimo los costos y aumentar la productividad. En este
mismo nivel el SCP considera posibles reorganizaciones de la unidad de producción (en
general mediante la variación de las asignaciones de recursos) en caso de una
modificación de la demanda o por fallos presentes en la máquina.
Las funciones del plan de ejecución del SCP se encargan de la ejecución física de la
programación en la fábrica. Las órdenes programadas se envían al sistema de
producción, es decir, a los recursos, y una actividad de seguimiento del progreso de la
producción se lleva a cabo. La reacción a las perturbaciones se considera primero por
el SCP a nivel de plan de ejecución, pero puede implicar re-programación de las
operaciones para reducir al mínimo los efectos de la perturbación y, en algunos casos,
la interrupción del proceso de producción. El nivel de manejo de estado patológico
tiene la intención de mantener el sistema en un estado seguro, a fin de evitar
recuperarse de estados del sistema indeseables, tales como un punto muerto.
Al investigar, depurar y formular el amplio conocimiento de los sistemas de manufactura,
agrupando los conceptos de un modo sistemático, y de manera independiente al
contexto del dominio tratado (obsérvese también la Tabla 3.2 y los predicados de la
Sección 3.3), la siguiente etapa “Formalización” puede primeramente elaborar una
ontología superior que permita subsecuentemente la integración de conceptos a
diferentes niveles.
PROPUESTA DE ONTOLOGÍA UNIFICADA
37
3.2.4. Formalización
La formalización de una ontología es la fase donde se representa la conceptualización
a través de un formato universal, comprensible por la comunidad en general. Una
herramienta de modelado usual es el “Unified Modelling Language” (UML), debido a su
gran uso y la descripción de relaciones entre actores y entidades de manera gráfica. Los
avances aquí mostrados hacen uso de clases “Agent Unified Modelling Language”
(AUML), que son una extensión de los diagramas de clase UML. La Tabla 3.1 muestra los
diferentes tipos de relaciones de asociación entre los diferentes conceptos.
Tabla 3.1. Tipos de relaciones de los conceptos de la ontología con recursos del dominio
manufactura.
Relación Asociación Descripción
Agregación Clase 2 Clase 1
La clase 2 es un objeto de agregación de la clase 1. Por
ejemplo: las órdenes de trabajo son parte de la orden de
producción.
Asociación Clase 2 Clase 1
Relación estructural bidireccional que describe una
conexión entre objetos de ambas clases que colaboran
entre sí.
Herencia Clase 2 Clase 1
Relación entre una superclases y sus clases. Por ejemplo: el
recurso de movimiento hereda los métodos y atributos
especificados por el recurso flexible.
En este orden de ideas, una ontología se puede clasificar bajo dos propósitos: ontologías
de orden superior y ontologías de orden específico.
Las ontologías de orden superior incluyen conceptos básicos, taxonomías y relaciones
de conceptos. Su propósito es permitir que las ontologías específicas se puedan integrar
de manera fluida a la misma arquitectura cognitiva común, lo que permite la distribución
efectiva del modelo de datos entre entornos heterogéneos (distintos modelos de
productos dentro del mismo concepto producto, etc.). Las ontologías de orden superior
son la prioridad y el marco de preocupaciones de las ontologías, esto es conocido como
el problema de alineación de ontologías, o problema de integración de ontologías [9].
Capítulo 3
38
Por otro lado, las ontologías integran conceptos a diferentes niveles, a los primeros grupos
de conceptos de primer orden se les agregan sub-clases (conceptos de segundo orden),
seguido a esto axiomas y finalmente restricciones, las cuales brindan la posibilidad de
inferir conocimiento. A esto se le conoce como conceptos de tercer orden.
Aquí, se muestran los conceptos, taxonomías y relaciones de la ontología de orden
superior, y se dan ejemplos de ontologías de segundo orden. Los componentes
ontológicos son mapeados en un conjunto de objetos, mismos que se ilustrarán en
diagramas de clases.
Asimismo, el formalismo de la estructura que integra esta clasificación se hace partiendo
de ontologías existentes y está ligada a la propuesta “Extended Enterprise” dada por la
referencia [10], la cual fue desarrollada con el fin de integrar modelos de datos EXPRESS
estandarizados bajo tres normas: ISO 10303, ISO 15531 e ISO 13584, conocidas como STEP,
MANDATE y PLIB, respectivamente. Así, los conceptos y taxonomías se describen en el
siguiente apartado.
3.2.4.1. Conceptos de primer y segundo orden
En la ontología de primer orden, es conceptualizado el conocimiento de una celda de
manufactura identificando, agrupando y describiendo conceptos de un modo
semántico y de manera independiente al contexto del dominio tratado. Esto es, los
conceptos comunes a toda ontología de orden superior en el dominio de Manufactura
son: Cliente, Producto, Orden, Operacion, Recurso, Holon, HolonAccion y Estado,
conceptos que servirán en lo subsiguiente para contener ontologías de orden inferior
como se muestra en la Figura 3.2. Así, este vocabulario se irá integrando bajando de
nivel en los diferentes grupos de conceptos.
PROPUESTA DE ONTOLOGÍA UNIFICADA
39
Figura 3.2. Conceptos. Orden superior.
A continuación, los incisos del a) al f) describen a cada uno de los conceptos de la Figura
3.2:
a) Cliente, Producto y Orden
En un inicio, es definida una clase “Cliente” agregándole algunos de los productos
ofertados por el sistema “Producto”, una cantidad de unidades requeridas
(unidadesPorProducto), un valor de preferencia (Prioridad) y la fecha de solicitud
(fechaSolicitud). La asociación de datos a una serie de productos se llama orden del
cliente (OrdenCliente), la cual incluye la referencia hacia un producto, su cantidad,
prioridad y fecha de solicitud, todos ellos definidos como atributos de una orden del
cliente.
Los productos son descritos por las especificaciones del modelo (EspecifModelo) y por
las especificaciones del proceso (EspecifProceso). Las especificaciones del modelo,
contienen todas las propiedades de cada modelo específico (PropModelo), como:
datos técnicos y características estructurales. Los datos técnicos incluyen la forma
geométrica (Computer-aided Design, CAD) e imágenes (Imagen) del producto, y las
características estructurales de cada producto incluyen materia prima (MP) y
subproductos (Sub_ensamble) con las partes de ensamble (Componentes) que lo
constituyen. Dichas especificaciones marcan la diferencia entre los distintos tipos de
productos, por lo tanto, las especificaciones incluidas en cada modelo delimitan los
Capítulo 3
40
requerimientos de calidad. Por otro lado, las especificaciones del proceso definen el
proceso de manufactura o ensamble al cual deben ser sometidas las materias primas o
los componentes de cada producto. A esto se le llama plan de procesos (PlanProcesos).
Las especificaciones antes descritas son necesarias para que un producto pueda ser
fabricado (Manufacturado) y entregado como producto terminado
(productoTerminado). Véase la parte superior izquierda de la Figura 3.3.
Figura 3.3. Ontología. Clases conceptuales de manufactura.
PROPUESTA DE ONTOLOGÍA UNIFICADA
41
b) Operación Vs Orden
Como se dijo, las especificaciones del proceso describen el plan de procesos
(PlanProcesos) que es una lista de operaciones necesarias para producir un producto
(por ejemplo: maquinados, ensambles o sub-ensambles, manipulación, transporte,
mantenimiento o inspección) de entre una serie de tiempos de operación posibles.
Así bien, una operación (Operacion) es un trabajo que debe ser ejecutado en un orden
específico con el fin de elaborar el producto y es caracterizada por un conjunto de
información o atributos como: tiempo estimado de procesamiento
(tiempoEstimadoProcesamiento), descripción (Descripcion), precedencia
(Precedencia) y requisitos técnicos (requisitosTecnicos).
Un plan de producción se constituye por una o varias órdenes de clientes las cuales se
convierten en órdenes de manufactura (OrdenManufactura). Una orden de
manufactura es indexada a un objeto producto y comprende una lista de órdenes de
trabajo. Una orden de trabajo (OrdenTrabajo) es la descripción de una operación (o
trabajo) y por lo tanto es parte de un plan de proceso (obsérvese sección superior
izquierda de la Figura 3.3).
c) Recurso
La sección inferior de la Figura 3.3 muestra cómo las órdenes de trabajo están destinadas
a ser ejecutadas por recursos (Recurso), tales como fresadoras, tornos, robots,
transportadores, entre otros. Cada recurso es una entidad que puede ejecutar una
determinada gama de trabajos (CapacidadProcesamiento), siempre y cuando esté
disponible (Disponibilidad), cuente con lo necesario (clases: Suministros, Herramental y
Dispositivos) y no exceda su capacidad (Capacidad). Los recursos que heredan las
características antes nombradas son denotados como recursos flexibles
(RecursosFlexibles), los cuales se clasifican como: recursos de procesamiento
(R_Procesamiento), recursos de manipulación (R_Manipulacion), recursos de transporte
(R_Transporte) y recursos de almacenamiento (R_Almacenamiento). Cada uno de ellos
es sub-clasificado según su tipo y modelo, y cuenta con una serie de propiedades
Capítulo 3
42
(Propiedades) para dar servicio a las propias necesidades requisitadas por una orden de
trabajo.
En la literatura revisada con frecuencia son usados los términos “disturbio” y
“mantenimiento” como factores afectivos a los recursos. Una emergencia normalmente
ocurre de un disturbio (Disturbio) inesperado activando un comportamiento adaptativo.
Los disturbios pueden clasificarse como una clase TipoPerturbacion, la cual tiene datos
de la gama de perturbaciones que pudieran afectar al sistema, sus causas e impactos
posibles. El mantenimiento (Mantenimiento) es asociado a una lista de descomposturas
posibles (TipoAveria). Según sea el factor que afecte a los recursos, se desencadena un
mecanismo de adaptación que puede dar inicio a la auto-organización individual de
los holones y que dependiendo de la gravedad del caos podría existir una
reorganización de todos los recursos involucrados en el sistema (sección inferior derecha
de la Figura 3.3).
d) Holon
Para que JADE pueda realizar las comprobaciones semánticas adecuadas en una
expresión de contenido dado, no sólo es necesario clasificar todos los elementos posibles
en el dominio tratado según sus características semánticas genéricas, sino que también
es necesario definir la acción de los holones involucrados, así como establecer
predicados y otros elementos.
En este entendido se hace necesaria la habilitación de holones. Dentro de la clase Holon
se contienen conceptos de segundo orden, cuatro holones básicos y seis
complementarios (Figura 3.4), cuya acción deberá obedecer a los propios principios de
acción que ejercen sobre ellos mismos o sobre algún otro holón.
e) HoloAccion
La Figura 3.5 ilustra componentes y acciones ejemplares de los holones básicos
característicos cuya descripción se indica como sigue:
PROPUESTA DE ONTOLOGÍA UNIFICADA
43
HolonProducto
Es parte de las órdenes del cliente.
Hace diseño y rediseño modular del producto.
Planea y (re)planea el plan de procesos.
Verifica la calidad.
Intercambia información del producto y del plan de procesos con el holón
operación.
Interactúa indirectamente con holones orden, operación y configuración durante la
elaboración de planes de procesos que incluyen holones recurso.
Supervisa la tardanza, el progreso y el estado de un producto.
Figura 3.4. Holones. Tipología de holones básicos y complementarios.
Capítulo 3
44
Figura 3.5. Holones básicos. Componentes y acciones.
HolonOrden
Recibe pedidos del cliente y órdenes de trabajo.
Administra la lista de productos y operaciones necesarias para su elaboración.
Crea y envía propuestas de órdenes de trabajo.
Resuelve los conflictos entre los holones orden que requieren el mismo recurso.
Formaliza un contrato entre un holón recurso y un holón producto mediante un
acuerdo de la orden de trabajo.
Programa, configura y monitorea acuerdos de trabajo con holones recurso.
Supervisa la tardanza, el progreso y el estado de una orden de trabajo.
Tiene la facultad de anular el acuerdo con un recurso.
Evalúa al holón recurso por el cumplimiento correcto de una orden de trabajo.
PROPUESTA DE ONTOLOGÍA UNIFICADA
45
Penaliza al recurso por incumplimiento de contrato de una orden de trabajo.
HolonRecurso
Selecciona una propuesta de orden de trabajo la cual incluye una o más
operaciones.
Tiene conocimiento de las capacidades del recurso físico.
Inicia y controla el procesamiento de una orden de trabajo.
Tiene facultades para controlar la producción de sub-recursos.
Administra el plan y ejecución de mantenimiento.
Se auto-examina y examina a sub-recursos.
Tiene conocimiento de los tiempos de proceso, movimiento, transporte y almacén
de un recurso para el cálculo de la fecha entrega.
Programa la ejecución.
Comunica acuerdos de ejecución a cada holón orden.
Solicita la ejecución de una máquina física.
Indica que el recurso físico ha iniciado el proceso de una orden de trabajo.
Informa el fin de la ejecución de operaciones.
Indica el estado del holón recurso.
Percibe y reporta perturbaciones afectivas al recurso físico.
Supervisa la tardanza, el progreso y el estado de un recurso físico.
HolonConfiguracion
Propone al holón operación la ejecución de operaciones de manera optimizada e
intercambia información relacionada con la asignación de recursos y el control de
ejecución de dichas operaciones.
Es responsable de la configuración del plan de proceso.
Genera la programación global del sistema de manufactura.
Evalúa el costo de (re)configuración de la holarquía.
Ajusta la configuración (insuficiencia o falla de recursos).
Es responsable de la negociación.
Capítulo 3
46
Está a cargo de resolver los conflictos derivados de una perturbación reportada.
Supervisa la tardanza, el progreso y el estado del total de holones integrados al
sistema.
f) Estado
Finalmente, en la Figura 3.6 se muestra la clase Estado que incluye información que
describe el estatus de los distintos conceptos de primer orden y de orden inferior de
manera dinámica en un instante particular del tiempo.
Figura 3.6. Estado. Monitoreo por instantes de tiempo.
3.2.4.2. Taxonomía de conceptos de tercer orden o atributos de asociación
Otro aspecto de importancia son los atributos asociados a cada clase. La Figura 3.7
presenta conceptos de tercer orden de la clase Propiedades (mostrada en la parte
inferior de la Figura 3.3) donde un concepto es el atributo de otro concepto. Por ejemplo,
el nombre del recurso es el atributo de la propiedad que corresponde con un recurso
específico.
PROPUESTA DE ONTOLOGÍA UNIFICADA
47
Figura 3.7. Un concepto es el atributo de otro concepto.
El ejemplo de clases de atributos mostrado en la Figura 3.7 es útil para los distintos tipos de
recursos flexibles existentes en el sistema, puesto que en todos son necesarios el ID,
Nombre y Tipo, sin embargo, pueden existir más atributos dependiendo de la clase.
Ejemplos de éstos son: Ejes, TipoProceso, Repetibilidad, VelocidadAvance, VelocidadEje,
VelocidadCorto, Contrapuntos, CargaUtil, MaxAlcanzabilidad, Autonomía,
Capacidades, entre otros. Para el caso de la clase OrdenCliente, los atributos asociados
podrían ser: idOrden, fechaSolicitud, fechaEntrega, etc. En la clase OrdenTrabajo sería
conveniente enlistar los siguientes atributos: idOrden, idOrdenManufactura,
estadoOrdenTrabajo, entre otras. Como un ejemplo final, la clase Operacion incluye entre
otros atributos: idOperacion, fechaEntrega, fechaLanzamiento, fechaProgramada, etc.
Para introducir al lector en el nivel de detalle necesario en toda ontología y atender lo
dicho en el párrafo anterior, la Tabla 3.2 amplía el número de atributos asociados con
algunas clases dadas en la Figura 3.3, siendo éstos sólo algunos ejemplos.
Es importante notar que los atributos alojan primitivas (elementos atómicos como
números o strings de caracteres), variables o términos que formarán parte de la
información compartida por los holones y que serán críticos en las decisiones que éstos
tomen.
Capítulo 3
48
Tabla 3.2. Ejemplo de clases y atributos.
Clases Atributos
Cliente + idCliente: integer
- nombreCliente: string
- direccionCliente: string
OrdenCliente
+ idOrden: integer
- fechaSolicitud: date
- fechaEntrega: date
- Prioridad: chart
- listaProductosOrdenados: ArrayList<Productos>
- unidadesPorProducto: Chart
- EstadoOrden: string
Producto + idProducto: integer
+ nombreProducto: string
- tipoProducto: string
+ costoProducto: numeric
+ idOrden: integer
+ cantidad: char
+ unidades: char
+ fechaVencimiento: date
+ EstadoProducto: string
SpecifModelo + idProducto: integer
+ idModel: integer
+ formaGeometrica: string
+ tipoMaterial: string
+ parametrosMfg: string
+ idPropModelo: integer
PropModel + idPropModel: integer
+ idModel: integer
+ MP: char
+ Diseño: CAD
+ Imagen: Pictures
+ Dimensiones: string
+ documentacionTecnica: string
MP
+ idMp: integer
- nombreMP: string
- tipoMP: string
- descMP: varchar
+ costoMP: numeric
+ numeroCatalogo: integer
- EstadoMP: string
Ensamble + idEnsamble: integer
- nombreEnsamble: string
+ tipoOperacion: string
+ componentesEnsamble: arrayList< Ensambles >
+ relacionProcedencia : arrayList< Operaciones >
PROPUESTA DE ONTOLOGÍA UNIFICADA
49
+ EstadoEnsamble: string
EspecifProceso
+ idProducto: integer
+ idEspecifProceso: integer
+ nombreEspecifProceso: string
PlanProcesos + idEspecifProceso: integer
+ idProducto: integer
+ idPlanProcesos: integer
+ listaOperaciones: ArrayList< Operaciones >
+ secuenciaOperaciones: ArrayList< Secuenciado >
Operacion + idOperacion: integer
+ nombreOperacion: string
+ tiempoEstimadoProcesamiento : ArrayList< Time >
+ Descripcion: varchar
+ Precedencia: varchar
+ requerimientosTecnicos: varchar
+ operacionConcluida: Boolean
+ operacionEntregada: Boolean
+ operacionMaquinadoCNC: Boolean
+ operacionEnsamble: Boolean
+ EstadoOperacion: string
OrdenManufactura + idOrdenManufactura: integer
+ listaOrdenes: ArrayList< Ordenes >
+ numeroOrden: integer
+ listaProductosOrdenados: ArrayList< Productos >
+ numeroProductos: integer
+ fechaEntrega: data
OrdenTrabajo + idOrdenTrabajo: integer
+ idOrder: integer
+ idOrdenManufactura: integer
+ EstadoOrdenTrabajo: integer
+ idOperacion: integer
+ idEnsamble: integer
Recurso + idRecurso: integer
+ tipoRecurso: chart
+ EstadoRecurso: string
Suministros + idSuministro: integer
+ nombreSuministro: chart
+ tipoSuministro: chart
+ EstadoSuministro: string
R_Procesamiento + idCNC: integer
+ ubicacionSuministros: integer
+ ubicacionHerramental: integer
+ ubicacionDispositivo: integer
+ ubicacionMPAlmacen: integer
+ Propiedades: ArrayList< propiedades >
Capítulo 3
50
De esta manera, una clase Cliente admite un rango de datos producto que pueden ser
solicitados así como el objeto Producto contiene datos de los diferentes modelos de
productos. Una Orden posee datos de asociación entre los diferentes tipos de órdenes
que capturan el aspecto logístico de la producción como: tiempos fijos, la cantidad y
tipo de recursos contratados. La clase Operación administra datos de los métodos y del
proceso de producción, además de que captura el tipo de operación y la descripción
técnica del funcionamiento. El concepto Recurso representa la capacidad y los registros
históricos de funcionamiento, rendimiento, orden y producto. La clase Holon captura las
distintas subclases de los holones, así como la clase HolonAccion contiene posibles
acciones de cada holón para cambiar su entorno interno y afectar el exterior, si es
necesario.
3.2.4.3. Predicados
Al igual que en la propuesta ontológica ADACOR [11], en los enfoques basados en el
control de MAS o manufactura holónica, el control se consigue mediante la interacción
entre las entidades distribuidas, es decir, los agentes o Holones. Un holón en ADACOR es
una entidad que representa la manufactura de componentes como recursos,
productos o pedidos, etc. Así, los predicados establecen relaciones entre conceptos,
por ejemplo:
Componente(x, y): x producto es un componente del producto y.
Asignacion(x, y, t): la operación x se asigna a los recursos y en el tiempo t.
Disponibilidad(x, y, t): el recurso x está disponible en el momento t para la
operación y.
RequisitoHerramental(x, y): la ejecución de la operación x requiere de la
herramienta y.
PoseeHerramental(x, y, t): el recurso x posee la herramienta y, y está disponible en
el tiempo t.
PoseeHabilidad(x, y): el recurso x tiene la habilidad (propiedad) y.
PoseeFalla(x, y, t): una perturbación x ocurrió en el recurso y en el tiempo t.
PROPUESTA DE ONTOLOGÍA UNIFICADA
51
Propuesta(x, y, w, z, u): la entidad x propone a la entidad y la ejecución de la orden
de trabajo w con la ubicación u a un precio z. Una entidad es un agente u holón
que representa a un componente de manufactura como un recurso, producto o
pedido, y el enfoque del control de manufactura holónico se consigue mediante la
interacción entre las entidades distribuidas.
Precedencia(x, y): la operación x requiere de la ejecución anterior de la operación
y.
UsosMateriasPrimas(x, y): la orden de producción x utiliza la materia prima y.
RequisitoConfiguracion(x, y): la operación x necesita la ejecución de la
configuración y.
PoseePlanProceso(x, y): la producción de x requiere del plan de proceso y.
EjecucionOrden(u, x, w, y): la operación u parte el plan de proceso w (que describe
la producción de y) para la orden de producción x.
PoseeRequisito(x, y): x operación requiere de la propiedad y.
PoseeGripper(x, y, t): el recurso x tiene el gripper y en el tiempo t.
EjecucionOperacion(x, y): la orden de trabajo x incluye la operación y.
Si estos predicados están disponibles, una agenda puede definirse como un conjunto de
asignaciones x, y, i disponibles para x, y, t predicados. Donde por ejemplo, la agenda
implicaría una orden de trabajo x, con una operación y, asignada a un recurso i, cuya
disponibilidad del recurso requiere del dispositivo x, la configuración y, por un tiempo
t.
Con los ejemplos dados, es importante imaginar que la variedad de atributos y
predicados es alta, pero esta tarea de inferir atributos y establecer predicados a partir
de las clases de conceptos dados en la presente investigación es propia del diseñador
de enfoques holónicos para casos distintos pues depende en gran medida del sistema
de manufactura al cual pretenda aplicarse.
Capítulo 3
52
3.3. COMENTARIOS
Para concluir el capítulo, se hacen notar que en la Figura 3.3, los conceptos que
estructuran a un producto, una orden, operaciones, planes de proceso, etc. son parte
de los componentes necesarios para activar una acción en los holones (Figuras 3.4 y 3.5).
Así, los conceptos, atributos y predicados propuestos en la investigación se podrán
controlar desde la perspectiva ontológica, pues esta última ofrece una categorización
distinta para cada tipo de entidades. Con ello, los holones pueden representar distintos
conceptos. Por ejemplo, el HolonOrden puede simbolizar órdenes de clientes, órdenes
de trabajo, órdenes de manufactura e incluso órdenes de mantenimiento. Asimismo, los
holones producto se pueden dividir en varias familias de productos y modelos, los cuales
se integren por materia prima, ensambles o sub-ensambles. Y más importante aún, los
elementos que son parte de cada holón (atributos) pueden compartirse con otros
holones por medio de una oración válida (con todo el protocolo que implica un mensaje
en la plataforma JADE) que incluya una ontología.
De esta manera, las descripciones se modelan explícitamente como entidades
abstractas y las propiedades se prestan a través de cualidades asociadas. Para probar
lo dicho, el siguiente capítulo muestra de manera ejemplar la forma en que opera el
protocolo de comunicación entre holones haciendo uso de la ontología propuesta en
un caso de estudio experimental.
3.4. BIBLIOGRAFÍA
[1] SHEN, W.; NORRIE, D.H.; BARTHÈS A. Multi-agent systems for concurrent intelligent
design and manufacturing. London EC4P 4EE: Taylor & Francis Group, 2001. pp.
30–47. ISBN 0-7484-0882-7
[2] GÓMEZ-PÉREZ, A.; FERNÁNDEZ, M.; VICENTE, A. DE. Towards a method to
conceptualize domain ontologies. 12th European Conference on Artificial
Intelligence (ECAI’96). 1996, pp. 41–51.
[3] USCHOLD, M.; GRUNINGER, M. Ontologies: principles, methods and applications.
Knowledge Engineering Review. 1996, Vol. 11, No. 2, pp. 93–136.
PROPUESTA DE ONTOLOGÍA UNIFICADA
53
[4] NOY, N.F.; MCGUINNESS, D.L. Ontology development 101: A guide to creating
your first ontology. [online] Stanford University, Stanford, CA, 94305. 2001.
Disponible en:
http://liris.cnrs.fr/alain.mille/enseignements/Ecole_Centrale/What%20is%20an%2
0ontology%20and%20why%20we%20need%20it.htm
[5] CORCHO, O.; FERNÁNDEZ-LÓPEZ, M.; GÓMEZ-PÉREZ, A. Methodologies, tools and
languages for building ontologies. Where is their meeting point? Data &
Knowledge Engineering. 2003, Vol. 46, pp.41–64.
[6] FERNÁNDEZ, M.; GÓMEZ-PÉREZ, A.; URISTO, N. Methontology: From ontological art
towards ontological engineering. AAAI Technical Report. 1997, pp. 33–40.
[7] CHECA, R.D.; ROJAS, A. O. Ontología para los sistemas holónicos de
manufactura basados en la unidad de producción. Revista Colombiana de
Tecnologías de Avanzada. 2014, Vol. 1, No. 23, pp.134–141.
[8] BELLIFEMINE, F.; CAIRE, G.; GREENWOOD, D. Developing multi-agent systems with
JADE. Wiley Series in Agent Technology, Series Editor: Michael Wooldridge,
Liverpool University, UK. 2004. 286 p. ISBN: 978-0-470-05747-6 (HB)
[9] LEMAIGNAN, S.; SIADAT, A.; DANTAN, J.Y.; SEMENENKO, A. MASON: A Proposal For
An Ontology Of Manufacturing Domain. Distributed Intelligent Systems:
Collective Intelligence and Its Applications (DIS’06). 2006. pp. 195–200.
[10] LÓPEZ-ORTEGA, O.; RAMÍREZ-HERNÁNDEZ, M. A formal framework to integrate
express data models in an extended enterprise context. Journal of intelligent
manufacturing. 2007, Vol. 18, No. 3, pp. 371–381.
[11] BORGO, S; LEITÃO, P. Foundations for a Core Ontology of Manufacturing.
Ontology Handbook, Laboratory for Applied Ontology, ISTC-CNR, via Solteri 38,
38100 Trento, Italy. 2007, pp. 751–775.
Capítulo 3
54
4. RESULTADOS EXPERIMENTALES
ESQUEMA DEL CAPÍTULO
4.1 INTRODUCCIÓN
4.2 CONDICIONES EXPERIMENTALES
4.3 IMPLEMENTACIÓN DE LA ONTOLOGÍA PROPUESTA
4.3.1 Celda de manufactura flexible de la UAEH
4.3.2 Integración y programación de ontología
4.4 PROTOCOLO DE COMUNICACIÓN
4.5 COMENTARIOS
4.6 DISCUSIÓN
4.7 BIBLIOGRAFÍA
El objetivo de este capítulo es mostrar los resultados experimentales de la ontología
unificada como otra contribución original del trabajo de investigación y probar,
mediante un ejercicio, que haciendo uso de una ontología es posible que los elementos
(holones) de un entorno de manufactura distribuido sean autónomos, estén dotados de
un conocimiento dinámico del sistema y puedan comunicarse para formar holarquías
en respuesta a condiciones cambiantes de su entorno.
Para atender lo antes dicho, en la Sección 4.1 se da una breve introducción al tema. Por
otro lado, en la Sección 4.2 se establecen las condiciones bajo las cuales es desarrollado
el experimento. Seguido a lo anterior, en la Sección 4.3, se describe un caso de estudio
particular, mismo que es revisado y puesto a prueba. En la Sección 4.4 se representa una
descripción general de protocolos de comunicación entre holones ejemplificados, y
para concluir el capítulo, en las Secciones 4.5 y 4.6 se hacen comentarios y se da una
discusión del tema, respectivamente.
4
Capítulo 4
56
4.1. INTRODUCCIÓN
El interés de aplicar la ontología unificada a un sistema real es de vital importancia dado
que los resultados observados son esenciales en el ciclo de vida de la misma. Por lo que,
para dar seguimiento a la metodología empleada en la concepción de la ontología, el
siguiente apartado se refiere a la fase de implementación, donde es integrada y
programada la ontología en un software específico, con la finalidad de crear holones
capaces de dotarse de conocimiento y compartir este mismo con algunos holones más
en un sistema distribuido y caracterizado por atributos de una celda de manufactura
particular.
Lo anterior es válido dado que en la literatura revisada son propuestas ontologías
limitadas y que carecen de experimentación, sin ella, es difícil lograr un sistema de
retroalimentación, y mucho menos permisible apreciar si realmente es o no factible la
comunicación entre holones, y más aún, si la información compartida es válida, formal
y explicita.
4.2. CONDICIONES EXPERIMENTALES
Las condiciones bajo la cuales se realizó el ejercicio experimental son las siguientes:
Se hace uso de conceptos, predicados, atributos y métodos integrados a la
ontología propuesta en el Capítulo 3.
Son analizadas y tomadas las características de la celda de manufactura del Área
Académica de Ingeniería Industrial de la Universidad Autónoma del Estado de
Hidalgo (UAEH).
La ontología es integrada en el software PROTÉGÉ.
El modelo es programado en una plataforma de múltiples agentes JADE.
Para el protocolo de comunicación, se hace uso de las especificaciones FIPA.
Para observar cómo se comparte la información, se ejemplifica la interacción entre
los holones: adquisición, producto y orden.
Por último, se hacen comentarios y discusiones del ejercicio.
Los resultados del ejercicio pueden observarse en tiempo real en JADE.
RESULTADOS EXPERIMENTALES
57
4.3. IMPLEMENTACIÓN DE LA ONTOLOGÍA PROPUESTA
La presente sección describe las principales características de la celda de manufactura
del Área Académica de Ingeniería Industrial de la Universidad Autónoma del Estado de
Hidalgo (UAEH), la cual es usada como caso de estudio en la investigación. Tambien, se
puntualiza sobre la integración y programación de la ontología y se concluye con un
ejemplo de protocolos de comunicación con la intención de evidenciar la aplicabilidad
de la ontología.
4.3.1. Celda de manufactura flexible de la UAEH
Una Celda de Manufactura Flexible (CMF) usualmente consta de dos o más máquinas
de control numérico, de robots industriales como sistemas automáticos para el manejo
de materiales, de un sistema de almacenamiento y recuperación para almacenar
materia prima y producto terminado, y de un conveyor que mediante pallets transporta
materia prima o componentes tipo prismáticos a los diferentes recursos del sistema para
ser procesados [1]. La celda es controlada por una computadora que a menudo se
ejecuta por controles programables, además de que estos sistemas pueden operar con
poca o sin asistencia humana, al igual que un SMF, pero con mezcla de piezas en
menores cantidades [2].
En la Figura 4.1 se muestra la celda de manufactura del Área Académica de Ingeniería
Industrial de la UAEH que servirá como caso de estudio para la presente investigación.
Esta celda está equipada con tres estaciones de trabajo e integrada por una banda
transportadora, y un software de operación y control de nombre Open CIM.
Los recursos disponibles en la celda de manufactura se clasifican como sigue:
Almacenamiento. El almacén automático (ASRS36u) de la estación 1 está integrado
por un robot cartesiano (36ASRS1) dedicado a transferir y recuperar partes entre las
celdas del almacén y los pallets detenidos en la estación de trabajo “CNV(1)” de la
banda transportadora.
Transporte. Se hace uso de un Conveyor de lazo cerrado integrado por cinco pallets
(P1, P2, P3, P4, P5) para el transporte de materia prima o componentes entre recursos.
Capítulo 4
58
Manipulación. Los robots “ROBOT2” y “ROBOT3” están encargados de la
manipulación y ensamble en las estaciones 2 y 3, respectivamente.
Procesamiento. Un centro de torneado (TURN01) y un centro de fresado (MILL01)
manufacturan los productos en la estación 2.
Figura 4.1. Celda de manufactura de la UAEH. 1) Plano esquemático, 2) imagen de
toda la celda, y 3) imagen de la estación 2.
Adicionalmente, se cuenta con dos áreas de ensamble, una para la agregación de
balines (BALLFDR1) y la otra para la adición de pegamento (GLUE1), además de un área
de inspección de calidad operada por un sistema de visión. El software Open CIM
RESULTADOS EXPERIMENTALES
59
proporciona seguimiento y rastreo de los contenidos del ASRS (Automatic Storage and
Retrieval System), permite el control en tiempo real de los inventarios, y controla las
operaciones de almacenaje y recuperación de la unidad.
La orden de un cliente puede constituirse hasta por tres tipos de productos distintos:
MILL_TEST, TURN_TEST y GAME-PROD. Los dos primeros productos requieren de materia
prima (ACRÍLICO y CILINDRO), mientras el último de ellos necesita de un sub-ensamble,
por lo que hace necesaria la demanda de componentes (BASE_JUEGO, BALINES y
TAPA_JUEGO). Véase lista de materiales (Bill of Material, BOM) en la Figura 4.2.
Figura 4.2. BOM. 1) MILL_TEST, 2) TURN_TST y 3) GAME-PRO
El abastecimiento tanto de materia prima como de los componentes BASE_JUEGO y
TAPA_JUEGO es responsabilidad del almacén automático (ASRS1) de la celda de
manufactura, el cual cuenta con suficientes elementos disponibles para la orden. Para
la tarea de sub-ensamble se requiere del suministro de “BALINES”, y en el ensamble se
hace necesario la agregación de “PEGAMENTO”. El abastecimiento tanto en el sistema
alimentador de balines como en la unidad automática de pegado es asumido
previamente y de manera suficiente por el administrador del sistema. La Tabla 4.1
Capítulo 4
60
muestra las diferentes partes y los datos característicos de las mismas para su
identificación.
Tabla 4.1. Datos característicos de la materia prima, los componentes y los productos.
Nombre de
la parte
ID de
la
parte
Número
de
Catalogo
Suministro No. de
modelo
Parámetros
de
manufactura
Descripción
ACRÍLICO 11 ACR001 ASRS1 020001 $TEMPLATEID Block de acrílico
CILINDRO 1 CIL001 ASRS1 010001 $TEMPLATEID Cilindro de bronce
BASE_JUEGO 21 BAS001 ASRS1 030001 ASRS1 Base de acrílico para el juego
TAPA_JUEGO 31 TAP001 ASRS1 040001 ASRS1 Tapa de acrílico para el juego
BALINES BAL001 BALLFDR1 - - Balines para el sub-ensamble
del juego
PEGAMENTO 44 PEG001 GLUE1 - - Pegamento para ensamble
final
MILL_TEST 19 - - 020001 ASRS1 Producto final de fresado
TURN_TEST 9 - - 010001 ASRS1 Producto final de torneado
GAME-PROD 22 - - 030001 RACK1 Producto final de ensamble
4.3.2. Integración y programación de ontología
Como se dijo en el Capítulo 2, “En cierto modo, una holarquía es una combinación de
una jerarquía y una heterarquía”. Dentro de un holón, todo sub-holón puede organizarse
como una heterarquía, mientras que la holarquía general está organizada
jerárquicamente. Así, en los HMS los holones se agrupan recursivamente a partir de
holones de alto nivel hasta que finalmente la fábrica es representada por una holarquía.
En este apartado, son puestos a prueba ejemplos simples de roles y comportamientos de
holones característicos haciendo uso de los conceptos propios de la celda de
manufactura del Área Académica de Ingeniería Industrial de la UAEH, en una
plataforma JADE. Para tal caso, se hace uso de una adaptación del asignador para las
ontologías OWL (Ontology Web Language) y el modelo interno JADE definido en la
referencia [3] e ilustrado en la Figura 4.3.
RESULTADOS EXPERIMENTALES
61
Figura 4.3. Mapeo entre OWL y JADE para el modelo antológico propuesto [3].
De esta manera, se genera una ontología con una implementación subyacente
inmediata para asegurar las operaciones de lenguajes JADE entre los distintos holones
(codificación, comprobación y decodificación de los mensajes).
4.3.2.1. Integración en PROTÉGÉ
La propuesta de la ontología unificada se integra mediante la herramienta PROTÉGÉ
(formato, OWLSimpleJADEAbstractOntology.owl) bajo los términos recomendados por la
OWL que utiliza clases para describir conceptos y predicados, y fija éstos como parte de
la aplicación ontológica [3]. De aquí, la ontología OWL, mostrada en la Figura 4.4, incluye
los siguientes elementos de interés en la presente investigación:
Clases, es decir, conceptos de dominio manufactura descritos en el tema
(“Formalización”) antes descrito.
Relaciones taxonómicas entre las mismas clases.
Propiedades del tipo de datos, como atributos de las clases (Tabla 3.2).
Propiedades de los objetos, es decir, las relaciones entre las clases (además de las
taxonómicas de los diagramas AUML).
Individuos, como son instancias (elementos) de las clases y propiedades.
Restricciones o limitaciones en las propiedades.
Capítulo 4
62
Figura 4.4. Integración de la ontología en PROTÉGÉ
Una ventaja importante al hacer uso de PROTÉGÉ es su capacidad para reescribir
archivos creados en PROTÉGÉ mediante código abierto como archivos Java haciendo
uso de la herramienta Ontology Bean Generator. De este modo la ontología FIPA es
compatible con Java, base para la plataforma multi-agent JADE. La Figura 4.5 muestra
las distintas clases y sus propiedades en JADE.
Nótese que para este ejercicio y en lo subsiguiente, los términos usados en la
“implementación” de la ontología propuesta son dados en idioma inglés. La razón deriva
de la practicidad en la declaración y programación de términos tanto en PROTÉGÉ
como en la plataforma JADE.
RESULTADOS EXPERIMENTALES
63
Figura 4.5. JADE. Programación de ontología.
En el paquete Ontology se define la clase principal “OntologyManufacturing” la cual
es una instancia de jade.content.onto.Ontology que a su vez requiere de la
agregación de un vocabulario con todos los conceptos que serán compartidos. Por
ejemplo, las clases: “order”, “product”, “operation”, “resource”, entre otras.
Adicionalmente, en esta misma clase fue necesario incorporar esquemas de acción
HolonActionSchema (clases: ManageCustomer, ManageOrder, ManageProces,
ManageResource, ManageSistemState, entre otras, implementadas como
Capítulo 4
64
HolonAction), mismos que implicarán la creación de un nuevo cliente, una orden o un
nuevo producto: CREATE_CUSTOMER, CREATE_ORDEN, CREATE_PRODUCT, entre otras
acciones.
4.3.2.2. Programación en JADE
Al iniciar la codificación en JADE la primera clase definida es
“VocabularyManufacturing” donde son establecidos slots y atributos de las diferentes
clases existentes en la ontología, clasificados estos últimos como vocabulario básico y
vocabulario para la ontología. La Tabla 4.2 da ejemplos del vocabulario usado.
Tabla 4.2. JADE. Código seccional del vocabulario usado.
//-------> Vocabulario de Manufactura
//-------> Vocabulario básico: Los siguientes son ejemplos de
// términos y primitivas como variables enteras y cadenas de
// caracteres: public static final int NEW_ORDER_CUSTOMER = 1;
public static final int MILL_TEST = 2;
public static final int TURN_TEST = 3;
public static final int GAME_PROD = 4;
public static final int ILLEGAL_OPERATION = 12;
public static final int CHOOSE_ANOTHER_PRODUCT = 13;
public static final String HOLONS = "Configuration_holon";
public static final String PRODUCT_HOLON = "Product_holon";
//-------> Vocabulario para la ontología: Cliente, Orden y Producto,
// son ejemplo de conceptos identificados con sus atributos
// (id, nombre, tipo, unidad, fecha, etc.).
public static final String CUSTOMER = "Customer";
public static final String CUSTOMER_ID = "id";
public static final String CUSTOMER_NAME = "name";
public static final String CUSTOMER_UNITS = "units";
-------
public static final String CREATE_ORDER = "Create_order";
public static final String CREATE_ORDER_NAME = "name";
-------
public static final String PRODUCT = "product";
public static final String PRODUCT_TYPE = "type";
public static final String PRODUCT_QUANTITY = "quantity";
public static final String PRODUCT_UNITS = "units";
public static final String PRODUCT_ORDERID = "orderId";
public static final String PRODUCT_DATE = "date";
RESULTADOS EXPERIMENTALES
65
Por otro lado, la clase “OntologyManufacturing” agrega los conceptos que serán
compartidos (order, product, operation, resource, entre otras), todos ellos definidos
con antelación en la clase “VocabularyManufacturing”. Adicionalmente, en esta
misma clase es necesaria la agregación de acciones (HolonAction) para cada holón
definido. Por ejemplo en la Tabla 4.3 el esquema de acción de cada holon es definido
como AgentActionSchema el cual implicar la creación de una nueva orden
(CREATE_ORDER) y la creación de productos (CREATE_PRODUCTS).
Tabla 4.3. JADE. Código seccional de la clase OntologyManufacturing.
// -------> Incialmente se hace una instancia a la ontología básica.
private OntologyManufacturing() {
super(ONTOLOGY_NAME, BasicOntology.getInstance());
try {
// -------> Son agregados los conceptos CustomerOrder y Producto.
// CustomerOrder
ConceptSchema cs = new ConceptSchema(CUSTOMER);
add(cs, CustomerOrder.class);
cs.add(CUSTOMER_ID, (PrimitiveSchema)
getSchema(BasicOntology.STRING), ObjectSchema.MANDATORY);
cs.add(CUSTOMER_NAME, (PrimitiveSchema)
getSchema(BasicOntology.STRING), ObjectSchema.MANDATORY);
cs.add(CUSTOMER_UNITS, (PrimitiveSchema)
getSchema(BasicOntology.FLOAT), ObjectSchema.MANDATORY);
// Product
add(cs = new ConceptSchema(PRODUCT), Product.class);
cs.add(PRODUCT_TYPE, (PrimitiveSchema)
getSchema(BasicOntology.INTEGER), ObjectSchema.MANDATORY);
cs.add(PRODUCT_QUANTITY, (PrimitiveSchema)
getSchema(BasicOntology.FLOAT), ObjectSchema.MANDATORY);
cs.add(PRODUCT_UNITS, (PrimitiveSchema)
getSchema(BasicOntology.FLOAT), ObjectSchema.MANDATORY);
cs.add(PRODUCT_ORDERID, (PrimitiveSchema)
getSchema(BasicOntology.STRING), ObjectSchema.MANDATORY);
cs.add(PRODUCT_DATE, (PrimitiveSchema)
getSchema(BasicOntology.DATE), ObjectSchema.MANDATORY);
// -------> Es agregada la acción de un agente “AgentActions”,
// en este ejemplo la acción implica crear una orden y agregar
// tantos productos a la orden como lo desee el cliente.
// ManageCustomer
Capítulo 4
66
AgentActionSchema as = new
AgentActionSchema(CREATE_ORDER);
add(as, ManageCustomer.class);
as.add(CREATE_ORDER_NAME, (PrimitiveSchema)
getSchema(BasicOntology.STRING), ObjectSchema.MANDATORY);
// ManageProducts
add(as = new AgentActionSchema(CREATE_PRODUCTS),
ManageProducts.class);
as.add(CREATE_PRODUCTS_TYPE, (PrimitiveSchema)
getSchema(BasicOntology.INTEGER), ObjectSchema.MANDATORY);
as.add(CREATE_PRODUCTS_QUANTITY, (PrimitiveSchema)
getSchema(BasicOntology.FLOAT), ObjectSchema.MANDATORY);
as.add(CREATE_PRODUCTS_ORDERID, (PrimitiveSchema)
getSchema(BasicOntology.STRING),
ObjectSchema.MANDATORY);
…
}
}// BankOntology
Hasta ahora se ha observado un pequeño fragmento del código incluido en las clases
“VocabularyManufacturing y OntologyManufacturing”. Subsecuentemente, se
muestra una sección del código incluido en los holones “AcquisitionHolon y
OrderHolon” como ejemplo para ilustrar en una siguiente sección cómo estos últimos se
comparten objetos de información de la ontología, y cómo actúan según sus acciones
definidas. De tal forma que son necesarias expresiones sobre el estado de sistema, por
ejemplo, true o false. Estas últimas se utilizan típicamente en mensajes de tipo INFORM,
QUERY-IF, etc.
Para iniciar es necesario que el administrador de la celda de manufactura interactúe
con la interfaz gráfica de usuario (“GUI” por sus siglas en inglés), para definir a un cliente
agregándole una orden con: productos, cantidades y una fecha de entrega, etc.
Posterior a ello, cuando el administrador solicita un pedido es creado en automático un
holón de nombre “AcquisitionHolon” (Tabla 5.4) quien interactúa tanto con la GUI
como con un segundo holón llamado OrderHolon.
Obsérvese en la Tabla 4.4 que son especificados códigos para que el holón
“AcquisitionHolon” haga una solicitud de tipo REQUEST con la cual se solicite al
“OrderHolon” la creación de un cliente nuevo y, subsecuentemente, se solicite a este
RESULTADOS EXPERIMENTALES
67
último holón una orden nueva mediante el acto de comunicación tipo QUERY_REF.
También se aprecia el uso de la instrucción sendMessage necesaria para la interacción
entre holones. Nótese la creación de un nuevo ACLMessage(performative) cuyo
contenido hace uso del método set para establecer un lenguaje y la ontología
específicos.
Tabla 4.4. JADE. Código seccional del AcquisitionHolon.
// -------> Se crea e implementa vocabulario en la nueva clase de
// holón AcquisitionHolon.
public class AcquisitionHolon extends
GuiAgent implements VocabularyManufacturing {
// -------------------------------------------------
void resetStatusGui() {
// -------> Es reestablecido el estado de la GUI.
myGui.resetStatus(); }
void createRequest() {
// -------> Se crea un proceso para que el holón haga la solicitud
// (request) de un cliente nuevo.
ManageCustomer ca = new ManageCustomer();
ca.setName("Order " + cnt++);
sendMessage(ACLMessage.REQUEST, ca); }
void requestProduct(CustomerOrder acc, float quantity) {
// -------> Se crea un proceso para que el holón solicite (request)
la realización de una orden
void queryInformation(CustomerOrder acc) {
// -Proceso para que el holon haga un consulta de la información
ManageSistemState info = new ManageSistemState();
info.setType(command);
info.setOrderId(acc.getId());
sendMessage(ACLMessage.QUERY_REF, info);
}
// -------> Métodos utilizados para identificar a un agentes capaces
// de crear a un nuevo cliente con su orden de productos.
// después de identificar a dicho Agente se inicia con el envío de
// mensajes.
void sendMessage(int performative, AgentAction action) {
if (server == null) lookupServer();
if (server == null) {
alertGui("Unable to localize the server! Operation
aborted!");
return; }
Capítulo 4
68
ACLMessage msg = new ACLMessage(performative);
msg.setLanguage(codec.getName());
msg.setOntology(ontology.getName());
try {
getContentManager().fillContent(msg, new Action(server,
action));
msg.addReceiver(server);
send(msg);
alertGui("Contacting server... Please wait!");
addBehaviour(new WaitServerResponse(this));
}
catch (Exception ex) { ex.printStackTrace(); } …}
En JADE cada método implica un comportamiento definido ligado a los holones
configurados para llevar acabo ciertas acciones. En este caso la definición y envío de
un nuevo mensaje.
De forma semejante en la Tabla 4.5, las clases y los atributos de la ontología son
asociados con métodos que activan acciones realizables por el “OrderHolon”. El
método get se usa para registrar el lenguaje y la ontología usada, así como para
conseguir las distintas acciones que serán ejecutadas si se cumplen una serie de
restricciones. Obsérvese que la agregación de comportamientos (addBehaviour) del
OrderHolon varía dependiendo tanto de tipo de mensaje (REQUEST o QUERY_REF) como
de las características mismas de la solicitud hechas por el AcquisitionHolon.
Tabla 4.5. JADE. Código seccional del OrderHolon.
// -------> Después de las acciones anteriores, el nuevo holón orden
// es creado y se le agrega el vocabulario.
public class OrderHolon extends
Agent implements VocabularyManufacturing{
// ---------------------------------------------------
protected void setup() {
// -------------------------------------------------------
// -------> Se registrar el lenguaje y la ontología usada.
getContentManager().registerLanguage(codec);
getContentManager().registerOntology(ontology);}
// -------------------------------------------------------
RESULTADOS EXPERIMENTALES
69
class ReceiveMessages extends CyclicBehaviour {
// -------> Son recibidas las solicitudes y consultas del holón
// adquisición.
// El holón inicia con los controladores apropiados para recibir
// mensajes.
public ReceiveMessages(Agent a) {
super(a);}
public void action() {
ACLMessage msg = receive();
if (msg == null) {block(); return; }
try {
ContentElement content = getContentManager().extractContent(msg);
Concept action = ((Action)content).getAction();
switch (msg.getPerformative()) {
case (ACLMessage.REQUEST):
System.out.println("Request from " +
msg.getSender().getLocalName());
if (action instanceof ManageCustomer)
addBehaviour(new HandleCreateRequest(myAgent, msg));
else if (action instanceof ManageOrders)
addBehaviour(new HandleOperation(myAgent, msg));
else replyNotUnderstood(msg);
break;
case (ACLMessage.QUERY_REF):
System.out.println("\nQuery from " +
msg.getSender().getLocalName());
if (action instanceof ManageSistemState)
addBehaviour(new HandleInformation(myAgent, msg));
else replyNotUnderstood(msg);
break;
default:
replyNotUnderstood(msg);
…}}}
// -------> Dependiendo de la petición del holón adquisición, el
// holón orden activa diferentes comportamientos, por ejemplo:
// administrar al cliente (ManageCustomer), administrar una orden
// (ManageOrders) o devolver un mensaje de no conformidad si el
// mismo no se cumplen las restricciones de cada mensaje
// (replyNotUnderstood).
Los comportamientos mostrados en la Tabla 4.5 dan referencias de códigos para distintas
acciones, por ejemplo: el HandleCreateReques hace una petición para crear a un
cliente, el comportamiento HandleOperation agrega productos a la cuenta del nuevo
Capítulo 4
70
cliente, HandleInformation muestra de manera visual al administrador del sistema la
orden del cliente con todos sus productos asociados, y finalmente replyNotUnderstood
regresa un mensaje de tipo “ACLMessage.NOT_UNDERSTOOD” en caso de no ser clara
alguna instrucción. Sin embargo, son usados muchos más. De esta forma, las clases y los
atributos son asociadas con métodos que activan acciones realizables por diferentes
holones, ejemplos de éstos son:
+SolicitProducts():Solicit
+LoadSolicit():Void
+CreateOrdersList(POL, DueDate, Priority): CustomerOrder
+SolicitCustomerOrder(POL, DueDate, Priority): CustomerOrder
+CreateP.Holon(ModelDetails, ProcessDetails): ProductHolon
+LoadModelSpecificationDetails(): Void
+LoadProcessSpecificationDetails(): Void
+ProcessCapabilityDetails():Void
+OperationDetails():Void
+SelectionTypeResource():Void
+SelectionOpConfig():Void
Cada método implica un comportamiento específico (obedece a las propias
necesidades de los diferentes holones) ligado a holones configurados para llevar acabo
ciertas acciones. Detalles de esto pueden verse en el siguiente apartado.
4.4. PROTOCOLO DE COMUNICACIÓN
Naturalmente, como JADE es en gran parte una implementación de las especificaciones
FIPA, los holones hacen uso de un Lenguaje de Comunicación entre Agentes (Agent
Communication Language, ACL) definido por la FIPA (FIPA-ACL), acompañado de una
selección de lenguajes de contenido (Semantic Language FIPA, FIPA-SL) y de un
conjunto de protocolos de interacción que van desde el intercambio de un sólo mensaje
hasta transacciones complejas.
RESULTADOS EXPERIMENTALES
71
Lo antes descrito, requiere que el contenido de un mensaje tenga una semántica
adecuada de acuerdo con la performativa de una ACLMessage [4].
Es decir, un mensaje JADE es implementado como un objeto de la clase
jade.lang.acl.ACLMessage que provee los métodos get y set para tener acceso a
todos los archivos especificados por el formato FIPA-ACL, con lo que todas las
“peformatives” definidas en las especificaciones FIPA son mapeadas como constantes
en la clase ACLMessage. De tal forma que son necesarias expresiones sobre el estado
de sistema, por ejemplo, true o false. Estas últimas se utilizan típicamente en mensajes de
tipo INFORM, QUERY-IF, etc. Véase Tabla D.2 “Actos comunicativos de la FIPA” del
APÉNDICE D.
Subsecuentemente, y de forma generalizada, se muestra un ejemplo de la interacción
entre distintos holones según la acción que estos ejercen.
Tal como se explica en el tema A.3.1.7. “Ejemplo del comportamiento un HMS” del
APÉNDICE A, en un principio, el sistema de manufactura holónico se compone de un
conjunto de holones no organizados, esperando a ser solicitados. Al ejecutar la
aplicación, es creado automáticamente un holón de nombre “AcquisitionHolon”,
quien es responsable de solicitar mediante una interfaz gráfica “GUI” al administrador de
la celda de manufactura las características que definen a un nuevo cliente en el sistema
(nombre, teléfono y dirección). Véase código en la Tabla 4.4 e imagen gráfica en Figura
4.6. La información correspondiente al cliente es almacenada como un conjunto de
parámetros en la clase “Cliente” con las siguientes variables: private String
idCliente, private String nombreCliente, private float telefonoCliente
= 0 y private String direccionCliente.
Capítulo 4
72
Figura 4.6. GUI. Definición de nuevos cliente y órdenes.
Posterior a ello, cuando el administrador solicita una nueva orden “Create a new
order” en la interfaz gráfica, es creado automáticamente un holón de nombre
“OrderHolon” quien interactúa tanto con la interfaz “GUI” como con el primer holón
definido (Tablas 4.4 y 4.5 de la sección anterior). Es entonces cuando se inicia con el
protocolo de comunicación entre holones (Figura 4.7).
RESULTADOS EXPERIMENTALES
73
Figura 4.7. Protocolo de comunicación. AcquisitionHolon y OrderHolon.
Al solicitarse una nueva orden el AcquisitionHolon agrega el objeto CreateSolicit
donde es instanciada la clase “ManageCustomer” como una acción que incluye los
atributos del cliente (customerId, customerMame, etc.), mismos que son enviados
mediante un mensaje tipo REQUEST al OrderHolon. Con dicha información el receptor
actúa creando una nueva orden del cliente asignándole un identificador numérico
(orderId). Posterior a ello, el remitente (AcquisitionHolon) solicita nuevamente al
receptor (OrderHolon) que realice la acción de agregar un producto elegido por el
cliente a la nueva orden mediante un acto de petición. Así, la clase ManageOrders es
enviada al receptor quien después de generar un producto (generateProduct) realiza
Capítulo 4
74
otro acto comunicativo pero esta vez regresando la clase CustomerOrder que agrega
tanto las propiedades del cliente, la orden y un primer producto solicitado. Finalmente,
un último mensaje es enviado al OrderHolon solicitando agregar a la orden una lista de
todos los productos requeridos por el cliente (productsOrderedList:
ArrayList<Products>), sus cantidades (unitsPerProduct), la fecha de solicitud
(solicitDate) y el estado (custOrder_status) en el que se encuentra la nueva orden.
De esta manera, es posible que los holones compartan objetos compuestos en JADE,
sacando provecho de las capacidades para compartir e intercambiar conceptos de
la ontología a través de protocolos de comunicación adecuados.
La Tabla 4.6 muestra el método utilizado para el envío de mensajes. Primeramente, se
busca al holón que incluya ciertas características lookupServer(). Seguido a esto, se
especifica el lenguaje semántico: (import jade.content.lang.sl.*;) definido como
una sub-gramática de la sintaxis de expresiones más generales y se agrega este mismo
al mensaje msg.setLanguage(codec.getName()). De igual forma, en las clases Holons
se hace una instancia de la ontología usada (private Ontology ontology =
OntologiaManufactura.getInstance()) y se agrega al mismo el mensaje que será
compartido msg.setOntology(ontology.getName()). Finalmente, se define un
comportamiento en espera de respuesta por parte del holón receptor
addBehaviour(new EsperarServidorResponda(this)).
Tabla 4.6. JADE. Método usado en el envío de mensajes.
// -------> Antes de enviar el mensaje se busca a un servidor que
// cumpla con una serie de características.
void sendMessage(int performative, AgentAction action) {
// --------------------------------------------------------
if (server == null) lookupServer();
if (server == null) {
alertGui("Unable to localize the OrderHolon! Operation
aborted!");
return;
}
ACLMessage msg = new ACLMessage(performative);
msg.setLanguage(codec.getName());
RESULTADOS EXPERIMENTALES
75
msg.setOntology(ontology.getName());
try {
getContentManager().fillContent(msg, new Action(server,
action));
msg.addReceiver(server);
send(msg);
alertGui("Contacting server... Please wait!");
addBehaviour(new WaitServerResponse(this));
}
catch (Exception ex) { ex.printStackTrace(); }
}
// -------> El mensaje enviado incluye tanto la ontología
//(setOntology) como el lenguaje (setLanguage) que será usado,
// además de mecanismos de respuesta como: addBehaviour.
En JADE cada método implica un comportamiento definido ligado a los holones
configurados para llevar acabo ciertas acciones. En este caso la definición y envió de
un nuevo mensaje.
4.5. COMENTARIOS
El FIPA-ACL se fundamenta en la teoría del acto del habla que afirma que los mensajes
representan acciones o actos comunicativos. En los estándares del FIPA se establece que,
para ser plenamente compatible, un holón debe ser capaz de recibir cualquier mensaje
de acto comunicativo FIPA-ACL y por lo menos responder con un mensaje de “no
comprendido” si el mensaje recibido no puede ser procesado. Algunos de los actos más
comúnmente usados son informar, solicitar, aceptar, no comprendido y rechazado. Éstos
captan la esencia de la mayoría de las formas de comunicación básica.
El ejercicio descrito, muestra que la comunicación es un componente clave en los
holones, tanto con los usuarios del sistema, recursos del sistema, con ellos mismos y con
cualquier otro holón. En particular, se aprecia como los holones interactúan unos con
otros usando un lenguaje de comunicación específico y protocolos de interacción
predefinidos.
Ejemplos de los conceptos relevantes y de importancia para el dominio de manufactura
fueron modelados en una ontología capturando las asociaciones entre los términos,
Capítulo 4
76
asegurando el mismo tipo de comprensión del conocimiento intercambiado durante la
comunicación inter-holón.
Así, todas las conceptualizaciones (definiciones, categorizaciones, jerarquías,
propiedades, herencia, etc.) de una ontología pueden ser procesables por el ordenador,
puesto que la profundización semántica proporciona una descripción lógica y formal que
puede ser interpretada tanto por las personas, como por las máquinas, con lo que cada
uno de estos ejemplos de comportamientos obedece a las propias necesidades de los
diferentes holones.
4.6. DISCUSIÓN
Con este ejercicio se puede observar que los holones comparten propiedades con
objetos como: encapsulación, frecuencia, herencia y envío de mensajes. De esta
manera, los lenguajes de programación incluidos en los holones proporcionan
mecanismos que apoyan atributos y que implican creencias, metas, planes y normas.
Así, esta clase de holones abstractos, que tienen ya implementadas las funcionalidades
básicas de los agentes inteligentes (búsqueda de otros agentes, comunicación, gestión
de comportamientos, gestión de la línea de espera de mensajes, etc.), constituyen un
sistema de múltiples agentes que interactúan para resolver los problemas que están más
allá de las capacidades individuales y del conocimiento individual de cada agente
abstracto; extendiéndose el sistema para crear las clases que representan cada tipo
holón de un sistema de manufactura (holones producto, orden, recurso, configuración,
etc.) añadiendo en cada caso los comportamientos e interacciones de cada recurso
flexible.
Con ello, en entornos de manufactura distribuida cada holón es autónomo y tiene
conocimiento parcial del sistema con lo que el control holónico sobre los sistemas de
manufactura surge como un todo integrado de la interacción entre los holones
distribuidos, donde cada uno de éstos contribuye con su conocimiento local.
RESULTADOS EXPERIMENTALES
77
4.7. BIBLIOGRAFÍA
[1] OBERG, E.; JONES, F.D.; HORTON, H.L.; RYFFEL, H.H. Machinery´s Handbook (29th
Edition) & Guide to Machinery's Handbook. Industrial Press Retrieved from
www.knovel.com. 2012. pp. 3151–3160.
[2] VICHARE, P.; NASSEHI, A.; KUMAR, S.; NEWMAN, S.T. A unified manufactuting
resource model for representing CAN machining asystems. Robotics and
computer-integrated manufacturing. 2009, Vol. 25, No. 6, pp. 999–1007.
[3] LEMAIGNAN, S.; SIADAT, A.; DANTAN, J.Y.; SEMENENKO, A. MASON: A Proposal For
An Ontology Of Manufacturing Domain. Distributed Intelligent Systems:
Collective Intelligence and Its Applications (DIS’06). 2006. pp. 195–200.
[4] CAIRE, G.; CABANILLAS, D. JADE TUTORIAL, application-defined content
languages and ontologies. Support provided by JADE. 2010. pp. 1–30.
http://jade.tilab.com/doc/tutorials/CLOntoSupport.pdf
Capítulo 4
78
5. ESTUDIO COMPARATIVO
ESQUEMA DEL CAPÍTULO
5.1 INTRODUCCIÓN
5.2 ANÁLISIS COMPARATIVO DE ONTOLOGÍAS PARA HMS
5.2.1 Descripción de ontologías
5.2.2 Análisis comparativo
5.3 COMENTARIOS
5.4 DISCUSIÓN
5.5 BIBLIOGRAFÍA
El objetivo del presente capítulo es hacer un estudio comparativo de la ontología
propuesta con la finalidad de ver las ventajas que presenta la propuesta con respecto a
otros trabajos de investigación ya publicados en el tema.
La organización del capítulo es la siguiente: En la Sección 5.1 se da una introducción al
tema, en la Sección 5.2 se hace un análisis comparativo entre propuestas ontológicas y
la propuesta de investigación, en las Secciones 5.3 y 5.4 se comentan y discuten los
resultados del análisis.
5.1. INTRODUCCIÓN
En todo trabajo de vanguardia es importante comparar los resultados obtenidos con otros
trabajos ya publicados. Esto tiene como finalidad saber en dónde estamos ubicados,
cuáles son nuestras aportaciones en el campo de investigación, qué cuestionamientos
surgen de manera natural a partir del estudio comparativo, qué tan importante ha sido
nuestra contribución y cómo podemos planear trabajos de investigación futuros.
5
Capítulo 5
80
5.2. ANÁLISIS COMPARATIVO DE ONTOLOGÍAS PARA HMS
En este apartado se describe el análisis comparativo de la ontología propuesta con
respecto a ontologías prominentes en dominio de manufactura. Para el presente
estudio, fueron seleccionados 7 proyectos específicos. La infraestructura comparativa
incluye características generales como: la propuesta ontológica, su cobertura general y
dominio específico, el formalismo usado y los alcances en la experimentación o
aplicaciones asociadas. Se hace hincapié en las características que describen el
contenido de la ontología incluyendo: tipo de conceptos cubiertos (y estructura interna
de conceptos), predicados, su organización taxonómica, la representación natural de
la agregación de axiomas, y la representación de las relaciones “parte y todo” respecto
a los holones o agentes involucrados.
Los criterios para la selección de ontologías fueron: (1) obtener un conjunto de ontologías
en dominio de manufactura con aplicaciones holónicas, (2) utilizar ontologías que son
significativas en tamaño y relativamente bien desarrolladas, y (3) utilizar un conjunto
bastante bien documentado de ontologías (por lo menos documentadas lo
suficientemente como para poder integrarse a la mayoría de las variables que son
analizadas, sin embargo, no todos los datos están disponibles para todos los proyectos
en el estudio).
5.1.1. Descripción de ontologías
La arquitectura ontológica propuesta por [1], es presentada en el dominio de
manufactura. Su cobertura hace referencia a los conceptos ADACOR acordes con la
fundación ontológica DOLCE (Descriptive Ontology for Linguistic and Cognitive
Engineering) para la programación de la producción (especialmente organizados en la
producción tipo job shop) y control del entorno. La propuesta reúne aspectos holónicos
y de manufactura con bastante aserción: describe diagramas AUML de las clases
propuestas, define los conceptos usados, y da ejemplos de predicados y atributos
asociados. Sin embargo, a pesar de hacer una amplia investigación respecto a
ontologías, sistemas inteligentes y HMS bajo la propuesta alineada ADACOR-DOLCE, el
proyecto no es lo suficientemente explícito.
ESTUDIO COMPARATIVO
81
Bajo otro enfoque, en la referencia [2] se detalla una ontología concerniente a una red
de manufactura en los términos de la arquitectura PROSA. El documento pone de relieve
conocimientos base como conceptos y slots que constituyen a la propuesta, estos
últimos asociados a un conjunto de reglas que permite la elección de recursos para la
fabricación de un producto. Pese a dichas aportaciones, es evidente observar el uso de
términos no estandarizados lo que hace ambigua la comprensión de conceptos.
La referencia [3], hace una conjetura entre elementos de una ontología (conceptos,
atributos y relaciones), agrupados en lo relativos a “Esquemas Preconceptuales” (EP) y
al tema HMS. El objetivo de este trabajo es concebir un mecanismo automático que
permita a los analistas acercarse a la implementación de HMS en una organización,
representando sus procesos con EP e instanciándolos en una ontología propuesta. En
este caso, la ontología definida permite detectar conceptos holónicos en una
organización e identifica los holones principales que están implícitos en los procesos de
producción. Sin embargo, este trabajo se enfoca en listar y explicar brevemente los
elementos de la ontología propuesta, sin describir por completo una ontología de HMS,
es decir, no hace hincapié respecto a cómo estos conceptos se relacionan sobre
holones característicos. La evidencia de aplicaciones al tema es simple y sin resultados
destacados.
Asimismo, también existen documentos donde se describe el proceso mediante el cual
se creó una ontología de aplicación para HMS basados en la “Unidad de Producción”
(UP) o HMS-UP, como es el caso de la referencia [4]. El proyecto puntualiza las fases
necesarias para crear una ontología. Sin embargo, no se definen de manera clara y
precisa cada uno de los términos, conceptos y relaciones necesarias para integrar un
sistema de manufactura desde el enfoque holónico, no hay evidencia de tecnología
computacional en el diseño de la misma y tampoco se muestran resultados o
experimentos.
Estas últimas referencias y algunas más como las dadas por [5], [6] y [7], se resumen en
la Tabla 5.1, categorizándose según sus fortalezas y contribuciones.
Capítulo 5
82
Tabla 5.1. Resumen de fortaleza y contribuciones de ontologías revisadas.
Fortalezas y Contribuciones Ontologías
Cobertura en dominio específico Ontología (Borgo and Leitão, 2007 [1])
Ontología (Jules et al., 2015 [2])
Ontología (Checa and Rojas, 2014 [4])
Ontología (Uschold et al., 1998 [6])
Ontología (Lemaignan et al., 2006 [5])
Creación de formalismos bien definidos Ontología (Borgo and Leitão, 2007 [1])
Ontología (Jules et al., 2015 [2])
Ontología (Giraldo et al., 2013 [3])
Ontología (Uschold et al., 1998 [6])
Ontología (Lemaignan et al., 2006 [5])
Enfoques basados en datos lingüísticos y
normados
Ontología (Borgo and Leitão, 2007 [1])
Ontología (Uschold et al., 1998 [6])
Ontología (Lemaignan et al., 2006 [5])
Ontología (Raileanu et al., 2014 [7])
Niveles y jerarquía extendida Ontología (Jules et al., 2015 [2])
Ontología (Giraldo et al., 2013 [3])
Ontología (Checa and Rojas, 2014 [4])
Ontología (Lemaignan et al., 2006 [5])
Evaluación de ontología Ontología (Jules et al., 2015 [2])
Aplicación asociada Holón/Agente Ontología (Borgo and Leitão, 2007 [1])
Ontología (Jules et al., 2015 [2])
Ontología (Giraldo et al., 2013 [3])
Ontología (Lemaignan et al., 2006 [5])
Ontología (Raileanu et al., 2014 [7])
No obstante, aunque lo anterior es válido en cada proyecto particular, no es posible
apreciar uniformidad en los términos empleados por los diferentes autores, ya que
mientras en algunos artículos se describe el término “operación” en otros lo refieren
como “tarea o trabajo”, o cuando se habla de un “producto” algunos usan los términos
“ítem, entidad o pieza”. Las ontologías se constituyen por una enorme cantidad de
conceptos por lo que toda esta variedad de términos usados que tienen el mismo
significado pero que se refiere a ellos de diferentes formas representan un problema de
formalismo para aquellos investigadores que desean iniciarse en el paradigma holónico.
ESTUDIO COMPARATIVO
83
Además de que no son explícitas globalmente puesto que pocos autores hacen
hincapié en cómo se estructura, complementa, relaciona y define cada concepto
dentro de una ontología de manufactura.
Con lo que queda claro que, enfoques basados en ontologías unificadas son necesarios
para encontrar la "esencia" común de la información que se maneja, proporcionando
un análisis claro, sin ambigüedades y con un diseño simple e inequívoco.
5.1.2. Análisis comparativo
Las ontologías antes descritas, aportan términos a diferentes frecuencias respecto a;
conceptos, predicados, relaciones taxonómicas, axiomas y tipos de holones empleados;
términos que en su mayoría son necesarios para el uso del protocolo FIPA-ACL. En la
Tabla 5.2 se describe el contenido de las ontologías revisadas, contrastando al final con
la propuesta otológica definida en este documento. El propósito es evaluar la
aportación de cada ontología respecto a los diferentes términos dados, los cuales se
clasifican como: abundante, mínimo o ninguno.
Tabla 5.2. Evaluación de ontología propuesta.
Ontología Conceptos Predicados Relaciones
taxonómicas Axiomas
Holones/
Agentes
Ontología (Borgo and Leitão, 2007) √ √√ — — √√
Ontología (Jules et al., 2015) √√ √ — — √√
Ontología (Giraldo et al., 2013) √√ √ — — —
Ontología (Checa and Rojas, 2014) √√ — √ √ √
Ontología (Uschold et al., 1998) √ √ √ √ —
Ontología (Lemaignan et al., 2006) √ — √ — √
Ontología (Raileanu et al., 2014) √√ — √ — √
Ontología (Propuesta unificada) √√ √√ √√ √√ √√
√√ Se dan abundantes aportaciones al tema.
√ Se dan mínimas aportaciones al tema.
— No se dan aportaciones al tema.
Capítulo 5
84
Cada una de las propuestas antes revisadas dieron pasos significativos en un área
subdesarrollada de la investigación ontológica, sin embargo, pese a las fortalezas y
contribuciones de cada proyecto mostrado en las Tablas 5.1 y 5.2, tales como la
creación de contenido, la creación de formalismo medianamente definido en la
mayoría de los casos y los variados enfoques para el diseño de la ontología, se hizo
notoria la necesidad de una ontología suficientemente amplia, bien definida y con el
formalismo respectivo en dominio manufactura. Por lo que la propuesta unificada de la
presente investigación buscó avanzar en esta importante dirección.
5.3. COMENTARIOS
En cuanto a la integración de diversas ontologías, este estudio mostró que, en este punto,
existe una gran diversidad en la forma en que se diseñan las ontologías y en la forma en
que representan al mundo. Antes de que el verdadero intercambio de conocimientos y
reutilización sea práctico, deberían surgir algunos estándares en lo que debería consistir
una ontología, cuáles son las clases básicas de objeto que deben ser representadas (por
ejemplo, cosas, procesos, relaciones) y cómo están representadas (no en términos de
formalismo sino en términos de conocimiento que debería acompañar a los conceptos).
Creemos que un estudio como el que se presenta aquí es un paso útil en el proceso de
desarrollo de estas normas porque antes de tratar de estandarizar, primero, tenemos que
entender las alternativas.
5.4. DISCUSIÓN
El estudio presentó una ontología unificada en el dominio de manufactura la cual provee
una estructura taxonómica explícita y dotada de formalismo en beneficio de los HMS.
Las aportaciones al hacer uso de la antología se pueden resumir como sigue:
La ontología actúa con claridad como repositorio para la organización correcta del
conocimiento en el dominio de manufactura y sirve de herramienta para la
adquisición de información.
Al hacer uso de un vocabulario común es posible representar coherentemente el
conocimiento para toda clase de holones.
ESTUDIO COMPARATIVO
85
El formalismo que brinda la ontología propuesta permite hacer uso de un lenguaje
de comunicación específico acompañado de una selección de lenguajes de
contenido para el intercambio de conocimiento.
La ontología brinda la posibilidad de crear conjuntos de protocolos de interacción
claves que van desde el intercambio de un sólo mensaje hasta transacciones
complejas extendiendo el conocimiento a los diferentes holones.
La ontología permite la recuperación y reutilización del conocimiento de manera
específica y precisa.
5.5. BIBLIOGRAFÍA
[1] BORGO, S; LEITÃO, P. Foundations for a Core Ontology of Manufacturing.
Ontology Handbook, Laboratory for Applied Ontology, ISTC-CNR, via Solteri 38,
38100 Trento, Italy. 2007, pp. 751–775.
[2] JULES, G.; SAADAT, M.; SAEIDLOU, S. Holonic ontology and interaction protocol
for manufacturing network organization. IEEE Transactions on systems, man, and
cybernetics: systems. 2015, Vol. 45, No. 5, pp. 819–830.
[3] GIRALDO, G.; ARBOLEDA, A.; ZAPATA, G. Enfoque ontológico para detectar
conceptos holónicos en las organizaciones. Revista facultad de ingeniería
Universidad de Antioquia. 2013, Vol. 69, pp. 53–66.
[4] FERNÁNDEZ, M.; GÓMEZ-PÉREZ, A.; URISTO, N. Methontology: From ontological art
towards ontological engineering. AAAI Technical Report. 1997, pp. 33–40.
[5] LEMAIGNAN, S.; SIADAT, A.; DANTAN, J.Y.; SEMENENKO, A. MASON: A Proposal For
An Ontology Of Manufacturing Domain. Distributed Intelligent Systems:
Collective Intelligence and Its Applications (DIS’06). 2006. pp. 195–200.
[6] USCHOLD, M.; KING, M.; MORALEE, S.; ZORGIOS, Y. The enterprise ontology. The
knowledge engineering review. 1998 Vol. 13, No. 1, pp. 31–89.
[7] RAILEANU, S.; BORANGIU, T.; RADULESCU, S. Towards an ontology for distributed
manufacturing control. Service Orientation in Holonic and Multi-Agent
Capítulo 5
86
Manufacturing and Robotics, Part II. Springer, Studies in computational
intelligence 544. 2014, pp. 97–109.
6. CONCLUSIONES Y TRABAJO A FUTURO
ESQUEMA DEL CAPÍTULO
6.1 CONCLUSIONES
6.2 TRABAJO A FUTURO
6.1. CONCLUSIONES
Las expresiones formales en JADE, tanto en tiempo de desarrollo como de ejecución,
muestran cómo en un inicio cada holón ejemplificado posee conocimiento parcial del
sistema o una lista de habilidades necesarias para cooperar con otros holones
indirectamente (actuando sobre el medio ambiente) o de manera directa (vía
comunicación y negociación) para alcanzar sus objetivos o para obtener información
adicional sobre el sistema, compartiendo conocimiento para transformar el
conocimiento local en conocimiento global, siendo ésta la característica principal de
HMS. Así, el modelo arquitectónico de una aplicación orientada a holones es
intrínsecamente de igual a igual, es decir, cualquier holón es capaz de iniciar la
comunicación con cualquier otro holón o ser objeto de una comunicación entrante en
cualquier momento.
Por otro lado, dentro de las ventajas destacadas de la ontología propuesta se aprecia
que la misma sirve como repositorio para la organización correcta del conocimiento
(tanto el definido desde un inicio como el recuperado o reutilizado); hace uso de un
vocabulario común y normado; permite un lenguaje de comunicación transparente, y
específico; y admite protocolos de comunicación eficientes entre holones de semántica
bien definida, creando condiciones cruciales para la comunicación, misma que servirá
para alcanzar ambientes adecuados para la formación de holarquías, mecanismos de
negociación y colaboración.
6
88
De lo anterior se concluye que se cumplió satisfactoriamente el objetivo planteado en
el proyecto de investigación, desarrollando una ontología unificada en beneficio de la
representación del conocimiento dinámico del ambiente que rodea a los holones y de
la semántica de los mensajes intercambiados entre estos mismos, garantizando un
lenguaje de contenido universal necesario en la comunicación y cooperación de los
elementos de un HMS.
6.2. TRABAJO A FUTURO
Haciendo uso de la ontología propuesta, implementada en los capítulos 4 y 5,
respectivamente, se pudo observar que es complejo el hecho de formalizar,
implementar y experimentar con una ontología propia y aplicada a un sistema de
inteligencia artificial distribuida (en nuestro caso holones vistos como agentes
inteligentes). Este hecho nos impulsa hacer un esfuerzo por crear y mantener un
programa de mantenimiento que mejore constantemente la consistencia de la
ontología en este dominio.
Por otro lado, dado que el dominio de manufactura es amplio y puesto que aquí sólo
fueron consideradas entidades implicadas en la programación y control de la
producción, se buscarán estrategias para cubrir este último y desarrollar ontologías en
áreas relacionadas. Por lo que, en un futuro, áreas como: logística, cadena de
suministros, costos, recursos, mantenimiento, pronósticos y ventas, almacenes, control de
la calidad, etc. son áreas de oportunidad donde un sistema de manufactura holónico
puede extenderse.
Sin duda, lo aquí mostrado son resultados iniciales que dan pie a seguir avanzando en la
investigación con modelos de acción complejos para cada holón que cubran las
expectativas necesarias en el control de los sistemas de manufactura inteligentes. A
continuación se plantean los problemas a explorar en el trabajo a futuro.
Entendimiento correcto de los mecanismos de comportamiento social de los
organismos biológicos, químicos, e industriales, para crear modelos capaces de
lograr que las entidades de un sistema holónico busquen atender objetivos tanto
particulares como globales.
CONCLUSIONES Y TRABAJO A FUTURO
89
Creación de un modelo operativo completo de la interacción entre holones donde
la ontología propuesta sea usada en su totalidad como parte del flujo de la
información intercambiada.
Generación de modelos de negociación que permitan establecer autonomía en las
unidades de producción, modelos de actividad administrativa para la gestión de
recursos de manufactura que atiendan órdenes de trabajo, y modelos reactivos que
brinden a los recursos de producción la capacidad de reactividad ante eventos
inesperados, tanto internos como externos, que afectan su adecuado
funcionamiento, todo ello haciendo uso de conceptos en dominio de manufactura
consignados en la ontología propuesta.
Planteamiento de una arquitectura de control inteligente haciendo uso del
paradigma de manufactura holónico en las áreas de manufactura antes
mencionadas, que permita vincular flexibilidad, modularidad y control
descentralizado en un sistema de manufactura flexible.
