Modelo de gestión del proceso de fabricación basado en la ... · Mora, Felipe y Joan Carles. A...

Modelo de gestión del proceso de fabricación basado en la incorporación de conocimiento mediante ontologías

Aplicación a los sistemas de fabricación ágil

Antonio Ferrándiz Colmeiro

www.ua.es

www.eltallerdigital.com

UNIVERSIDAD DE ALICANTE

TESIS DOCTORAL

MODELO DE GESTIÓN DEL

PROCESO DE FABRICACIÓN

BASADO EN LA

INCORPORACIÓN DE

CONOCIMIENTO MEDIANTE

ONTOLOGÍAS

APLICACIÓN A LOS SISTEMAS DE

FABRICACIÓN ÁGIL

UNIVERSIDAD DE ALICANTE

TESIS DOCTORAL

MODELO DE GESTIÓN DEL

PROCESO DE FABRICACIÓN

BASADO EN LA

INCORPORACIÓN DE

CONOCIMIENTO MEDIANTE

ONTOLOGÍAS

APLICACIÓN A LOS SISTEMAS DE

FABRICACIÓN ÁGIL

Presentada por ANTONIO FERRÁNDIZ COLMEIRO

Dirigida por DR. FRANCISCO MACIÁ PÉREZ

DEPARTAMENTO DE TECNOLOGÍA INFORMÁTICA Y COMPUTACIÓN JULIO DE 2014

“Después de escalar una montaña muy alta,

descubrimos que hay muchas otras montañas por escalar.”

Nelson Mandela

Agradecimientos

Durante el desarrollo de este trabajo siento que han participado de una manera u otra muchas personas que han hecho posible desarrollarlo, y a las que querría expresar mi agradecimiento en estas líneas.

En primer lugar, me gustaría agradecer a Paco por su dedicación y esfuerzo durante todos estos años. ¡Quién nos iba a decir cuando llegué al departamento con una beca de 6 meses que llegaríamos hasta aquí! Durante estos años he aprendido muchísimas cosas de ti, tanto a nivel

académico como personal. Gracias por sacar un hueco siempre que lo he necesitado y por esforzarte en ayudarme en todo lo que te ha sido posible y más. Por el cariño con el que has supervisado este trabajo (y todos los que hemos hecho juntos) y por tus aportaciones tan enriquecedoras.

¡Gracias!

A mi familia por apoyarme y animarme siempre a no tirar la toalla. A mis padres por llevar toda la vida pendientes de mi, por no dudar ni un

momento cuando he necesitado algo y por animarme siempre a estudiar y superarme. También por preguntarme todos los domingos de los últimos seis años que cuando acababa la universidad y recibir siempre un “ya queda poco…”. A mis hermanas Isa y Ana por compartir conmigo

momentos de alegrías y penas, y por ser ese “diablillo” que me decía “chico déjate la tesis por hoy y vente a tomar unas cervezas”. A mis suegros Agustín y Carmen por tratar de ayudarme siempre en todo, y a

mis cuñados por interesarse y aconsejarme.

A toda la gente con la que he compartido vivencias en la Universidad. A mis compañeros del grupoM José Vicente, Jorge Selva, Héctor, Iren,

Mora, Felipe y Joan Carles. A Jorge Gea, con quien compartí penas esos días cuando no sabíamos que era “eso de las ontologías”. A Juan Antonio por acogerme durante dos años en la Escuela. A Diego por ayudarme siempre que lo he necesitado, por esas revisiones a nivel de pixel y sobre

todo por ese humor que siempre te saca una sonrisa. A mis compañeros Irene, Andrés, Oscar, Joaquín y Pepe que llegaron al “laboratorio Punset” para acabar con el silencio que allí había y darle mucha más alegría.

A Virgilio, por haber sacado un rato siempre para mí y porque sin su apoyo en los momentos iniciales, sin esos festivos revisando artículos, sin sus opiniones, sin sus aportaciones y sin su trabajo de tesis este

trabajo no habría sido posible. Por todo ello, este trabajo es un poco suyo también.

A mis compañeros de Teralco que siempre se han interesado por mi tesis y han valorado el esfuerzo que requiere. En especial a Javi que desde que entré a trabajar con él siempre me ha apoyado e ilusionado con este proyecto. ¡Ahora nos toca conseguir empezar un proyecto juntos!

A Dominique Gellez por la fotografía de la cubierta.

Por último quisiera dar las gracias a Carmen, por estar en los buenos y malos momentos, por tu apoyo, por tus ánimos, por enseñarme a no rendirme, por animarme a superarme, por ayudarme en los momentos difíciles con una sonrisa, por todo lo que hemos pasado y por todo lo que

tenemos que pasar. Cada día aprendo algo de ti. ¡Gracias!

Resumen

En la presente tesis se realiza un trabajo de investigación en el ámbito de la gestión de procesos aplicado a las organizaciones manufactureras. Concretamente se ha centrado en la integración y automatización de la gestión de los procesos de negocio y fabricación de forma que las

organizaciones manufactureras puedan acortar el ciclo de vida de los procesos, recortando su tiempo de respuesta ante las nuevas demandas de un mercado cada vez más orientado a la personalización masiva, y por lo tanto les sitúe en una posición ventajosa en un mercado de

competencia global.

El objetivo principal de la presente tesis es lograr un sistema de gestión ágil de procesos de negocio, que reduzca al mínimo la interacción

humana en el ciclo de vida de los procesos, haciendo transparente el nivel de planta, y automatizando la composición y posterior despliegue de los procesos de fabricación y negocio.

Para llevar a cabo el objetivo se ha realizado un estudio de los antecedentes y de los trabajos relacionados con los ámbitos en los que se ubica el problema. Este estudio ha permitido justificar el problema, plantear la hipótesis y proponer una solución novedosa con respecto a

los enfoques existentes en la línea de investigación.

La solución propuesta se basa en el concepto IMaaS (Industrial Machine

as a Service) en el que la maquinaria industrial es ofertada como servicio y sus capacidades productivas son conceptualizadas como procesos de negocio. IMaaS permite superar las brechas conceptuales y tecnológicas que hacían muy difícil la integración de los niveles de planta y de

negocio, permitiendo abordar de manera directa las nuevas necesidades de los sistemas de gestión ágil de procesos.

Como medio para lograr los objetivos planteados se realiza una

exhaustiva conceptualización de los dominios implicados, identificando los conceptos relevantes e identificando las relaciones entre ellos. Toda esta información se formaliza mediante una ontología que permite incorporar conocimiento semántico a IMaaS, a partir de la cual se puede

inferir nuevo conocimiento realizando una serie de razonamientos lógicos basados en cláusulas de Horn.

X Modelo de gestión de los procesos basado en conocimiento

Se identifican los elementos necesarios para lograr un sistema de gestión ágil de procesos de fabricación y negocio, y se define la arquitectura del sistema.

Para validar nuestra investigación, se ha implementado la solución propuesta; se ha diseñado un entorno realista donde se pudiera reproducir la problemática planteada en la investigación y finalmente se

han diseñado un conjunto de experimentos basados en la hipótesis de partida que han permitido demostrar la validez de la propuesta.

Resum

En la present tesi es realitza un treball de recerca en l'àmbit de la gestió de processos aplicat a les organitzacions manufactureres. Concretament s'ha centrat en la integració i automatització de la gestió dels processos de negoci i fabricació de manera que les organitzacions manufactureres

puguen escurçar el cicle de vida dels processos, retallant el seu temps de resposta davant les noves demandes d'un mercat cada vegada més orientat a la personalització massiva, i per tant els situe en una posició avantatjosa en un mercat de competència global.

L'objectiu principal de la present tesi és aconseguir un sistema de gestió àgil de processos de negoci, que reduïsca al mínim la interacció humana en el cicle de vida dels processos, fent transparent el nivell de planta, i

automatitzant la composició i posterior desplegament dels processos de fabricació i negoci.

Per a dur a terme l'objectiu s'ha realitzat un estudi dels antecedents i

dels treballs relacionats amb els àmbits en els quals se situa el problema. Aquest estudi ha permès justificar el problema, plantejar la hipòtesi i proposar una solució nova pel que fa als enfocaments existents en la línia de recerca.

La solució proposada es basa en el concepte IMaaS (Industrial Machine as a Service) en el qual la maquinària industrial és oferida com a servei i

les seues capacitats productives són conceptualitzades com a processos de negoci. IMaaS permet superar les bretxes conceptuals i tecnològiques que feien molt difícil la integració dels nivells de planta i de negoci, permetent abordar de manera directa les noves necessitats dels sistemes

de gestió àgil de processos.

Com a mitjà per a aconseguir els objectius plantejats es realitza una exhaustiva conceptualització dels dominis implicats, identificant els

conceptes rellevants i identificant les relacions entre ells. Tota aquesta informació es formalitza mitjançant una ontologia que permet incorporar coneixement semàntic a IMaaS, a partir de la qual es pot inferir nou coneixement realitzant una sèrie de raonaments lògics basats en

clàusules d'Horn.

XII Modelo de gestión de los procesos basado en conocimiento

S'identifiquen els elements necessaris per a aconseguir un sistema de gestió àgil de processos de fabricació i negoci, i es defineix l'arquitectura del sistema.

Per a validar la nostra recerca, s'ha implementat la solució proposada; s'ha dissenyat un entorn realista on es poguera reproduir la problemàtica plantejada en aquesta investigació; i finalment s'han

dissenyat un conjunt d'experiments basats en la hipòtesi de partida que han permès demostrar la validesa de la proposta.

Abstract

The following thesis presents a research work in the field of process management applied to manufacturing companies. The work has been particularly focused on the integration and automation of the business processes management and fabrication, so that manufacturing

companies are able to shorten the processes lifecycle, cutting down their response time against new market demands in an increasing mass personalization oriented environment, and thereby placing these companies in an advantageous position in a global competency market.

The main goal of the following thesis work is to achieve an agile management system of business processes which reduces to the minimum the human interaction in the processes lifecycle and makes

the plant level become transparent, thus automating both the composition and the later deployment of manufacturing processes and business.

In order to meet the objective, a background study has been carried out, and also a full revision of works related to the scope of the problem. Such study has allowed to justify the problem, set the hypothesis and propose a novel solution with regard to existent approaches in the same

investigation line.

The proposed solution is based on the IMaaS concept (Industrial

Machine as a Service), in which industrial machinery is offered as a service and its productive capabilities are conceptualized as business processes. IMaaS allows overcoming conceptual gaps and technological that made the integration of plant level and business a really challenging

issue, allowing to tackle directly the new needs of agile management system of processes.

A comprehensive conceptualization of the implied domains has been

carried out as a mean to achieve the proposed goals, identifying the relevant concepts and the relationships between them. All this information is formalized through an ontology, which permits to incorporate semantic knowledge to IMaaS, from which it is possible to

infer new knowledge by realizing a series of logical reasonings based on Horn clauses.

XIV Modelo de gestión de los procesos basado en conocimiento

The necessary elements are identified to achieve an agile management system of manufacturing processes and business. The system architecture is also defined according to lifecycle phases of the processes

defined in the BPM methodology.

The proposed solution has been implemented in order to validate the investigation. A realistic environment where the problem posed in this

investigation can be reproduced has been designed. Finally, a set of experiments based on the starting hypothesis have been performed in order to demonstrate the proposal validity.

Resumen del contenido

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

Capítulo 2. Estado del Arte .................................................................. 15

Capítulo 3. Antecedentes. IMaaS ......................................................... 43

Capítulo 4. Modelo de Gestión Semántica de Procesos Industriales ...... 71

Capítulo 5. Información Semántica IMaaS ........................................... 99

Capítulo 6. Gestión Semántica de los Procesos de Fabricación ........... 143

Capítulo 7. Implementación y Validación ........................................... 195

Capítulo 8. Conclusiones ................................................................... 257

Capítulo 9. Referencias ...................................................................... 265

Anexo I. Especificación Ontologías Plantas......................................... 277

Anexo II. Elementos Intermedios Methontology .................................. 291

Contenido

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

1.1 Identificación del Problema .......................................................... 6

1.2 Hipótesis ..................................................................................... 8

1.3 Objetivos ..................................................................................... 9

1.4 Propuesta de Solución ............................................................... 10

1.5 Metodología ............................................................................... 11

1.6 Plan de Trabajo .......................................................................... 13

Capítulo 2. Estado del Arte .................................................................. 15

2.1 Ontologías y Tecnologías de la Web Semántica .......................... 16

2.2 Teorías de Gestión de Procesos de Negocio ................................. 24

2.3 Modelos de Fabricación .............................................................. 33

Capítulo 3. Antecedentes. IMaaS ......................................................... 43

3.1 Normalización Conceptual de la Maquinaria Industrial .............. 44

3.1.1 Proceso de Normalización Conceptual de los Procesos de Fabricación de la Maquinaria Industrial ....................................... 45

3.1.2 Proceso de Normalización Conceptual de la Gestión de los Procesos de Negocio de la Maquinaria Industrial .......................... 51

3.2 Normalización Tecnológica de la Maquinaria Industrial .............. 53

3.2.1 Normalización Hardware de la Maquinaria Industrial .......... 55

3.2.2 Normalización del Middleware de la Maquinaria Industrial .. 58

3.2.3 Normalización de los Servicios de la Maquinaria Industrial .. 63

3.3 Conclusiones ............................................................................. 67

Capítulo 4. Modelo de Gestión Semántica de Procesos Industriales ...... 71

4.1 Modelo Conceptual de Gestión Semántica de Procesos Industriales ....................................................................................................... 74

XVIII Modelo de gestión de los procesos basado en conocimiento

4.1.1 Proceso de Definición de Información Semántica ................. 79

4.1.2 Proceso de Gestión Semántica de Procesos de Fabricación .. 84

4.2 Modelo Funcional de Gestión Semántica de Procesos Industriales ....................................................................................................... 87

4.3 Modelo Arquitectónico de Gestión Semántica de Procesos Industriales ..................................................................................... 95

Capítulo 5. Información Semántica IMaaS ........................................... 99

5.1 Conceptualización del Dominio Industrial IMaaS ..................... 100

5.1.1 Conceptualización del Nivel de Planta ................................ 102

5.1.2 Conceptualización del Nivel de Procesos ............................ 117

5.1.3 Conceptualización del Nivel de Servicios ............................ 126

5.2 Normalización y Conceptualización de los procesos BPMN........ 129

5.2.1 Representación de Conceptos BPM .................................... 130

5.2.2 Validación de los Procesos BPMN ...................................... 134

5.2.3 Instanciación de Procesos BPM ......................................... 137

Capítulo 6. Gestión Semántica de los Procesos de Fabricación ........... 143

6.1 Modelo de Composición Semántica de Procesos........................ 145

6.1.1 Manejador de Procesos ...................................................... 147

6.1.2 Manejador de Ontología de Planta ..................................... 152

6.1.3 Compositor de Procesos .................................................... 155

6.1.4 Selector de Procesos .......................................................... 165

6.2 Modelo de Compilación de Procesos ......................................... 167

6.2.1 Manejador de Servicios Semánticos ................................... 169

6.2.2 Compositor de Procesos .................................................... 176

6.2.3 Funcionalidad del Compilador de Procesos ........................ 179

6.3 Modelo de Ejecución y Monitorización de Procesos ................... 185

6.3.1 Monitor de Procesos .......................................................... 186

Capítulo 7. Implementación y Validación ........................................... 195

7.1 Diseño e Implementación del Escenario de Pruebas ................. 196

7.1.1 Planta IMaaS .................................................................... 197

7.1.2 Sistema de Información ..................................................... 206

Contenido XIX

7.1.3 Sistema de Gestión Semántica de Procesos de Fabricación. BPMS Semántico. ...................................................................... 207

7.2 Pruebas y Validación ............................................................... 208

7.2.1 Experimentación T1: Generación de un Proceso para n-plantas ...................................................................................... 213

7.2.2 Experimentación T2: Generación de Procesos Compuestos para n-plantas ........................................................................... 231

7.2.3 Experimentación T3: Regeneración ante Fallos de Planta ... 247

7.2.4 Conclusiones de la Experimentación Realizada .................. 253

Capítulo 8. Conclusiones ................................................................... 257

8.1 Principales Aportaciones .......................................................... 258

8.2 Problemas Abiertos .................................................................. 259

8.3 Líneas Futuras ........................................................................ 260

8.4 Publicaciones ........................................................................... 261

Capítulo 9. Referencias ...................................................................... 265

Anexo I. Especificación Ontologías Plantas......................................... 277

Anexo II. Elementos Intermedios Methontology .................................. 291

Índice de Figuras

Figura 1.1 Fases del ciclo de vida BPM. ............................................. 3 Figura 1.2 Brecha Conceptual y Tecnológica en la gestión de

procesos. .......................................................................... 5 Figura 1.3 Incremento de la demanda de productos

personalizados. ................................................................ 7 Figura 1.4 Propuesta General en el que, mediante la incorporación

de conocimiento, se automatizan tareas de gestión reduciendo el cuello de botella producido por el

incremento en la demanda personalizada. ...................... 10 Figura 1.5 Identificación de los elementos de la propuesta ............... 12 Figura 2.1 Pirámide de las tecnologías de la Web Semántica

(Koivunen & Miller, 2002). .............................................. 20

Figura 2.2 Ciclo de vida BPM (Smith & Fingar, 2002). ..................... 28 Figura 2.3 Brecha conceptual y tecnológica de BPM (Hepp et al.,

2005). ............................................................................ 30 Figura 2.4 Conceptos de la ontología ADACOR (Borgo & Leitao,

2007). ............................................................................ 36 Figura 2.5 Conceptos de mayor nivel de MASON (Lemaignan et al.,

2006). ............................................................................ 37 Figura 3.1 Proceso de normalización conceptual de la maquinaria

industrial (Gilart, 2010). ................................................. 45 Figura 3.2 Representación mediante modelado UML de la

definición y clasificación del concepto proceso de negocio. .......................................................................... 48

Figura 3.3 Representación mediante modelado UML de los procesos de fabricación. ................................................. 49

Figura 3.4 Modelado en UML del mapa de procesos de la maquinaria industrial..................................................... 51

Figura 3.5 Proceso de Normalización Tecnológica de la Maquinaria

Industrial. ...................................................................... 54 Figura 3.6 Modelo conceptual de la Maquinaria Industrial

Computacional. .............................................................. 57 Figura 3.7 Arquitectura resultante de la Maquinaria Industrial

Computacional. .............................................................. 58 Figura 3.8 Modelo de Capas de la arquitectura conceptual IMaaS.... 60 Figura 3.9 Servicios de fabricación de la maquinaria industrial. ...... 65

XXII Modelo de gestión de los procesos basado en conocimiento

Figura 3.10 Arquitectura IMaaS mínima que proporciona el proveedor de la maquinaria. ........................................... 66

Figura 3.11 Arquitectura IMaaS de la maquinaria industrial. ............ 68

Figura 4.1 Fases del Marco Formal para el modelado del ModGSPI. . 74 Figura 4.2 Proceso para la gestión semántica de procesos. .............. 75 Figura 4.3 Problema ente Usabilidad y Reusabilidad en Ontologías

(Gómez-Pérez et al., 2004). ............................................. 80

Figura 4.4 Modelado de tareas que componen el proceso �� expresadas mediante Casos de Uso. .... 82

Figura 4.5 Modelado de tareas que componen el proceso �� expresadas mediante Casos de Uso .......... 83

Figura 4.6 Modelado de tareas que componen el proceso �� expresadas mediante Casos de Uso. . 83

Figura 4.7 Modelado de tareas que componen el proceso �� expresadas mediante Casos de Uso. .......... 85

Figura 4.8 Modelado de tareas que componen el proceso �� expresadas mediante Casos de Uso. ........... 86

Figura 4.9 Modelado de tareas que componen el proceso �� centrado en las tareas de

monitorizacización, expresadas mediante Casos de Uso. . 86 Figura 4.10 Entradas y salidas del sistema propuesto. ...................... 88 Figura 4.11 Niveles conceptuales de la propuesta y su

correspondencia con los procesos conceptuales del ModConceptGSPI. ........................................................... 89

Figura 4.12 Elementos identificados en el Nivel de Planta para la realización del proceso de ejecución y monitorización

��. ............................................................. 90 Figura 4.13 Secuencia de la interacción entre los elementos

funcionales del Nivel de Planta. ...................................... 91 Figura 4.14 Elementos pertencientes al Nivel de Conocimiento. .......... 91 Figura 4.15 Elementos pertencientes al Nivel de Procesos de

Negocio. .......................................................................... 92 Figura 4.16 Secuencia de los elementos del Modelador de Procesos. .. 93 Figura 4.17 Secuencia de los elementos Compilador de Procesos....... 94

Figura 4.18 Secuencia de los elementos del Desplegador de

Servicios. ........................................................................ 95 Figura 4.19 Modelo arquitectónico ModArqGSPI propuesto. ............... 96

Figura 5.1 Ámbitos de conceptualización de la ontología IMaaS propuesta e interconexión con otras ontologías específicas de dominio. ................................................. 101

Figura 5.2 Taxonomía establecida de la Maquinaria Industrial. ...... 105

Figura 5.3 Clasificación de las Materias en el dominio industrial. .. 107 Figura 5.4 Clasificación de los tipos de Herramientas. ................... 107

Índice de Figuras XXIII

Figura 5.5 Clasificación de algunos de los tipos de Materiales. ....... 108 Figura 5.6 Relaciones binaria de las Cintas Transportadoras. ........ 109

Figura 5.7 Relaciones binarias de las Mesas de Giro. ..................... 110 Figura 5.8 Relaciones binarias del Raíl de Carga ........................... 111 Figura 5.9 Relación entre Máquina de Transporte y Máquina de

Procesado. .................................................................... 111

Figura 5.10 Relaciones de la Máquina Herramienta (a) y Máquina

Multi Herramienta (b). ................................................... 111 Figura 5.11 Relaciones entre los conceptos Herramientas y

Materiales. ................................................................... 112 Figura 5.12 Relaciones ente los conceptos Materia y Material. ......... 112 Figura 5.13 Relación binaria entre los conceptos Máquinas de

Transporte y Materia. .................................................... 113 Figura 5.14 Clasificación de los Procesos. ........................................ 121 Figura 5.15 Detalle de los procesos de Procesado. ........................... 121

Figura 5.16 Procesos de Ensamblaje................................................ 122 Figura 5.17 Procesos de Manejo de Material ..................................... 122 Figura 5.18 Procesos de Inspección y Test ....................................... 123

Figura 5.19 Procesos de Coordinación y Control. .............................. 123 Figura 5.20 Relación binaria ente Procesos de Transporte y

Máquinas de Transporte................................................ 123

Figura 5.21 Relación entre los conceptos Procesado y Máquinas de

Procesado. .................................................................... 124 Figura 5.22 Relación entre la Máquina de Almacenaje y los procesos

de Almacenaje. ............................................................. 124 Figura 5.23 Taxonomía de la clase Servicio. ..................................... 128 Figura 5.24 Ejemplos de objetos de flujo en notación BPMN. Eventos

(a), Actividades (b) y Gateways (c). ................................ 131

Figura 5.25 Ejemplos de objetos de conexión. Secuencias de flujo (a), Mensajes de flujo (b) y u Asociaciones (c). ............... 131

Figura 5.26 Ejemplos de objetos Swimlane, Pool (a) y Lanes (b)........ 132

Figura 5.27 Taxonomía de los elementos gráficos de BPMN. ............ 134 Figura 5.28 Pasos de la traducción BPMN a ontología. .................... 138 Figura 5.29 Estructura del Instanciador de Procesos BPMN. ............ 139 Figura 6.1 Correspondencia entre el Modelo Conceptual y el

Modelado Funcional del Proceso. .................................. 146 Figura 6.2 Detalle de entradas y salidas del Compositor de

Procesos. ...................................................................... 147 Figura 6.3 (a) Primer Proceso Funcional objetivo, (b) Segundo

Proceso Funcional Objetivo, (c) Proceso Funcional Resultante. ................................................................... 148

XXIV Modelo de gestión de los procesos basado en conocimiento

Figura 6.4 Esquema general del modelo de Compilación de Procesos con sus entradas, salidas y la correspondencia con el ModConceptGSPI. ............................................... 168

Figura 6.5 Elementos del Modelo de Compilación de Procesos......... 170 Figura 6.6 Equivalencias entre estructuras BPMN y BPEL. (Ouyang

et al., 2009). ................................................................. 178

Figura 6.7 Imagen del proceso resultante de la gramática antes de la reducción (a) y después de la reducción (b). .............. 179

Figura 6.8 Correspondencia de la definición funcional del modelo de ejecución y monitorización con sus entradas, salidas y la correspondencia con el ModConceptGSPI. ............... 186

Figura 6.9 Elementos del Monitor de Procesos. ............................... 188 Figura 7.1 Tecnologías del prototipo del modelo ModArqGSPI

propuesto. .................................................................... 197

Figura 7.2 Implementación del prototipo IMaaS. ............................ 198 Figura 7.3 Plano de la Planta 1 (a) y elementos de fabricación (b). .. 200 Figura 7.4 Plano de la Planta 2 (a) y elementos de fabricación (b). .. 201

Figura 7.5 Datos de conexión en la descripción semántica del servicio de una Cinta Transportadora. ........................... 206

Figura 7.6 Diseño de la experimentación T1 de composición para n-plantas. ........................................................................ 210

Figura 7.7 Diseño de la experimentación T2 de composición de procesos concurrentes. ................................................. 211

Figura 7.8 Diseño de la experimentación T3 de recuperación ante

errores. ........................................................................ 211 Figura 7.9 Distribución del procesos y máquinas por la Planta 1 (a)

y la Planta 2 (b). ........................................................... 212 Figura 7.10 Proceso funcional utilizado para el experimento T1. ...... 213

Figura 7.11 Captura del resultado de la normalización del proceso funcional y la importación de las ontologías de las plantas industriales...................................................... 214

Figura 7.12 Proceso a medida de la Planta 1 a partir de proceso

funcional. ..................................................................... 215 Figura 7.13 Trayectoria del proceso planteado sobre el plano de la

Planta 1. ....................................................................... 216

Figura 7.14 Caminos desde la máquina de procesado MT1 a otra máquina MT2 de la Planta 2. ........................................ 216

Figura 7.15 Proceso a medida de la Planta 2 a partir de proceso funcional. ..................................................................... 218

Figura 7.16 Trayectoria del proceso planteado sobre el plano de la Planta 2. ....................................................................... 218

Figura 7.17 Captura del proceso generado automáticamente para el proceso de la Planta 1. .................................................. 219

Índice de Figuras XXV

Figura 7.18 Captura de la hoja BPEL generada automáticamente a partir del proceso de menor peso para la Planta 2. ........ 221

Figura 7.19 Gráfica de comparación de procesos óptimos calculados

a partir de todos los caminos y de los caminos mínimos.225 Figura 7.20 Gráfica de evolución del número de procesos candidatos

de la Planta 1. .............................................................. 226

Figura 7.21 Gráfica de evolución del tiempo de ejecución para la Planta 1. ....................................................................... 226

Figura 7.22 Gráfica del tiempo de composición de procesos. ............ 227 Figura 7.23 Gráfica de comparación de procesos óptimos obtenidos

sobre la Planta 2........................................................... 229 Figura 7.24 Gráfica de evolución del número de procesos candidatos

para la Planta 2. ........................................................... 229 Figura 7.25 Gráfica de evolución del tiempo de ejecución Planta 2. .. 230

Figura 7.26 Gráfica de evolución del tiempo de composición de procesos en la Planta 2. ................................................ 230

Figura 7.27 Captura de los dos Procesos Funcionales utilizados en la

composición del proceso del segundo experimento. ....... 232 Figura 7.28 Unión conceptual de los procesos funcionales del

experimento tipo 2........................................................ 232 Figura 7.29 Captura de proceso compuesto no válido por

concurrencia sobre las máquinas. ................................ 233 Figura 7.30 Captura de proceso compuesto válido con pausas para

el control de la concurrencia para la Planta 1. .............. 234 Figura 7.31 Trayectoria del proceso resultante de la unión de dos

Procesos Funcionales. En rojo el proceso 1 y en verde el proceso 2. .................................................................... 234

Figura 7.32 Cronograma de los procesos independientes y del resultado de unirlos mediante los dos enfoques

planteados en la presente tesis sobre la Planta 1. ......... 235 Figura 7.33 Resultado del proceso de compilado sobre el mejor

proceso para la Planta 1. .............................................. 235

Figura 7.34 Procesos óptimos para el primer Proceso Funcional (a) y el segundo Proceso Funcional (b) para la Planta 2. ......... 236

Figura 7.35 Mejor proceso obtenido a partir de los caminos mínimos (a) y de la exploración de todos los caminos (b) para la

Planta 2. ....................................................................... 236 Figura 7.36 Cronograma de los procesos independientes y del

resultado de unirlos mediante los dos enfoques planteados en la presente tesis sobre la Planta 2. ......... 237

Figura 7.37 Captura del proceso modelado para la Planta 2 (a) y su correspondiente estructura de ejecución (b). ................. 238

XXVI Modelo de gestión de los procesos basado en conocimiento

Figura 7.38 Dispersión de los procesos originales (con colisión) y los procesos que satisfacen los requisitos del dominio (sin colisión). ....................................................................... 239

Figura 7.39 Gráfica de pesos de los mejores procesos obtenidos a partir de explorar el camino mínimo y de todos los caminos, y la diferencia entre pesos por proceso para la Planta 1. ....................................................................... 242

Figura 7.40 Evolución del número de procesos en función del número actividades del Proceso Funcional para la Planta

1. ................................................................................. 243

Figura 7.41 Evolución del tiempo de cálculo en función del número de actividades de los Procesos Funcionales para la Planta 1. ....................................................................... 243

Figura 7.42 Gráfica del peso del mejor proceso obtenido para todos

los caminos y el camino óptimo y la diferencia entre pesos para la Planta 2. ................................................. 245

Figura 7.43 Evolución del número de procesos en función del número de actividades del Proceso Funcional para la

Planta 2. ....................................................................... 246 Figura 7.44 Evolución del tiempo de cálculo de procesos en función

del número de actividades del proceso funcional para la

Planta 2. ....................................................................... 246 Figura 7.45 Proceso a ejecutar y localización del fallo forzado. ......... 247 Figura 7.46 Imagen del proceso generado con control de errores (a) y

detalle del manejador de errores global y capturador de

error de un elemento invoke (b)..................................... 249 Figura 7.47 Captura de la ontología sin la Cinta de Transporte CB7. 251 Figura 7.48 Captura del Proceso Funcional pendiente de ejecutar (a)

y del proceso ................................................................ 252 Figura 7.49 Captura del proceso BPEL regenerado para la Planta 1. 252

Índice de Tablas

Tabla 2.1 Ejemplo de definición de conceptos. ................................... 22 Tabla 2.2 Ejemplo de definición de instancias ................................... 22 Tabla 2.3 Ejemplo de propiedades de clase. ....................................... 23 Tabla 2.4 Ejemplo de propiedades de Objeto. .................................... 24

Tabla 4.1 Proceso de Gestión Semántica expresado en pseudo-código. .............................................................................. 78

Tabla 5.1 Definición de la Maquinaria Industrial. ............................. 105 Tabla 5.2 Definición de los atributos de la Maquinaria Industrial. .... 106

Tabla 5.3 Definición de propiedades de objeto de conexión entre Máquinas de Transporte. ................................................. 108

Tabla 5.4 Definición de relacionas binarias para las Cintas

Transportadoras. ............................................................. 109 Tabla 5.5 Definición de propiedades de objeto entre Herramientas y

Máquinas Herramienta. ................................................... 112

Tabla 5.6 Definición de propiedad hay_camino_entre Máquinas de

Transporte. ..................................................................... 113 Tabla 5.7 Definición de regla que establece caminos entre

máquinas. ...................................................................... 114

Tabla 5.8 Definición de propiedad Puede_procesar entre Herramientas y Materias. ................................................ 115

Tabla 5.9 Definición de la regla Puede_procesar. ............................. 115

Tabla 5.10 Regla que establece las condiciones para Procesar de las maquinas herramienta. ................................................... 116

Tabla 5.11 Regla que establece las condiciones para procesar de las Máquinas Multi Herramienta. ........................................... 116

Tabla 5.12 Declaración de las clases Proceso, SubProceso y Actividad.118 Tabla 5.13 Declaración de las propiedades de las clases del Nivel de

Negocio. .......................................................................... 119

Tabla 5.14 Declaración de relaciones entre clases. ........................... 119 Tabla 5.15 Declaración de la relación Precede entre actividades. ...... 120 Tabla 5.16 Relaciones entre KPI y Procesos, Subprocesos y

Actividades. .................................................................... 120 Tabla 5.17 Especificación de restricción sobre concurrencia de

Actividades. .................................................................... 125 Tabla 5.18 Definición de las propiedades de la clase Servicio. ........... 128

XXVIII Modelo de gestión de los procesos basado en conocimiento

Tabla 5.19 Instanciación de un diagrama BPMN en Sintaxis Funcional. ...................................................................... 133

Tabla 5.20 Declaración de propiedades de un diagrama BPMN. ........ 133

Tabla 5.21 Algoritmo de instanciación de procesos expresado en pseudo-código. ................................................................ 141

Tabla 6.1 Algoritmo de unión de procesos expresado en pseudo-código. ............................................................................ 149

Tabla 6.2 Consulta simple para obtener el evento inicio en SPARQL. ......................................................................... 151

Tabla 6.3 Consulta de extracción de elemento siguiente de un nodo en SPARQL. .................................................................... 151

Tabla 6.4 Consulta que obtiene las instancias de un tipo de elemento expresado en SPARQL. ..................................... 151

Tabla 6.5 Cálculo de camino entre máquinas contiguas. ................. 153 Tabla 6.6 Cálculo de camino entre máquinas con distancia 2. ......... 153

Tabla 6.7 Cálculo de camino entre máquinas con distancia n. ......... 154 Tabla 6.8 Esqueleto de la función utilizada ..................................... 158 Tabla 6.9 Función de generación de proceso. Parte de generación de

caminos. ......................................................................... 159

Tabla 6.10 Función de generación de proceso. Parte de generación de todas las posibilidades. ................................................... 160

Tabla 6.11 Matriz de colisiones de secuencias paralelas. .................. 162 Tabla 6.12 Cálculo de la distancia máxima a la que se obtiene un

proceso sin colisiones. .................................................... 163 Tabla 6.13 Función de resolución de colisiones. ............................... 164 Tabla 6.14 Algoritmo de selección de procesos. ................................. 166 Tabla 6.15 Precondición de servicio de transporte. ........................... 173 Tabla 6.16 Ejemplo de descripción de resultado en SWS para

parámetro de dirección positivo sobre un proceso de transporte. ...................................................................... 173

Tabla 6.17 Ejemplo de descripción de resultado en SWS para parámetro de dirección negativo sobre un Proceso de

Transporte. ..................................................................... 174 Tabla 6.18 Algoritmo de cálculo de parámetros basado en

Información Semántica. .................................................. 175 Tabla 6.19 Gramática y Traducción propuestas. ............................... 177

Tabla 6.20 Identificación de las áreas dentro de la estructura de un proceso BPEL.................................................................. 180

Tabla 6.21 Definición de función inicial de traducción. ..................... 181 Tabla 6.22 Pseudo-Código de la función de traducción S. ................. 182

Tabla 6.23 Algoritmo de generación de elemento invoke BPEL a partir de información semántica...................................... 184

Índice de Tablas XXIX

Tabla 6.24 Pseudo-código de la función de actualización de la ontología. ........................................................................ 189

Tabla 6.25 Función de extracción del proceso funcional a partir de

un proceso completo expresada en pseudo-código. .......... 190 Tabla 6.26 Elemento recursivo de extracción de elemento funcional a

partir de proceso completo. ............................................. 191 Tabla 6.27 Evaluación de cada tipo de servicio. ................................ 192

Tabla 6.28 Función de creación de tarea a partir de un elemento. .... 192 Tabla 7.1 Servicios ofertados por cada tipo de Máquina Industrial. .. 201 Tabla 7.2 Propiedades de la Máquina de Transporte CB4 y de la

Máquina Herramienta MT3 de la Planta 1. ....................... 203

Tabla 7.3 Ejemplo de instanciación de cinta transportadora. ........... 204 Tabla 7.4 Instanciación de proceso y servicio de la máquina CB4. ... 204 Tabla 7.5 Frecuencia por peso de los procesos candidatos para la

Planta 2. ......................................................................... 217 Tabla 7.6 Extracto del código de la hoja BPEL generada

automáticamente para la Planta 1. .................................. 219 Tabla 7.7 Extracto del código de la hoja BPEL generada

automáticamente para la Planta 2. .................................. 221 Tabla 7.8 Procesos funcionales utilizados experimento T1. .............. 223 Tabla 7.9 Resumen de los datos obtenidos para la Planta 1 a partir

de todos los procesos en experimentación T1. ................. 224 Tabla 7.10 Resumen de los datos obtenidos para la Planta 1 a partir

del camino óptimo entre máquinas en experimentación T1. .................................................................................. 224

Tabla 7.11 Resumen de los datos obtenidos para la Planta 2 a partir de todos los procesos en experimentación T1. ................. 227

Tabla 7.12 Resumen de los datos obtenidos para la Planta 2 a partir de los caminos mínimos en experimentación T1. ............. 228

Tabla 7.13 Procesos funcionales utilizados en los experimentos de tipo 2. ............................................................................. 240

Tabla 7.14 Datos obtenidos para los procesos del experimento T2 para la Planta 1 explorando todas las posibilidades. ........ 241

Tabla 7.15 Datos obtenidos para los procesos del experimento T2 para la Planta 1 explorando los caminos mínimos. .......... 241

Tabla 7.16 Datos obtenidos en el experimento 2 para la Planta 2

explorando todos los procesos. ........................................ 244 Tabla 7.17 Datos obtenidos en el experimento 2 para la Planta 2

explorando los caminos óptimos. .................................... 244 Tabla 7.18 Captura de la lógica de la gestión de errores en un

elemento invoke del proceso. ........................................... 249 Tabla 7.19 Captura del código compensationHandler del proceso. ..... 250

C a p í t u l o 1

Introducción

El uso de las Tecnologías de la Información y las Comunicaciones (TIC) e Internet está cambiando tanto la forma en que las organizaciones se relacionan con el entorno como la forma de realizar las transacciones de negocio. De hecho, la aparición de los modelos e-Business, los cuales se

basan en el uso TIC e Internet para llevar a cabo los procesos de negocio, se ha convertido en el factor más determinante en el mundo empresarial desde la revolución Industrial (Burton, 2001), dando lugar a lo que se denomina la nueva economía (Comisión Europea, 2008).

La implantación de los modelos e-Business en las organizaciones facilita la eliminación de las barreras geográficas y logísticas, permitiendo a las organizaciones implantarse en nuevos mercados con inversiones

relativamente pequeñas. Actualmente las transacciones comerciales se pueden realizar desde cualquier sitio y a cualquier hora, lo que implica total disponibilidad del funcionamiento de la organización (Harmon, 2003) (Burlton, 2001).

La capacidad que Internet ha otorgado a los clientes para seleccionar los productos y servicios que más les convienen en cada momento y a los

precios más ajustados está provocando un cambio en los procesos de negocio de las empresas. Cada vez más, las organizaciones deben ser capaces de personalizar sus productos y servicios ante la creciente demanda por parte de la sociedad. En el escenario actual, el consumidor

interviene en el diseño y desarrollo de los productos provocando la aparición de nuevos modelos de negocio. Este cambio de paradigma productivo implica la necesidad de optimizar y modificar de forma ágil

2 Modelo de gestión de los procesos basado en conocimiento

los procesos de negocio existentes para poder adaptarse ante la demanda tan cambiante del mercado (OPTI, 2009).

En este escenario, la competitividad de las empresas en el mercado se fundamenta, entre otros factores, en la capacidad que tengan de adaptarse de forma rápida a la demanda cambiante de los clientes. La forma de lograrlo es acortando al máximo el tiempo invertido en cada

una de las fases implicadas en los procesos de negocio. Por este motivo han aparecido modelos de negocio fundamentados en el cambio continuo del entorno, que permiten la modificación de los objetivos estratégicos de la organización en tiempos cortos.

Estos nuevos modelos de negocio exigen a las organizaciones modelos de gestión ágiles, dinámicos y flexibles que permitan alinear de manera

rápida los objetivos estratégicos con los procesos de negocio y la tecnología que los sustenta (Smith & Fingar, 2002) (Chang, 2005).

Una de las teorías de gestión que tratan la problemática surgida es la

denominada Business Process Management (BPM). Esta teoría da respuesta a las exigencias de las nuevas formas de gestión de los nuevos modelos de negocio. BPM contempla el cambio como una de sus principales características y la adecuación ágil a dichos cambios por

parte de los procesos de negocio y las infraestructuras TI que los sustentan.

Concretamente, la metodología BPM contempla las fases fundamentales

en la gestión de los procesos de negocio, y la velocidad en la que se completen todas las fases determina la velocidad en la que las organizaciones son capaces de adaptarse a los nuevos objetivos estratégicos. Así, en la Figura 1.1 se puede ver cómo el cliente participa

de manera activa en la fase de diseño, y en función de sus requerimientos se adaptan todas las fases del proceso de negocio.

Las TI se han convertido en una herramienta fundamental a la hora de

poder aplicar el paradigma BPM en las organizaciones. De hecho, asociado a esta teoría ha surgido un nuevo concepto de plataforma software denominado Business Process Management System (BPMS) que da soporte a todo el ciclo de vida definido en BPM, dando soluciones que

integran tanto a las personas como a las tecnologías que sustentan los procesos de negocio.

Capítulo 1. Introducción 3

Figura 1.1 Fases del ciclo de vida BPM.

Uno de los sectores donde más impacto ha tenido la introducción de las

TI y los modelos e-Business ha sido el de la manufactura. Las reglas y modelos de negocio en este tipo de organizaciones se han visto afectadas por los cambios impulsados por la demanda personalizada de los clientes, provocando un cambio en el paradigma productivo y, por lo

tanto, incrementando la dificultad de gestión de las organizaciones manufactureras.

Este cambio en el modelo productivo se basa en el cambio desde el

tradicional modelo orientado a la producción masiva hacia modelos orientados a la personalización masiva que satisfagan la demanda cambiante de los clientes (Younghwan et al., 2005) (Jeston & Neils, 2006). Como ejemplo de organizaciones que han adoptado este nuevo

modelo de producción se pueden destacar las siguientes: Dell Computers en el sector de la informática, donde Michael Dell fue proclamado el Henry Ford de la personalización masiva; Levi Strauss & Company’s (Burlton, 2001), Adidas o Nike Retail (Nike, 2014) en el sector textil;

Nokia Corporation o Motorola del sector de la telefonía móvil (Di Pierri, 2006), o Heineken (Heineken, 2014) en el sector de las bebidas alcohólicas. Todas estas marcas ofrecen productos personalizados, contemplando una gama de productos acotada para cada cliente,

permitiéndoles diseñar y modificar las características de sus productos por un pequeño aumento en el coste.

Casos como los presentados demuestran la necesidad de crear modelos

de gestión ágil en todos los niveles de la organización, desde la solicitud


del producto hasta su entrega. Sin embargo, por la rígida estructura de las organizaciones manufactureras, la aplicación de modelos de gestión de procesos de negocio ágiles resulta complicada. Actualmente, en las

organizaciones manufactureras, la viabilidad de los nuevos modelos de negocio se hace compleja puesto que sería necesario alcanzar una plena integración de los procesos de fabricación dentro del mapa global de la organización. Dicha integración, se ve dificultada por las restricciones

físicas, tecnológicas y conceptuales en los niveles inferiores (PLC, CNC, maquinaria industrial, etc.), así como por la falta de estandarización en los elementos de producción en dichos niveles.

Debido a la brecha conceptual y tecnológica existente entre el nivel de gestión de procesos y el nivel de planta, provocada por la alta rigidez de los elementos situados en los niveles inferiores de la producción, no es posible la aplicación del paradigma BPM de forma integral en las

organizaciones manufactureras (Worthington & Boyes, 2002). Aunque es posible aplicar el paradigma BPM en los niveles superiores de las organizaciones, como se ve en la Figura 1.2, no es posible la continuidad de las fases del paradigma BPM por las características del nivel de

planta. La falta de estandarización de los elementos situados en el nivel de planta, así como las diversas tecnologías que los sustentan hace que exista una ruptura entre el modelado de procesos y la posterior ejecución de los mismos. Por ello, el nivel de planta suele estar gestionado de

manera independiente al resto de la organización, lo que provoca una falta de continuidad en las fases de los modelos de gestión ágil de procesos, y por lo tanto, provoca un mayor consumo de tiempo a la hora de adaptar los procesos productivos a las nuevas demandas del

mercado.

Una forma de superar esta ruptura en el ciclo de los procesos en los entornos manufactureros es ofreciendo la maquinaria industrial como

servicio (IMaaS) (Gilart et al., 2007). La propuesta IMaaS elimina las restricciones tecnológicas y conceptuales mencionadas anteriormente que impedían la integración de los procesos de negocio y los de fabricación. Para lograrlo, la propuesta define dos procesos, el proceso de

normalización conceptual y el proceso de normalización tecnológica de la maquinaria industrial. La normalización conceptual de la maquinaria industrial establece un modelo que elimina las restricciones conceptuales existentes entre los procesos de fabricación y los procesos

de negocio. Para ello incorpora en la maquinaria industrial los elementos necesarios para visualizarla como un sistema basado en el ciclo de vida del modelo BPM y expone la funcionalidad de dichos elementos como servicios al resto de la organización. El objetivo final es obtener un


patrón BPM de la maquinaria industrial orientado a un modelo de servicios. El proceso de normalización tecnológica de la maquinaria industrial establece la arquitectura (arquitectura IMaaS) que permite

sustentar el anterior modelo conceptual de servicios, eliminando las tradicionales restricciones tecnológicas y aportando flexibilidad y dinamismo a la maquinaria.

Figura 1.2 Brecha Conceptual y Tecnológica en la gestión de procesos.

Con la propuesta de IMaaS se posibilita la gestión de los entornos manufactureros siguiendo el ciclo de vida de los procesos definido en el paradigma BPM (Figura 1.1), permitiendo la gestión ágil de los entornos manufactureros ante las demandas cambiantes de los clientes.

Como ya se ha comentado, la capacidad de una organización para personalizar sus productos es un factor clave a la hora de situarse en una posición privilegiada en el marco de competitividad global de las

organizaciones.

Pese a los avances en los sistemas de gestión de procesos de negocio (BPMS, Business Process Manager System), el grado de personalización

que una empresa puede ofrecer sobre sus productos afecta directamente al número y complejidad de los procesos que las organizaciones deben gestionar. Por este motivo, las organizaciones manufactureras ven cómo se incrementan de manera exponencial los procesos y tareas que deben

desarrollar para poder competir en el mercado de la personalización


masiva, y cómo los sistemas BPMS no aportan funcionalidades añadidas para dar soporte a dichos requerimientos.

Sin embargo, pese a la integración del nivel de planta dentro del sistema de gestión de procesos, sigue existiendo elementos que provocan retardos en la adaptación y creación de nuevos procesos que se adecuen a las demandas de los clientes. Uno de estos factores es la falta de

relación conceptual entre los procesos de fabricación y los servicios ofrecidos por la maquinaria que los implementa. Lo que implica que se deben conocer ambos dominios para poder gestionar los procesos. Por ello, tampoco se puede lograr la automatización en todo el proceso de

gestión, desde el modelado hasta la fabricación propiamente dicha.

El volumen actual de procesos y su dinamismo hace que no puedan ser

gestionados de manera ágil por parte de los Ingenieros de Procesos, por lo que se provocan retardos en todas las fases de la cadena de producción.

Una forma de solventar estos problemas es estableciendo relaciones conceptuales entre los procesos y actividades con los elementos físicos en los que se llevan a cabo dichos procesos y con las tecnologías que los ofertan a los niveles superiores de las organizaciones.

1.1 Identificación del Problema Como se ha visto en el análisis anterior, el nivel de personalización que una empresa sea capaz de ofrecer a sus clientes será la clave del existo de la misma.

Esta personalización implica un incremento exponencial en los procesos que se deben gestionar por las organizaciones manufactureras. La capacidad de adaptarse a los cambios ante las demandas de los clientes hace, además, que los procesos de fabricación y de negocio sean

dinámicos y cambiantes. Por lo que se deben poder readaptar a las nuevas exigencias del mercado de manera ágil.

Como se puede apreciar en la Figura 1.3, al considerar al cliente un elemento activo en la fase de diseño se incrementa exponencialmente las tareas a desarrollar en todas las fases del ciclo de vida de los procesos de negocio, convirtiéndose el modelado de los procesos y su posterior

despliegue en un entorno ejecutable en elementos críticos en la gestión


de procesos de fabricación y negocio. Debido al bajo nivel de automatismo en las fases de modelado y despliegue, estas actividades se convierten en un cuello de botella que provoca retardos en el ciclo de

vida de los procesos y, por lo tanto, aumenta el tiempo de respuesta ante nuevas demandas del mercado, reduciendo la competitividad de la organización.

Figura 1.3 Incremento de la demanda de productos personalizados.

Los problemas detectados afectan a las siguientes fases del ciclo de vida

de los procesos de negocio:

• Modelado. La falta de relación entre los objetivos estratégicos de

los procesos, y la manera de llevarlos a cabo, hace que el modelado de los procesos de negocio y fabricación sea una

actividad manual, que depende del conocimiento de los expertos tanto en gestión de procesos de negocio como en los procesos de fabricación. Debido a que los procesos de fabricación dependen del nivel de planta donde se van a llevar a cabo, existe un fuerte

acoplamiento entre el proceso de fabricación y el nivel de planta. Esto hace que ante un cambio del proceso, o del nivel de planta, se tenga que volver a iniciar la fase de modelado del proceso. Otro problema en la fase de modelado es que al modelar los

procesos de fabricación en función del cómo se deben llevar a cabo, en lugar de qué se debe conseguir, cualquier pequeño


cambio en los elementos productivos implica rehacer un proceso que no ha variado en sus objetivos.

• Despliegue y Ejecución. Aunque los sistemas BPMS ofrecen

herramientas para agilizar el despliegue de los procesos en los

entornos de ejecución, especialmente en los sistemas basados en servicios, sigue siendo necesario relacionar de forma manual cada una de las actividades del proceso modelado con los servicios que los llevan a cabo. Esto implica que se debe conocer

qué máquinas implementan los procesos, qué tipo de información manejan y cómo comunicarse con ellas, por lo que no existe una transición trasparente entre las fases de modelado y ejecución.

1.2 Hipótesis Partiendo de la definición del problema y del análisis realizado en el estado del arte y los antecedentes se ha planteado la hipótesis de partida de la presente tesis:

La introducción de conocimiento en la definición de los procesos y

elementos productivos posibilitará la automatización en las fases del

ciclo de vida BPM, reduciendo las tareas de gestión y agilizando el

cambio de los procesos de fabricación.

En función de la hipótesis de partida se define una serie de sub-hipótesis para lograr la hipótesis general:

El conocimiento representativo de los dominios implicados en la

gestión de los procesos productivos puede ser conceptualizado

formalmente en una ontología.

De la ontología se puede inferir nuevo conocimiento que permita la

composición de nuevos procesos productivos.

Es posible desarrollar un sistema software que integre la información

conceptual recogida en la ontología con las herramientas de gestión

de procesos, de forma que, a partir de inferencias sobre la misma, se

puedan automatizar las fases concretas del ciclo de vida BPM.


1.3 Objetivos Teniendo en cuenta la hipótesis de partida se ha planteado como objetivo

general:

Concebir un modelo que introduzca conocimiento en las fases de

gestión de procesos de negocio y fabricación, integrando de forma

trasparente los objetivos estratégicos de los procesos de fabricación

con los elementos que los sustentan, aumentando el soporte de dan

las TIC a la gestión de procesos de manera que sean las propias TIC

las encargadas del grueso del control (TICC) en las distintas fases

del ciclo de vida BPM.

Además se han establecido los siguientes objetivos específicos con el fin de guiar la metodología adecuada y establecer un plan de trabajo:

• Realizar un estudio del estado del arte en los ámbitos relacionados con el problema para localizar las diferencias en las

propuestas existentes y estudiar modelos que permitan resolver las carencias identificadas y cumplir los requerimientos indicados en la hipótesis.

• Definir un modelo de gestión semántica de procesos que

contemple la introducción de información semántica en las fases del ciclo de vida BPM.

• Crear una base de conocimiento formal que contenga la información referente al dominio industrial y a la gestión de los

procesos de negocio, que permita identificar y razonar con los diferentes elementos implicados en los procesos productivos.

• Diseñar una arquitectura que sustente e integre las fases del ciclo de vida BPM y la información semántica en los entornos

productivos manufactureros.

• Diseñar e Implementar un escenario de pruebas para validar la

propuesta. De forma general este escenario estará formado por un conjunto de plantas de fabricación, compuestas por un

conjunto de prototipos IMaaS, un prototipo de sistema BPMS que gestione los procesos a partir del conocimiento del sistema, y las infraestructuras SOA auxiliares que permitan obtener un modelo de gestión ágil para validar la propuesta.


1.4 Propuesta de Solución La creciente demanda de productos personalizados por parte de los clientes implica un gran incremento en las tareas de modelado de

procesos de fabricación y de negocio. En los últimos años han aparecido herramientas como los BPMS que facilitan estas tareas, sin embargo, siguen siendo tareas críticas y poco automatizadas dentro del ciclo de vida de los procesos de fabricación.

La solución propuesta en este trabajo consiste en un modelo de gestión de procesos de fabricación dentro de los sistemas de gestión de procesos de negocio, de forma que se pueda automatizar la composición de

procesos de negocio y fabricación de manera automática. De esta forma, mediante el automatismo en el modelado, compilación y despliegue de los procesos, se puede agilizar las labores que se han convertido en un cuello de botella en la gestión ágil de los procesos de fabricación. Como

se ilustra en la Figura 1.4mediante la automatización en el modelado de procesos se puede minimizar este cuello de botella en el que se estaba convirtiendo la fase de modelado de procesos de fabricación en los entornos de producción ágil.

Figura 1.4 Propuesta General en el que, mediante la incorporación de

conocimiento, se automatizan tareas de gestión reduciendo el cuello de botella producido por el incremento en la demanda personalizada.

Para lograr esta automatización se propone la introducción de

conocimiento en la definición de procesos, mediante el uso de una herramienta formal como son las ontologías. De esta forma, a partir de una especificación abstracta del proceso a realizar, se obtiene un proceso


concreto que puede ser llevado a cabo en cualquiera de las diferentes plantas de las que disponga la organización.

Tal como se aprecia en la Figura 1.5en la etapa de diseño es el cliente, o el ingeniero de procesos, el que demanda un producto personalizado. Las características de esta personalización se materializan en lo que se ha denominado Proceso Funcional, el cual contiene los objetivos a realizar

para lograr el producto personalizado. A partir del proceso funcional, en la etapa de modelado se identifican las actividades necesarias para lograr realizar el Proceso Funcional. Para ello, el razonador semántico infiere

conocimiento a partir de la ontología con información del dominio y, a partir de este conocimiento, se realiza la tarea de modelar el proceso, la cual es llevada a cabo por el compositor de procesos. El resultado de la etapa de modelado es un proceso ad-hoc que contempla todas las

actividades necesarias para lograr desarrollar el proceso funcional en una planta concreta. A partir del proceso completo, se realiza la traducción del proceso a un lenguaje ejecutable. Para ello se descubren los servicios y se calculan los parámetros necesarios para lograr las

transformaciones especificadas en el proceso. Finalmente, cuando se dispone del proceso ejecutable, se pasa a un sistema de planificación se encarga de orquestar el proceso y llevarlo a cabo en función de los recursos físicos y tecnológicos de la organización, obteniendo como

resultado el producto personalizado demandado por el cliente en la etapa de diseño

1.5 Metodología La metodología del trabajo se ha planteado en función de los objetivos generales y concretos descritos en el apartado anterior siguiendo

diferentes aspectos del método científico. A continuación se detallan los métodos y técnicas que se han utilizado en el proceso de investigación científica del presente trabajo para abordar cada uno de los objetivos.

A partir de la hipótesis planteada, a la cual se ha llegado mediante el análisis de los diversos ámbitos en los que se ubica el problema, se ha realizado un proceso de deducción para obtener la consecuencia de la hipótesis planteada y los enunciados que se deberán demostrar

posteriormente mediante los procesos de experimentación necesarios para comprobar la validez de la propuesta. Para ello, en función del objetivo global, se ha utilizado como marco general a lo largo del presente trabajo el método hipotético-deductivo.


Figura 1.5 Identificación de los elementos de la propuesta

Sin embargo, en cada una de las etapas de las que consta el trabajo de investigación, y que han sido definidas a partir de los objetivos específicos, ha sido necesario el uso de diferentes métodos científicos.

Inicialmente se ha realizado un estudio del estado del arte mediante la observación y el análisis de los diferentes ámbitos de investigación en los que se ha ubicado el problema. Concretamente, el estudio se ha centrado en el análisis de los modelos de gestión ágil de procesos de negocio y

cómo se aplican estos modelos de gestión en los entornos de producción. Así mismo, se ha realizado un estudio de las carencias y posibles soluciones planteadas por la comunidad científica para mejorar los sistemas de gestión de procesos de negocio. En esta etapa del trabajo se

ha utilizado un método de observación científica que ha permitido concretar en cada uno de los ámbitos del problema las líneas específicas objeto de estudio y el método analítico que ha permitido analizar cada una de las propuestas y enfoques de estas líneas e identificar las

carencias y virtudes de estas propuestas para la resolución del problema.

Mediante la aplicación del método sistémico se han determinado los

componentes necesarios para definir la base de conocimiento que refleje


los diferentes aspectos involucrados en la gestión de procesos y las relaciones existentes entre cada uno de estos componentes, las cuales se han definido como relaciones semánticas en una ontología.

A partir de las diferentes propuestas se han unido diversos conceptos para establecer un modelo de gestión que permita realizar de forma ágil los procesos de fabricación y de negocio. Para ello se ha utilizado el

método sintético.

Finalmente, con el objetivo de validar las hipótesis mediante

experimentación, se han diseñado los escenarios de pruebas y se han utilizado métodos empíricos sobre dichos escenarios para validar los casos de uso propuestos en los objetivos. Para ello se han determinado propiedades para cada escenario como los tiempos de reconfiguración

del escenario, el grado de automatismo o los tiempos de cambio en los procesos de la organización. El método de medición es el adecuado para llevar a cabo esta etapa.

1.6 Plan de Trabajo Para una mejor compresión de los aspectos fundamentales tratados en la

presente tesis, la memoria se ha estructurado en distintos capítulos especificando las tareas que se llevan a cabo en cada uno de ellos.

En el capítulo 2 se aborda el estudio de los antecedentes y el estado del

arte en los diferentes ámbitos en los que se encuadra el problema. En concreto, se centra en el estudio de los sistemas de gestión de procesos de negocio y en propuestas que incrementan su automatismo. Por otro lado, se realiza un estudio de las propuestas actuales para agilizar los

procesos en los entornos manufactureros. Finalmente, se analizan las propuestas que unan la gestión de procesos y fabricación dentro de un mismo sistema de gestión.

En el capítulo 3, se presenta el concepto de IMaaS, sus características principales y como mediante este concepto se han superado las brechas tecnológicas y conceptuales que permiten gestionar de forma conjunta los procesos de fabricación y de negocio, y en especial, los procesos de

fabricación dentro de los sistemas de gestión de procesos de negocio BPMS.


En el capítulo 4 se identifican cada una de las actividades que componen el proceso de gestión semántica de procesos de fabricación, y se establece las entradas y el resultado de cada actividad. Una vez se

dispone de la especificación de cada actividad se propone un sistema que sea capaz de llevarlas a cabo dentro de una arquitectura orientada a servicios.

En el capítulo 5 se estudian las actividades, y su especificación en el sistema propuesto, de aquellas tareas relacionadas con la gestión de la información semántica. Por un lado se específica la información semántica necesaria para la gestión de procesos y se propone una

ontología que conceptualice el nivel de planta y de procesos de una organización manufacturera. Por otro lado, se especifica el proceso de conversión de procesos desde su representación gráfica estándar a un sistema de información basado en información semántica. De esta forma

se especifican las actividades de gestión de la información.

El capítulo 6 se corresponde con el estudio de las actividades de gestión del ciclo de vida BPM, que se corresponden con el modelado,

implementación, ejecución y monitorización de procesos. Se presenta como se han diseñado estas partes del sistema para automatizar la composición e implementación a partir de información semántica y como la monitorización ayuda a mantener la ontología del dominio actualizada.

Durante el capítulo 7 se diseñan y desarrollan un conjunto de pruebas sobre el sistema propuesto que permitan la validación de lo propuesto en

la presente tesis. Para ello, se explica la implementación de cada una de las partes del sistema y se muestra el resultado de la ejecución de cada una de las pruebas diseñadas.

Por último, en el capítulo 8 se presentan las principales conclusiones y las aportaciones del presente trabajo. También se plantean las líneas de investigación futuras que se han identificado a lo largo de la presente tesis.

C a p í t u l o 2

Estado del Arte

En el capítulo anterior se ha establecido como objetivo del trabajo de investigación la creación de un modelo de gestión de procesos de negocio y fabricación basado en el uso de información semántica que permita gestionar de forma ágil los procesos productivos de las organizaciones

manufactureras.

Para ello, en este capítulo se ha recogido de forma sintetizada aquellos antecedentes y trabajos del ámbito de estudio que enmarca el presente

trabajo de investigación, y que han podido servir, por un lado, para identificar el problema y plantear la hipótesis de partida y, por otro lado, para justificar el enfoque de la propuesta que aborda el problema.

El capítulo se ha estructurado en tres secciones. En la primera sección se realiza una contextualización de las ontologías y las tecnologías asociadas con la web semántica, desde sus inicios hasta la situación actual. En la segunda sección se realiza una revisión de la evolución de

las teorías de gestión de procesos para finalizar poniendo el foco sobre aquellas propuestas que hacen uso de ontologías para agilizar la gestión de procesos. Finalmente se muestra el estudio del tercer dominio implicado, el dominio de fabricación, sobre el cual se realiza un estudio

de las últimas propuestas enfocadas sobre la gestión y conceptualización de operaciones industriales.


2.1 Ontologías y Tecnologías de la Web Semántica Los sistemas basados en ontologías o información semántica están adquiriendo una gran importancia hoy en día. Aunque la mayoría de las propuestas estudiadas se centran a nivel teórico, cada vez más, se

pueden encontrar diversos estudios que hacen uso de las ontologías en entornos reales. El éxito de los sistemas basados en información semántica radica en las características de formalización de dominios y automatización. Por ello, se pueden encontrar aplicaciones que tratan

desde la gestión de red (López de Vergara et al., 2009) hasta la automatización de los entornos productivos, especialmente a nivel de planta (Puttonen et al., 2013).

Como forma de identificar cuáles son las características principales de dichos sistemas, así como las virtudes y carencias que tienen, se realiza un estudio de diversas propuestas que tienen funcionalidades que pueden ayudar a resolver la problemática planteada anteriormente.

La aplicación de ontologías en los sistemas informáticos fue promovida inicialmente por el creador de la Web y presidente del consorcio W3C Berners-Lee en (Berners-Lee et al., 2001). Mediante el uso de ontologías

perseguía que las máquinas pudieran entender el contenido que aparecía en la Web y, por lo tanto, pudieran utilizarlo. La propuesta se basa en una nueva web que estaría poblada por agentes o representantes software capaces de navegar y realizar operaciones por nosotros para

ahorrarnos trabajo y optimizar los resultados. Los agentes extraen la información y las relaciones entre los diversos conceptos de las ontologías.

El termino ontología proviene originariamente de la filosofía, aunque en el campo de la informática hace ya muchos años que se viene usando. Durante estos años ha existido un amplio debate de lo que se considera una ontología desde un punto de vista computacional. Por ello, la

definición del concepto ontología ha ido evolucionando (Neches et al., 1991) (Gruber, 1993) (Borst, 1997) hasta llegar a la que actualmente cuenta con un mayor consenso, establecida en (Studer, 1998), y que define una ontología como:

“Una ontología es una especificación formal y explicita de una

conceptualización compartida.”

Capítulo 2. Estado del Arte 17

“La conceptualización se refiere a un modelo abstracto de algún

fenómeno en el mundo a través de la identificación de los conceptos

relevantes de dicho fenómeno. Explícita significa que el tipo de

conceptos y relaciones se definen explícitamente. Formal representa

el hecho de que la ontología debería ser entendible por las

máquinas. Compartida refleja la noción de que una ontología

representa conocimiento consensual, esto es, que no es de un

individuo, sino que es aceptada por un grupo”

Las ontologías se forman principalmente usando los siguientes componentes (Gruber, 1993):

• Clases: representan conceptos, puede ser algo sobre lo que se

dice algo, como un tipo de objeto, una descripción de una tarea, función, acción, estrategia, proceso de razonamiento, etc. Las clases de una ontología suelen organizarse en taxonomías. No

debemos confundir las taxonomías con las ontologías, aunque algunas veces la ontología se diluye en el término taxonomía que es una ontología completa.

• Atributos: representan la estructura interna de los conceptos.

Atendiendo a su origen, los atributos se clasifican en específicos

y heredados. Los atributos específicos son aquellos que son propios del concepto al que pertenecen, mientras que los atributos heredados vienen dados por las relaciones taxonómicas, en las que el concepto desempeña el rol de “hijo” o

“especificación”.

• Relaciones: representan un tipo de relación entre conceptos del

dominio. Se define formalmente como un subconjunto de un producto de n conjuntos, esto es R: C1 x C2 x C3 x…x Cn. Entre los distintos tipos de relaciones posibles, se encuentran las relaciones taxonómicas (“es un”) y las partonómicas (“parte

de”) como relaciones binarias más destacadas.

• Funciones: son un tipo especial de relaciones en las que el

elemento n-ésimo es único para los n-1 elementos precedentes. Formalmente, definimos las funciones (F) como F: C1 x C2 x … x Cn-1. Por ejemplo las relaciones

“precio_de_un_coche_tras_descuento”, en la que el precio del coche se obtiene a partir del precio original y el descuento.

• Axiomas: son expresiones que son siempre ciertas. Pueden ser

incluidas en una ontología con muchos propósitos, tales como


definir el significado de los componentes ontológicos, definir restricciones complejas sobre los valores de los atributos, argumentos de relaciones, etc.…

• Instancias: son las ocurrencias en el mundo real de los

conceptos. En las instancias todos los atributos del concepto tienen asignado un valor.

Para que los agentes o elementos software puedan realizar procesos de inferencia sobre la información almacenada en ontologías, estas deben

fundamentarse en algún formalismo lógico. La utilización de estos formalismos además de aportar la base necesaria para el uso automatizado de la información, da la posibilidad de realizar procesos de razonamiento e inferencia que conducen a la adquisición de nuevo

conocimiento a partir del conocimiento existente.

La lógica define un lenguaje formal para expresar conocimiento a cerca de algún dominio y las proposiciones que pueden ser derivadas de ese

conocimiento. Además, fija el conjunto de primitivas que pueden emplearse para modelar el mundo, es decir, la sintaxis. La lógica establece la semántica formal de cada proposición en el lenguaje correspondiente (valor de verdad de cada sentencia respecto a cada

mundo posible) y si está equipada con un procedimiento formal (computable) para derivar nuevos hechos (descritos en el lenguaje correspondiente) a partir de un conjunto de proposiciones.

La LPO (Lógica de Primer Orden) posee una gran capacidad expresiva, lo que implica que algunas tareas de razonamiento de este lenguaje son, en general, indecidibles, es decir, que no se puede obtener una respuesta en un tiempo finito. Por este motivo, las ontologías se basan en un

subconjunto de la LPO como es la Lógica Descriptiva.

La Lógica Descriptiva es un formalismo para representar conocimiento. El nombre “Lógica Descriptiva” hacer referencia a dos conceptos, por un

lado, a la descripción de conceptos que se usan para definir el dominio, y por el otro lado, a la semántica basada en lógica (semántica formal bien definida) que viene dada por su traducción en predicados de LPO. Este formalismo se ideó buscando un compromiso ente la capacidad de ser

computable y la capacidad expresiva. La sintaxis de la lógica descriptiva consiste en:

• Conceptos atómicos: equivalentes a los predicados unarios en

LPO. Un concepto denota un conjunto de individuos que

pertenecen a una clase


• Roles atómicos: equivalentes a los predicados binarios en LPO.

Un rol denota una relación entre conceptos.

• Operadores: establecen relaciones entre conceptos y

restricciones sobre los mismos.

La lógica descriptiva se puede utilizar tanto para definir las bases del

conocimiento como para hacer inferencias sobre ellas. En una base de conocimiento se pueden distinguir el conocimiento “intensional” (conocimiento general acerca del dominio de un problema) y el conocimiento “extensional” (conocimiento específico de un problema particular).

En Lógica Descriptiva la base del conocimiento se divide en dos componentes: TBox (Terminological Box) y ABox (Assertional Box).

• TBox: Contiene conocimiento intensional en forma de una

terminología y está construida por declaraciones que describen propiedades generales de los conceptos. En otras palabras, la TBox contiene el conjunto de axiomas que describen la

estructura del dominio (esquema de clases).

• ABox: Contiene conocimiento extensional (conocimiento de

aserciones), es decir, conocimiento especifico de los individuos del dominio de discurso representable por medio de un conjunto de axiomas que describen una situación concreta.

Las ontologías, al estar fundamentadas en Lógica Descriptiva, deben

cumplir los principios de subsunción, satisfacibilidad, decidibilidad. Subsunción se refiere a probar formalmente que un término es más específico que otro, satisfacibilidad se refiere a que una base de conocimiento no contenga proposiciones contradictorias, y decidibilidad

se refiere a que se puedan establecer razonamientos obteniendo respuestas en un tiempo finito.

Como soporte tecnológico para poder utilizar las ontologías en los

sistemas software el W3C estableció la pirámide de las tecnologías que lo sustentan (Koivunen & Miller, 2002).

En la Figura 2.1 se propone que los recursos sean codificados en Unicode, de manera que puedan ser traducidos desde cualquier lenguaje a otro inteligible por las máquinas. Estos recursos serán referenciados por la URI (Uniform Resource Identifier) de manera que no exista

ambigüedad y todos los recursos representados sean únicos. A partir de XML (eXtensible Marktup Language), las hojas de esquemas de XML y


los espacios de nombres, que permiten expresar la información de una forma estructurada, se constituyen el resto de lenguajes necesarios para la representación de los lenguajes de ontologías. El lenguaje RDF

(Resource Description Framework) (RDF, 2004) y RDFS (Resources Description Framework Schema) (RDFS, 2004) es la base a partir de la cual se puede dotar de significado a los recursos, estableciendo propiedades a cada uno. En el siguiente nivel, se encuentra un lenguaje

puro de ontologías, como por ejemplo OWL 2 (Ontology Web Language) (Motik et al., 2009), que añade características adicionales que permiten una mayor expresividad para representar conocimientos y una forma de establecer las bases para realizar inferencias. En los tres niveles

superiores, se aplican reglas lógicas sobre los conocimientos representados para encontrar evidencias y poder trabajar con ellas, uno de los lenguajes de reglas que más influencia está teniendo es el lenguaje SWRL (Semantic Web Rule Language) (SWRL, 2004).

Figura 2.1 Pirámide de las tecnologías de la Web Semántica (Koivunen &

Miller, 2002). Para extraer información de las ontologías construidas, es necesario disponer de un agente inteligente capaz de trabajar con el conocimiento existente e inferir nuevo conocimiento a partir de una serie de requerimientos dados. Estos elementos reciben el nombre de razonadores.

Los razonadores son un elemento clave para dar soporte a la toma de decisiones ya que, a partir de unos objetivos, pueden identificar y extraer

el conocimiento necesario para lograr dicho objetivo. Los razonadores


actuales se basan en meras comprobaciones simples, que quedan lejos de las capacidades teóricas que pueden tener, aunque alcanzan un nivel funcional que puede ser usado por los sistemas software para tomar

decisiones o componer servicios.

Existen multitud de propuestas de razonadores para trabajar con ontologías, por su importancia y capacidades se pueden destacar los

siguientes: KAON2 (Motik et al., 2004), PELLET (Sirin et al., 2007) y FACT++ (Tsarkov & Horrocks, 2006), que son razonadores que trabaja sobre los lenguajes OWL, SWRL y F-Logic.

En (Dentler et al., 2011) se establece una comparación entre los diferentes razonadores y se concluye que no existe un razonador que destaque por encima de los demás, sino que será el propósito de la

aplicación, la estructura de la ontología y el entorno los factores para elegir uno u otro razonador.

Para la definición de ontologías han ido apareciendo diferentes

metodologías conforme la ingeniería del conocimiento ha ganado en madurez, una metodología que recoge los aspectos fundamentales es METHONTOLOGY (Gómez-Pérez et al., 2004). Esta metodología se compone de 11 tareas fundamentales:

• Tarea 1: Construir el glosario de términos que identifica el

conjunto de términos que serán incluidos en la ontología, su descripción en lenguaje natural, sus sinónimos y acrónimos.

• Tarea 2: Construir taxonomías de conceptos para clasificar

conceptos. La salida de esta tarea es una o más taxonomías con los conceptos clasificados.

• Tarea 3: Construir diagramas de relaciones binarias entre

conceptos de la ontología y conceptos de otras ontologías.

• Tarea 4: Construir un diccionario de conceptos, el cual

contendrá principalmente las instancias de cada concepto, los atributos de clases e instancias y sus relaciones.

• Tarea 5: Describir en detalle cada relación establecida en las

tareas 3 y 4.

• Tarea 6: Describir en detalle cada atributo de instancia que

aparece en el diccionario de conceptos. El resultado de esta

tarea es una tabla donde están descritos todos los atributos.


• Tarea 7: Describir cada atributo de la clase que aparece en el

diccionario de conceptos. El resultado de esta tarea es una tabla donde se describen los atributos de las clases.

• Tarea 8: Describir constantes que especifican el mismo valor.

• Tarea 9: Definir axiomas formales. De este proceso se obtiene

una serie de tablas donde se especifica cada uno de los axiomas identificados.

• Tarea 10. Definir reglas, similar a la tarea 9 pero sobre reglas

entre los conceptos.

• Tarea 11: Definir instancias.

Como breve introducción a la Sintaxis Funcional, Manchester y la notación gráfica utilizadas se presentan a continuación unos ejemplos. La definición de una clase denominada Persona, la cual es subclase de la

clase Thing (clase superior de cualquier ontología) se realiza tal como sigue:

Tabla 2.1 Ejemplo de definición de conceptos.

Sintaxis Funcional Declaration ( Class (Persona)) SubClassOf ( :Clase1 :Thing)

Sintaxis Manchester Class: Persona SubClassOf: Thing

Notación Gráfica

Como ejemplo de instancias, la clase Persona tiene una instancia denominada Juan.

Tabla 2.2 Ejemplo de definición de instancias

Sintaxis Funcional Declaration ( NamedIndividual(Juan)) ClassAssertion ( :Persona :Juan)

Sintaxis Manchester Individual: Juan Types: Persona

Notación Gráfica


Se pueden definir propiedades de datos para unir instancias y datos o propiedades de objeto para unir a otras instancias.

Tabla 2.3 Ejemplo de propiedades de clase.

Sintaxis Funcional Declaration ( DataProperty(:Edad) ) Declaration(ObjectProperty(:Esta_Casado_Con :Person a :Persona) DataPropertyAssertion ( :Edad :Juan :”40”^^xds:inte ger) ObjectPropertyAssertion (:Esta_Casado_Con :Juan :Ma ria)

Sintaxis Manchester DataProperty: Edad Domain: Persona Range: integer ObjectProperty: Esta_casado_con Domain: Persona Range: Persona Individual: Juan Types: Persona Facts: Esta_casado_con Maria, Edad 40

Notación Gráfica

Además de las propiedades vistas, se pueden establecer multitud de axiomas sobre clases, instancias, propiedades de datos y objetos, etc. Por ejemplo, la propiedad de objeto “Esta_casado_con” tiene una serie de axiomas como son que es una propiedad Simétrica, Funcional e

Irreflexiva.

Una vez revisados los conceptos y tecnologías en las que se sustentan las ontologías y la web semántica, se puede afirmar que han alcanzado un

grado de madurez suficiente como para establecer aplicaciones basadas


en ellas. Además, las ontologías son el elemento adecuado para conceptualizar un dominio y poder inferir conocimiento mediante los razonadores, gracias a la lógica subyacente en ellas.

Tabla 2.4 Ejemplo de propiedades de Objeto.

Sintaxis Funcional SymetricObjectProperty( :Esta_casado_con) FunctionalObjectProperty (:Esta_casado_con) Irreflexive(:Esta_casado_con)

Sintaxis Manchester ObjectProperty: Esta_casado_con Domain: Persona Range: Persona ObjectPropertyFrame: Symetric, Functional, Irreflexive

2.2 Teorías de Gestión de Procesos de Negocio Para integrar de forma trasparente los procesos de negocio y de fabricación es necesario conocer los aspectos generales de las teorías de gestión de procesos de negocio, estudiando su evolución para poder identificar los aspectos fundamentales en la gestión de procesos de

negocio, así como los factores que provocan la escasa integración conceptual y tecnológica existente hoy en día en las herramientas de gestión de procesos de negocio modernas.

Desde que en 1776, Adam Smith fue uno de los primeros en describir procesos, a través del principio de división del trabajo propuesto en La

riqueza de las naciones (Smith, 1776), el concepto de la división del

trabajo en procesos especializados ha ido evolucionando. Así en 1911, Taylor propuso identificar por diferentes métodos la mejor forma de realizar una tarea y medir la salida para poder mejorarla en su libro principios de la gestión científica, tras el que es considerado como uno de

los precursores de la reingeniería de procesos de negocio (Espinosa, 2003). Paralelamente, Henry Ford, comenzó a diseñar la cadena de producción aplicada al sector de la automoción, basada en la división de tareas secuenciales, lo que maximizaba la rentabilidad de la producción.

Ya en la época reciente Thomas Davenport, uno de los pioneros de la reingeniería de procesos, propone la definición de un proceso de negocio como (Davenport, 1993):


“Un conjunto estructurado, medible de actividades diseñadas para

producir un producto especificado, para un cliente o mercado

específico. Implica un fuerte énfasis en cómo se ejecuta el trabajo

dentro de la organización, en contraste con el énfasis en el

qué…Este elemento estructural es clave para lograr los beneficios

de la innovación de procesos.”

Esta definición ha ido evolucionando (Hammer, 1990), (Hammer & Champy, 1993), (Rummler & Brache, 1995), y en 2003, a partir de las diversas propuestas realizadas, se establece un modelo que define un proceso de negocio como una secuencia de actividades que buscan

alcanzar un objeto de negocio común (Harmon, 2003). El modelo jerárquico propuesto se divide en los siguientes procesos:

• Cadena de valor: se trata de los procesos principales de la organización de donde parte el resto. Son los procesos más

genéricos soportados por cualquier empresa.

• Proceso: se trata de una subdivisión de la cadena de valor que

comprende otros procesos, subprocesos y actividades.

• Actividades: se trata de los procesos de menor tamaño y que

son tareas indivisibles o que no tiene sentido dividirlas.

Como se define en el modelo, una cadena de valor se divide en procesos

que, a su vez, son divididos en subprocesos y, finalmente, en actividades. De la misma forma se deben establecer los objetivos de cada elemento relacionado con los objetivos de nivel superior. En este sentido, se debe establecer medidas que controlen el cumplimiento de los objetivos por cada cadena de valor, proceso, subproceso y actividad.

En (Barros, 2007) se propone una ontología de procesos de negocio que implica otra clasificación de los procesos a través de lo que denominan

macroprocesos. Estos macro procesos se dividen en macro1 que hace referencia a la cadena de valor, macro2 relacionado con aquellos procesos que implican el desarrollo de nuevas capacidades y oportunidades que permitan posicionarse frente a la competencia,

macro3 para referirse a los procesos estratégicos que dirigen el futuro del negocio y macro4 para aquellos procesos relacionados con procesos de gestión de recursos de soporte. La propuesta define cada macro proceso

como un proceso que puede ser dividido en subprocesos y éstos, a su vez, en actividades.


Por último, dos de los principales impulsores del modelo BPM en (Smith & Fingar, 2002) matizan el concepto de proceso de negocio a partir de la propuesta de Thomas Davenport, indicando que no se recoge la

naturaleza colaborativa y transaccional de los procesos de negocio:

«Un proceso de negocio es el conjunto completo y dinámico de

actividades colaborativas y transaccionales que proveen valor a los

clientes.»

Y destacan la importancia de la coordinación como característica

fundamental de los procesos de negocio, debido a que si todas las tareas son unidades individuales, para formar un proceso de negocio deben coordinarse fundamentalmente.

El uso de las Tecnologías de la Información en la gestión de procesos, junto con la evolución de internet ha propiciado lo que hoy conocemos como e-Business.

Fundamentados en el soporte de las TIC, aparecen las teorías de reingeniería de procesos, como BPR (Business Process Reengineering) (Hammer, 1990). En esta propuesta se destaca que muchas de las tareas realizadas en las organizaciones se realizaban sin aportar valor añadido

para los clientes, y estas actividades deberían ser eliminadas y no aceleradas a través de la automatización. Estas tareas debían ser rediseñadas para aprovechar todo el potencial de las TI. En (Hammer & Champy, 1993) se profundiza en este enfoque, realizando una

transformación radical de la organización eliminado las actividades sin valor añadido.

En (Davenport & Short, 1990) se propone una metodología para la

reingeniería de procesos mediante la combinación de las TI y el rediseño de los procesos de negocio. De esta forma se podría transformar la organización y mejorar sus procesos de negocio. Por ello, Davenport se ha convertido en el precursor de la integración entre negocio y las TI

(Davenport, 1998).

Tanto el enfoque de Hammer como el de Davenport, insistían en que las compañías debían pensar en términos de procesos comprensibles y

coincidían en que la solución para la organización debía darse en dos fases: una primera donde los procesos de negocio debían ser conceptualizados por completo como entidades comprensivas que abordasen desde la petición inicial del cliente hasta la entrega del


producto. Una segunda fase donde la TI se debía usar para integrar estos procesos (Harmon, 2003).

Tras estas propuestas la reingeniería de procesos de negocio BPR se apoyó en las TI como una herramienta clave para la gestión de procesos de negocio y el cambio de procesos. Como consecuencia, las grandes empresas iniciaron la implementación de los sistemas ERP (Enterprise

Resource Planning) (Chang, 2005). Estos sistemas se denominaban Sistemas de Gestión de Procesos de Negocio.

Sin embargo, se identificaron ciertas carencias en los sistemas ERP que les restaron popularidad. Entre ellas se pueden destacar que el uso de los sistemas ERP se realiza en orden inverso. Los procesos de la organización se deben adaptar a la aplicación, y realizar este proceso en

orden inverso conlleva un gran coste (Harmon, 2003) (Chang, 2005) (Smith & Fingar, 2002). Otra de las carencias de los sistemas ERP, es que estos parten de buenas prácticas que incluye el conjunto de procesos de la organización debería tener, no contemplan otra solución óptima. Debido a esto, no están concebidos para la evolución de los

procesos ni para innovar los procesos (Chang, 2005). Además, no tienen en cuenta los problemas de integración y alineación de las TI (Harmon, 2003).

A mediados de los 90 comenzaron a aparecer las primeras ideas del movimiento BPM (Business Process Management) para mejorar, controlar y gestionar los procesos de negocio con el fin de mejorar la

calidad de los productos (Elzinga et al., 1995).

Aunque existen diversas propuestas de lo que es realmente BPM, de las cuales se hace una síntesis en (Gilart, 2010), se puede entender como el

enfoque BPM (Smith & Fingar, 2002):

“La maduración y la síntesis de las prácticas de gestión de

procesos y las TI modernas, es decir, una convergencia real entre

ambos dominios que permite la alineación entre el negocio y las TI...

Por primera vez en la historia del negocio, esta convergencia hace

posible que las compañías puedan gestionar sus procesos de

negocio con gran agilidad…»

El modelo BPM incluye ocho funcionalidades: el descubrimiento de

procesos, el diseño o modelado, el despliegue, la ejecución, la interacción con los procesos, la monitorización, el control, y finalmente el análisis y


optimización. En la Figura 2.2 se puede ver la jerarquía de las ocho fases enumeradas, donde el descubrimiento seria la actividad inicial y el análisis y optimización sería el punto de retroalimentación del proceso.

Las soluciones software que sustenta el enfoque BPM son los sistemas BPMS (Business Process Management System). Estos sistemas han logrado la integración de tecnologías provenientes de distintas áreas con

el fin de lograr la gestión de procesos de negocio. Los principales componentes son (Jeston & Neils, 2006):

• Motor de ejecución de procesos (workflow).

• Motor de reglas de negocio (BPMS ―Business Process Management System).

• Soluciones para integración de aplicaciones de empresa (EAI ―Enterprise Application Integration).

• Sistemas de monitorización de procesos (BAM ―Business Activity Monitoring).

• Sistemas de modelado de procesos (Business Process Modelling).

Figura 2.2 Ciclo de vida BPM (Smith & Fingar, 2002).

Descubrimiento

Diseño

Despliegue

Ejecución Monitorización ControlInteracción

Análisis

Optimización


Las principales ventajas que puede ofrecer un sistema BPMS en las organizaciones son, según el punto de vista, las siguientes (Chang, 2005):

• Desde el punto de vista de negocio:

o Mostrar información de los indicadores claves de proceso.

o Reducir costes mediante la automatización y la mejora

de los procesos en tiempo real.

o Mejorar la satisfacción del cliente.

o Adaptar los procesos a los cambios de forma ágil.

• Desde el punto de vista de las TI:

o Despliegue inmediato de aplicaciones centradas en

procesos.

o Llevar a cabo soluciones que hagan frente a las necesidades derivadas del cambio continuo.

o Minimizar el riesgo de proyectos.

o Aprovechar las inversiones en las TI existentes.

Como se ha visto, los sistemas BPMS se han convertido en una herramienta fundamental para la gestión de los procesos de negocio. En el escenario actual, en el que la creciente demanda del mercado de productos personalizados exige a las organizaciones adaptar su

producción a sus demandas, el modelo BPM, permite adoptar estos requerimientos, se fundamenta en el cambio como una de sus características fundamentales para la mejora continua de los procesos.

Sin embargo, tal como se identifica en (Hepp et al., 2005), sigue siendo necesario incrementar las capacidades de los sistemas BPM para la integración entre negocio y las TI, la gestión de las grandes cantidades

de información, así como el creciente cambio en los procesos productivos.

Como ya se ha comentado previamente, los sistemas BPM son los

adecuados para afrontar las nuevas demandas del mercado. Sin embargo, existen una serie de problemas que aún están por abordar, y es precisamente por estos problemas por lo que es necesario dotar a los BPMS de mayores funcionalidades.


En primer lugar, las visiones de negocio y de las TI pertenecen a diferentes mundos, por lo que es necesaria una estrecha colaboración entre los Business managers y los IT managers. Sin embargo, este factor

se convierte en un punto que introduce retardos en la adaptación y posterior despliegue de los procesos de negocio en las organizaciones. Tal como se ve en la Figura 2.3, la comunicación necesaria entre los expertos de negocio y los expertos tecnólogos, ya sea para conocer el

ámbito de negocio o para implementar los procesos necesarios para el negocio, se convierte en una labor manual que rompe con el ciclo ágil propuesto en BPM (Hepp et al., 2005).

Figura 2.3 Brecha conceptual y tecnológica de BPM (Hepp et al., 2005).

En segundo lugar, la metodología BPM es una metodología abierta, que

acepta múltiples tecnologías, y es precisamente por este motivo que existen incompatibilidades entre estas tecnologías, desde los lenguajes de modelado de procesos como BPMN, FMBL, UML con distinta capacidad expresiva, hasta los lenguajes de ejecución como BPEL

basados en servicios SOAP o REST-Full. Esto provoca que los procesos de negocio implementados sean altamente dependientes de la tecnología utilizada y la implementación manual realizada.

Estos motivos ponen de relieve la necesidad de seguir mejorando la gestión de procesos de negocio en las organizaciones, reduciendo el número de tareas manuales y agilizando la transición de modelos conceptuales a implementaciones concretas.

Una de las corrientes que está teniendo éxito en los últimos años es la de introducir información semántica como modo de enriquecer la información con la que trabajan los sistemas BPMS para incrementar la


compatibilidad entre tecnologías y reducir las labores manuales de comunicación.

Tal como se muestra en (Markovic & Kowalkeiwicz, 2008), el uso de información semántica puede automatizar e identificar posibles relaciones a la hora de modelar procesos de negocio. En este estudio introducen información semántica de los objetivos de negocio como base

para automatizar, en cierto grado, el modelado de procesos de negocio.

El paso de modelos de procesos de negocio a un lenguaje que pueda ser

ejecutado por los sistemas informáticos de la organización es otra de las carencias actuales de los sistemas BPMS. Existen propuestas como la desarrollada en (Ouyang et al, 2006) que consisten en hacer un mapeado de la notación BPMN con las correspondientes sentencias en BPEL, de

forma que se pueda pasar de manera automática de un diagrama en notación gráfica BPMN a una hoja WS-BPEL. Sin embargo, esta correlación proporciona la estructura de la hoja WS-BPEL pero no identifica las características de los servicios como las llamadas a servicios y los pasos de mensaje entre las distintas llamadas de los

servicios que componen el proceso.

Aprovechando la posibilidad de generar procesos BPEL a partir de

diagramas en notación BPMN, en (White, 2005) se propone el uso de diagramas BPMN, en los cuales se introduce información específica de los servicios y los tipos de de mensajes que se pasan entre los distintos procesos, para modelar servicios en notación BPEL. Esta misma filosofía

es la que se ha usado en el desarrollo de herramientas comerciales como INTALIO (INTALIO, 2011), con la cual se pueden traducir modelos de negocio en notación gráfica a servicios BPEL, introduciendo en el diagrama BPMN la información referente a las llamadas a servicios. Aunque este enfoque posibilita el desarrollo y despliegue rápido de

procesos, mezcla los niveles de negocio y de tecnología en un mismo diagrama, lo que hace que los procesos modelados sean dependientes de la tecnología, perdiendo un poco la separación entre nivel de negocio y nivel tecnológico. Lo que se traduce en un alto acoplamiento entre

niveles y que ante un cambio en uno de los dos niveles sea necesario rehacer el proceso completamente.

En (Shen et al., 2005) se propone un sistema para traducir servicios en BPEL4WS a notación de SWS en lenguaje OWL-S. De forma que para las organizaciones sea relativamente rápido adaptar sus WS a SWS (Semantic Web Services), lo que es un paso fundamental a la hora de adaptar los sistemas BPMS a SBPMS (Semantic Business Process


Management Systems). Esto es posible gracias a que en la descripción semántica de servicios en OWL-S se introduce, tanto las características de invocación de los servicios reflejadas en las hojas WSDL, como la

orquestación de los mismos reflejada en BPEL4WS.

Otra de las ventajas que proporcionan los SBPMS (Semantic Business Process Management System) es la posibilidad de consultar de manera

automática procesos modelados ya disponibles en la organización, con el fin de encontrar procesos ya desarrollados que puedan ser similares a los que se desea desarrollar y evitando así, posibles duplicidades a la hora de desarrollar nuevos procesos (Awad et al., 2008). Esto que para

un humano requiere un amplio conocimiento de los procesos desarrollados por la organización a lo largo del tiempo y un gran esfuerzo a nivel temporal puede ser automatizado gracias a la información semántica, favoreciendo la reusabilidad de procesos ya desarrollados.

Debido a la aparición de forma paralela de diversas propuestas para mejorar partes independientes de los sistemas BPMS mediante el uso de información semántica, se planteo el proyecto de la Unión Europea IST

SUPER (Semantics Utilised for Process Management within and between Enterprises) (IP-SUPER, 2006). Este proyecto dotado con 15 millones de euros y con el soporte de empresas punteras en el sector informático como SAP, IBM y Telefónica entre otras y con la colaboración de más de

15 centros de investigación surge con los objetivos de desarrollar completamente un sistema de SBPM (Semantic Business Process Management). Los objetivos concretos que se desean lograr son los siguientes:

• Un Framework para la gestión semántica de procesos de negocio.

• Ofrece una visión a los expertos de negocio alejada de la visión

puramente técnica.

• Reacción inteligente y flexible ante cambios

• Integración de procesos de negocio heterogéneos

• Mediación dentro y entre organizaciones.

Para lograr los objetivos se partió desde la definición de un nuevo lenguaje ontológico WSML (Web Services Model Language), y se creó una nueva ontología para el modelado de procesos denominada BPMO


(Business Process Modelling Ontology). Estos procesos se traducen a un nuevo lenguaje de SWS como WSMO (Web Services Modelling Ontology) y se ejecutan en un entorno desarrollado a medida del sistema. Si bien

en este proyecto se pone de manifiesto la utilidad de la información semántica en todo el ciclo de BPM, la falta de soporte hacia los sistemas BPMS tradicionales y la falta de estandarización de las tecnologías utilizadas suponen un hándicap para la implantación de lo propuesto en

este proyecto en las organizaciones.

2.3 Modelos de Fabricación El modelo productivo basado en la fabricación ágil es el que mejor se adapta a los nuevos requisitos derivados, en gran parte, de la evolución de Internet y de las TIC (Avella & Vázquez, 2005). La fabricación ágil se

puede definir como un modelo de producción que integra la tecnología, los recursos humanos y la organización a través de las TIC, que otorga flexibilidad, rapidez, calidad y eficiencia y que permite responder de forma deliberada, efectiva y coordinada ante cambios en el entorno.

La llegada de Internet ha influido notablemente en la adopción de nuevas estrategias por parte de las organizaciones actuales para adaptar sus

procesos, reingeniería de procesos (Harmon et al., 2001), así como la incorporación de paradigmas empresariales basados en servicios y componentes software distribuidos, desplegados sobre arquitecturas de n-niveles que las ayuden a implantar nuevos modelos de negocio y a

obtener provecho del nuevo modelo de competencia creado (Maciá et al., 2005).

Sin embargo, debido a limitaciones físicas y tecnológicas, los procesos de

fabricación no han logrado el nivel de integración y automatización deseables, teniendo que ser considerados, en muchos casos, como sistemas heredados.

Las primeras propuestas de integración de los componentes de fabricación con los componentes de negocio se basaban en protocolos propietarios situados en el nivel de recursos del modelo e-Business, como sistemas externos a los procesos de negocio. (Modbus, Profibus,

AS-I, FIPIO, DeviceNET, Interbus o Ethernet industrial). (Moreno, 2004).

En (Transparent Factory, 2001), se opta por el uso de dispositivos embebidos en los dispositivos de control o PLCs, estos dispositivos


proporcionan conexión Ethernet, soporte TCP/IP e incluso un servidor Web embebido. Transparent factory define una arquitectura de automatización abierta basada en las tecnologías de Internet que

proporciona una comunicación transparente entre el nivel de planta y los sistemas de gestión empresarial y permite el control de la fabricación desde cualquier parte del mundo.

La incorporación de tecnologías de Internet también es una propuesta para normalizar el nivel de planta. Así en (Topp & Müller, 2002), se propone usar dos enfoques: El uso de páginas Web dinámicas para un

modelo B2C, y el uso de SOAP para un modelo B2B. Se basa en el uso de Servicios Web como medio normalizado para acceder a las funcionalidades de los dispositivos, de forma que estos se puedan integrar en los sistemas de planificación de recursos empresariales (ERP). En este trabajo se propone una arquitectura que utiliza la

tecnología de Servicios Web como mecanismos de comunicación de los elementos de producción y se introduce el concepto de Workflow para la composición de los Servicios mediante un motor de orquestación y el uso

de ontologías que incluyan la información semántica del flujo del proceso que asocia cada una de las actividades del Workflow con el servicio Web que expone dicha actividad. El objetivo perseguido en la propuesta es que la ontología desacople el flujo del proceso de los Servicios Web

necesarios para su ejecución ofreciendo dinamismo ante los cambios que se producen en el entorno.

En el marco de proyectos europeos de investigación, se encuentran

importantes propuestas que avalan el interés de esta línea, con importantes resultados que avanzan hacia SOA y dispositivos embebidos en la maquinaría industrial como tecnologías válidas (SIRENA, 2003), (SODA, 2006), (SOCRADES, 2006), (eSONIA, 2010).

Apoyadas en la línea de la maquinaria industrial integrada en una arquitectura SOA y con la intención de satisfacer las nuevas necesidades de los modelos productivos han surgido diversas propuestas para dar

soporte a los sistemas de fabricación ágil.

En la actualidad la mayoría de los enfoques de automatización y control industrial abogan por el uso de inteligencia distribuida para maximizar

la agilidad y flexibilidad de los sistemas: Bionic Manufacturing Systems (Ueda, 1992), Reconfigurable Manufacturing Systems (Koren et al., 1999) (Mehrabi et al., 2000), Holonic Manufacturing Systems (Babiceanu &

Chen, 2006) (Bussmann & Mcfarlane, 1999) (Gou et al., 1998) (Van Brussel et al., 1998), Balanced Automation systems (Barata et al., 2006)


(Frei et al., 2007a) (Onori et al., 2006), Evolvable Production Systems (Barata et al., 2007a) (Barata et al., 2007b) (Frei et al., 2007c).

Además, en este sentido existen propuestas como la de (Ribeiro et al., 2008) que aboga por el uso de sistemas MAS (MultiAgent Systems) junto

con el paradigma SOA en los dispositivos de producción como solución adecuada para afrontar los requerimientos de los nuevos modelos de producción en el ámbito de la fabricación y automatización industrial. En esta misma línea, en (Villaseñor et al., 2008) se presenta una

combinación del binomio MAS-Servicios Web que propone un sistema de control distribuido que automatice la reconfiguración en sistemas de fabricación que contienen parte de la funcionalidad del sistema.

Propuestas como la de (Barata et al., 2007c) indican que gran parte de los métodos de diagnosis de sistemas pueden ser trasladados a nivel de dispositivo dotándoles de mayor inteligencia. De esta forma cada elemento deberá ser capaz de auto-monitorizarse, auto-diagnosticarse y

auto-recuperarse. Como indica, estas auto-capacidades permitirán que el sistema reaccione automáticamente ante problemas inesperados y ante los cambios derivados del entorno.

En (McFarlane & Bussmann, 2000) y (Lee et al., 2004) se presentan dos propuestas de sistemas distribuidos de control y planificación de la producción con un enfoque holónico que sugiere el traslado de las

capacidades de decisión, control y supervisión a nivel local. Además, indican la necesidad del comportamiento proactivo y reactivo, capacidad auto-organizativa, flexibilidad de cada componente a la vez que se estructuran mediante una arquitectura distribuida que conforma el

sistema global.

Una forma de lograr introducir inteligencia en los sistemas industriales es mediante el uso de información semántica. En (Borgo & Leitao, 2007)

se define el núcleo de una ontología para fabricación que se centra en clasificar ontológicamente los conceptos de ADACOR de acuerdo con la ontología genérica DOLCE (DOLCE, 2010). En la Figura 2.4 se pueden ver las clases implicadas en la definición de la ontología ADACOR.

En (Lemaignan et al., 2006) se presenta la ontología MASON (MAnufacturing´s Semantic Ontology) que conceptualiza las características del nivel de planta de forma más específica, así como una

serie de posibles relaciones entre elementos. En este estudio se muestran dos posibles aplicaciones de la ontología, una para la estimación de costes de manera automática y otra para el uso de agentes


inteligentes que utilizan la información semántica para identificar posibles errores en los procesos industriales.

Figura 2.4 Conceptos de la ontología ADACOR (Borgo & Leitao, 2007).

Esta ontología se basa en la descripción del dominio industrial realizada en (Martin & D´Acunto, 2003), y que establece el dominio industrial

como la suma de productos y recursos.

La ontología propuesta se basa en tres conceptos de nivel superior: las operaciones, los recursos y las entidades. Cada uno de estos conceptos

está compuesto por conceptos más específicos. Dentro del concepto entidad se pueden encontrar los conceptos de Entidad de Coste, Entidad

Administrativa y Entidad Tecnológica, a su vez dentro del concepto

Entidad Tecnológica se pueden clasificar los siguientes conceptos:

Entidad de ensamblado, Entidad Geométrica, Entidad geométrica para

fabricación y Materia Prima. De la misma forma se conceptualizan una serie de operaciones como Operaciones Logísticas, Operaciones de

fabricación, Operaciones de ejecución y Operaciones Humanas.

Finalmente se identifican los conceptos que componen la clase Recurso, entre los que cabe destacar la clasificación en Recursos Humanos,

Recursos Geográficos y Recursos Materiales. Entre todos estos conceptos existen diferentes relaciones semánticas como se puede ver en la Figura 2.5.


Con esta ontología se cubre tanto el nivel conceptual, que requiere un amplio conocimiento de los recursos y procesos que intervienen en la actividad productiva y las relaciones entre ellos, como el nivel

operacional, que permite tener un flujo de datos entre entornos heterogéneos, lo que proporciona un contexto operacional para dichos recursos.

Figura 2.5 Conceptos de mayor nivel de MASON (Lemaignan et al., 2006). Siguiendo con este enfoque, en (Al-Safi & Vyatkin, 2007) se propone un

sistema de reconfiguración de maquinaria industrial sin intervención humana, basándose en ontologías, con el objetivo final de que la maquinaria sea capaz de reconfigurarse de manera autónoma para cambiar el entorno productivo. Con la hipótesis de partida de que “el

conocimiento del entorno de fabricación puede ser formalizado con reglas y relaciones entre los objetos” y apoyados en la ontología MASON definida en (Lemaignan et al., 2006) se crea un sistema en el que caben destacar los siguientes elementos:

• El analizador de requisitos extrae todas las operaciones

requeridas de un documento de requerimientos que contiene las operaciones, atributos y circunstancias.


• El analizador de entorno captura toda la especificación del

entorno necesaria sobre las máquinas del sistema. posición, conexiones, elementos, etc.

• El modelador de conocimiento construye la ontología del

entorno de fabricación.

• El motor de decisión produce una configuración factible que satisface el modelo de conocimiento.

Esta propuesta es especialmente interesante por la identificación de los elementos necesarios para obtener información del nivel de planta y actuar sobre él. Sin embargo, en esta propuesta sigue existiendo una brecha entre el nivel de negocio y de planta, lo que implica una

discontinuidad en el proceso productivo, desde la demanda de un producto hasta su venta cuando ha sido fabricado.

Otro enfoque utilizado para lograr la automatización en el nivel de planta

es el propuesto en (Martínez-Lastra & Delamer, 2006), el cual se basa en el uso de Servicios Web Semánticos (SWS) para componer de manera automática procesos de fabricación. En este trabajo se identifica que mientras la reconfiguración de la maquinaria industrial a nivel mecánico

es posible mediante la reorganización de los componentes modulares, todavía es necesaria una reprogramación manual a nivel informático. Destaca que actualmente los sistemas se construyen utilizando diferentes tipos de agentes inteligentes que actúan de forma

independiente, lo que supondrá un caos de dispositivos, máquinas y agentes software que actúan de manera independiente en la tarea emergente de producción bajo demanda.

Siguiendo en esta línea en (Delamer & Martinez-Lastra, 2006), se propone un sistema basado en el uso de Servicios Web Semánticos con el objetivo de que sean las propias máquinas, a partir de la información semántica contenida en los SWS, las que puedan realizar razonamientos

y deducir el conocimiento suficiente para actuar recíprocamente. Así, el conjunto de habilidades de comunicación de los diferentes componentes se puede utilizar con el objetivo de coreografiar la interacción de las mismas. De esta forma se logra un sistema con capacidad de auto-

organización y ejecución de procesos de fabricación bajo demanda.

Con el uso de SWS se puede lograr automatizar (Martínez-Lastra & Delamer, 2008) la coordinación o orquestación de los Servicios Web que

encapsulan las operaciones para lograr procesos de mayor nivel. También se puede lograr la generación de los mensajes necesarios para


invocar a los Servicios Web involucrados en el proceso productivo. Gracias a la información disponible en la descripción semántica de los servicios se pueden evaluar las precondiciones necesarias para la

invocación de un proceso, lo que facilita planificar los procesos productivos sin la necesidad de conocer las condiciones justo en tiempo de ejecución. Por último, se puede automatizar la evolución del modelo productivo y del equipamiento, de acuerdo con los efectos de los servicios

web.

Sin embargo, en esta propuesta sigue presente la falta de continuidad de los procesos de negocio y fabricación, quedando relevado a un segundo

plano los objetivos fundamentales de las organizaciones manufactureras, por lo que sigue siendo necesario conectar los procesos de fabricación auto-organizados con el resto de procesos de la organización.

Debido al interés que está teniendo el uso de información semántica para la automatización de los entornos manufactureros, especialmente a nivel de planta, han ido surgiendo de forma paralela diversas ontologías para conceptualizar dicho dominio. Por ello, en (Martínez-Lastra &

Delamer, 2008) se identifican las directrices comunes para el desarrollo de sistemas de automatización industrial en ontologías. Entre ellas cabe destacar:

• Para mejorar los procesos es necesario introducir en las

ontologías nociones de tiempo. En la mayoría de ontologías el modelado del tiempo de ejecución de un proceso es un aspecto que suele faltar o está definido de manera insuficiente, lo que hace más difícil planificar de forma autónoma la secuencia

óptima de un proceso.

• Es necesario el uso de ontologías de tarea. Los enfoques

actuales centran la Lógica Descriptiva en aspectos dinámicos de los procesos, como por ejemplo, precondiciones y efectos.

• Optimizar algoritmos para A-Boxes dinámicas. La mayoría de

los motores de inferencia están optimizados para adiciones

incrementales de conocimiento y no para la revisión de conocimiento, como por ejemplo, el cambio de estados de un producto o del entorno.

• Aplicación de algoritmos de reconciliación de ontologías. La

mayoría de los enfoques actuales sólo funcionan con las ontologías para compartir, y no cuando ontologías diferentes se


deben usar en conjunto, por ejemplo cuando los dispositivos son de diferentes fabricantes.

• Mediación entre ontologías. Como alternativa a la reconciliación

de ontologías, los mediadores podrían usarse para traducir

automáticamente entre ontologías.

• Demostraciones. Se necesitan demostraciones para ilustrar la

aplicación de ontologías, para mostrar la viabilidad del enfoque y facilitar la transferencia de tecnología a la industria.

• Aplicaciones al diagnostico. Las fábricas producen un flujo

constante de información de procesos que refleja los innumerables estados de una fábrica, y que deben ser

interpretados en tiempo real. Las ontologías puede ayudar a modelar las relaciones entre la información y el modelado de condiciones y eventos, facilitando el razonamiento que conduce a un diagnostico para evitar condiciones de error.

• La integración de información en la empresa. El uso de

ontologías puede facilitar la integración de los entornos de producción en los sistemas de información de la empresa.

De las propuestas evaluadas se desprende que existen dos tendencias para la composición automática de servicios, por un lado el uso de SWS

y por otro el uso de servicios en lenguaje BPEL. En (Ren et al., 2007) se hace una comparativa entre estas dos tendencias y se concluye que los SWS son más apropiados para entornos dinámicos y que los servicios compuestos en BPEL son la opción idónea para flujos de trabajo

controlados.

La mayoría de estudios analizados pertenecen al ámbito científico. Sin embargo, existe un gran interés en esta línea de investigación por parte

de la industria. Como muestra de este interés en (Arancón et al., 2008) se presenta un caso de estudio para conceptualizar el dominio de la industria metalúrgica ARCELOR.

Las propuestas estudiadas se centran de manera independiente en el ámbito industrial o en el de la gestión de procesos, lo que provoca que se siga produciendo una separación entre la gestión de procesos y la gestión de la producción. Mediante la propuesta de IMaaS (Industrial

Machine as a Service) (Gilart, 2010) (Gilart et al.,2007), que se centra en modelar la maquinaria industrial como un contenedor de procesos ofertados como servicios, se integran los procesos de fabricación dentro de los sistemas de gestión de procesos de negocio. Esta integración es


gracias a la normalización conceptual y tecnológica llevada a cabo en esta propuesta. Sin embargo, sigue existiendo la separación entre los niveles conceptuales y tecnológicos característicos en los sistemas de

gestión BPM (Hepp et al., 2005) que unidos al giro productivo hacia la personalización masiva (Younghwan et al., 2005) (Jeston & Neils, 2006), que se confirma como una necesidad en los próximos años (OPTI, 2009), hace que sea necesario abordar una propuesta de solución para reducir

el cuello de botella que se produce ante el incremento de demanda de productos personalizados en los entornos industriales, con tareas de gestión y producción tan diferenciadas conceptual y tecnológicamente.

Del estudio realizado se puede concluir que el uso de información semántica en los sistemas de gestión de procesos de negocio permite la composición automática de procesos e independizar las distintas visiones del nivel de negocio y del nivel tecnológico. Además, el uso de

información semántica también posibilita la elaboración de sistemas inteligentes a nivel de planta para la reconfiguración automática de procesos de fabricación, permitiendo introducir inteligencia en los elementos distribuidos a nivel de planta. También, se han identificado

las características fundamentales que debe poseer una ontología para conceptualizar el nivel de planta y establecer razonamientos que den soporte a la gestión de los procesos productivos.

De cara a la propuesta del presente trabajo, el uso de información semántica es una herramienta válida para lograr la integración de los procesos de fabricación dentro de los sistemas de gestión de procesos de negocio. Dando soporte a la auto-organización de los entornos

productivos, estableciendo un comportamiento reactivo y proactivo que pueda dar respuesta tanto a inesperados cambios en un corto plazo de tiempo como a los cambios de la demanda del mercado y dando soporte a la personalización masiva en las organizaciones manufactureras.

IMaaS es una base adecuada sobre la que construir la propuesta de solución gracias a la normalización tecnológica y conceptual realizada de los elementos de fabricación, lo que permite integrarlos con los diferentes elementos de gestión de la organización.

C a p í t u l o 3

Antecedentes. IMaaS

El punto de partida del presente trabajo es la visión de la Maquinaria Industrial como Servicio o IMaaS (Industrial Machine as a Service), conceptualizada como procesos de negocio.

Esta propuesta ha sido desarrollada en el seno del grupoM de redes y middleware, de la cual se han derivado diversas publicaciones (Marcos et al., 2009) (Gilart et al., 2006a) (Gilart et al., 2006b) (Gilart et al., 2007) (Maciá et al, 2011) y que ha culminado con la presentación de la Tesis

Doctoral “Metodología para la gestión integral de los procesos de

producción: Modelado de la maquinaria industrial como un sistema de

gestión de procesos de negocio” (Gilart, 2010).

Esta propuesta ha permitido la normalización conceptual y tecnológica de la maquinaria industrial para que pueda ser usada dentro de un sistema de gestión de procesos de negocio BPMS. Precisamente esta

propuesta es la que posibilita el desarrollo del presente trabajo de investigación, dando un soporte fundamental para la integración y gestión ágil de los procesos de fabricación dentro de los sistemas BPMS.

Por este motivo, a continuación se presenta un resumen de los aspectos más relevantes de la propuesta tal y como se estructuran en la tesis doctoral (Gilart, 2010):

• Normalización Conceptual de la Maquinaria Industrial.

• Normalización Tecnológica de la Maquinaria Industrial.

• Conclusiones.


3.1 Normalización Conceptual de la Maquinaria Industrial Como resultado de la aplicación de la metodología para construir un SGP (Sistema de Gestión de Procesos) en las organizaciones manufactureras, se concluyó que los sistemas BPM representan el enfoque más adecuado

para la consecución de un SGP ágil, conforme a los requerimientos derivados de los nuevos modelos de negocio. Sin embargo, por definición, los sistemas BPM no están preparados para gestionar procesos de fabricación.

Existen diferencias conceptuales debidas a la propia naturaleza de los procesos de negocio y de fabricación que han supuesto un factor determinante a la hora de definir los sistemas TI que los gestionan. Por

un lado, los procesos de negocio poseen un carácter más abstracto, relacionado con las transacciones comerciales de las organizaciones (cumplir los objetivos estratégicos de la organización). Por otro lado, la naturaleza de los procesos de fabricación está relacionada con los

aspectos mecánicos originados por las operaciones llevadas a cabo por la maquinaria industrial y están orientados a la modificación de las propiedades de las materias primas para la consecución de un producto final.

Por estos motivos, para poder aprovechar todo el potencial de los sistemas BPM en las organizaciones manufactureras, es necesario realizar un proceso de transformación que traslade los procesos de

fabricación y su gestión al dominio de los procesos de negocio.

Para llevar a cabo este proceso de transformación, el proceso de normalización conceptual de la maquinaria industrial (Figura 3.1) tiene

como objetivo principal establecer un modelo que elimine las restricciones conceptuales existentes entre los procesos de fabricación y los procesos de negocio, incorporando a la maquinaria industrial los elementos necesarios para mostrarla como un sistema de gestión basado

en el ciclo de vida del modelo BPM. Como resultado final del proceso se obtiene un modelo o patrón BPM de la maquinaria industrial, que posteriormente servirá de controlador en el proceso de normalización tecnológica de la maquinaria industrial. Con esta propuesta se pretende

evitar que se produzcan desviaciones de la visión y de los objetivos de negocio trazados en los niveles superiores de la organización.

Capítulo 3. Antecedentes. IMaaS 45

Para lograr su objetivo, el proceso se ha dividido en dos subprocesos con objetivos claramente diferenciados (Figura 3.1). En primer lugar, el

proceso de normalización de los procesos de fabricación de la maquinaria

industrial tiene como objetivo mostrar los procesos de fabricación y operaciones mecánicas llevadas a cabo por la maquinaria industrial como procesos de negocio, estableciendo para ello una correlación entre

ambos dominios: el de fabricación y el del negocio. En segundo lugar, el

proceso de gestión de los procesos de negocio de la maquinaria industrial tiene como objetivo mostrar la maquinaria industrial como un sistema BPM incluyendo los elementos y componentes necesarios para satisfacer

sus principios fundamentales, pero manteniendo a la vez los requerimientos de la gestión de procesos de fabricación. Para ello, es necesario establecer una correlación entre la gestión de los procesos de fabricación y la gestión de los procesos de negocio.

Figura 3.1 Proceso de normalización conceptual de la maquinaria industrial (Gilart, 2010).

3.1.1 Proceso de Normalización Conceptual de los

Procesos de Fabricación de la Maquinaria Industrial

Los sistemas de Gestión de Procesos de Negocio (BPMS) establecen como

unidad básica los procesos de negocio. Para poder gestionar los procesos

Normalización tecnológica de la

maquinaria industrial

<<control>>

<<achieve>>

<<goal>>

Eliminar restricciones tecnológicas

<<physical>>Maquinaria Industrial

<<physical>>Maquinaria

Industrial como Servicio

<<process>>

<<abstract>> Procesos de fabricación

de la maquinaria industrial

Mapa de procesos

de laMaquinaria industrial

Normalización Conceptual la Maquinaria Industrial

Normalización conceptual de

servicios

Normalización conceptual de la gestión de los

procesos

<<goal>>

Estructurar la maquinaria industrial como procesos

<<achieve>>

<<goal>>

Mostrar la maquinaria industrial como un BPMS

<<achieve>>

Normalización conceptual de

procesos

Normalización conceptual de los

procesos de fabricación

<<abstract>>Modelo BPM


<<achieve>>

<<goal>>

Eliminar restricciones conceptuales


de fabricación llevados a cabo por la maquinaria industrial, estos deben ser trasladados al dominio de los procesos de negocio. Para ello, se debe establecer una correlación entre el dominio de los procesos de

fabricación y de negocio que permita visualizar y estructurar los procesos de fabricación como procesos de negocio. Este es el objetivo de la normalización conceptual de los procesos de fabricación de la maquinaria industrial llevada a cabo en (Gilart, 2010).

Como resultado de la aplicación del proceso de normalización conceptual de los procesos de negocio de la maquinaria industrial se obtiene un modelo conceptual que permite estructurar los procesos y operaciones

de fabricación de la maquinaria industrial de la misma forma que se hace en un mapa de procesos de negocio y, de esta manera, podrán ser gestionados por un BPMS. A este elemento se le ha denominado mapa de procesos de negocio de la maquinaria industrial.

Para lograr el objetivo del proceso y evitar desviaciones del mismo se identificaron un conjunto de elementos de control encargados de guiar y conducir la ejecución del proceso. Estos elementos están formados por

las teorías de procesos de negocio, las teorías de gestión de calidad de procesos, las teorías de procesos de fabricación y los fundamentos de gestión de los procesos de fabricación.

Las definiciones y clasificaciones de los procesos de fabricación contempladas en las teorías de procesos de fabricación permiten controlar el proceso a la hora de establecer un modelo organizativo de

partida del concepto proceso de fabricación.

De los fundamentos de gestión de procesos de fabricación se extraen las

técnicas, métodos y recomendaciones más utilizadas en la gestión de los procesos llevados a cabo por la maquinaria industrial y que deben ser contemplados en el modelo.

Para llevar a cabo el proceso se definieron las siguientes fases:

• La definición del concepto de proceso de negocio.

• La categorización de los procesos de negocio.

• La definición formal del concepto proceso de negocio a partir de

las fases anteriores.

• La definición del concepto proceso de fabricación.

• La clasificación de procesos y operaciones de fabricación.


• La formalización del concepto de proceso de fabricación a partir

del análisis realizado en las dos fases anteriores.

• La correlación de ambos modelos.

La definición alcanzada, tras un amplio estudio de las definiciones propuestas por los autores y organizaciones más relevantes del ámbito,

establece que se puede entender por proceso de negocio:

«Un conjunto estructurado, medible, de actividades diseñadas para

producir un resultado de negocio definido en base a unos objetivos.»

La categorización de procesos de negocio establece dos tipos de procesos de negocio, los procesos de negocio principales que son aquellos que aportan el valor a la organización y los procesos de negocio de soporte

que facilitan las operaciones en curso de los procesos principales.

El concepto de proceso de negocio se formaliza mediante notación UML, a partir de la definición y categorización de procesos de negocio, tal como

se ve en la Figura 3.2. A partir de este modelo conceptual se estructuran los procesos de la maquinaria industrial como un mapa de procesos de negocio.

La representación formal del concepto de proceso de fabricación ha sido establecida a partir del análisis de las definiciones y clasificaciones.

El concepto de proceso de fabricación ha sido definido a partir de las propuestas descritas en (Espinosa, 2003) (Groover, 2000) y en (Alting, 1993) como:

«El conjunto de operaciones que realiza una maquinaria industrial

para transformar una materia de partida en un producto diferente

conforme a las necesidades del propio fabricante o de un cliente.»

«Desde el punto de vista de la maquinaria industrial se puede

definir como el conjunto de operaciones de la maquinaria para

realizar la transformación requerida.»


Figura 3.2 Representación mediante modelado UML de la definición y clasificación del concepto proceso de negocio.

A esta definición

puntos de inspección son una de las principales formas de medir el éxito del proceso y del producto en los procesos de fabricación y las operaciones supeditadas. En (Espinosa, 2003) (Groover, 2000) se puedever los distintos tipos de inspección basados en la comprobación de

atributos y variables

acercarlo al de proceso de negocio. Los datos claves adquiridos pueden ser recogidos a través de sensores.

La categorización de los procesos y operaciones de fabricación que tienen lugar en la maquinaria industrialen (Groover, 2000) y (Alting, 1993)

procesos de fabricaciónconcepto de proceso de negocio.

Los procesos de fabricación se han clasificado como: básicos o primarios

y auxiliares. Aunque, la clasificación y la definición únicamente establece como procesos de fabricación aquetransformación en el material. Pde cualquier maquinaria que participe en la producción aunque no

realice transformaciones en la materia, como puede ser: un sistema de almacenamiento o sistemas de transporte, dotados de una mayor semántica, estableciendo los procesos básicos

Modelo de gestión de los procesos basado en conocimiento

Representación mediante modelado UML de la definición y clasificación del concepto proceso de negocio.

A esta definición se le ha añadido el concepto de medida ya que

puntos de inspección son una de las principales formas de medir el éxito del proceso y del producto en los procesos de fabricación y las operaciones supeditadas. En (Espinosa, 2003) (Groover, 2000) se puedever los distintos tipos de inspección basados en la comprobación de

variables y que han servido para formalizar el modelo y al de proceso de negocio. Los datos claves adquiridos pueden

ser recogidos a través de sensores.

zación de los procesos y operaciones de fabricación que tienen lugar en la maquinaria industrial, basándose en las propuestas descritas

(Groover, 2000) y (Alting, 1993) en función de la importancia de los

procesos de fabricación, siguiendo la propuesta de la formalización del concepto de proceso de negocio.


y auxiliares. Aunque, la clasificación y la definición únicamente omo procesos de fabricación aquellos que realizan algun

transformación en el material. Para solventar el problema de integración de cualquier maquinaria que participe en la producción aunque no

realice transformaciones en la materia, como puede ser: un sistema de almacenamiento o sistemas de transporte, los tipos de procesos han sido dotados de una mayor semántica, estableciendo los procesos básicos

Representación mediante modelado UML de la definición y

se le ha añadido el concepto de medida ya que los

puntos de inspección son una de las principales formas de medir el éxito del proceso y del producto en los procesos de fabricación y las operaciones supeditadas. En (Espinosa, 2003) (Groover, 2000) se pueden ver los distintos tipos de inspección basados en la comprobación de

y que han servido para formalizar el modelo y al de proceso de negocio. Los datos claves adquiridos pueden

zación de los procesos y operaciones de fabricación que tienen basándose en las propuestas descritas

en función de la importancia de los

de la formalización del


y auxiliares. Aunque, la clasificación y la definición únicamente alguna

ara solventar el problema de integración de cualquier maquinaria que participe en la producción aunque no

realice transformaciones en la materia, como puede ser: un sistema de los tipos de procesos han sido

dotados de una mayor semántica, estableciendo los procesos básicos


como aquellos que son principales desde el punto de vista de la maquinaria que los lleva a cabo. Los auxiliares abarcan los procesos de apoyo a los anteriores.

Como resultado de la conceptualización y clasificación de los procesos de fabricación, en la Figura 3.3, se muestra la formalización obtenida mediante la notación UML del concepto de proceso de fabricación.

Partiendo de los modelos descritos se puede establecer una correlación, tal como ve en la Tabla 3.1, que permite representar los procesos de fabricación en el dominio del negocio.

Figura 3.3 Representación mediante modelado UML de los procesos de

fabricación. Los procesos deben ser medidos a través de la adquisición de ciertos parámetros para alcanzar los objetivos para los que han sido definidos. En los procesos de negocio los indicadores, denominados Key

Performance Indicators (KPI), o Indicadores Clave de Desempeño, miden la correcta ejecución de los procesos en base a los objetivos fijados. De igual forma, en los procesos de fabricación existen los puntos de inspección a través de los cuales se definen las características clave del

producto y del proceso que garanticen el cumplimiento de las especificaciones.

Proceso de Fabricación

1

1..*

medido por

ActuadorSensor

1..*

compuesto de

*

*

1..*

compuesto de

Operación de Fabricación

Punto de Inspección

Operación Atómica

1..*

compuesto de

*

Variable Atributo

compuesto de1..* *

1

1..*

med

ido

por

Básico Auxiliar


Tabla 3.1 Correlación entre proceso de fabricación y de negocio.

En un proceso de fabricación las operaciones más básicas son las que se realizan sobre un sensor o un actuador. Estas pueden ser equiparadas a

las actividades en el dominio de negocio, ya que las actividades son los elementos más básicos que no pueden ser divididas debido a que su descomposición no implica valor para la organización.

El modelo denominado mapa de procesos de la maquinaria industrial está formado por el conjunto de procesos de negocio que llevaran a cabo en la maquinaria industrial. En la Figura 3.4 se puede apreciar que el mapa de procesos de negocio de la maquinaria industrial se ha dividido en tres

niveles. En el nivel 1 se han contemplado aquellos procesos de negocio que ejecutan las actividades de mayor nivel de abstracción de la maquinaria industrial. Éstos serán utilizados, junto con otros procesos y subprocesos del mapa global de la organización, para conformar

procesos de negocio de un nivel superior. La configuración de los parámetros (objetivos, indicadores, variables de control, etc.) de los procesos de nivel 1 vendrá definida en función de los parámetros del proceso de la cadena de valor o proceso de soporte en el que esté

incluido y, por tanto, estará alineado directamente con los objetivos del mismo. Existen dos tipos de procesos de nivel 1: procesos principales y procesos de soporte.

El nivel 2 está formado por los procesos de negocio que conforman los procesos definidos en el nivel 1. Éstos, a su vez, y en función de su complejidad, pueden subdividirse en otros procesos del nivel 2 de forma reiterativa (subprocesos).

En el último nivel, el nivel 3, se encuentran las actividades o procesos básicos que reflejan el comportamiento de más bajo nivel de la

Dominio de la Fabricación

Dominio del Negocio

Proceso de Fabricación(Principal y Soporte)

Proceso de Negocio(Básico y Auxiliar)

Operación de Fabricación Subproceso de Negocio

Operación Atómica Actividad

Punto de Inspección KPI


maquinaria industrial y, por tanto, más cercano a la funcionalidad mecánica de la máquina. Éstas son utilizadas para componer procesos de los niveles superiores anteriormente nombrados (en el caso del

almacén inteligente podría tener actividades de lectura de sensores, movimiento de motores, etc.).

Figura 3.4 Modelado en UML del mapa de procesos de la maquinaria

industrial.

3.1.2 Proceso de Normalización Conceptual de la

Gestión de los Procesos de Negocio de la Maquinaria

Industrial

Para poder realizar la normalización conceptual de la gestión de los procesos de negocio de la maquinaria industrial se especifican los

elementos necesarios que permitan a la maquinaria industrial gestionar dicho mapa de procesos. Estos elementos deben satisfacer los principios fundamentales del modelo BPM pero alineándolo con las teorías de gestión de procesos de fabricación. De esta forma, se puede obtener una

visión de la maquinaria industrial como un sistema de gestión de


procesos de negocio que, además, contemple los requerimientos del entorno manufacturero. Este es el objetivo del proceso de gestión de los procesos de negocio de la maquinaria industrial.

La normalización conceptual de la gestión de los procesos de negocio de la maquinaria industrial se ha desarrollado en función de las características o funcionalidades que los autores identifican como parte

del modelo BPM (Figura 2.2): descubrimiento, modelado, despliegue, ejecución, interacción, control, optimización y análisis de procesos.

El sistema de descubrimiento tiene como objetivo describir y dar a conocer todos los detalles, tanto internos como externos, de los procesos de negocio llevados a cabo en la maquinaria industrial al resto de la organización. Este sirve de enlace entre el mapa de procesos de la

organización y el mapa de procesos de la maquinaria industrial. De esta forma se podrá, en primer lugar, diseñar nuevos procesos de negocio de mayor nivel de abstracción en la maquinaria industrial a partir de los existentes.

La funcionalidad de diseño o modelado propuesta por Smith y Fingar engloba el modelado, manipulación y rediseño de los procesos de negocio de la organización. En la propuesta esta funcionalidad será distribuida y

llevada a cabo por el sistema de modelado incluido en la maquinaria industrial y por el sistema BPM central que gestiona los procesos de negocio de toda la organización. El sistema de modelado de la maquinaria industrial ofrece una interfaz al ingeniero de procesos que le

permite definir nuevos procesos de mayor nivel de abstracción a partir de los procesos existentes en dicha maquinaria o modificar sus características y parámetros. Este sistema aporta un mayor grado de autonomía a la maquinaria industrial en la gestión de procesos de negocio, en concreto en el aspecto de diseño, independientemente del

sistema global. El sistema debe interactuar o comunicarse con el sistema de despliegue para incluir los cambios realizados y con el sistema de descubrimiento para que el sistema BPM global pueda manejar los nuevos procesos creados.

El sistema de despliegue incluye la funcionalidad necesaria que posibilita la incorporación en la máquina industrial de nuevos procesos o

procesos existentes que han sido modificados o rediseñados, así como las reglas de negocio, parámetros, métricas y el flujo de los procesos.

El sistema de ejecución tiene como objetivo garantizar que los procesos

de negocio de la maquinaria industrial sean llevados a cabo de forma


correcta, tanto los incluidos de forma nativa en la maquinaria como los desplegados posteriormente sobre la misma, controlando el estado de los mismos y sincronizando las diferentes actividades que componen los

procesos, así como la interacción entre los diferentes participantes.

El sistema de control engloba las funcionalidades de monitorización, control, análisis y optimización definidas en la propuesta de Smith y

Fingar. Este sistema se encarga de la supervisión y el control de los procesos que se están ejecutando en la maquinaria industrial para asegurarse que dicha ejecución se realiza de acuerdo con los objetivos e indicadores establecidos para cada proceso, subproceso o actividad.

Parte de la funcionalidad de análisis y optimización será llevada a cabo por el sistema BPM central cuando no pueda ser realizada por el sistema

de control de la maquinaria industrial. En este caso, es el subsistema de alerta el responsable de comunicar los errores o las desviaciones detectadas. Estos avisos permiten establecer mejoras en el diseño de los procesos y en su ejecución a los responsables de la organización.

3.2 Normalización Tecnológica de la Maquinaria Industrial En los últimos tiempos se ha demostrado los beneficios de la

convergencia de entre el modelo BPM y el paradigma SOA (Harmon, 2005). Este enfoque ha permitido la alineación entre los procesos de negocio y las TI, obteniendo una propuesta en consonancia con los requerimientos fundamentales de los nuevos modelos de negocio, como

la agilidad, flexibilidad, reducción de costes y eficiencia (Kamoun, 2007) (Harmon, 2005).

Sin embargo, estos paradigmas tecnológicos se caracterizan por tener un

alto nivel de abstracción y por el elevado requerimiento computacional de las infraestructuras sobre las que se sustentan que, difícilmente pueden ser soportadas por los actuales dispositivos de fabricación.

La maquinaria industrial, en la cual se lleva a cabo la ejecución de los procesos de fabricación, se fundamenta en los principios de la mecánica y la electrónica, y aunque existe maquinaria más moderna que incorpora

en mayor o menor medida capacidad de comunicación y computación, las máquinas actuales no ofrecen la infraestructura necesaria para


soportar las características de los paradigmas de computación distribuida mencionados. Por este motivo es necesario trasladar, a nivel tecnológico, la maquinaria industrial al dominio de las TIC.

En este sentido, el objetivo del proceso de normalización tecnológica de la maquinaria industrial (Figura 3.5) es establecer la arquitectura tecnológica (arquitectura IMaaS) que permita sustentar el modelo

presentado en el capítulo anterior eliminando las restricciones tecnológicas existentes entre los sistemas de gestión TI ubicados en el nivel de empresa y la maquinaria industrial ubicada en los niveles inferiores de producción. De esta forma se aportará flexibilidad,

dinamismo y autonomía a la maquinaria industrial.

Para lograr alcanzar su objetivo, el proceso se ha dividido en tres subprocesos como se muestra en la Figura 3.5. En primer lugar, el proceso de normalización del hardware tiene como objetivo dotar a la

maquinaria industrial de las capacidades de comunicación y computación necesarias para sustentar el modelo de servicios de la maquinaria industrial. En segundo lugar, el proceso de normalización middleware tiene como objetivo mostrar la maquinaria industrial como

un contenedor de servicios de soporte que permita sustentar la

Figura 3.5 Proceso de Normalización Tecnológica de la Maquinaria Industrial.

Normalización Tecnológica la Maquinaria Industrial


<<physical>>Maquinaria

Industrial como Servicio


Computacional


como Contenedor

<<achieve>> <<achieve>><<achieve>>

<<goal>>

Agregar a la maquinaria industrial capacidad de

computación y comunicación

<<goal>>

Mostrar la maquinaria industrial como un

contenedor de servicios

<<goal>>

Exponer la funcionalidad de la maquinaria industrial

como servicios

Normalización del hardware

Normalización del

middleware

Normalización de servicios

<<control>>

<<achieve>>

<<goal>>

Eliminar restricciones tecnológicas

<<abstract>> Procesos de fabricación

de la maquinaria industrial

<<abstract>>Modelo BPM


Normalización conceptual de la

maquinaria industrial

<<process>>

<<achieve>>

<<goal>>

Eliminar restricciones conceptuales


funcionalidad de carácter general del modelo BPM. Finalmente, el proceso de normalización de servicios tiene como objetivo exponer como servicios de aplicación la funcionalidad definida en el modelo BPM de la

maquinaria industrial dependiente del dominio de aplicación.

3.2.1 Normalización Hardware de la Maquinaria

Industrial

El objetivo del proceso de normalización del hardware de la maquinaria industrial es dotar a la maquinaria industrial de la capacidad de comunicación y computación necesarias que sienten las bases para

sustentar e introducir los paradigmas de computación distribuida ampliamente difundidos con la evolución de Internet, en concreto el paradigma SOA mediante el uso de Servicios Web.

Como resultado del proceso se obtiene una nueva versión de la maquinaria industrial utilizada como elemento de entrada del proceso pero con capacidades añadidas: la capacidad de comunicación y la de computación que permitirá sustentar la arquitectura de servicios. Al

recurso obtenido como resultado del proceso se le ha denominado Maquinaria Industrial Computacional.

Para poder llevar a cabo el proceso de normalización del hardware de la maquinaria industrial se han definido diversos objetos de tipo suministro que serán utilizados durante su aplicación para lograr el objetivo. Estos objetos son los sistemas computacionales especializados, como

dispositivos embebidos y System on Chips (SoC), y los sistemas operativos que permitan gestionar los recursos hardware de estos sistemas computacionales.

Los avances que se han producido en los últimos años en la electrónica y las comunicaciones ha propiciado la aparición de dispositivos computacionales de carácter específico, como los mencionados dispositivos embebidos y los sistemas en chip caracterizados por su

robustez, sus pequeñas dimensiones y con un bajo coste y consumo que permiten la integración dentro de otros sistemas, dotándoles de características adicionales que propicien la consecución de los requerimientos definidos, obteniendo lo que se comienza denominar

dispositivos inteligentes (Catsoulis, 2005) (Gill & Hobday, 1999).

Otro de los recursos utilizados para lograr el objetivo del proceso son los sistemas operativos embebidos que serán utilizados para gestionar de


forma eficiente los recursos de los sistemas computacionales específicos y servirán como base sobre la cual construir la arquitectura IMaaS de la maquinaria industrial.

Además, para lograr el objetivo del proceso evitando desviaciones del mismo se han identificado un conjunto de elementos de control encargados de guiar y conducir la ejecución del mismo. Estos elementos

son el paradigma SOA y los Servicios Web de segunda generación (WS-*).

Actualmente la maquinaria industrial se ofrece con una limitada

capacidad de computación y comunicación que difícilmente puede dar soporte a los paradigmas emergentes de computación distribuida. En el ámbito de la fabricación actual se pueden contemplar una gran variedad de tipos de dispositivos en función de su complejidad computacional y

capacidad de comunicación:

• Los elementos de bajo nivel son dispositivos sin un sistema computacional basados principalmente en sistemas electrónicos de control mediante tecnología cableada. Se trata de

dispositivos dotados de una interfaz de conexión más o menos compleja o configurable (CNC, PLC, maquinaria industrial) que permite el acceso y la gestión del dispositivo.

• Los elementos de nivel medio están compuestos por la maquinaria industrial o elementos de control que tiene

integrada una plataforma computacional. Esta plataforma no se basa en paradigmas complejos de las TIC y es una mera interfaz de alto nivel para acceder a la funcionalidad del dispositivo en cuestión. En este caso, la gestión se puede realizar de forma

remota utilizando tecnologías TIC.

La normalización del hardware de la maquinaria industrial propone un enfoque centrado en dotar a dicha maquinaria, desde su creación, de las características necesarias para que puedan interactuar con el resto de sistemas de la organización a través de paradigmas orientados a

servicios. Estas características son:

• La capacidad de comunicación en red que permita la interacción

con los sistemas de gestión TIC del nivel de empresa. En este sentido deberá contemplar tecnologías estándares tan

extendidas como Ethernet, TCP/IP, etc.


• La capacidad de procesamiento necesaria para dar soporte a los

elementos y arquitectura software centrada en el paradigma SOA Contemporáneo.

En la Figura 3.6 se ha modelado mediante UML la estructura conceptual

de la maquinaria industrial computacional que se debe obtener como resultado del proceso.

En la propuesta presentada en (Gilart, 2010) no sólo se enmarca el

nuevo enfoque de la maquinaria industrial que podríamos denominar de alto nivel, si no que mediante la introducción de dispositivos externos se puede transformar la maquinaria y contemplar los tipos existentes en el mercado actual que se describieron anteriormente.

En el caso de la maquinaria de bajo nivel, para lograr los objetivos de la propuesta, es posible utilizar sistemas embebidos o SoC que aporten una

plataforma mínima de computación y comunicación posibilitando la interacción con el resto de sistemas TIC de la organización. Para ello, se parte de la base de que los elementos de producción contemplados deben tener algún mecanismo o interfaz de conexión mínima para acceder a su funcionalidad permitiendo la gestión y la configuración (puerto serie,

paralelo, USB, Ethernet, etc.).

Figura 3.6 Modelo conceptual de la Maquinaria Industrial Computacional.


En el caso de la maquinaria de nivel medio, esta ya cuenta con una plataforma base, y por tanto posee los requisitos mínimos que permiten interaccionar con el sistema. En cualquier caso, si no se pudiera utilizar

la plataforma software por tratarse de un sistema propietario o con capacidad de computación limitada, se podría incorporar un dispositivo embebido o SoC de la misma forma que en la maquinaria de bajo nivel.

Como resultado del proceso de normalización del hardware de la maquinaria industrial se ha obtenido lo que se ha denominado Maquinaria Industrial Computacional y que ha sido plasmada de forma

conceptual en la Figura 3.7. El resultado obtenido ayudará a sentar las bases sobre las que sustentar el resto de la arquitectura IMaaS que finalmente permitirá eliminar las restricciones físicas y tecnológicas características de la maquinaria industrial.

Figura 3.7 Arquitectura resultante de la Maquinaria Industrial Computacional.

3.2.2 Normalización del Middleware de la

Maquinaria Industrial

El proceso de normalización del middleware de la maquinaria industrial tiene como objetivo introducir dicha infraestructura de servicios, que dote a la maquinaria industrial computacional de las características típicas de los modelos middleware y arquitecturas empresariales, en este

caso, orientado al enfoque SOA Contemporáneo: flexibilidad, escalabilidad, interoperabilidad, reusabilidad, seguridad, transacciones, agilidad, dinamismo, etc. Como resultado del proceso se obtiene la


maquinaria industrial vista como un contenedor de servicios, Maquinaria

Industrial como Contenedor, que proporciona la infraestructura

adecuada, en términos de servicios middleware y servicios de soporte, a los servicios de aplicación que encapsularán la funcionalidad definida por el modelo BPM de la maquinaria industrial, servicios de producción. De esta forma la funcionalidad del sistema vendrá determinada por el

software y no por el hardware, contribuyendo a la eliminación de las restricciones tecnológicas y sentando las bases que permitan contemplar el modelo BPM de la maquinaria industrial que eliminaba las restricciones conceptuales.

Para lograr el objetivo de la Maquinaria Industrial como Contenedor, se definen dos subprocesos: El proceso de definición de servicios

middleware SOA y el proceso de definición de servicio middleware WS-*

El proceso de definición de los servicios middleware SOA tiene como objetivo establecer las bases de la arquitectura IMaaS

independientemente de la tecnología. En este proceso se han definido las funciones y características que debe contener la capa middleware de la maquinaria industrial bajo el paradigma SOA siguiendo los requerimientos del modelo BPM de la maquinaria industrial.

La arquitectura conceptual propuesta para obtener la visión de maquinaria industrial como servicio se ha basado en el patrón arquitectónico Service Layer propuesto en (Erl, 2005). Dicho patrón

define una serie de capas funcionales que clasifica los diferentes tipos de servicios en el modelo SOA. La arquitectura conceptual de la maquinaria industrial está compuesta por la capa de servicios de aplicación, la capa

de servicios de negocio, la capa de servicios de orquestación y la capa de

servicios de infraestructura (Figura 3.8)

En este proceso se han definido los servicios de utilería ubicados en la

capa de infraestructura que se corresponde con los servicios de soporte y middleware del contenedor de servicios de la maquinaria industrial y que serán consumidos por los servicios definidos en las otras capas. Se trata

de servicios genéricos y reusables validos para cualquier aplicación. La mayoría de los servicios de utilería de la capa de infraestructura establecen el patrón de intercambio de mensajes petición-respuesta. Concretamente se implementaron los sistemas de descubrimiento, despliegue y ejecución.

El servicio de descubrimiento es el responsable de la publicación de procesos y subprocesos. Este servicio se compone del agente de


descubrimiento, responsable de publicar toda la información de los procesos y actividades existentes en la maquinaria industrial, y de las entidades que representan la información que se va a publicar como la

entidad proceso, y actividad. El agente debe detectar el momento en el que la maquinaría se conecta a la red y comenzará su proceso de publicación. Antes de desconectarse de la red deberá asegurarse que ningún consumidor pueda acceder a sus servicios por no ser accesible.

A partir del sistema de despliegue se ha definido otro de los servicios de utilería más importantes de la arquitectura, el servicio de despliegue. Este servicio se compone de una interfaz SOA que permite interactuar

con el servicio de forma remota, una interfaz de programación de aplicaciones para su uso de forma local, el gestor de despliegue responsable de analizar la petición que recibe y almacenar la información correspondiente a los procesos y actividades, las reglas de

negocio y los indicadores claves de los procesos que miden la consecución de los objetivos a través de las entidades proceso, actividad, regla de negocio y KPI.

El sistema de ejecución es el que más peso tiene a la hora de definir las funcionalidades de los servicios de utilería que componen el middleware

Figura 3.8 Modelo de Capas de la arquitectura conceptual IMaaS.


de la maquinaria industrial como un contenedor. Los servicios que componen el sistema de ejecución son los siguientes: servicio de

comunicación, servicio de mensajería, servicio de gestión servicio de

transacciones, servicio de tiempo, servicio de persistencia, servicio de

seguridad y el servicio de reglas.

El servicio de comunicación es el responsable de llevar a cabo las funcionalidades de invocar un proceso o actividad. El servicio define las funcionalidades necesarias para que los servicios SOA que representan actividades o procesos de negocio puedan ser invocados a través de la

red por otros servicios SOA o clientes externos abstrayéndoles de las peculiaridades y las características propias de la comunicación en los sistemas distribuidos. Este está compuesto por una interfaz de acceso responsable de la recepción de peticiones remotas a servicios o procesos,

una interfaz de tipo API que permite el uso de su funcionalidad de forma local y un gestor de comunicación responsable de la abstracción de todas las peculiaridades surgidas en el proceso de comunicación de sistemas distribuidos (transmisión e interpretación de la información,

serialización, gestión de la conexión, invocación de la lógica de negocio de actividades, etc.).

El servicio de mensajería se compone de dos interfaces, una SOA y otra

tipo API, que permiten usar las funcionalidades del servicio para establecer la comunicación, un gestor de mensajería responsable de hacer transparente dicha comunicación y de la gestión de los mensajes y

una entidad mensaje que representa la información de estado de dichos mensajes. Este servicio utiliza por debajo las primitivas de intercambio de mensajes definidas por el servicio de comunicación.

El servicio de gestión es el encargado de gestionar el ciclo de vida de un proceso o actividad. El servicio está compuesto por una interfaz SOA que permite la gestión de forma remota, por una interfaz API para el acceso a su funcionalidad de forma local y por el gestor del ciclo de vida

responsable de gestionar el ciclo de vida de los servicios a través de sus diferentes estados, su persistencia y su monitorización.

El servicio de transacciones está compuesto por los siguientes artefactos:

una interfaz de acceso al servicio mediante el paradigma SOA, una interfaz de programación de aplicaciones (API), el gestor de transacciones y la entidad transacción. El gestor de transacciones encapsula la lógica

de negocio necesaria para gestionar los cambios realizados sobre el sistema por las operaciones implicadas en la transacción, evitando que este pueda permanecer en un estado de inconsistencia y, en caso de


llegar a esta situación, debe ser capaz de recuperar el sistema devolviéndole a un estado estable. La entidad transacción representa conceptualmente la información de estado de las transacciones y cómo

ésta es almacenada de forma persistente. Ésta será utilizada por el gestor de transacciones para llevar a cabo su cometido.

La realización de la gestión de sincronización es llevada a cabo por el servicio de tiempo compuesto por una interfaz SOA que permite el acceso al servicio por parte de otros servicios, una interfaz API que permite interactuar con el servicio de forma local y el gestor de tiempo

responsable de la sincronización de tiempo del sistema.

La gestión del estado y la persistencia la realiza el servicio de

persistencia, que se compone de dos interfaces. Una interfaz SOA y otra

de programación de aplicaciones que permite la comunicación con entidades locales y remotas, el gestor de persistencia y las entidades que representa a las propias entidades y sus estados. La principal función

del gestor de persistencia es dar soporte y gestionar los artefactos de tipo entidad. Ofrece una capa de abstracción que permite la sincronización y manejo entre los elementos entidad junto con la información que representan, y los que se encuentra almacenada físicamente. A través de estos, será expuesta al resto de los servicios.

El servicio de seguridad es el responsable gestionar la seguridad. El servicio de seguridad está formado por una interfaz SOA, una interfaz de

programación de aplicaciones, el gestor de seguridad que encapsula la lógica de negocio necesaria para coordinar y gestionar las funcionalidades de autenticación y autorización de acceso. La encriptación de mensajes y los artefactos de entidad usuario y rol

establecerán los permisos de identificación y acceso a las funcionalidades del sistema y serán usadas por el gestor de seguridad.

La ejecución de los procesos es llevada a cabo por un servicio de

orquestación, responsable de coordinar el flujo de trabajo definido por el proceso y el intercambio de mensajes entre los diferentes servicios que lo forman. El servicio se compondrá de una interfaz de tipo SOA para

invocar al servicio, normalmente a través del servicio de comunicación que delegará la ejecución del proceso y del gestor de orquestación, que es el responsable de analizar la petición y ejecutar el proceso asociado, coordinar el flujo de trabajo del proceso controlando la interacción entre

los diferentes servicios a través de los servicios de comunicación, de mensajería, de transacciones, etc., y los artefactos de entidad variable, mensaje y estado del proceso.


El servicio de reglas se encarga de Ejecutar las reglas de negocio. Está compuesto por la interfaz SOA del servicio de reglas, la interfaz de programación de aplicaciones, el gestor de reglas de negocio y la entidad

reglas de negocio. El gestor de reglas de negocio se encarga de la ejecución de las reglas de negocio, así como de la coordinación y control de las mismas. El gestor de reglas interactuará con la entidad regla de negocio para obtener las reglas que debe ejecutar. La entidad regla de

negocio representa la información sobre la regla significativa para el servicio y expone las operaciones y primitivas para su gestión.

3.2.3 Normalización de los Servicios de la

Maquinaria Industrial

El objetivo del proceso de normalización de los servicios de la maquinaría industrial es definir los servicios de tipo no genérico dependientes del

dominio de aplicación, en este caso, la gestión de procesos de fabricación de la maquinaria industrial. Dichos servicios encapsulan y exponen las funcionalidades especificadas por el modelo BPM de la maquinaria industrial que no forman parte de la infraestructura de soporte. Estos

son los procesos de negocio de la maquinaria industrial y la funcionalidad de los sistemas de control, interacción y modelado. Concretamente se centra en los servicios ubicados en las capas de servicios de aplicación, de servicios de negocio y de servicios de

orquestación (Figura 3.8).

Las funcionalidades a encapsular se extraen a partir del modelo BPM de

la maquinaria industrial enfocado al paradigma SOA. Como resultado se obtiene la vista conceptual de la arquitectura de la maquinaria industrial como servicio, IMaaS.

El enfoque propuesto establece una relación entre la estructura del mapa de procesos de la maquinaria y la estructura de servicios de producción distinguiendo tres tipos de servicios: los servicios de proceso,

los servicios de medición y los servicios de actividad.

Los servicios de proceso representan los procesos y subprocesos ubicados en los niveles 1 y 2 del mapa de procesos de la maquinaria

industrial exponiendo la lógica de proceso o funcionalidad de alto nivel que ofrece la maquinaria industrial. Estos servicios se han dividido en dos tipos: los servicios de fabricación y los servicios de soporte. Ambos

tipos son utilizados y orquestados junto con otros servicios de la organización para conformar y automatizar los procesos de negocio de


mayor nivel de abstracción de la organización. Los servicios de fabricación y de soporte están basados en el patrón de orquestación con un comportamiento similar al descrito en (Erl, 2009).

Los servicios de fabricación son servicios que exponen la lógica de proceso o funcionalidades que ofrece la máquina industrial. Representan

los procesos principales de la maquinaria industrial establecidos en el mapa de procesos. Establecen un comportamiento pasivo a la espera de peticiones provenientes de consumidores externos mediante paradigmas orientados a servicios (patrones de mensaje petición-respuesta o de

único sentido). Los servicios de fabricación están basados en el patrón de orquestación con un comportamiento similar al descrito en (Erl, 2009).

Los servicios de soporte exponen la lógica de los procesos de soporte

descritos en el patrón BPM de la maquinaria industrial. Estos servicios encapsulan la lógica necesaria para que los servicios de producción puedan ser ejecutados conforme a los objetivos estratégicos (un ejemplo de estos servicios sería un servicio de inventario que se encargaría de

comprobar que la maquinaria cuenta con los elementos necesarios para desempeñar su función principal, como en una fresadora ver si cuenta con las herramientas necesarias o en un almacén inteligente si dispone de huecos vacíos para poder almacenar materia. Otro proceso de soporte

podría controlar el gasto asociado a una máquina para evitar desviarse del objetivo de costes de producción y controlar por ejemplo el gasto de consumo eléctrico, de materia prima o material necesarios para su funcionamiento como aceite lubricante. Los servicios de soporte serán

invocados en el momento en el que un servicio de producción sea también invocado. El ingeniero de procesos podría modelar este tipo de servicio indicando la información a recibir si se diese alguna anomalía que pudiera desviar al proceso principal de su objetivo de negocio. El

patrón de comportamiento sería similar al de los servicios de procesos de tipo principal.

Los servicios de medición exponen la lógica necesaria para calcular los

indicadores clave de procesos de los cuales se nutrirán los servicios de gestión, en concreto el de monitorización. Está compuesto de dos servicios ubicados en la capa de negocio uno de ellos de tipo task-centric (Erl, 2005) y el otro de tipo entity-centric (Erl, 2005).

El servicio de medida es un servicio de negocio centrado en la tarea que expone la lógica necesaria para calcular los indicadores clave de proceso

a partir de la información obtenida del correspondiente servicio de proceso o de los procesos de adquisición. El servicio de medida utiliza el


servicio de reglas de negocio de la capa de infraestructura que permite al ingeniero de procesos parametrizar el cálculo de los KPI.

El servicio KPI es un servicio de negocio de tipo entidad que representa el concepto de indicador clave de un proceso del mapa de procesos de la maquinaria industrial implementando un patrón petición-respuesta. El

servicio se basa en el servicio de notificación para comunicarse con el servicio de persistencia.

Los servicios de actividad ubicados en la capa de aplicación representan las actividades del mapa de procesos de la maquinaria industrial (operaciones con sensores y actuadores) y exponen la funcionalidad básica que será reutilizada por otros servicios de las capas superiores.

En el modelo propuesto los principales servicios de actividad son: los servicios de adquisición y los servicios de ejecución. Los servicios de actividad establecen el patrón de intercambio de mensajes petición-respuesta y representan los servicios de carácter más tecnológico.

Figura 3.9 Servicios de fabricación de la maquinaria industrial.

Los servicios de adquisición se encargan de exponer la funcionalidad necesaria para la lectura de información procedente de los sensores de la máquina industrial.


Los servicios de ejecución exponen la funcionalidad de la máquina, orientada a tareas básicas, sobre los componentes mecánicos (control y gestión de los actuadores).

Estos dos tipos de servicios son definidos como servicios de envoltura (wrapper services) (Erl, 2009), que establece la fachada de acceso a

dichos componentes y abstraen las peculiaridades mecánicas y electrónicas de los mismos.

Ambos servicios representan la funcionalidad básica de la maquinaria

industrial a partir de los cuales se compondrán los servicios de mayor nivel de abstracción y más cercanos a los procesos de negocio.

Como resultado, en la Figura 3.10 se muestra la arquitectura conceptual

en capas de los servicios que exponen la funcionalidad del mapa de procesos de la maquinaria industrial.

Figura 3.10 Arquitectura IMaaS mínima que proporciona el proveedor de

la maquinaria. Para obtener la arquitectura técnica, en (Gilart, 2010) se define el

proceso de definición de los servicios WS-* de producción. Para ello el único paso que se realiza es definir los servicios del dominio de aplicación obtenidos en el proceso de definición de servicios SOA de producción como Servicios Web. Como resultado se obtiene la


arquitectura física de la maquinaria industrial como servicio o lo que es lo mismo, la arquitectura IMaaS.

En (Gilart, 2010) se establece una distinción entre los servicios de aplicación definidos por el proveedor de la maquinaria industrial IMaaS y los servicios de aplicación definidos por el ingeniero de procesos en función de los requerimientos de su organización. En la Figura 3.10 se

muestra la arquitectura IMaaS con los servicio mínimos que debe proporcionar y definir el proveedor de la maquinaria. Los servicios de

actividad, los servicios de entidad y los servicios de negocio orientados a

la tarea.

A partir de la arquitectura mínima, el ingeniero de procesos podrá componer los servicios de producción (servicios de proceso y servicios de

monitorización) que reflejen el mapa de procesos de la maquinaria industrial y su gestión y personalizar a través de la definición de reglas de negocio el comportamiento de los servicios de negocio orientados a la

tarea. Los servicios definidos por el ingeniero de procesos se basan en la orquestación de servicios y vendrán representados por sus correspondientes hojas BPEL y WSDL. Como resultado se obtiene la arquitectura IMaaS, Maquinaria industrial como un Servicio, que

permite superar las restricciones conceptuales y tecnológicas ofreciendo la maquinaria industrial como un conjunto de procesos de negocio que puedan ser modificados de una forma ágil y flexible, alineándolos con los cambios que se produzcan en los objetivos estratégicos del negocio

originados por el dinamismo del entorno (Figura 3.11).

3.3 Conclusiones Los resultados generales obtenidos en la investigación desarrollada en (Gilart, 2010) han demostrado, por un lado, la transparencia a la hora de gestionar los procesos mediante técnicas del e-Business ―desde el

modelado hasta su ejecución y monitorización― independientemente de su naturaleza, fabricación o negocio; por otro lado, se ha demostrado la flexibilidad de la arquitectura que permite una rápida adaptación de los procesos alineándolos con los objetivos estratégicos de la organización

sin necesidad de modificaciones tecnológicas.

Todos estos aspectos avalan la validez de la propuesta de integración de la maquinaria industrial con el enfoque IMaaS, demostrando que se han

eliminado las barreras existentes en la gestión de los procesos de negocio


y fabricación y se han eliminado las restricciones tecnológicas y conceptuales que impedían ofrecer un Sistema de Gestión de Procesos integral conforme a los requerimientos de los nuevos modelos de negocio

y producción.

Figura 3.11 Arquitectura IMaaS de la maquinaria industrial.

La investigación realizada en (Gilart, 2010) se ha centrado en la integración de forma transparente de la maquinaria industrial en los sistemas de gestión de procesos basados en los nuevos modelos de negocio. En este sentido, las aportaciones más relevantes son, de forma

sintetizada, los siguientes:


• La formalización de una metodología general que describe y guía

de forma sistemática la integración de forma transparente de la maquinaria industrial dentro de los sistemas de gestión ágil de procesos de negocio. En concreto, la metodología ha sido

aplicada a la maquinaria industrial y a los sistemas de gestión ágiles como BPMS, pero puede ser aplicada mediante diferentes instanciaciones a problemas similares en otros dominios que incluyan distintos dispositivos y sistemas de gestión. Cada

instancia de la metodología dependerá del problema al que se aplique, del momento en el que se aplique y de los paradigmas y tecnologías más adecuadas para resolverlo.

• Un método de normalización conceptual de la maquinaria

industrial permite de forma sistemática eliminar las restricciones conceptuales entre los procesos de negocio y los

procesos de fabricación. Pero, como en el caso anterior, puede instanciarse para eliminar las restricciones conceptuales en otros dominios aplicando adecuadamente la metodología general.

• Modelo del mapa de procesos de negocio de la maquinaria

industrial a partir de la correlación entre los procesos de negocio y los de fabricación, que permite representar un proceso de fabricación en el dominio del negocio. Este modelo se ha considerado de interés debido a que permitirá,

independientemente de la tecnología, que los ingenieros de procesos puedan modelar el mapa de la organización incluyendo los procesos de fabricación y, de esta forma, comprender mejor su funcionamiento y poder mejorar el funcionamiento de la

organización. Además, se puede utilizar la propuesta para otros paradigmas de gestión basados en procesos.

• Un modelo que permite mostrar la maquinaria industrial como

un sistema BPM desde el punto de vista conceptual, independiente de la tecnología. Este modelo incluye la funcionalidad necesaria para la gestión de los procesos de la

maquinaria industrial de forma autónoma e independiente que podría ser soportado por otras tecnologías más adecuadas en un futuro.

• Un método de normalización tecnológica de la maquinaria

industrial que permite de forma sistemática eliminar las

restricciones tecnológicas existentes entre los procesos de negocio y los procesos de fabricación. Como se ha comentado


anteriormente, esta metodología podría aplicarse a otros elementos de entrada y estar dirigida por otros controladores y suministradores e, incluso podría aplicarse a otro sistema de

gestión de procesos.

• Un modelo de servicios de la maquinaria industrial que expone

su funcionalidad bajo el paradigma SOA pero independientemente de las tecnologías utilizadas para su implementación. En un futuro podría ser utilizada para crear

una arquitectura con una tecnología distinta a la de los Servicios Web de segunda generación.

• La segunda consiste en la arquitectura IMaaS como propuesta

realista para validar los modelos expuestos a lo largo del presente trabajo. Como se vio en el estado del arte, se trata de otra propuesta de pila de especificaciones de WS-* para un

perfil de dispositivos de fabricación.

• Implementación de un motor SOAP específico para dispositivos

embebidos con una limitación de recursos.

• Implementación de un motor de orquestación WS-BPEL también

para dispositivos embebidos que posean recursos limitados.

• Implementación de la arquitectura IMaaS completa a partir de

la integración de soluciones de código abierto de terceros.

• De forma trasversal, se ha logrado una metodología general

para la creación sistemática de sistemas de gestión empresarial

estratégicos. La importancia de esta propuesta radica en la apertura de nuevas líneas de investigación que continúen la propuesta de este trabajo en el campo de la gestión empresarial.

Basándonos en las líneas futuras de la propuesta IMaaS (Gilart, 2010),

el presente trabajo se centra en la incorporación de semántica al sistema de gestión de procesos ágil y al modelo IMaaS de la maquinaria industrial a partir de la propuesta descrita en el trabajo.

Como ya se ha comentado en capítulos anteriores, mediante la incorporación de información semántica a la propuesta IMaaS se pretende agilizar el modelado, implementación y despliegue de procesos de fabricación y de negocio haciendo trasparente los aspectos referentes

a la organización física de las plantas industriales, así como los servicios que implementan cada uno de los procesos identificados en este capítulo.

C a p í t u l o 4

Modelo de Gestión Semántica de Procesos

Industriales

Como se ha visto a través de los capítulos anteriores, el uso de los elementos de fabricación ofertados como servicios permite integrarlos

dentro de los sistemas de gestión de las organizaciones manufacturares. En el capítulo anterior se ha reflejado el proceso para integrar los procesos de fabricación dentro de los sistemas BPMS de las compañías, ya que la metodología BPM es una de las más adecuadas para la gestión

ágil de procesos, como también se ha justificado en los antecedentes.

Partiendo de esta premisa, se han identificado una serie de factores propios de los procesos de fabricación que hacen que su integración

dentro de los sistemas BPMS tengan una serie de características a resolver, que abrirían aun más, las posibilidades de gestión de los procesos de fabricación como un proceso más de negocio de la organización (Hepp et al., 2005).

Como ya se ha identificado en la introducción, los procesos de fabricación tienen una fuerte dependencia del nivel de planta, de forma que las características físicas de una planta es lo que hace que un

proceso de fabricación se realice de una determinada manera. Esto implica que para conseguir el mismo objetivo, dependiendo del nivel de planta se implementarán procesos completamente diferentes que optimicen el uso de recursos de la planta donde se lleven a cabo. Para


poder realizar este diseño es necesario tener el conocimiento de los recursos del nivel de planta, por un lado, y los conocimientos tecnológicos para implementarlo, por otro. Esto hace que no sea posible

la automatización en las fases de diseño e implementación de los procesos de fabricación.

El problema anterior, multiplicado a la creciente demanda de procesos

personalizados, implica un incremento en el número de procesos a modelar, implementar y gestionar. Se hace necesario, por lo tanto, lograr una mejora en estas fases de la gestión de procesos para que estas tareas no se conviertan en un cuello de botella dentro del ciclo BPM.

Durante los antecedentes se ha estudiado cómo el uso de ontologías y tecnologías de la web semántica puede ser un buen enfoque para

automatizar gran parte de las tareas del ciclo de vida BPM y mejorar así la capacidad de respuesta de una organización, gracias a la estandarización de la información y los procesos de inferencia que se pueden realizar sobre la ontología.

Para solucionar los problemas planteados, en el presente capítulo se propone un modelo de gestión de procesos, concretamente procesos industriales, basado en información semántica. Con este modelo se

busca incrementar el automatismo de las fases del ciclo BPM orientado a un dominio industrial en las fases de diseño de procesos, implementación, ejecución y monitorización.

La definición del Modelo de Gestión Semántica de Procesos Industriales ModGSPI se ha realizado desde tres puntos de vista. Por un lado, el Modelo Conceptual de Gestión Semántica de Procesos ModConceptGSPI se centra en describir las principales tareas, permitiendo ver el sistema

como un conjunto de procesos (P) que se llevan a cabo dentro del mismo. En el Modelo Funcional de Gestión Semántica de Procesos Industriales ModFunGSPI se identifican los diferentes actores (A) que intervienen en el

proceso, en que actividades intervienen y las relaciones entre ellos. Finalmente el Modelo Arquitectónico de Gestión Semántica de Procesos Industriales ModArqGSPI se centra en definir la arquitectura bajo la que se implementa el modelo propuesto, estableciendo la tecnología más

adecuada de cada componente (C). De este modo el ModGSPI se compone de tres modelos más los conjuntos obtenidos.

�� = {��,��,��, �, �, �} (4.1)

Capítulo 4. Modelo de Gestión Semantica de Procesos Industriales 73

Para definir el modelo propuesto de forma sistemática y lo menos ambiguo posible, es necesario utilizar un método que garantice el logro de estos objetivos. El marco formal propuesto se basa en el uso de un

método de formalización y en el uso de herramientas de formalización.

�� = {é��!��, "��#��!��ó�} (4.2)

Tal como se muestra en la Figura 4.1, el Marco Formal se compone de

tres tareas de modelado secuenciales. El Modelado Conceptual utiliza los procesos involucrados en la Gestión Semántica de Procesos Industriales para definir el ModConceptGSPI, formalizado a través de notación UML

(Unified Modeling Language) y Erikson-Penker (Eriksson & Penker, 1999) como extensión de UML. A partir del modelo obtenido, expresado como una secuenciación de procesos, se realiza el Modelado Funcional, en el cual se establecen los actores implicados en los procesos, sus

funcionalidades y la manera en que se relacionan cada uno de ellos. El Modelado Funcional hace uso de diagramas UML, Teoría de Conjuntos y los principios definidos en SOA para obtener el ModFuncGSPI.

Finalmente, en el Modelado Arquitectónico se define la arquitectura del modelo y las tecnologías que lo sustentan, bajo un enfoque orientado a servicios.

El presente capítulo se estructura, siguiendo el Marco Formal definido, en tres partes: El Modelo Conceptual de Gestión Semántica de Procesos

Industriales donde se identifican y detallan los procesos implicados en el

modelo con sus entradas, salidas y actividades; El Modelo Funcional de

Gestión Semántica de Procesos donde se identifican los actores implicados en los procesos y que actividad realiza cada uno de ellos, así como la comunicación entre ellos; Finalmente, se el Modelo

Arquitectónico de Gestión Semántica de Procesos de Fabricación, en el cual se define la arquitectura bajo la que se organizara el Modelo Propuesto.


Figura 4.1 Fases del Marco Formal para el modelado del ModGSPI.

4.1 Modelo Conceptual de Gestión Semántica de Procesos Industriales El Modelo Conceptual de Gestión Semántica de Procesos Industriales

ModConceptGSPI se define como un conjunto P compuesto de Procesos p

identificados y definidos en el modelo. Donde cada uno de los proceso p

está compuesto a su vez por una tupla de los elementos necesarios en el

proceso. Definidas como un conjunto I de entradas, un conjunto de salidas O, un conjunto de objetivos G y un flujo de trabajo WF compuesto de tareas T.

� = {�%, '%, �%, (�%} (4.3)


Durante la presente sección se identifican los procesos que componen el

Modelo Conceptual de Gestión Semántica de Procesos Industriales.

Mediante este modelado conceptual se establecerán los procesos que

darán paso al modelado funcional y arquitectural de la presente tesis.

Tras la revisión del estado del arte se han identificado una serie de actividades necesarias para llevar a cabo la gestión semántica de

procesos industriales. Del estudio de los sistemas basados en ontologías se han extraído las bases para establecer el proceso de conceptualización del dominio. Durante el estudio de la aplicación de ontologías en dominios industriales con diferentes propósitos se ha identificado los

aspectos relevantes de la conceptualización de dominios industriales. Del estudio de los sistemas de gestión BPM se han identificado las actividades de gestión necesarias para realizar la gestión semántica de procesos industriales. De esta forma el Modelo Conceptual propuesto se

compone, tal como se muestra en la Figura 4.2, de los siguientes procesos: Proceso de Conceptualización de la Información, Proceso de Normalización de los Procesos de Fabricación, Proceso de Conceptualización del Nivel de Planta, Proceso de Modelado Semántico

de Procesos, Proceso de Compilado y Proceso de Ejecución y Monitorización.

Figura 4.2 Proceso para la gestión semántica de procesos.

Por lo tanto se define el ModConceptGSPI como un proceso (4.4) compuesto por el conjunto de entradas (4.5), salidas (4.6), objetivos (4.7)

y flujo de tareas o procesos (4.8). Atendiendo a la naturaleza de los


procesos se clasifican en dos grupos, procesos de definición de la información semántica (4.9) y procesos de gestión de procesos (4.10).

�� = {�)*+, , ')*+, , �)*+, ,(�)*+,} (4.4)

Donde cada uno de los conjuntos se compone de:

�)*+, = {��-��#, ��#��, �.��} (4.5)

')*+, = {��, ��ó��#�/��} (4.6)

�)*+, = {��#��#�} (4.7)

(�)*+, = {0�. ��23 , ��#�. ��#�23 } (4.8)

0�. ��23 = {��, ��, ��} (4.9)

��#�. ��#�23 = {��, ��, ��} (4.10)

Cada una de las actividades que compone flujo de tareas definidas en WFModC se considera en sí mismas un proceso con sus entradas, salidas, y flujo de tareas.

El Proceso de Conceptualización de la Información IMaaS (ConceptInfoIMaaS) hace uso de las teorías y metodologías de ingeniería

del conocimiento é�� para traducir ideas y conceptos del mundo físico a un lenguaje interpretable por máquinas. Concretamente la salida

de este proceso es una serie de conceptos y relaciones genéricas especificadas sobre diversas ontologías que conceptualizan cada uno de los aspectos implicados en la fabricación ágil. Esta información se

contiene en una ontología terminológica IMaaS89:;.

��= {��, {IMaaS89:;, BPMN89:;}, ��!��,é��}

(4.11)

El Proceso de Normalización de los Procesos de Fabricación

(NormProcFabr) hace uso de la ontología de procesos definida por el proceso anteriorBPMN89:; y junto con una serie de reglas propias de los

procesos de fabricación y según las especificaciones BPM, se conceptualiza la información del Proceso Funcional de forma que pueda ser tratada mediante ingeniería del conocimiento. El resultado de esta

fase es una ontología asercional BPMN?9:; (ABox).


�� = {{BPMN89:;, Proc. Funcional}, BPMN?9:;, Normalizar,InstanciaciónLM} (4.12)

El Proceso de Conceptualización de Plantas IMaaS (ConceptPlantaIMaaS)

permite generar a partir de la ontología específica de los niveles de planta IMaaS89:;, una conceptualización ad-hoc de una planta concreta

preparando dicha información para ser procesada de manera conjunta con los procesos de fabricación. En este proceso se traducen las características físicas, como posición, vecindad, consumo, etc. obteniéndose una ontología asercional con la información de la planta

IMaaS?9:;.

�� =N{IMaaS89:;, PlantaIMaas}, IMaaS?9:;, Conceptualizar, InstanciaciónLM}R (4.13)

El Proceso de Modelado Semántico de Procesos de Fabricación

(ModeladoProc) extrae la información del proceso de fabricación S� TU*V obtenido por la fase de normalización �� y junto a la

ontología general obtenida en la etapa ��, la instanciación

sobre la ontología��TW*V obtenida en el proceso ��, modela un proceso de fabricación completo que se adapte a los objetivos

del proceso y características concretas de una planta industrial determinada. El resultado de esta etapa es un proceso de fabricación, o negocio, diseñado para una planta específica en función de los objetivos estratégicos definidos.

�� = X{S� TU*V, ��TW*V}, S� TU*V,*Y%Z[\*, ��#�,

��#�23] (4.14)

El Proceso de Compilación de Procesos (CompilarProc) de Fabricación, extrae la información referente del proceso modelado en la fase anterior, identifica los elementos que pueden ejecutar las actividades del proceso y las traduce a lenguaje que pueda ser ejecutado por máquinas. En el

caso concreto de esta propuesta, a un formato compatible con un nivel tecnológico basado en servicios. El resultado de esta etapa es un proceso ejecutable que puede ser desplegado en un motor de ejecución para que pueda ser realizado.

�� =XNS� TU*V

,*Y%Z[\*, ��TW*VR, S��^, ��, ��#�23] (4.15)


El Proceso de Ejecución y Monitorización (EjeccProc) contempla las fases donde se ejecuta el proceso resultante de los procesos anteriores y se comprueba su correcta ejecución. Así el proceso de ejecución, como su

propio nombre indica, es el encargado de orquestar el proceso durante su implementación, mientras que el proceso de monitorización incluye aquellas tareas que garanticen la correcta ejecución del mismo y garantice el cumplimento de los objetivos marcados. El sistema de

monitorización puede realimentar el sistema con nueva información para modificar el proceso en ejecución o para que se tenga en cuenta en la composición de procesos futuros, como por ejemplo ante el fallo de una máquina.

�� = {S��^, {��, ��},��, ��#�23 } (4.16) Expresado el proceso conceptual en forma de pseudocódigo, Tabla 4.1,

se podría ver cómo un proceso que está compuesto por un conjunto de funciones, las cuales tienen una serie de entradas y salidas. Cada una de estas funciones proporciona información relevante para la gestión del proceso. Finalmente, el propio desarrollo del proceso proporciona

información nueva sobre el contexto, lo que permite la retroalimentación del proceso. Por lo tanto, se puede ver el proceso de forma recursiva, ya que está conceptualizado para realimentarse de forma que pueda corregir posibles incidentes en la gestión de los procesos de fabricación.

Por lo tanto, el ModConceptGSPI se consideraría como una función cuyas entradas son el conocimiento del dominio, un proceso de fabricación y una planta concreta. Dentro de esta función se irían generando cada una de las fases descritas anteriormente.

Tabla 4.1 Proceso de Gestión Semántica expresado en pseudo-código.

ModConceptGSPI ( ��- ∈ ��, ��/ ∈ ��#�, ��! ∈ ��){ Ontología ont ← ConceptualizacionInformacion(in x); Proceso procesoSimple ← NormalizacionProcesos(in y); Instancia instFab ← ConceptualizacionPlanta(in ont,in Y); Modelo modelo ← ModeladoSemantico(in ont,in procesoSimple,in IntsFab); Ejecutable proceso ← CompilacionModelo(in Ont,in InstFab,in modelo); Ejecución ejec ← EjecucionyMonitorizacion(in/out proc,in/out instFab); si ejec = OK entonces resultado = OK; sino resultado = ModConceptGSPI (X, ejec, instFab); fin si }


Una vez modelados cada uno de los procesos que componen el ModelConceptGSPI, y contextualizadas sus entradas y salidas, se modelan cada una de las tareas que permiten cumplir con los objetivos

de cada proceso y transformar la entrada del proceso en la salida identificada. Los seis procesos definidos se estructuran en dos grupos, al igual que se han definido en (4.8), en función de la naturaleza de los mismos. Un grupo de procesos en los que se genera el conocimiento para

la gestión de procesos 0�. ��23 y un grupo de procesos donde se

realizan y gestionan los procesos de fabricación ��#�. ��#�23 .

Cada uno de los procesos estudiados a continuación se compone, a su vez, de otros procesos y actividades. En este nivel de detalle la composición de procesos se expresará mediante Casos de Uso de UML, etiquetando con la etiqueta <<include>> los procesos que componen un

proceso de nivel superior y mediante <<uses>> las actividades que hacen uso de la salida de otras actividades. Los actores definirán las entradas y salidas de cada proceso.

4.1.1 Proceso de Definición de Información

Semántica

El Proceso de Definición de Información Semántica 0�. ��23 es el mecanismo por el cual se identifican los conceptos implicados en el

proceso productivo y de negocio, se clasifican, se jerarquizan y se identifican las relaciones entre ellos. A partir de esta información se puede establecer una representación formal, explicita y compartida del dominio en una ontología. A partir de la taxonomía de la ontología se

pueden establecer procesos de inferencia para extraer nueva información que resulte valiosa para automatizar y mejorar los procesos.

Sin embargo, el proceso de conceptualización de la información no es

una tarea trivial, sino que se debe buscar un compromiso entre lo específica que es una ontología y lo reusable que pueda ser. De esta forma, una ontología muy genérica resulta muy reutilizable, pero al mismo tiempo contendrá menos información y los procesos de inferencia

que se puedan realizar sobre ella producirán, generalmente, menos información. Por otro lado, si la ontología es muy específica pude proporcionar una información muy valiosa en un entorno determinado, pero esta información puede que no sea extrapolable a otros entornos.

Tal como se indica en (Klinker et al, 1991) (Gómez-Pérez et al., 2004), la relación entre usabilididad y reusabilidad de una ontología es inversamente proporcional, es decir, que a medida que una ontología se


acota a un dominio concreto para ser funcional se hace menos extensible a otros dominios (Figura 4.3

Figura 4.3 Problema ente Usabilidad y

Existen multitud de metodologías propuestas para el desarrollo de

ontologías, mediante el uso de una metodología para la definición de la taxonomía de la ontología necesarias para la correcta definición de las oescogida para la conceptualización del dominio industrial ha sido la

metodología METHONTOLOGY, por contemplar todas las tareas para el desarrollo desde la implementación y validación.es un proceso en el que intervienen varios

en cada uno de los procesos que componen el flujo de trabajo

0�. ��23.

Como método de representación formal de la ontologías en edocumento de tesis se utilizará la sintaxis funcional definida por el W3C (Bock et al., 2012) dado que permite una fácil lectura, aunque cuando

por motivos de expresividad sea necesario, se recurrirá a la denominada sintaxis Manchester para defiSchneider, 2012). En cada caso se especificará el lenguaje mediante el cual se está especificando cada una de las propiedades de la ontología.

Junto con estos métodos de definición de la ontología se utilizará la herramienta Protégé (Protégé, 2012) y concretamente el plug


acota a un dominio concreto para ser funcional se hace menos extensible Figura 4.3).

Problema ente Usabilidad y Reusabilidad en Ontologías (Gómez-Pérez et al., 2004).


ontologías, mediante el uso de una metodología para la definición de la taxonomía de la ontología se garantiza que se cubran las fases mínecesarias para la correcta definición de las ontologías. La metodología escogida para la conceptualización del dominio industrial ha sido la

metodología METHONTOLOGY, por contemplar todas las tareas para el desarrollo desde la definición conceptual del dominio hasta su implementación y validación. La etapa de conceptualizar la información es un proceso en el que intervienen varios actores, los cuales se detallan


Como método de representación formal de la ontologías en el presente documento de tesis se utilizará la sintaxis funcional definida por el W3C (Bock et al., 2012) dado que permite una fácil lectura, aunque cuando

por motivos de expresividad sea necesario, se recurrirá a la denominada sintaxis Manchester para definir ontologías en OWL2 (Horridge &

, 2012). En cada caso se especificará el lenguaje mediante el cual se está especificando cada una de las propiedades de la ontología.

Junto con estos métodos de definición de la ontología se utilizará la Protégé (Protégé, 2012) y concretamente el plug-in ontograf

acota a un dominio concreto para ser funcional se hace menos extensible

en Ontologías


ontologías, mediante el uso de una metodología para la definición de la que se cubran las fases mínimas

La metodología escogida para la conceptualización del dominio industrial ha sido la

metodología METHONTOLOGY, por contemplar todas las tareas para el conceptual del dominio hasta su

etapa de conceptualizar la información los cuales se detallan


l presente documento de tesis se utilizará la sintaxis funcional definida por el W3C (Bock et al., 2012) dado que permite una fácil lectura, aunque cuando

por motivos de expresividad sea necesario, se recurrirá a la denominada nir ontologías en OWL2 (Horridge & Patel-

, 2012). En cada caso se especificará el lenguaje mediante el cual se está especificando cada una de las propiedades de la ontología.

Junto con estos métodos de definición de la ontología se utilizará la in ontograf


(Ontograf, 2011) como método de representación gráfica. Mediante la combinación de estas tres formas de representar la información se busca dar una mayor expresividad y claridad a la definición de la ontología.

El Proceso de Conceptualización de la Información IMaaS �� ∈ 0�. ��23 (Figura 4.4) se centra en la

conceptualización del dominio de fabricación y de negocio. Se puede dividir en tres actividades principales. Por un lado la tarea de definición

de conceptos del dominio implicaría la experiencia del experto del dominio como entrada, en el caso de los procesos industriales podría ser el ingeniero de planta o el experto de procesos. Este actor es el encargado de definir el glosario de términos, los conceptos implicados,

cómo se jerarquizan estos conceptos y qué relaciones hay entre ellos. Esta información no es en sí una ontología, sino que será reflejada en lenguaje natural. A partir de esta información se define la ontología, identificando sobre el resultado de la definición de conceptos qué

información debe ser considerada como una clase, qué información se debe considerar atributos de una clase, de qué manera se relacionan las clases, y se definen restricciones y axiomas sobre la información del dominio. Se puede considerar que esta información ya es una ontología por estar especificada formalmente y de manera no ambigua. Tal como

se identifica en (Gómez-Pérez et al., 2004), la elección de si un concepto se debe definir como atributo o clase es una decisión que viene marcada por el uso que se vaya a hacer de la ontología y que no tiene una regla general que se pueda aplicar. El conocimiento del ingeniero de

conocimiento será el que determine, en función del uso, cómo se establece la ontología. La tercera tarea es donde la ontología definida formalmente se implementa para que sea interpretable por máquinas. Para ello se selecciona un lenguaje de representación sobre el que se

implementa y se comprueba su correcta implementación, tanto a nivel de consistencia como de decidibilidad de la ontología. La implementación se debe realizar sobre lenguajes estándares que faciliten la interoperabilidad con otros sistemas informáticos.

En el Proceso de Normalización de los Procesos de Fabricación �� ∈ 0�. ��23 (Figura 4.5) se define cómo se gestiona la

información de un proceso de fabricación que se desea realizar, facilitado por el ingeniero de procesos. En esta etapa se valida la información

referente al proceso; se comprueba que sea correcta tanto a nivel de objetivos como estructural; se extraen los objetivos del proceso; y se definen, sobre una base de conocimiento, para que se pueda realizar inferencias con ellos. Para poder realizar esta instanciación se debe


haber definido un mecanismo para convertir de la especificación dada por el ingeniero de procesos a la ontología terminológica. Este mecanismo suele ser definido por el ingeniero de procesos.

Figura 4.4 Modelado de tareas que componen el proceso ��

expresadas mediante Casos de Uso.

En el Proceso de Conceptualización de Plantas IMaaS �� ∈ 0�. ��23 se definen las tareas orientadas a la instanciación del nivel

de planta (Figura 4.6). Es la fase donde se obtiene la información de una planta industrial concreta y se instancia sobre la ontología terminológica

definida en ��. Esta tarea puede ser realizada de manera manual por el ingeniero de planta o se podría establecer un mecanismo

de correspondencias, al igual que en la etapa anterior. Una vez se conocen los elementos del nivel de planta y sus características se instancian sobre la ontología terminológica, estableciendo relaciones entre conceptos del mundo real y clases de la ontología, propiedades,

relaciones etc. El resultado de esta etapa es una ontología asercional con los elementos del nivel de planta definidos sobre la ontología terminológica.


Figura 4.5 Modelado de tareas que componen el proceso �� expresadas mediante Casos de Uso

Figura 4.6 Modelado de tareas que componen el proceso

�� expresadas mediante Casos de Uso.


4.1.2 Proceso de Gestión Semántica de Procesos de

Fabricación

El Proceso de Gestión Semántica de Procesos de Fabricación ��#�. ��#�23 engloba las tareas más relacionadas con el manejo de los

procesos de fabricación. Estas tareas se identifican dentro de la metodología BPM como las principales actividades dentro del ciclo de vida BPM. Sin embargo, es necesario extender estas actividades para adaptarlas al uso de información semántica. Por lo tanto, el proceso

��#�. ��#�23 se compone de las siguientes tareas: Modelado

Semántico de Procesos, Compilación de Procesos y Ejecución y Monitorización de procesos, tal como se ha visto en (4.10). Estas tareas son las encargadas de, a partir de la información generada en el proceso

0�. ��23, realizar las diferentes tareas del ciclo de vida BPM.

El Proceso de Modelado Semántico de Procesos de Fabricación �� ∈ ��#�. ��#�23 se agrupan todas aquellas actividades identificadas para conseguir desarrollar procesos de fabricación y de

negocio que puedan ser llevados a cabo en algún entorno determinado de manera automática (Figura 4.7). Entre las actividades que identificadas están la de interpretar los procesos objetivo que se desean realizar, para lo cual se debe poder leer y manejar la información de los

procesos. A partir de los objetivos se debe poder realizar procesos de inferencia sobre la ontología de la planta industrial, la cual permite contextualizar los objetivos en un entrono concreto. En esta etapa se pueden obtener los procesos que pueden implementar los objetivos, las

máquinas que los realizan, e incluso, los caminos a seguir para ir de máquina a máquina. A partir de esta información, se establece la actividad de generar un nuevo proceso en un formato estándar. En función de la planta industrial sobre la que se modele el proceso, se

puede obtener más de un proceso que cumpla con los mismos objetivos. Para ello, la tarea de selección de procesos seleccionara el que más se amolde a los objetivos estratégicos definidos.

En el Proceso de Compilación de Procesos de Fabricación �� ∈��#�. ��#�23 engloba las actividades para la traducción del proceso de fabricación completo a un lenguaje que sea interpretable por un

motor de ejecución (Figura 4.8). En este proceso se definen las tareas para realizar la traducción desde la visión conceptual, más propia del ingeniero de procesos, a la visión tecnológica, típicamente dominada por los expertos TI. El proceso de compilación se compone de un conjunto


de actividades más específicas. Por un lado todas aquellas actividades relacionadas con la interpretación del proceso, como la lectura e interpretación del proceso. Por otro lado, los procesos de inferencia que

se realizan sobre la ontología de planta, para los cuales se ha de definir una serie de cuestiones sobre la ontología. Otra de las actividades está relacionada con la tramitación de información de servicios, tanto información a nivel de conexiones físicas de servicios, como a nivel de

acciones, precondiciones y consecuencia de la invocación de los mismo. Por último, todas aquellas tareas relacionadas con la generación propia del ejecutable, más relacionada con aspectos concretos de un lenguaje de programación, etc.

Figura 4.7 Modelado de tareas que componen el proceso �� expresadas mediante Casos de Uso.

Aunque el Proceso de Ejecución y Monitorización de Procesos de

Fabricación �� ∈ ��#�. ��#�23 se podría entender como dos procesos independientes, al existir una fuerte vinculación entre

ambos, se trataran en la presente tesis de manera conjunta. La parte relacionada con la ejecución contempla las actividades para orquestar la ejecución del proceso. Si en algún momento se produce un error durante la ejecución de un proceso se pasa al proceso de monitorización. Las

tareas de monitorización reciben la información de ejecución durante la realización del proceso. La primera actividad del proceso de monitorización es recolectar la información necesaria acerca del error,


máquina en el que se ha producido, estado actual de la máquina y tipo de error. Con esta información se actualiza el estado de la información de la fábrica, se publican los cambios del estado de la planta en el

sistema de información del sistema y se devuelve el proceso al sistema de modelado, para que lo re-estructure en función del estado de la planta y pueda ser finalizado.


expresadas mediante Casos de Uso.


centrado en las tareas de monitorizacización, expresadas mediante Casos de Uso.


4.2 Modelo Funcional de Gestión Semántica de Procesos Industriales El Modelo Funcional de Gestión de Proceso de Fabricación ModFuncGSPI recoge los diferentes actores, o unidades funcionales, que componen el ModGSPI. Los elementos que componen ModFuncGSPI se corresponden

con los elementos necesarios para desarrollar los procesos identificados durante el Modelado Funcional. Durante esta sección se modelan los diferentes elementos y su funcionalidad, así como se relacionan entre ellos para realizar los procesos identificados.

Mediante la definición del modelo ModFuncGSPI se busca identificar, modelar y definir funcionalmente aquellos elementos para cumplir con

los diferentes objetivos del presente trabajo de investigación. A partir de las procesos identificados en ModConceptGSPI, se define una serie de componentes que estructurarán el modelo y permitirán encapsular cada una de las actividades identificadas en diferentes elementos,

estableciendo los flujos de comunicación entre partes y cómo colaboran las diferentes partes del modelo para conseguir la integración de los procesos de fabricación en los entornos de producción ágil.

Uno de los objetivos es el de automatizar el modelado de procesos de fabricación de acuerdo a los objetivos estratégicos de la organización. En este caso, el objetivo final de cada proceso de fabricación vendrá determinados por los diagramas facilitados al sistema. Este diagrama de

objetivos, denominado Proceso Funcional, vienen determinados por el ingeniero de procesos y es independiente de las características físicas o tecnológicas de cualquier planta de fabricación. A partir de la

automatización del modelado se puede plantear la automatización de las compilaciones del proceso. Esta tarea que tiene que ver más con los niveles tecnológicos de la organización.

En la Figura 4.10 se muestra de forma simplificada los objetivos del modelo propuesto, de forma que permita alinear los procesos identificados durante el modelado conceptual con los objetivos generales marcados en la presente investigación. El modelo hará uso de la

información del dominio, definida como una ontología en ��, de la información de planta �� y de

los objetivos del proceso definidos por el ingeniero de procesos. A partir de estas entradas se realizan los procesos de normalización �� y modelado ��, obteniendo un proceso


completo para una planta determinada. En el proceso de compilación ��, se obtiene, en un lenguaje ejecutable, el mismo proceso

modelado. Este proceso ejecutable es ejecutado por el sistema industrial ��, el cual mantiene información sobre la ejecución y el

estado de la planta.

Partiendo de los objetivos y del modelo conceptual ModConceptGSPI, se puede establecer se identifican los elementos funcionales necesarios para desarrollar cada uno de los procesos identificados, identificar entradas, salidas y como colaboran entre ellos. El modelo funcional

propuesto ModFuncGSPI se divide en tres niveles desde un punto de vista conceptual: el nivel de negocio, el nivel de conocimiento y el nivel de fabricación. Estos tres niveles se han establecido atendiendo a la visión dada en (Hepp et al, 2005) sobre la brecha en la gestión de procesos BPM

y recogida en la Figura 2.3, dejando en un nivel superior aquellos aspectos relacionados con la gestión de procesos BPM, en el nivel inferior los elementos industriales, mas relacionados con la capa tecnológica y el nivel de conocimiento como intermediario entre ambos.

Figura 4.10 Entradas y salidas del sistema propuesto.

El Nivel de Planta es el nivel inferior implicado en el modelo, se corresponde con los niveles físicos de la organización. Es en este nivel

donde se lleva a cabo gran parte del proceso de fabricación, principalmente todas las tareas de manejo y transformación de materia, logística, etc. En el Nivel de Planta se sitúa el Proceso de Ejecución y

Monitorización ��.


Como se ve en la Figura 4.12 cada una de las denominadas Fabricas IMaaS se modela a partir de una serie de máquinas IMaaS, las cuales ya se han estudiado en el capítulo 3 (Figura 3.6). Estas máquinas ofrecen

sus funcionalidades como servicios a través de un sistema de registro de servicios, que permite publicar la información referente a los mismos. Cada una de las Máquinas IMaaS (Gilart, 2010) está dotada de un motor de orquestación, de modo que puede ejecutar los servicios que actúan

sobre ella. Adicionalmente se estima conveniente que dentro de cada fábrica IMaaS existe un motor de orquestación que controle los procesos ejecutados por diversas máquinas. Sin embargo, no es indispensable este motor de orquestación, ya que al estar basado en servicios,

cualquier motor de orquestación externo podría acceder y orquestar el proceso remotamente, siempre que disponga de los permisos necesarios. El motor de orquestación suele tener asociado, muchas veces embebido, un sistema de monitorización que permite validar la correcta ejecución

de un proceso. Durante la monitorización se pueden identificar errores sobre los propios elementos de fabricación y actualizar información en el Nivel de Conocimiento. El nivel físico, por lo tanto tiene flujo de salida que se compone de la información de los servicios y la información de la

planta y un flujo de entrada relacionado con la ejecución de los procesos y servicios.

Figura 4.11 Niveles conceptuales de la propuesta y su correspondencia con los procesos conceptuales del ModConceptGSPI.


Figura 4.12 Elementos identificados en el Nivel de Planta para la realización del proceso de ejecución y monitorización

��. El comportamiento modelado para la ejecución de un proceso se corresponde con el mostrado en la Figura 4.13. La ejecución de un

proceso en el nivel de planta comienza tras la solicitud de ejecución de un proceso al motor de orquestación. El motor de orquestación realiza, según la logica del proceso, la invocacion a cada uno de los servicios implicados, y que son ejecutados por las diferentes máquinas IMaaS que

componen una planta de producción. Si se produce algun fallo durante la ejecución del proceso, se actualiza el estado de la información referente al Nivel de Planta. Por ejempo, indicando que una máquina de transporte no funciona. La información de la planta se actualiza en la

ontología del sistema de información y el proceso es finalizado por el motor de ejecución. Este proceso será regenerado de manera automática en el sistema de modelado para que pueda ser finalizado.

El Nivel de Conocimiento se corresponde con el nivel intermedio, este nivel permite independizar los procesos de Modelado ��, y

Compilacion �� de las caracteristicas del Nivel de Planta,

recogidas dentro del proceso de ejecucion y monitorización ��, que es donde se encuentran las caracteristicas físicas y

tecnológicas de cada una de las plantas de fabricación que pueden existir en el sistema. En este nivel se recibe como entrada las ontologías con la descricpión semántica de los servicios y la ontología con la información referente a cada planta industrial realizadas en el proceso

��. Esta información queda registrada en el sistema y es ofertada a los elementos del modelo que la necesiten, generalmente el

Nivel de Procesos de Negocio.


Figura 4.13 Secuencia de la interacción entre los elementos funcionales del Nivel de Planta.

Figura 4.14 Elementos pertencientes al Nivel de Conocimiento.

El tercer nivel es el que se ha denominado el Nivel de Procesos de

Negocio. En este nivel se sitúan las actividades relacionadas con la gestión de los procesos de fabricación y negocio. Este nivel se apoya en

los niveles inferiores para construir los procesos de negocio y, como un tipo específico de proceso de negocio, los procesos de fabricación. Las principales actividades del ciclo de vida BPM se corresponden con este nivel. Las tareas de diseño, modelado (��) y composición de

procesos (��) se realizan en este nivel, para ello el sistema está

compuesto por partes específicas para cada una de estas tareas, las cuales interactúan entre sí y con el usuario (ingeniero de procesos) para lograr automatizar las tareas del nivel.


Tal como se puede ver en la Figura 4.15, el nivel de negocio se compone del Modelador de Procesos, el Compilador de Procesos y el Desplegador de

Procesos. El Modelador de Procesos de Fabricación MPF es el encargado

de implementar el proceso de modelado ��. En el Compilador

de Procesos de Fabricación CPF se implementan las funcionalidades de traducción de un proceso de fabricación modelado a un lenguaje que sea ejecutable por máquinas��. El Desplegador de Servicios DS es

el encargado de completar la información necesaria para poder desplegar y dejar disponible un proceso de fabricación para su ejecución.

Figura 4.15 Elementos pertencientes al Nivel de Procesos de Negocio.

Desde un punto de vista funcional, y tal como se ve en la Figura 4.16, el

MPF debe ofrecer una entrada a través de una herramienta de modelado BPMN. Mediante esta herramienta se pueden crear lo que se han denominado los Procesos Funcionales. Un Proceso Funcional es aquel en


el que se especifican los objetivos que debe cumplir un proceso de fabricación. Este proceso debe cumplir una serie de características que garantizan que pueda ser desarrollado por un sistema informatizado. El

validador de procesos debe encargarse de comprobar la corrección del proceso introducido. El proceso validado será traducido a una representación semántica para poder ser procesado. El tercer elemento identificado que compone el Modelador de Procesos es el Compositor de

Procesos, el cual se apoyará en un razonador semántico para extraer la información necesaria de las ontologías ABox de cada planta industrial, a partir de una serie de funcionalidades definidas.

Figura 4.16 Secuencia de los elementos del Modelador de Procesos.

El denominado Compilador de Procesos de Fabricacion, CPF en adelante, es el encargado de traducir un proceso de una vision conceptual, aunque ya especifico para un entorno de ejecución concreto, a un lenguaje que

pueda ser ejecutado por los elementos computacionales disponibles en la organización.En el diseño propuesto, el CPF hace uso del diagrama

completo S� TU*V,*Y%Z[\* obtenido en por el MPF y junto a las ontologias

IMaaSABox y BPMNAbox, se realiza la busqueda de los servicios que pueden llevar a cabo las tareas del proceso. Para extraer los parámetros

con los que se invoca a los servicios se hace uso de la descripcion semántica de los servicios disponibles, analizando las precondiciones y efectos establecidos en la descripcion semántica. Para extraer la


información del proceso a traducir, el CPF se apoya en el denominado Manejador de Ontología de Diagrama, el cual proporciona información acerca de la estructura de un proceso definido como una ontología

BPMNAbox. Mediante la ontología del Nivel de Planta IMaaSABox, se puede extraer la información referente a los servicios que implementan cada operación en cada máquina. Partiendo de esta información, se analiza la

descricpión semántica de cada uno de los servicios, y se puede inferir a partir de la información conceptual referente a sus parámetros y el efecto en la ejecución. El último paso en la traducción es extraer los aspectos referentes a la conexión para la ejecución de cada servicio como la dirección del servicio y los tipos de datos aceptados, tal como se recoge

en Figura 4.17.

Figura 4.17 Secuencia de los elementos Compilador de Procesos.

El Desplegador de Servicios de Fabricación es el encargado de preparar el

proceso resultante de los procesos de modelado y compilacion y enviarlo a las fabricas IMaaS para que se incorpore al sistema de información y quede accesible para su posible invocación.


Figura 4.18 Secuencia de los elementos del Desplegador de Servicios.

4.3 Modelo Arquitectónico de Gestión Semántica de Procesos Industriales La presente tesis parte de la idea de ofrecer la maquinaría Industrial como Servicio (Gilart, 2010) dentro del sistema de gestión de procesos de

una organización. En consecuencia, el Modelo Arquitectónico ModArqGSPI propuesto se centra en integrar todos los elementos descritos en el ModFuncGSPI dentro de un escenario realista, basado en una arquitectura orientada a Servicios.

Aunque tradicionalmente el modelo BPM y el paradigma SOA (Service

Oriented Architecture) han crecido como dos iniciativas independientes,

en los últimos tiempos se ha demostrado el beneficio de la convergencia de ambos enfoques (Kamoun, 2007).

Los actores que participan en un escenario SOA se pueden resumir en los proveedores de servicios que exponen sus funcionalidades a través de la red como capacidades de servicios, los consumidores que invocan a dichos servicios y el intermediario o bróker que sirve como catálogo de servicios.


Concretamente, en modelo propuesto se basa en el estilo arquitectónico matchmaker style (Dillon et al., 2008). En esta arquitectura el elemento intermedio o bróker únicamente se encarga del registro de los servicios

para que estos puedan ser localizados y consumidos por los consumidores de servicios. El modelo propuesto se divide en tres partes claramente diferenciadas, el Sistema de Información, el cual engloba todas aquellas partes identificadas en el nivel intermedio, el Sistema de

Fabricación compuesto por Plantas ImaaS y el Sistema de Gestión Semántica de Procesos, donde se llevan a cabo las tareas de gestión de los procesos.

Tal como se ve en la Figura 4.19, la arquitectura propuesta se compone de plantas ImaaS, las cuales actúan como proveedores de servicios. El Sistema de Información que actúa como intermediario y el Sistema BPMS Semántico, el cual tiene el rol de consumidor de Servicios.

Figura 4.19 Modelo arquitectónico ModArqGSPI propuesto.

Las Plantas ImaaS se componen, a su vez, por un conjunto de máquinas industriales que ofrecen su funcionalidad como procesos de negocio expuestos como servicios (ImaaS). Estos procesos son los responsables

de llevar a cabo los procesos físicos del entorno de producción. Cada una


de estas máquinas oferta los procesos que es capaz de realizar como un servicio. Estos servicios se registran en el Sistema de Información de forma que queden disponibles para que puedan ser consumidos.

Además, cada Planta ImaaS contiene la información semántica del conjunto de máquinas y procesos de los que dispone. Dicha información semántica corresponde con la instanciación de los elementos del sistema de producción (��TW*V) dentro de la ontología propuesta en la presente

tesis, y que se desarrolla en el capítulo 5. Engloba por lo tanto los elementos identificados en el Nivel de Planta definidos en ModFuncGSPI.

El Sistema de Información se compone, por un lado, por la descripción de los servicios disponibles en los diferentes sistemas de fabricación, y

por otro lado, por la base de conocimiento semántico, formalizada como una ontología (ImaaS8`:;) que contiene una clasificación de las diferentes

máquinas que se pueden encontrar en una planta de fabricación, las relaciones entre los diferentes tipos de maquinaria, qué servicios oferta cada máquina, y de qué forma se relaciona cada servicio con un conjunto de procesos de fabricación genéricos. La descripción semántica

de los servicios permite relacionar ambas informaciones de forma que se contextualice sobre la ontología de cada planta industrial las acciones, consecuencias y requisitos de cada uno de los servicios desde un punto de vista conceptual y no solo tecnológico, como sucede con la descripción

que recogen los estándares. Se corresponde por lo tanto con los elementos identificados en el Nivel de Conocimiento del ModFuncGSPI.

El BPMS Semántico es responsable de la gestión de las políticas,

objetivos y estrategias de negocio mediante un sistema BPMS dirigido por información semántica. Este sistema se compone de los elementos definidos dentro del Nivel de Procesos de Negocio del ModFuncGSPF. El MPF a partir de un proceso funcional, compone de forma automática el

proceso completo que refleja las características específicas de una planta de fabricación concreta. Se entiende como proceso funcional una especificación del qué se debe realizar, independientemente del cómo se

debe realizar. Una vez se dispone del proceso modelado, éste se le pasa al CPF, el cual, a partir de la información especificada en cada ontología de cada planta, junto con el proceso compuesto automáticamente, es capaz de traducir el modelo a un lenguaje ejecutable, que pueda ser

interpretado por la maquinaria industrial y llevado a cabo de manera física. Lo que permite reducir la difícil comunicación entre los responsables de las diferentes áreas de la empresa y que no manejan, en muchos casos, los mismos conceptos. El proceso ejecutable obtenido se

envía a la planta de fabricación, en la cual se registra y se instancia en la


ontología mediante es DS. De esta forma se consigue una retroalimentación del sistema de fabricación, permitiendo a la planta de producción ofertar su nuevo proceso como servicio para futuros usos.

La arquitectura propuesta está basada en una arquitectura distribuida, y el BPM Semántico se basa en una fuente de conocimiento genérica

como son las ontologías, este modelo propuesto se puede extender de forma que desde un único elemento de gestión se puedan manejar diferentes plantas de fabricación de manera remota. El sistema propuesto cumple con los requisitos para satisfacer los objetivos del

presente trabajo ya que permite modelar procesos de negocio y fabricación con un nivel de abstracción sobre el nivel de planta muy alto (��). La información semántica de la planta y de los servicios,

junto con una serie de reglas establecidas en la presente tesis, permite realizar la traducción desde un proceso modelado de forma gráfica a un lenguaje que pueda ser ejecutado por máquinas (��). Lo cual

dota de un mayor automatismo al sistema. Al lograr un sistema capaz de componer procesos de fabricación mediante información semántica, se

puede componer y desplegar un proceso para diferentes plantas industriales y que sea ejecutado (��), simplemente

haciendo uso de la información semántica de cada una de las plantas donde se quiera desplegar.

Durante los siguientes capítulos se profundiza en cada uno de los

elementos identificados en el presente capítulo. Los siguientes capítulos se organizan en función de la naturaleza de los procesos definidos en el modelo ModConceptGSPI, siendo en el capítulo 5 donde se describen los procesos y elementos funcionales necesarios para el proceso de

Conceptualización de la Información 0�. ��23 y en el capítulo 6 se definen los elementos y funcionalidades necesarias para realizar el

proceso de gestión definido en el modelo conceptual ��#�. ��#�23.

Ambos capítulos se centran en la definición de las funcionalidades que permiten llevar a cabo estos procesos, y por lo tanto se estructuran conforme el Modelo Funcional definido ModFuncGSPI.

C a p í t u l o 5

Información Semántica ImaaS

En el capítulo anterior se ha desarrollado el Modelo de Gestión Semántica

de Procesos Industriales. Tal como se ha visto en el ModGPSI los procesos implicados en el modelo conceptual ModConceptGSPI se han estructurado en dos partes atendiendo a su naturaleza. En el presente

capítulo se aborda aquellos procesos relacionados con la Definición de

Información Semántica de Procesos Industriales 0�. ��23.

Siguiendo con el modelado de este proceso, el presente capítulo se estructura en dos partes diferencias: en la primera se desarrolla la conceptualización del dominio industrial ImaaS y la creación como una

ontología; en la segunda se desarrolla el Proceso de Normalización de los

Procesos de Fabricación ��, en el que describen los elementos

implicados en el proceso y su funcionalidad siguiendo los elementos identificados en el modelo funcional ModFuncGSPI ; el Proceso de

Conceptualización de Plantas ImaaS ��, que es el tercer

proceso implicado, se desarrolla durante la implementación del modelo

propuesto en el capítulo 7 y anexo I por tratarse de una parte dependiente de una instanciación concreta de planta industrial.

En este capítulo se pueden destacar dos aportaciones principales que se

desarrollaran en las siguientes secciones: Por un lado se realiza la conceptualización del dominio industrial de acuerdo a las especificaciones contenidas en (Groover, 2000) sobre la información del Nivel de Planta; Por otro lado, se propone un mecanismo automático de


extracción de información de un sistema de representación de procesos y población de una ontología con la información extraída.

5.1 Conceptualización del Dominio Industrial ImaaS El proceso de conceptualización de la información hace uso del

conocimiento generado por los expertos en el dominio industrial así como de las teorías y metodologías para la ingeniería del conocimiento para generar una ontología que conceptualice de manera formal una serie de información del dominio de forma que pueda ser explotada

automáticamente por máquinas. Por ello, en base a la definición de ontología realizada por Studder en 1998,

“Una ontología es una especificación formal y explicita de una

conceptualización compartida.”

En el presente apartado se realiza una conceptualización formal de un subconjunto de los conceptos del dominio industrial y de los conceptos

del nivel de negocio, definiendo explícitamente los tipos de conceptos tanto industriales como de negocio, y las relaciones entre ellos y las tecnologías que los sustentan. La ontología resultante estará definida formalmente de manera que sea interpretable por las diferentes partes

del sistema propuesto. La conceptualización de los dominios implicados en el entrono productivo es un tema de estudio lo suficientemente amplio como para requerir por si solo varios trabajos de investigación realizados por expertos en las diferentes áreas.

Como se ha identificado en el estado del arte y en los antecedentes del presente trabajo, una de las metodologías que mejor se adapta a las demandas cambiantes del mercado es la metodología BPM. Se podría

decir que esta metodología tiene dos áreas de alto nivel, como se puede ver en la Figura 2.3. Por un lado la visión de los expertos de negocio, agrupado en un conjunto de procesos y actividades, y por otro lado de las tecnologías que lo sustentan (Hepp et al., 2005). En la presente

propuesta la tecnología subyacente que da soporte al sistema productivo es la tecnología de servicios.

De esta forma se pone de manifiesto que uno de los dominios a conceptualizar es el de nivel de negocio, con los procesos como unidad

Capítulo 5. Información Semántica 101

de nivel superior. Además, queda claro que existe una relación explicita entre el nivel de negocio y el nivel tecnológico. El nivel tecnológico del sistema de producción viene determinado por ImaaS (Gilart, 2010), visto

en los antecedentes, por lo que otro de los dominios a conceptualizar es el nivel tecnológico basado en Servicios Web.

Uno de los aspectos más importantes es que, a diferencia de otros

dominios, el dominio industrial está muy centrado en la producción o transformación física de materias, por lo que es necesaria la conceptualización del nivel de planta desde un aspecto físico (Borgo & Leitao, 2006). Esta conceptualización tiene un impacto directo en la

forma de construir los procesos, la optimización de la gestión del nivel de planta tiene un influye sobre la forma de llevar a cabo los procesos y los costes que estos tienen.

Atendiendo a los tres niveles identificados anteriormente, la ontología que se va a conceptualizar se centra en tres ámbitos que están relacionados entre sí. Como se puede ver en la Figura 5.1 en la ontología se conceptualizan y relacionan entre sí tres grupos de conceptos:

Conceptos del Nivel de Planta, relacionados con la maquinaria y sus características físicas; Conceptos del Nivel de Negocio, relacionados con los procesos y sus restricciones conceptuales; y Conceptos del Nivel

Tecnológico, relacionado con las características tecnológicas de los

Servicios Web. Además, la ontología propuesta se extiende mediante el uso de otras ontologías específicas de cada dominio. OWL-S (OWL-S, 2004) que contiene todos los elementos implicados en la descripción de

Servicios Web y BPMN Ontology, que conceptualiza los elementos específicos de BPMN (Ghidi et al., 2009).

Figura 5.1 Ámbitos de conceptualización de la ontología IMaaS propuesta

e interconexión con otras ontologías específicas de dominio.


Como ya se ha comentado, el estudio realizado se centra en definir una ontología basada en los dominios industriales, tecnológicos y conceptuales implicados en los procesos productivos de las

organizaciones manufactureras. Con el objetivo de estructurar de forma clara la implementación de la ontología, se agruparan las tareas identificadas en la metodología por cada uno de los dominios identificados anteriormente.

La definición de la ontología se ha seguido usando la metodología METHONTOLOGY (Gómez-Pérez, 2004), sin embargo por motivos de claridad durante la explicación de la misma se utilizará el resultado

obtenido de aplicar la metodología. En el Anexo II se pueden encontrar los elementos intermedios, como el glosario de términos, la definición de de relaciones binarias, etc.

5.1.1 Conceptualización del Nivel de Planta

En el estado del arte se ha visto una revisión de las principales

ontologías como MASON (Lemaignan et al., 2006) y ADACOR (Borgo & Leitao, 2007) que conceptualizan el nivel de planta. Las ontologías no son excluyentes, sino que se pueden conectar entre sí, complementar y extender apoyándose unas con otras. Por lo tanto, los conceptos presentados en esta investigación, son compatibles con las ontologías

existentes de forma que cumplen el principio de extensibilidad reflejado en la mayoría de metodologías de desarrollo de ontologías.

Para conceptualizar el dominio de fabricación, se ha seguido la clasificación de los elementos desarrollada por Groover (Groveer, 2000), donde sus descripciones constituyen el conocimiento del experto industrial a partir del cual se construye la ontología propuesta. Por lo

tanto, se realiza una conceptualización fiel a la descripción del dominio de Groover para, a partir de ella, poder relacionar con otros dominios y extender su funcionalidad en el Modelo de Gestión Semántica de Procesos

Industriales propuesto.

El concepto de nivel superior es la Maquinaria Industrial. La maquinaria industrial tiene una serie de propiedades físicas y mecánicas comunes

independientemente del tipo de maquinaria que sea. Entre estas características, que serán heredadas por los conceptos hijos, se encuentran las siguientes:

• Posicionamiento: una maquinaria industrial se encuentra

situada físicamente en algún punto (X,Y)


• Identificador: una máquina tiene un identificador que la

diferencia de los demás.

• Consumo eléctrico: una máquina industrial automatizada tiene

un consumo eléctrico para funcionar.

La maquinaria industrial se clasifica atendiendo a su funcionalidad

(Groove, 2001) en Maquinas de Transporte, Maquinas de Transformación

de Materia y Maquinas Almacenamiento.

La Máquina de Transporte, a su vez se puede clasificar en función de su

naturaleza. Según Groover, las Maquinas de Transporte se puede clasificar en 6 subgrupos.

• Vehículos Industriales: este grupo de elementos se caracteriza por facilitar el transporte de materias de forma manual por los operarios. Entre los elementos característicos de este grupo encontramos las carretillas, carros de carga y Trans-palés.

• Vehículos Industriales Motorizados: son elementos que hacen uso de un motor, ya sea eléctrico o de combustión, para facilitar

el transporte de materias. Entre estos vehículos se puede destacar los toros, trans-pales motorizados, remolques, etc. No constituyen en la actualidad máquinas computacionales.

• Vehículos Auto-guiados: son vehículos que no necesitan de la interacción con un operario para realizar su labor, son

autónomos y normalmente basan su funcionamiento en un conjunto de sensores y actuadores y un sistema de navegación para desplazar la materia. Son los más costosos que se pueden encontrar en una fábrica ya que ofrecen completa flexibilidad a

la hora de transportar materia.

• Cintras transportadoras motorizadas y Mesas de Giro: son, sin duda, el elemento más común en las plantas industriales, son elementos fijos que transportan materia por su superficie. Existen diversos tipos de cintas como las que utilizan como

superficie deslizante rodillos, ruedas o cintas. Además existen diversos tipos en función de si son fijas o tienen cierto grado de libertad para rotar.

• Raíles de Carga: son elementos que transportan materia a través de raíles fijos.

• Grúas y Poleas: son elementos destinados a transportar las materias por el aire, normalmente son elementos motorizados.


Cada una de estas Máquinas Industriales tiene una serie de características, las cuales se implementan como relaciones o propiedades en función de su naturaleza. Se consideran propiedades

aquellos conceptos que no van a relacionarse con ningún otro, como puede ser el tiempo de ejecución, la posición, el consumo electico, etc. Se consideran relaciones las propiedades que establecen alguna característica de la maquinaria en relación a otros conceptos.

Para las Máquinas de Transporte existen una serie de características comunes como son el tiempo de ejecución, posición, identificador, nombre,

etc. Además cada una de las Máquinas de Transporte tiene una serie de características específicas que se detallarán en la especificación formal de la ontología. Otra de las grandes ramas donde se puede clasificar la Maquinaria Industrial es como Máquinas de Almacenaje. Estas se pueden

clasificar de diversas formas en función de la materia que almacenan, la capacidad que tienen, si están motorizadas o automatizadas, si son fijas o móviles, etc.

Siguiendo la clasificación en función del tipo de máquina que sea (Groove, 2000), se pueden clasificar como motorizadas y no motorizadas. Por cuestiones de funcionalidad, en la ontología se desarrollaran más

extensamente el primer tipo de máquinas, pudiendo encontrar las siguientes máquinas clasificadas como máquinas motorizadas.

• Almacén en rack automatizado: consiste en una máquina que almacena en celdas en altura un determinado número de

materias. Es la propia máquina la que accede mediante una plataforma a cada celda para cargar o descargar mercancía.

• Carrusel de Almacenaje Horizontal: permite almacenar un determinado número de mercancías en estantes que se

desplazan a través de un raíl motorizado. Es el almacén el que se mueve para permitir almacenar y des almacenar materias.

El último tipo de Máquina Industrial que se conceptualiza en la ontología son las Máquinas de Procesado de materias. Es sin duda una de las clasificaciones más amplias que se puede hacer dentro del dominio, ya que la naturaleza de las mismas puede ser muy diversa, desde las

máquinas de control numérico CN hasta las prensas, pasando por las máquinas de oxidación o corte, se pude encontrar multitud de tipos de maquinaria orientadas a la transformación de materia.


Tal como se muestra en la Figura 5.2, y se especifica en la Tabla 5.1, las diferentes clases conceptualizadas van del concepto genérico de Máquina

Industrial hasta llegar a cada tipo de máquina industrial disponible en

una planta industrial.

Tabla 5.1 Definición de la Maquinaria Industrial.

Sintaxis funcional Declaration (Class (Maquinaria_industrial)) Declaration (Class (Máquina_de_transporte)) SubClassOf(:Máquina_de_transporte :Maquinaria_indus trial) Declaration ( Class(Cinta_transportadora)) SubClassOf(:Cinta_transportadora :Máquina_de_transp orte) Declaration ( Class(Mesa_de_giro)) SubClassOf(:Mesa_de_giro :Máquina_de_transporte) Declaration (Class (Rail_de_carga)) SubClassOf(:Rail_de_carga :Máquina_de_transporte) Declaration (Class (Máquina_de_almacenaje)) SubClassOf(:Máquina_de_almacenaje :Maquinaria_indus trial) Declaration ( Class(Almacen_en_rack) SubClassOf(:Almacen_en_rack :Máquina_de_almacenaje) Declaration (Class (Carrusel_de_giro)) SubClassOf(:Carrusel_de_giro :Máquina_de_almacenaje ) Declaration (Class(Máquina_de_procesado)) SubClassOf(:Máquina_de_procesado :Maquinaria_indust rial) Declaration ( Class (Máquina_herramienta)) SubClassOf(:Máquina_herramienta :Máquina_de_transformacion_de_materia) Declaration ( Class(Máquina_multi_herramienta)) SubClassOf(:Máquina_multi_herramienta :Máquina_de_transformacion_de_materia)

Figura 5.2 Taxonomía establecida de la Maquinaria Industrial.


Las Máquinas Industriales tienen una serie de propiedades, Tabla 5.2, como un nombre, mediante el cual se identifican, un número de serie que

es único entre ellas, una posición y un consumo eléctrico.

Tabla 5.2 Definición de los atributos de la Maquinaria Industrial.

Sintaxis Funcional Declaration (DataProperty (Nombre)) DataPropertyDomain(:Nombre :Maquinaria_industrial) DataPropertyRange(:Nombre xsd:string) FunctionalDataProperty(:Nombre) DataExactCardinality(1 :Nombre) Declaration (DataProperty(Número_de_serie)) DataPropertyDomain(:Número_de_serie :Maquinaria_ind ustrial) DataPropertyRange(:Número_de_serie xsd:string) DataMaxCardinality(1 :Número_de_serie) Declaration (DataProperty(Posición)) DataPropertyDomain(:Posición :Maquinaria_industrial ) DataPropertyRange(:Posición xsd:string) Declaration ( DataProperty(Consumo_eléctrico)) DataPropertyDomain(:Consumo_eléctrico :Maquinaria_i ndustrial) DataPropertyRange(:Posición xsd:float)

El Nivel de Planta también se encuentra compuesto por los diferentes

tipos de materias con las que se va a trabajar. Entre los tipos de materias que se pueden encontrar en una fábrica, según Groover, se pueden conceptualizar las siguientes en función de si forman parte del proceso de fabricación en sí o, si por el contrario, forman parte del apoyo

logístico de la empresa.

La jerarquía entre los diferentes tipos de Materia se establece como se

muestra en la Figura 5.3, en la cual se establece que una Materia puede ser Materia Logística o Materia Procesable. Dentro de las Materias

Procesables se pueden clasificar en función de su estado dentro del ciclo productivo. Así una Materia Procesable puede ser una Materia Prima

antes de entrar al proceso productivo, una Materia Procesada si ha finalizado su manufactura, una Materia en Proceso si se encuentra a mitad de manufactura o una pieza despreciada si ha sufrido algún daño.

A su vez, las Materias Logísticas se pueden clasificar de diversas formas. Este tipo de materias no han sido conceptualizadas por no entrar dentro de los objetivos de la tesis.

Las máquinas están dotadas de Herramientas para realizar la transformación de materia. Las Herramientas se pueden clasificar según la función que cumplan, por ello se clasifican como herramientas de

Ensamblado, Pulido, Pintado, Corte, Lijado, Devastado (Figura 5.4).


A su vez, las materias son de algún material, aunque no se ha profundizado en los diferentes tipos de materiales, se conceptualizan una serie de materiales básicos que se verán envueltos en la definición

de reglas de fabricación dentro de la ontología.

Figura 5.3 Clasificación de las Materias en el dominio industrial.

Figura 5.4 Clasificación de los tipos de Herramientas.

Los conceptos definidos anteriormente tienen una serie de relaciones binarias entre sí. Estas relaciones binarias se corresponden con las denominadas propiedades de objeto (ObjectProperty). Estas propiedades establecen como se pueden relacionar los conceptos entre sí, y por tanto

delimitan las posibles relaciones de las instancias que se definan sobre las ontologías. A continuación se definen las relaciones binarias así como sus propiedades.


Figura 5.5 Clasificación de algunos de los tipos de Materiales.

Las Máquinas de Transporte se encuentran conectadas las unas a las otras en una planta industrial para permitir a las Materias que se van a procesar llegar a las máquinas de procesado a través de ellas. Una Máquina de Transporte puede estar conectada a más máquinas de

transporte. El número de máquinas de transporte a las que puede estar conectada viene determinado por el tipo de Máquina de Transporte que sea.

Tabla 5.3 Definición de propiedades de objeto de conexión entre Máquinas de Transporte.

Sintaxis Funcional Declaration(ObjectProperty(Tiene_conexion)) Declaration(ObjectProperty(Esta_conectada)) ObjectPropertyDomain(:Tiene_conexion :Máquina_trans porte) ObjectPropertyRange(:Tiene_conexion :Máquina_transp orte) ObjectPropertyDomain(:Esta_conectada :Máquina_trans porte) ObjectPropertyRange(:Esta_conectada :Máquina_transp orte) InverseObjectProperty(:Tiene_conexión :Esta_conecta da) IrreflexiveObjectProperty(:Tiene_conexion) IrreflexiveObjectProperty(:Esta_conectada)

Las Cintas Transportadoras se pueden encontrar conectadas a otras Máquinas de Transporte. Como las cintas transportadoras se

caracterizan por tener dos extremos, se pueden establecer propiedades de conexión a través de cualquiera de sus dos lados. Así se definen las propiedades Tiene_conexion_ejeX+ y Tiene_conexion_ejeX- por las cuales

se establece que una Cinta Transportadora puede estar conectada a una

Máquina de Transporte. Estas relaciones son inversas a las relaciones Esta_conectada_en_ejeX+ y Esta_conectada_en_eje_X- respectivamente.

Además, estas relaciones son funcionales, es decir, que solo pueden tener como máximo un valor por relación, e irreflexivas, ya que una máquina no puede estar conectada a sí misma.


Figura 5.6 Relaciones binaria de las Cintas Transportadoras.

Tabla 5.4 Definición de relacionas binarias para las Cintas

Transportadoras.

Las Mesas de Giro son Máquinas de Transporte que pueden estar conectadas con hasta cuatro máquinas (Figura 5.7), además de cumplir la función de cinta transportadora, pueden girar sobre su eje y estar conectadas a otras dos máquinas. Así, además de extender las

propiedades de Tiene_conexion_ejeX+, Tiene_conexion_ejeX-,

Sintaxis Funcional Declaration (ObjectProperty(Tiene_conexion_ejeX+)) SubObjectPropertyOf(:Tiene_conexion_ejeX+ :Tiene_co nexion) Declaration (ObjectProperty(Tiene_conexion_ejeX-)) SubObjectPropertyOf(:Tiene_conexión_ejeX- :Tiene_co nexion) Declaration (ObjectProperty(Esta_conectada_en_ejeX+ )) SubObjectPropertyOf(:Esta_conectada_ejeX+ :Esta_con ectada) Declaration (ObjectProperty(Esta_conectada_en_ejeX- )) ObjectPropertyDomain(:Tiene_conexion_ejeX+ :Cinta_t ransportadora) ObjectPropertyRange(:Tiene_conexion_ejeX- :Máquina_ transporte ) FunctionalObjectProperty(:Tiene_conexion_ejeX+) IrreflexiveObjectProerty(:Tiene_conexion_ejeX+) InverseObjectPropert(:Tiene_conexion_eje_X+ :Esta_conectada_en_ejeX+) ObjectPropertyDomain(:Tiene_conexion_ejeX- :Cinta_t ransportadora) ObjectPropertyRange(:Tiene_conexion_ejeX- :Máquina_ transporte ) FunctionalObjectProperty(:Tiene_conexion_ejeX-) IrreflexiveObjectProerty(:Tiene_conexion_ejeX-) InverseObjectPropert(:Tiene_conexion_eje_X- :Esta_conectada_en_ejeX-) ObjectPropertyDomain(:Esta_conectada_en_ejeX+ :Máqu ina_transporte) ObjectPropertyRange(:Esta_conectada_en_ejeX+ :Cinta_transportadora) IrreflexiveObjectProerty(:Esta_conectada_en_ejeX+) InverseObjectPropert(:Esta_conectada_en_ejeX+ :Tiene_conexion_eje_X+) ObjectPropertyDomain(:Esta_conectada_en_ejeX- :Máqu ina_transporte) ObjectPropertyRange(:Esta_conectada_en_ejeX- :Cinta_transportadora) IrreflexiveObjectProerty(:Esta_conectada_en_ejeX-) InverseObjectPropert(:Esta_conectada_en_ejeX- :Tiene_conexión_eje_X-)


Esta_conectada_en_ejeX+, Esta_conectada_en_ejeX+. Tiene las relaciones de estar conectadas por el eje Y, estas relaciones tienen las mismas características.

Los Raíles de Carga, Figura 5.8, al contrario de las Mesas de Giro y

Cintas Transportadoras tienen la capacidad de desplazarse entre diferentes líneas de Máquinas de Transporte. Por este motivo se toma como referencia su posición respecto a los ejes X e Y conjuntamente. Estas propiedades, al igual que las anteriores son irreflexivas, ya que

una máquina no puede estar conectada a sí mismo, funcionales, ya que solo puede estar conectada a una máquina de transporte.

Dentro del Nivel de Planta, las Máquinas de Transporte son las encargadas de mover las materias a procesar entre las diferentes máquinas de transformación de materia, que son, al fin y al cabo, las que realizan las actividades que trasforman una materia prima en un

producto procesado. Por ello, existe una relación binaria entre las Máquinas de Transporte y las Máquinas de Procesado. Concretamente una Máquinas de Procesado se encuentra asociada a una Máquina de

Transporte concreta, que será el destino de la materia para que pueda

ser procesada.

Figura 5.7 Relaciones binarias de las Mesas de Giro.


Figura 5.8 Relaciones binarias del Raíl de Carga

Figura 5.9 Relación entre Máquina de Transporte y Máquina de

Procesado. Las Máquinas Herramienta tienen asociada un único tipo de Herramienta, mientras que las Máquinas Multi Herramienta pueden tener

asociadas más de una herramienta, tal como se ve en la Figura 5.10 a y b respectivamente.

Figura 5.10 Relaciones de la Máquina Herramienta (a) y Máquina Multi

Herramienta (b).

De este modo, una Máquina Herramienta tiene una sola Herramienta y esa Herramienta está solo en una máquina. Por el contrario, una Máquina Multi Herramienta usa varias Herramientas, cada una de esas

herramientas es usada por una sola máquina, tal como se ve en la Tabla 5.5.


Tabla 5.5 Definición de propiedades de objeto entre Herramientas y Máquinas Herramienta.

Sintaxis Funcional Declaration(ObjectProperty(:Tiene)) ObjectPropertyDomain(:Tiene :Máquina_herramienta) ObjectPropertyRange(:Tiene :Herramienta) FuntionalObjectProperty(:Tiene) Declaration(ObjectProperty(:Esta_en)) ObjectPropertyDomain(:Esta_en :Herramienta) ObjectPropertyRange(:Esta_en :Máquina_herramienta) FuntionalObjectProperty(:Esta_en) InverseObjectProperty(:Tiene :Esta_en) Daclaration(ObjectProperty(:Usa)) ObjectPropertyDomain(:Usa :Máquina_multiherramienta ) ObjectPropertyRange(:Usa :Herramienta) Declaration(ObjectProperty(:Es_usada)) ObjectPropertyDomain(:Es_usada :Herramienta) ObjectPropertyRange(:Es_usada :Máquina_Multi_Herram ienta) InverseObjectProperty(:Usa :Es_usada)

Una Herramienta puede procesar diversos tipos de Materiales. Sin embargo, puede que no sea aconsejable su uso con otros materiales, ya sea por la integridad de la herramienta o por las características físicas

del material. Por ejemplo, difícilmente una herramienta de corte como una sierra dentada metálica podría cortar un delicado cristal sin quebrarlo.

Figura 5.11 Relaciones entre los conceptos Herramientas y Materiales. A su vez, una Materia puede Estar Compuesta de uno o varios materiales. Del mismo modo, un material puede formar parte de una o

más Materia.

Figura 5.12 Relaciones ente los conceptos Materia y Material. Una Materia se puede encontrar situada en alguna Máquina de

Transporte de transporte de la fábrica en un momento determinado. Una


materia solo se puede encontrar en una máquina de transporte a la vez, y una máquina de transporte solo puede tener una materia.

Figura 5.13 Relación binaria entre los conceptos Máquinas de Transporte y Materia.

Las propiedades conceptualizadas en la ontología permiten definir la información básica del dominio industrial. A partir de estas propiedades se pueden definir una serie de reglas lógicas que permitan inferir nueva

información para dar una visión más completa del dominio industrial. Gracias a estas reglas, y al conocimiento inferido a partir de ellas, se pueden automatizar ciertas labores en la composición de los procesos productivos ya que suplen, en parte, la información que conoce el

ingeniero de procesos experto en el dominio.

Las reglas lógicas se definen en base a Lógica Descriptiva (Description

Logic). Para definir las reglas, además de las tablas con la especificación definida de acuerdo a la metodología, se utiliza la sintaxis definida por el W3C (Bock et al., 2012).

Las reglas se componen de dos partes, por un lado lo que se denomina cuerpo, también llamado antecedente, y lo que se denomina cabecera o consecuente. Cuando el cuerpo es cierto, entonces, la cabecera también lo es.

La primera regla definida está orientada a establecer una propiedad que identifique entre qué máquinas existe un posible camino y entre cuáles no. Para ello se define una propiedad de objeto Hay_camino_entre. Esta

propiedad es transitiva, es decir que si hay camino ente una máquina M1 y una máquina M2, y entre ente la máquina M2 y otra máquina M3. Entonces hay camino también entre M1 y M3.

Tabla 5.6 Definición de propiedad hay_camino_entre Máquinas de

Transporte.

Sintaxis Funcional Declaration(ObjectProperty(Hay_camino_entre)) ObjectPropertyRange(:Hay_camino_entre :Máquina_de_t ransporte) ObjectPropertyDomain(:Hay_camino_entre :Máquina__de _transporte) TransitiveObjectProperty(:Hay_camino_entre) IrreflexiveObjectProperty(:Hay_camino_entre)


La regla definida específica que si una Máquina de Transporte Tiene_conexión con otra y esta otra Tiene_conexión con una tercera

entonces hay un camino entre la primera máquina y la tercera, tal como se define en la Tabla 5.7.

Máquina_de_transporte(?x), Máquina_de_transporte(?y),

Máquina_de_transporte(?z), Tiene_conexion(?x,?y),

Tiene_conexion(?y,?z), DifferentIndividuals(?x,?y?z) �

Hay_camino_entre(?x,?z)

Tabla 5.7 Definición de regla que establece caminos entre máquinas.

Sintaxis Funcional Prefix(var:=<urn:swrl#>) DLSafeRule( Annotation(rdfs:comment “Regla Hay_camino_entre”) Body( ClassAtom( :Máquina_transporte Variable(var:x ) ) ClassAtom( :Máquina_transporte Variable(var:y ) ) ClassAtom( :Máquina_transporte Variable(var:z ) ) ObjectPropertyAtom( :Tiene_conexion Variable(var :x) Variable(var:y)) ObjectPropertyAtom( :Tiene_conexion Variable(var :y) Variable(var:z)) DifferentInstanceAtom(Variable(var:x) Variable(v ar:y) Variable(var:z) ) ) Head( ObjectPropertyAtom(:Hay_camino_entre Variable(va r:x) Variable(var:y)) ) )

El concepto Materia también tiene una serie de restricciones en el mundo real que modelan el comportamiento del entorno. Así, una Herramienta para cortar un Material no puede procesar una Materia que

esté compuesta de otro Material, o una Máquina de Transporte no puede transportar a la vez más de una materia sin que colisionen. Estas restricciones, aunque simples en sí mismas, son necesarias explicitarlas para poder cubrir mediante posteriores razonamientos parte del

conocimiento que hoy en día aportan los ingenieros de procesos industriales.

Según las relaciones binarias ilustradas en la Figura 5.11 y Figura 5.12

entre las Herramientas y los Materiales, y los Materiales y las Materias respectivamente, existe una relación entre las Herramientas y la Materia. De esta forma, una Herramienta sólo puede procesar Materias que estén


compuestas de algún Material que pueda procesar. Por materia se entiende una pieza en proceso de fabricación y por material un componente físico.

Se declara una propiedad de objeto denominada Puede_procesar, donde se declara que una Herramienta (dominio) puede procesar una Materia

(rango).

Tabla 5.8 Definición de propiedad Puede_procesar entre Herramientas y

Materias.

Sintaxis Funcional Declaration(ObjectProperty(Puede_procesar)) ObjectPropertyRange(:Puede_procesar :Herramienta) ObjectPropertyDomain(:Puede_procesar :Materia) IrreflexiveObjectProperty(:Puede_procesar)

Y la regla establece qué Herramientas pueden procesar qué Materias en función del Material del que estén hechos.

Material(?X), Materia(?Y), Herramienta(?Z), Esta_compuesta(?X,?Y),

Transforma(?Z,?X) � Puede_procesar(?Z,?Y)

Tabla 5.9 Definición de la regla Puede_procesar.

Sintaxis Funcional Prefix(var:=<urn:swrl#>) DLSafeRule( Annotation(rdfs:comment “Regla Puede procesar”) Body( ClassAtom( :Material Variable(var:x) ) ClassAtom( :Materia Variable(var:y) ) ClassAtom( :Heramienta Variable(var:z) ) ObjectPropertyAtom( :Esta_compuesta Variable(var :x) Variable(var:y)) ObjectPropertyAtom( :Transforma Variable(var:z) Variable(var:x)) ) Head( ObjectPropertyAtom(:Puede_procesar Variable(var: z) Variable(var:y)) ) )

De esta regla se puede extender (Tabla 5.10, Figura 5.11) que una Máquina Herramienta que tiene conectada una Herramienta que puede procesar una Materia, procesa la Materia siempre y cuando esté_situada en una Cinta Transportadora que esté conectada a la Máquina de

Procesado. Una regla más compleja que las anteriores, pero que sin


embargo está construida a partir de las relaciones binarias construidas anteriormente.

Herramienta(?X), Máquina_herramienta(?Y), Materia(?Z),

Máquina_de_transporte(?I), Puede_procesar(?X,?Z),

Esta_situada(?Z,?I), Esta_asociada(?Y,?I) ,Tiene(?Y,?X) �

Procesa(?Y,?Z)

Tabla 5.10 Regla que establece las condiciones para Procesar de las maquinas herramienta.

Sintaxis Funcional Prefix(var:=<urn:swrl#>) DLSafeRule( Annotation(rdfs:comment “Regla Procesa”) Body( ClassAtom( :Herramienta Variable(var:x) ) ClassAtom( :Máquina_herramienta Variable(var: y) ) ClassAtom( :Materia Variable(var:z) ) ClassAtom( :Máquina_de_transporte Variable(va r:i) ) ObjectPropertyAtom( :Puede_procesar Variable(var :x) Variable(var:z)) ObjectPropertyAtom( :Esta_situada Variable(var:z ) Variable(var:i)) ObjectPropertyAtom( :Esta_asociada Variable(var: y) Variable(var:i)) ObjectPropertyAtom( :Tiene Variable(var:x) Varia ble(var:y)) ) Head( ObjectPropertyAtom(:Procesa Variable(var:y) Vari able(var:z)) ) )

También las Máquinas Multi Herramienta deben cumplir condiciones similares para procesar Materias (Tabla 5.11).

Herramienta(?X), Máquina_multi_herramienta(?Y), Materia(?Z),

Máquina_de_transporte(?I), Puede_procesar(?X,?Z),

Esta_situada(?Z,?I), Esta_asociada(?Y,?I) , Usa(?Y,?X) �

Procesa(?Y,?Z)

Tabla 5.11 Regla que establece las condiciones para procesar de las

Máquinas Multi Herramienta.

Sintaxis Funcional Prefix(var:=<urn:swrl#>) DLSafeRule( Annotation(rdfs:comment “Regla Procesa”) Body( ClassAtom( :Herramienta Variable(var:x) )


ClassAtom( :Máquina_multi_herramienta Variabl e(var:y) ) ClassAtom( :Materia Variable(var:z) ) ClassAtom( :Máquina_de_transporte Variable(va r:i) ) ObjectPropertyAtom( :Puede_procesar Variable(var :x) Variable(var:z)) ObjectPropertyAtom( :Esta_situada Variable(var:z ) Variable(var:i)) ObjectPropertyAtom( :Esta_asociada Variable(var: y) Variable(var:i)) ObjectPropertyAtom( :Usa Variable(var:x) Variabl e(var:y)) ) Head( ObjectPropertyAtom(:Procesa Variable(var:y) Vari able(var:z)) ) )

5.1.2 Conceptualización del Nivel de Procesos

El segundo ángulo que compone la ontología es el Nivel de Procesos. En este nivel se hace referencia a los conceptos relacionados con los

procesos productivos en sí.

El paradigma BPM establece una clasificación de los procesos en función de su complejidad. Un proceso es un conjunto de tareas que se realizan

de forma conjunta, mientras que se considera una actividad a una tarea que no puede ser dividida en otras más pequeñas. El hecho de no dividir una actividad en otra no es porque sea imposible fraccionar la tarea, sino porque dividir esta tarea no aporta ningún valor añadido al ciclo

productivo.

Tal como se refleja en (Gilart, 2010) y se ha visto durante el capítulo 3

(Figura 3.2), los procesos se pueden clasificar en Proceso de Negocio, Subproceso de Negocio o Actividad en función de su composición. Además, estos procesos son medidos por un concepto denominado Punto de Inspección KPI, el cual ofrece indicadores para comprobar el correcto

desarrollo de los procesos.

Un Proceso de Negocio y un Subproceso de Negocio se podrían considerar

como el mismo concepto desde un punto de vista funcional, con la salvedad que un subproceso forma parte de un proceso de nivel superior. Gracias a la expresividad que permiten las ontologías se identificará si un proceso es subproceso mediante el uso de reglas que determinen si

forma parte de otro proceso o no, y por lo tanto, esta clase no se alimentara de manera automática.


En la ontología se definen dos conceptos básicos como son los Procesos y las Actividades. Un proceso está compuesto como mínimo de una

Actividad. A su vez, un proceso puede formar parte de otro Proceso, si se diera este caso entonces se entiende que el primer proceso es, a su vez, un Subprocesos del segundo. Es decir, que un proceso puede ser a su vez subproceso si forma parte de un proceso más complejo.

El nivel de proceso se encuentra compuesto por los conceptos Actividad, Proceso y Subproceso y KPI (Key Performance Indicator)

De estos cuatro conceptos, el concepto Proceso representa a un conjunto de acciones que juntas logran algún objetivo de negocio. El concepto

Subproceso es un conjunto de acciones que junto a otras acciones componen un proceso. El concepto Actividad representa aquella acción indivisible por no aportar un valor añadido su división en más tareas. El concepto de KPI representa lo que se denomina Indicadores Clave de

Desempeño, que miden la correcta ejecución de los procesos en base a los objetivos fijados.

Tabla 5.12 Declaración de las clases Proceso, SubProceso y Actividad.

Sintaxis Funcional Declaration(Class(Processo)) Declaration(Class(SubProceso)) Declaration(Class(Actividad)) Declaration(Class(KPI)) DisjointClasses(KPI,Proceso) DisjointClasses(KPI,SubProceso) DisjointClasses(KPI,Actividad) DisjointClasses(KPI,Materia,Maquinaria_insutrial,Ma terial,Herramienta) DisjointClasses(Proceso, Materia,Maquinaria_insutrial,Material,Herramienta) DisjointClasses(SubProceso, Materia,Maquinaria_insutrial,Material,Herramienta) DisjointClasses(Actividar, Materia,Maquinaria_insutrial,Material,Herramienta)

Estos conceptos disponen de una serie de propiedades de dato que complementan la información referente a cada uno de los conceptos. Como se define en la Tabla 5.13, cada Proceso tiene una propiedad denominada secuencia, que indica la posición del proceso o actividad

dentro de otro proceso. Un Proceso está compuesto de Actividades que se pueden desarrollar secuencialmente o en paralelo, la propiedad denominada pasos indica el número máximo de actividades secuenciales

que se ejecutan. La propiedad tiempo ejecución hace referencia al tiempo de ejecución aproximado que tardaría en completarse un proceso. La


propiedad consumo eléctrico hace referencia a la potencia consumida durante el desarrollo de un proceso. Esta última propiedad ya está definida para las máquinas industriales, aunque también se asocia a la

ejecución de un proceso por aportar información más detallada.

Tabla 5.13 Declaración de las propiedades de las clases del Nivel de

Negocio.

Sintaxis Funcional Declaration(DataProperty(Secuencia)) Declaration(DataProperty(Pasos)) Declaration(DataProperty(Tiempo_ejecución)) Declaration(DataProperty(Consumo_eléctrico)) DataPropertyDomain(:Secuencia :Actividad) DataPropertyRange(:Secuencia xsd:integer) DataMaxCardinality(1 :Secuencia) DataPropertyDomain(:Pasos :Proceso) DataPropertyRange(:Pasos xsd:integer) DataMaxCardinality(1 :Pasos) DataPropertyDomain(:Tiempo_ejecución :Actividad) DataPropertyRange(:Tiempo_ejecución xsd:float) DataMaxCardinality(1 :Tiempo_ejecución) DataPropertyDomain(:Consumo_electirco :Actividad)

Las propiedades de objeto, o relaciones de los conceptos, vienen definidas por la clasificación estudiada en los antecedentes en la Figura

3.2. Así, la propiedad Compuesto indica si un Proceso, Subproceso o Actividad está compuesto de más Subprocesos o Actividades. Además, esta propiedad de objeto tiene las características de ser Transitiva e

Irreflexiva, ya que un proceso no puede estar compuesto por sí mismo y, a su vez, si un primer proceso está compuesto por un segundo proceso y este segundo proceso está compuesto por un tercer proceso, el primero también está compuesto por el tercero. Y su propiedad Inversa, que

establece qué Actividades o Subprocesos forman parte de un proceso de nivel superior.

Tabla 5.14 Declaración de relaciones entre clases.

Sintaxis Funcional Declaration(ObjectProperty(Compuesto)) ObjectPropertyDomain(:Compuesto :Proceso) ObjectPropertyDomain(:Compuesto :Subproceso) ObjectPropertyRange(:Compuesto :Actividad) ObjectPropertyRange(:Compuesto : SubProceso) IrreflexiveObjectProperty(:Compuesto) AsymmetricObjectProperty(:Compuesto) TransitiveObjectProperty(:Compuesto) Declaration(ObjectProperty(Forma_parte)) ObjectPropertyDomain(:Forma_parte :Actividad) ObjectPropertyDomain(:Forma_parte :Subproceso)


ObjectPropertyRange(:Forma_parte :Proceso) ObjectPropertyRange(:Forma_parte :SubProceso) IrreflexiveObjectProperty(:Forma_parte) AsymmetricObjectProperty(:Forma_parte) TransitiveObjectProperty(:Forma_parte) InverseObjectProperties(:Compuesto :Forma_parte)

Un Proceso está compuesto por Actividades. Estas Actividades tienen un orden determinado, por lo que existen relaciones entre ellas. Una Actividad es predecesora de otras si está situada justo antes de otra Actividad en la composición de un Proceso (Tabla 5.15). Inversamente

una Actividad es sucesora de otra si está situada antes. Sin embargo una Actividad puede aparecer varias veces en la composición de un proceso, por lo que no se puede descartar que una actividad sea

predecesora de sí misma, en el caso por ejemplo que se desarrolle dicha actividad más de una vez.

Tabla 5.15 Declaración de la relación Precede entre actividades.

Sintaxis Funcional Declaration(ObjectProperty(Precede)) ObjectPropertyDomain(:Precede :Actividad) ObjectPropertyRange(:Precede :Actividad) Declaration(ObjectProperty(Sucede)) ObjectPropertyDomain(:Sucede :Actividad) ObjectPropertyRange(:Sucede :Actividad) TransitiveObjectProperty(:Precede) TransitiveObjectProperty(:Sucede) InverseObjectProperties(:Sucede :Precede)

Otra de las propiedades de objeto que se establece en la Tabla 5.16 es la que establece que un KPI mide un Proceso, Subproceso o Actividad, y por lo tanto también se establece la propiedad inversa, de que un Proceso, Actividad o Subproceso, es_medido por un KPI.

Tabla 5.16 Relaciones entre KPI y Procesos, Subprocesos y Actividades.

Sintaxis Funcional Declaration(ObjectProperty(Mide)) ObjectpropertyDomain(:Mide :KPI) ObjectPropertyRange(:Mide :Actividad) ObjectPropertyRange(:Mide :Proceso) ObjectPropertyRange(:Mide :Subproceso) Declaration(ObjectProperty(Es_medido) ObjectPropertyDomain(:Es_medido :Actividad) ObjectPropertyDomain(:Es_medido :Proceso) ObjectPropertyDomain(:Es_medido :SubProceso) ObjectPropertyRange(:Es_medido :KPI) InverseObjectProperties(:Mide :Es_medido)


Además de la clasificación de los procesos en función de su composición, se pueden clasificar en función de su naturaleza. En la literatura especializada, una de las clasificaciones más comunes de los procesos es

en función del tipo de acción que desarrollan. En (Groover, 2000) se clasifican los procesos en cinco grandes grupos. Procesos de ensamblaje , Procesado, Manejo de Materia, Inspección y Test, y finalmente,

Coordinación y Control.

Figura 5.14 Clasificación de los Procesos.

Dentro de los procesos de Procesado, Figura 5.15, se pueden encontrar los Procesos de Solidificación, como procesos de Moldeado para plásticos y vidrio o de Fundido para metales. Otro de los tipos de operaciones de

procesado son las de Procesado de Partículas, como las operaciones de Prensado o Fusionado. Los procesos de Deformación como Forja, Extrusión (estirado a presión), Laminación, Formado, Doblado.

Finalmente los procesos de Eliminación de Materia como Torneado, Taladrado, Fresado, Haz laser, Erosión Química, Energía Electroquímica.

Figura 5.15 Detalle de los procesos de Procesado.


Las operaciones de Ensamblaje, consisten en unir dos o más piezas de manera que formen una nueva entidad. Las operaciones se clasifican en función de si el ensamblado es Permanente o Semipermanente. Entre las

operaciones de ensamblado permanente se encuentran Remachado, Fusionado, Soldadura y Pegado. Entre las operaciones Semipermanentes se encuentran el atornillado, el enroscado y la unión

por presión.

Figura 5.16 Procesos de Ensamblaje.

Los Procesos de Manipulación de materia, Figura 5.17, son de los más usados en los procesos de fabricación, de hecho, se estima (Groover, 2000) que el 95% del tiempo que tarda en ejecutarse un proceso se

están llevando a cabo tareas de Manipulación de Materia. Es difícil clasificar en tipos de operaciones estos procesos, ya que dependen mucho de las máquinas que los lleven a cabo, pero se pueden clasificar

en dos grandes grupos: procesos que cruzan un elemento de transporte y procesos que transportan hasta un punto concreto de los elementos de transporte.

Figura 5.17 Procesos de Manejo de Material

Los Procesos de Inspección y Test, Figura 5.18, son los que se encargan de validar que el proceso productivo se esté llevando a cabo conforme a


las especificaciones dadas. En función del tipo de elemento que se fabrique se puede clasificar en Inspección Visual, ya sea mediante una máquina o persona, pruebas mecánicas sobre el producto, escaneado

laser, etc.

Figura 5.18 Procesos de Inspección y Test

Finalmente se encuentran los Procesos de Coordinación y Control. Las actividades de control implican el control de la ejecución en función de los parámetros y objetivos especificados. El control implica el

mantenimiento de equipos, el control de inventario, control de costes, etc.

Los Procesos son llevados a cabo por diferentes tipos de Máquinas

Industriales en función de la naturaleza tanto de los procesos como de las máquinas que los llevan a cabo. Cada tipo de máquina posee características físicas que le permiten desarrollar ciertos tipos de procesos u actividades. Así, por ejemplo, las Máquinas de Transporte

realizan Procesos de Manejo de Materia.

Figura 5.19 Procesos de Coordinación y Control.

Figura 5.20 Relación binaria ente Procesos de Transporte y Máquinas de

Transporte.


Igualmente, las operaciones de transformación de materia, definidas en la ontología como Procesos de Procesado y Ensamblaje, son implementadas por las Máquinas de Procesado, ya que son las únicas

que tienen una configuración Hardware que permita desarrollar estas actividades.

Figura 5.21 Relación entre los conceptos Procesado y Máquinas de

Procesado. Los Procesos de Almacenaje se realizan por las Máquinas de Almacenaje.

Figura 5.22 Relación entre la Máquina de Almacenaje y los procesos de

Almacenaje. Las relaciones binarias enumeradas hasta el momento se extienden

mediante reglas que permiten modelar relaciones más complejas dentro del dominio de la gestión de procesos, permitiendo posteriormente, mediante inferencias, disponer de información más detallada acerca de los procesos y sus relaciones semánticas con el nivel de planta.

La primera regla definida está orientada a especificar las restricciones conceptuales propias del dominio industrial dentro del marco de la gestión de procesos de negocio BPM. Así, dentro de un proceso se

pueden ejecutar actividades de forma paralela o secuencial. Sin embargo, existe una serie de restricciones físicas y conceptuales propias del dominio industrial que limitan el diseño de procesos. Por ejemplo, una máquina no puede trasportar dos materias a la vez. Mientras que en

el desarrollo de procesos de forma manual, es el conocimiento del ingeniero de procesos el que establece el flujo de ejecución y las incompatibilidades en función del conocimiento que posee sobre el nivel de planta, en un sistema automatizado, estas restricciones deben ser

especificadas.

En la ontología propuesta se modela un comportamiento específico ante unas determinadas circunstancias. Pero es importante destacar que este


comportamiento no necesariamente es universal, sino que viene determinado por la aplicación concreta que se le vaya a dar a la ontología.

Como uno de los objetivos del presente trabajo es lograr la automatización en la composición de procesos, se modela una serie de características entre los procesos y las máquinas que los implementan

que permiten detectar colisiones o bloqueos dentro del flujo de ejecución de un proceso.

Un axioma básico es que si una máquina ejecuta más de una actividad, estas actividades no se podrán realizar en paralelo, ya que, aunque el modelo conceptual de BPM lo permite, las restricciones físicas del nivel de planta no permiten que una máquina actúe sobre más de una materia

a la vez, pues esto provocaría una colisión entre las diferentes materias; o movimientos imposibles, como intentar que una cinta trasportadora moviera materias en dos direcciones a la vez. La posición de una actividad dentro de un proceso viene determinada por la propiedad del dato secuencia, explicada anteriormente, que establece en qué momento

se realiza la actividad.

Formalmente se define mediante dos reglas en función de la naturaleza

del Proceso o de la máquina que lo ejecuta. Si una Máquina de Procesado M1 implementa un Proceso P1 en una secuencia X dentro de una Actividad A1, esa misma máquina M1 no puede implementar otra

Actividad A2 cuya secuencia sea X dentro del mismo proceso P1.

Máquina_de_procesado(?m1), Proceso(?p1), Actividad(?a1),

Actividad(?a2), Integer(?x), Integer(?y) Secuencia(?a1 ?x),

Secuencia(?a2,?y), Compuesto (?p1,?a1), Compuesto(?p1,?a2),

Implementa(?m1,?a1), Implementa(?m1,?a2) � Different(?x,?y)

Tabla 5.17 Especificación de restricción sobre concurrencia de Actividades.

Sintaxis Funcional DLSafeRule( Anotation(rdfs:comment “Control de Concurrencia so bre una máquina”) Body( ClassAtom(:Máquina_de_procesado Variable(var:m1) ) ClassAtom(:Proceso Variable(var:p1)) ClassAtom(:Actividad Variable(var:a1)) ClassAtom(:Actividad Variable(var:a2)) DataRangeAtom(xsd:integer Variable(var:x)) DataRangeAtom(xsd:integer Variable(var:x)) DataPropertyAtom(:Secuencia Variable(var:x)) DataPropertyAtom(:Secuencia Variable(var:a1) Var iable(var:x))


DataPropertyAtom(:Secuencia Variable(var:a2) Var iable(var:y)) DataPropertyAtom(:Compuesto Variable(var:p1) Var iable(var:a1)) DataPropertyAtom(:Compuesto Variable(var:p1) Var iable(var:a2)) DataPropertyAtom(:Implementa Variable(var:m1) Va riable(var:a1)) DataPropertyAtom(:implementa Variable(var:m1) Va riable(var:a2)) ) Head ( DifferentFrom(?x,?y) ) )

La regla anterior permite controlar la concurrencia dentro de un proceso concreto de fabricación. Sin embargo, conceptualmente en el modelo BPM es posible ejecutar en paralelo procesos, por lo que en un entorno industrial se deberá restringir esta opción para controlar la concurrencia

sobre cada máquina. Todos los procesos concurrentes dentro de una fábrica, se conceptualizaran como un único proceso de flujos paralelos, ya que permitirá seguir manteniendo el control sobre los procesos de manera centralizada.

5.1.3 Conceptualización del Nivel de Servicios

El último conjunto de conceptos introducidos en la ontología está relacionado con la parte más tecnológica de los procesos de fabricación, el nivel de Servicios.

La propuesta de IMaaS (Industrial Machine as a Service), tal como se ha visto en el capítulo 3, permite la integración de los elementos de fabricación dentro de los sistemas de gestión de negocio gracias a que la maquinaria es capaz de ofrecer sus funcionalidades como Servicio.

El conceptualizar la información de los servicios que ofrece la maquinaria permite unir el nivel tecnológico con el nivel de negocio a través de las relaciones entre servicios y procesos y el nivel de servicios

con el nivel físico para poner en contexto cada servicio físicamente donde se desarrolla y qué consecuencias tiene.

Gracias a esta información se establecen relaciones entre los conceptos

de fabricación y las tecnologías que los sustentan y, en consecuencia, se puede automatizar el proceso de traducción de un modelo de proceso de fabricación conceptual a una implementación concreta que pueda ser ejecutada por un motor de ejecución de servicios y, de esta manera, ser

ejecutada en una fábrica. Por ello, se conceptualiza un conjunto de información que permita el descubrimiento y contextualización de los

servicios durante el desarrollo del proceso de compilación ��.


La conceptualización del nivel tecnológico viene marcada por los escenarios en los que se vaya a utilizar el sistema propuesto. En el caso concreto de esta tesis, se ha optado por un Nivel Tecnológico basado en

servicios ya que, como se ha visto en el estado del arte y los antecedentes, permite una fácil integración en los sistemas BPM (Gilart, 2010). Sin embargo, que en la presente ontología se conceptualice exclusivamente una tecnología basada en servicios no excluye que en un

futuro pueda extenderse o unirse a otras ontologías para cubrir otras tecnologías que puedan estar presentes en el Nivel de Planta.

Los conceptos principales que se pueden encontrar, hablando de Servicios Web, están relacionados con: el direccionamiento de los servicios, los parámetros de entrada y de salida, los tipos de datos que manejan, los tipos de servicio, etc. Esta información se encuentra

habitualmente en los servidores de publicación como pueden ser los servidores UDDI (UDDI, 2005) o en la descripción de los servicios como en las hojas WSDL (Christensen et al., 2001). Sin embargo, el establecer una descripción semántica de los servicios permite contextualizar los

parámetros, el proveedor de servicios, las circunstancias que se deben cumplir para que se pueda invocar un servicio o las consecuencias que tiene su ejecución. El motivo de introducir esta información en la ontología no es el remplazar los estándares actuales de descripción de

Servicios Web, sino complementarlos para poder establecer relaciones entre los servicios y los procesos. Además, se establece una relación que identifica que tipo de máquina ejecuta cada uno de los servicios, de esta forma se dispone de la información tecnológica relacionada con el entorno físico y conceptual.

La información de los servicios en la ontología se complementa con la descripción semántica de cada servicio, basada en la ontología de

servicios recomendación del W3C OWL-S (OWL-S, 2004). OWL-S permite especificar para cada servicio qué hace, cómo lo hace y cómo se accede a él.

La conceptualización de los servicios se define en función de la clasificación propuesta en IMaaS (Gilart, 2010), tal como se muestra en la Figura 5.23. Como ya se ha estudiado en los antecedentes, está basada en el patrón arquitectónico Service Layer propuesto en (Erl,

2005). Dicho patrón define una serie de capas funcionales que clasifica los diferentes tipos de servicios en el modelo SOA. Se definen por lo tanto los tipos de servicio de aplicación, negocio, orquestación e infraestructura (Figura 3.8)


Figura 5.23 Taxonomía de la clase Servicio.

Las propiedades de objeto que se definen sobre los servicios, están orientadas a por un lado establecer la relación entre el servicio y el

mundo físico, indicando qué máquina industrial ejecuta qué servicio o especificando qué servicio se corresponde con la implementación de que proceso. Un Servicio tiene asociada una WSDL con las especificaciones de los servicios. Un Servicio también tiene una URL con su descripción

semántica. Además un Servicio puede ser ofertado por una Máquina

Industrial concreta. A su vez, una Máquina Industrial puede ofrecer varios servicios. Y un Servicio ejecuta un Proceso determinado, de

manera inversa un Proceso es ejecutado por un Servicio tal como se muestra en la Tabla 5.18.

Tabla 5.18 Definición de las propiedades de la clase Servicio.

Sintaxis Funcional Declaration (DataProperty(:wdsl)) DataPropertyDomain(:wdsl :Servicio) DataPropertyRange(:wsdl xsd:anyURI) Declaration (DataProperty(:url)) DataPropertyDomain(:url:Servicio) DataPropertyRange(:url xsd:anyURI) Delcaration( ObjectProperty(:máquina_ofrece_servici o) ) ObjectPropertyDomain(:máquina_ofrece_servicio :Maquinaria_industrial) ObjectPropertyRange(:máquina_ofrece_servicio :Servi cio) Declaration(ObjectProperty(:Ejecuta)) Declaration(ObjectProperty(:Es_ejecutado))


ObjectPropertyDomain(:Ejecuta :Servicio) ObjectPropertyRange(:Ejecuta :Proceso) ObjectPropertyDomain(:Es_ejecutado :Proceso) ObjectPropertyRange(:Es_ejecutado :Servicio) InferseObectProperties(:Ejecuta : Es_ejecutado) FunctionalObjectProperty(Ejecuta) FunctionalObjectProperty(Es_ejecutado)

5.2 Normalización y Conceptualización de los procesos BPMN El ciclo de vida BPM, como ya se ha estudiado, se compone de diferentes fases. La fase de modelado consiste en el desarrollo del proceso desde un punto de vista conceptual. El modelado se suele establecer de acuerdo

con el estándar de representación de procesos BPMN (BPMN, 2008). Sin embargo, aunque este estándar establece la notación gráfica de la etapa de modelado, no existe una normalización de cómo representar estos procesos desde un punto de vista de que sean entendibles para las

máquinas y cada fabricante establece su propio lenguaje de forma que se limita el uso del proceso a una herramienta determinada.

Para integrar la representación del proceso con las restricciones del

dominio y para normalizar la conceptualización de los procesos se propone el uso de una ontología de procesos BPM. La elección de una ontología como forma de representación se basa en las múltiples ventajas que ofrece:

• Una ontología permite guardar la información referente a un

proceso de negocio de forma independiente a la herramienta en la que haya sido implementado.

• La ontología que contiene la información del proceso puede ser

conectada con la ontología diseñada en el presente capítulo

para trabajar de forma conjunta con los conceptos y restricciones de BPM y del entorno de fabricación.

• Gracias a las reglas definidas en las ontologías se puede saber

rápidamente si un proceso es consistente, es decir, si cumple con todos los requisitos necesarios.

• Permite representar la información de una forma comúnmente

aceptada, tal como se recoge en la propia definición de

ontología.


Durante el Proceso de Normalización de Procesos ��, se recibe

como entrada un Proceso Funcional de forma gráfica, y en base a una ontología que conceptualiza los conceptos de BPM BPMN89:;, lo traduce

a una ontología en la cual quede reflejada toda la información referente al Proceso Funcional denominada BPMN?9:;,. Para conseguir esta

traducción, el proceso �� se divide en tres actividades

diferenciadas: en una primera actividad se define una ontología que contiene la conceptualización de los elementos implicados en los procesos de negocioBPMN89:;; en la segunda actividad se define las

reglas que hace que un proceso sea valido mas allá de la representación gráfica; y la tercera actividad, se define desde un punto de vista

funcional el mecanismo para traducir un Proceso Funcional a una

ontología BPMN?9:; que pueda ser usada en procesos de inferencia.

5.2.1 Representación de Conceptos BPM

La representación de procesos de negocio de forma gráfica es una forma sencilla y rápida de ver como se estructura un proceso de negocio. Sin embargo, la aparición de diversas notaciones gráficas orientadas a representar los mismos conceptos hace que se pierda, en cierto modo, la

legibilidad de los diagramas, y sea necesario conocer la notación exacta en cada representación. Como forma de unificar la representación gráfica y la expresividad de la notación gráfica de BPM, surgió el estándar BPMN de OMG (BPMN, 2008). En este estándar se recogen que elementos gráficos se corresponden con que conceptos. Se basa en clasificar los

elementos en cuatro grupos. Los objetos de flujo (Flow Objects), los objetos de conexión (Connecting Objects), los swimlanes, los Artefactos

(Artifacts). Los objetos de flujo, se clasifican a su vez en Eventos (Events),

Actividades (Activity) y “Puertas” (Gateways). Los eventos son aquellos objetos que indican el inicio, el fin y los acontecimientos en el flujo. Las actividades se corresponden con las tareas a desarrollar en el flujo y los Gateways son aquellos elementos que indican modificaciones en el flujo,

como condiciones, bifurcaciones, etc. En la Figura 5.24 se muestra la notación gráfica de cada elemento.

Dentro de los objetos de conexión, los objetos de secuencia de flujo (Sequence Flow) se usan para identificar el orden el que deben realizarse las actividades. Los mensajes (Message Flow) se usan para ver el flujo de mensajes entre dos participantes. Las asociaciones se usan para unir

información a objetos de flujo, tal como se muestra en la Figura 5.25.


Dentro de los Swimlane se encuentra los denominados Pool. Cada Pool representa a un participante en un proceso. Los Lanes son

subparticiones dentro de un Pool. Los lanes se utilizan para organizar y categorizar actividades dentro de un participante.

Figura 5.24 Ejemplos de objetos de flujo en notación BPMN. Eventos (a),

Actividades (b) y Gateways (c).

Figura 5.25 Ejemplos de objetos de conexión. Secuencias de flujo (a),

Mensajes de flujo (b) y u Asociaciones (c).

Por último, los Artefactos son objetos que no tienen un efecto directo sobre el flujo. Los Data Object proporcionan información acerca de las

actividades. Los Grupos permiten asociar actividades de alguna forma según algún criterio, pero no afecta al flujo. Las anotaciones (Text

Anotation) permiten añadir información adicional a los diagramas.

A partir del lenguaje de representación estándar BPMN se dispone de la notación necesaria para poder representar un proceso de negocio y, por lo tanto, también un proceso de fabricación. A partir del estándar se puede establecer una taxonomía de una ontología que permita clasificar

todos los elementos que intervienen en un proceso así como su orden y restricciones.


Figura 5.26 Ejemplos de objetos Swimlane, Pool (a) y Lanes (b).

Siguiendo la metodología METHONTOLOGY se encuentra que existen propuestas para la conceptualización de BPMN, por ello para la conceptualización de los procesos nos basaremos en la ontología

BPMNOntology (Ghidini et al., 2009) que implementa el estándar BPMN de OMG (BPMN, 2008). Esta ontología ha sido desarrollada por el grupo de Gestión del conocimiento y datos de la fundación Bruno Kessler. En (Ghidini et al., 2009) se refleja de manera formal como está especificada

la ontología en Lógica Descriptiva a partir del estándar BPMN.

En esta ontología, el concepto más global es el de diagrama de proceso de negocio, implementado en la ontología como

Business_Process_Diagram. Este concepto tiene entre sus propiedades de datos el tener un identificador (has business_process_diagram_id), un nombre (has_business_ process_name), una versión

(has_business_process_version) o un autor (has_business_process_author).

Un diagrama está compuesto por un Pool como mínimo, y a su vez un Pool está compuesto por al menos un Lane. Si no se cumple esta condición, el proceso no será consistente, ya que se incumplen las

restricciones del estándar y de la ontología. Mediante propiedades de objeto se relacionan los Pools, Lanes y Diagrama. Tal como se muestra en la Tabla 5.19, un diagrama se instanciaría declarando el NamedIndividual de la clase Diagrama, Pool y Lane, y estableciendo las

relaciones entre ellos a partir de las propiedades de objeto de cada una de las clases. De forma que se establezca que un diagrama tiene un pool, y este pool a su vez está compuesto por un solo lane.

Cada Pool tiene un elemento Process asociado, un elemento Process hace referencia al conjunto de Activities, Events y Gateways que se implementan dentro de un Pool, o lo que es lo mismo, que son llevadas a

cabo por un participante en el proceso de negocio. Mediante el concepto


Process se establecen ciertas propiedades de datos como Nombre (Name), el Estado (State) que tiene [none, ready, active, cancelled, aborting,

aborted, completing, completed], el Tipo (Type) [prívate, abstract,

collaboration, condition, etc.].

Tabla 5.19 Instanciación de un diagrama BPMN en Sintaxis Funcional.

Sintaxis Funcional

Declaration ( NamedIndividual (NombreDiagrama) ) Declaration ( NamedIndividual (NombrePool) ) Declaration ( NamedIndividual (NombreLane) ) ClassAsertion(:Business_Process_Diagram :NombreDia grama) ClassAsertion(:Pool :NombrePool) ClassAsertion(:Lane :NombreLane) ObjectPropertyAsertion(:has_business_process_pool : NombreDiagrama :NombrePool) ObjectPropertyAsertion(:has_proces_lanes :NombrePoo l :NombreLane) DataPropertyAsertion(:has_business_process_diagram :NombreDiagrama :”NombreAutor”) [Resto de propiedades] DataPropertyAsertion(….)

Tabla 5.20 Declaración de propiedades de un diagrama BPMN.

Sintaxis Funcional Declaration ( NamedIndividual (NombreProcess) ) ClassAsertion(:Process :NombreDiagrama) ObjectPropertyAssertion(:has_pool_process_ref :Nomb rePool :NombreProcess ) DataPropertyAsertion(:has_process_name :NombreProce ss) DataPropertyAsertion(:has_process_type :NombreProce ss :None) DataPropertyAsertion(:has_process_status :Ready)

Un Process está compuesto, a su vez, por un conjunto de elementos

gráficos (has_process_graphical_element). Cada uno de estos elementos gráficos se puede dividir a su vez en artefactos, objetos de conexión u objetos de flujo, tal como se puede apreciar en la Figura 5.27.

La definición de estos elementos se hace desde el nivel inferior al superior, ya que por ejemplo, un Evento (Event) es un tipo específico de Objeto de Flujo (Flow_Object) y por lo tanto, también hereda sus

propiedades. La forma de instanciar la información de un proceso en la


ontología es, partiendo del concepto más especifico, establecer las propiedades de cada nivel hasta reflejar la relación del elemento gráfico con el proceso.

Figura 5.27 Taxonomía de los elementos gráficos de BPMN.

Para ello, se identifican los elementos que existen dentro de un Pool y se declaran dentro de la ontología. En primer lugar se definen los elementos clasificados como Objetos de Flujo (Flow_object) o Artefactos (Artifact)

debido a que son los nodos del diagrama. A continuación se definen los objetos de conexión (Conecting_object) que establecen mediante propiedades de objetos que objeto de flujo está conectado con que otro. O lo que es lo mismo, se conceptualizan los ejes cuando ya se han

conceptualizado los nodos ya que los nodos son independientes de los ejes, pero los ejes se conceptualizan las propiedades de objeto que los relacionan con los nodos origen y destino.

5.2.2 Validación de los Procesos BPMN

Los diagramas BPMN, como ya se ha visto en el punto 5.2.1, son una representación de un proceso en notación gráfica. Esta representación

conceptual permite reflejar no solo aspectos tecnológicos, sino que permite reflejar cualquier tipo de acción que se pueda producir en un proceso. Desde un punto de vista tecnológico, la expresividad que permite el estándar pudiera llegar a ser ambigua en algunos casos por lo

que se establecen una serie de restricciones que permitan desde una visión de negocio, especificar procesos que no comprometan la viabilidad tecnológica del mismo (Ouyang et al., 2009).

Aunque a priori un proceso de negocio es algo abierto, existen una serie de restricciones que se deben tener en cuenta a la hora de reflejarlo en


un diagrama. Si bien, no todas las restricciones recogidas en este apartado están recogidas en el estándar BPMN 2 (BPMN2, 2011). Se justifican para reducir posibles ambigüedades que se pudieran dar en la

notación gráfica y permiten una mejor trazabilidad del proceso. En cualquier caso, cuando una restricción recogida en este apartado sea más restrictiva que el propio estándar se justificará el por qué de ella.

La unidad inicial que se conceptualiza es la de Diagrama, identificado como D. Un diagrama está compuesto por objetos O. A su vez un objeto se puede clasificar como tarea (T), Eventos (E) y elemento de control de

flujo (G, por su traducción inglesa Gateway). Los eventos, como ya se ha visto, se pueden dividir en tres conjuntos disjuntos de eventos: eventos inicio (EIni), eventos finales (EFin) o eventos intermedios (EInt). Del mismo modo, los elementos de control de flujo se pueden dividir en conjuntos

disjuntos: inclusivos (GI), exclusivos (GE), paralelos (GP), basados en eventos (GEv) o complejos (GC). Los elementos de control de flujo se pueden clasificar en dos conjuntos disjuntos entre sí: Divergentes (GDiv)

si dividen el flujo o Convergentes (GConv) si unen dos remas del flujo del proceso en una sola.

Formalmente, y tal como se ve en (5.1), los eventos se clasifican en eventos de tipo inicio, intermedios y fin.Por (5.2) cualquier evento inicio

no puede ser cualquier otro tipo de evento. Los evento fin, no pueden ser intermedios (5.3) ni iniciales (5.2). Los elementos de control de flujo se pueden dividir en conjuntos disjuntos atendiendo a su tipo (5.4-5.8) o de su conectividad (5.9-5.10). Tanto los eventos, como los Gateways como

las tareas pertenecen al conjunto de objetos (5.11).

�abc ⊂ �;�ab\ ⊂ �;�3cb ⊂ �; (5.1)

∀- ∈ �abc ∶ - ∉ �ab\ ∧ - ∉ �3cb (5.2)

∀- ∈ �3cb ∶ - ∉ �ab\ (5.3)

�abj ⊂ �;�kVj ⊂ �;�l ⊂ �;�, ⊂ �;�km ⊂ �; (5.4)

∀- ∈ �abj ∶ - ∉ n�kVj ∩�l ∩�, ∩�kmp; (5.5)

∀- ∈ �kVj ∶ - ∉ n�l ∩�, ∩�kmp; (5.6)

∀- ∈ �l ∶ - ∉ n�, ∩�kmp; (5.7)

∀- ∈ �, ∶ - ∉ �km; (5.8)

�,*bm ⊂ �;�qcm ⊂ �; (5.9)

�,*bm ∩ �qcm = ∅ (5.10)


� ⊂ '; � ⊂ '; s ⊂ '; (5.11)

Las relaciones de flujo entre objetos se definen a través de F. Esta relación define la conexión de los objetos a través de los arcos (Sequence

Flow)

� ⊆ '-' (5.12)

Los objetos tienen la propiedad de tener un número determinado de entradas (in) y salidas (out) en función de su naturaleza. Expresado formalmente como:

��n�p = {-:n-, /p ∈ � ∧ / = �} (5.13)

��n�p = {/:n-, /p ∈ � ∧ - = �} (5.14)

Se considerará un diagrama válido, y por lo tanto, representable tanto conceptualmente como computacionalmente, aquel que cumpla con las restricciones formuladas a continuación:

• Un evento inicio, solo puede tener un flujo de secuencia que parta de él y a su vez, no puede ser destino de ningún otro flujo (5.15). Del mismo modo, un evento final, es aquel que es destino de un flujo, pero no lo continua (5.16). Las tareas y eventos

intermedios, son aquellos que tienen siempre una única entrada del flujo y una salida del flujo1 (5.17).

∀� ∈ �abc:��n�p = ∅ ∧ ��n�p = 1 (5.15)

∀ ∈ �3cb:��np = 1 ∧ ��np = ∅ (5.16)

∀- ∈ �ab\ ∪ s:��n-p = 1 ∧ ��n-p = 1 (5.17)

• Los elementos de control de flujo divergentes son aquellos que

contienes un único elemento entrante y más de un elemento saliente (5.18). De forma contraria, los elementos de control de flujo convergentes son aquellos que unen varios flujos en uno solo (5.19).

1 El estándar BPNM 2.0 dicta que una tarea puede no tener eje entrante, y en tal caso se le considerará como tarea y evento inicio. De forma opuesta, si una tarea no tiene un eje saliente, se le considera a la vez tarea y evento fin. A efectos de simplificación, no se considerará este polimorfismo en la presente tesis, ya que funcionalmente no tiene implicaciones relevantes.


∀� ∈ �qcm: ��n�p = 1 ∧ ��n�p > 1 (5.18)

∀� ∈ �,*bm: ��n�p > 1 ∧ ��n�p = 1 (5.19)

• Por último, cualquier objeto del proceso se debe encontrar en

un flujo que tenga un inicio y un fin. Independientemente de los objetos Intermedios.

∀- ∈ ', ∃� ∈ �abc , ∃ ∈ �3cb ∶ ��∗- ∧ - �∗ # (5.20)

Por lo tanto, se consideraran procesos validos aquellos que cumplan con las restricciones planteadas, que tal como se identifica en (Ouyang et al., 2009) garantizan tanto una expresividad conceptual de los procesos BPMN como una expresividad computacional a la hora de traducir el

flujo del proceso a instrucciones de computación.

Como resultado de esta etapa del Proceso de Normalización de los

Procesos se obtiene un proceso válido que puede ser instanciado sobre una ontología que represente estos conceptos.

5.2.3 Instanciación de Procesos BPM

La actividad de instanciación de procesos consiste en traducir de la representación gráfica a una ontología que recoja la conceptualización, jerarquía, propiedades y relaciones entre los conceptos que componen

un diagrama BPMN válido (Ghidini et al., 2009).

El traducir un diagrama en notación gráfica a una representación

computable del mismo tiene numerosas ventajas. La primera de ellas es que permite establecer razonamientos y procesos de inferencia sobre el proceso para extraer de forma automática información del mismo. Por otro lado, el abstraerse de la representación gráfica facilita el trabajar

con los procesos, ya que se puede hacer uso de las propiedades de las ontologías para unirlos a otros procesos, realizar procesos más complejos, o integrarlos con otras ontologías que contengan información de un dominio concreto que resulte más restrictivo que el propio estándar BPMN. Finalmente, al ser instanciado en una ontología, el

proceso queda representado en un lenguaje comúnmente aceptado, independiente de cualquier producto informático concreto, y extensible por reglas y otras ontologías.

La ontología terminológica BPMNOntology (Ghidini et al., 2009) está especificada en inglés, por este motivo nos referiremos a sus conceptos


por su nombre original,identificador único de cada concepto. términos en ingles como

estamos refiriendo a un concepto de la ontología o se está comentando un concepto general.

BPMN es una notación

diagramas en un sistema notación. En este lenguaje se guardadiagramas. Para establecer un sistema diagramas es necesario acceder a un tipo de información que sea

manejable por un ordenador. Por ello se traducción de un diagramainterpretación de los diagramas BPMN a través de su lenguaje de especificación intermedio, también conocido como

Process Modelling Language)

La especificación sintaxis u otra en función de la herramienta utilizada para modelar

Existen multitud de lenguajdependen de la herramienta utilizada, apueden encontrar en las herramientas comerciales se basan en lenguajesBPML definidos en XML.

Figura 5.28 Debido a las características identificadas durante la presente necesario establecer una serie de elementos funcionales especializados en realizar alguna tarea

de Procesos, Figura 5.29necesarios para resol

Diagramas, Manejador de

de Diagramas, Validador de Diagramas, Razonador, L

Escritor de Ontología.


por su nombre original, el cual forma parte de su URI y por lo tanto es el identificador único de cada concepto. En esta sección se trataran tanto términos en ingles como términos en castellano, en función de si nos

estamos refiriendo a un concepto de la ontología o se está comentando un concepto general.

una notación gráfica, sin embargo cuando se manejan

diagramas en un sistema informático existe un lenguaje detrás de esta notación. En este lenguaje se guarda de forma persistente los diferentes

Para establecer un sistema automático de instanciación de diagramas es necesario acceder a un tipo de información que sea

manejable por un ordenador. Por ello se considera apropiado que un diagrama gráfico a una ontología se base de los diagramas BPMN a través de su lenguaje de intermedio, también conocido como BPML (Business

Process Modelling Language).

ificación BPML no está estandarizada y se implementaráen función de la herramienta utilizada para modelar

Existen multitud de lenguajes de representación, que usualdependen de la herramienta utilizada, aunque la mayoría de los que se pueden encontrar en las herramientas comerciales se basan en lenguajesBPML definidos en XML.

Figura 5.28 Pasos de la traducción BPMN a ontología.

Debido a las características identificadas durante la presente secciónnecesario establecer una serie de elementos funcionales especializados en realizar alguna tarea de las identificadas. Por lo tanto el Instanciador

Figura 5.29, se modela en función de los elementos necesarios para resolver los problemas identificados: Manejador de

Diagramas, Manejador de Ontologías BPMN, Lector de Diagramas, Escritor

de Diagramas, Validador de Diagramas, Razonador, Lector de Ontología y

de Ontología.

el cual forma parte de su URI y por lo tanto es el n esta sección se trataran tanto

términos en castellano, en función de si nos

estamos refiriendo a un concepto de la ontología o se está comentando

gráfica, sin embargo cuando se manejan

s de esta de forma persistente los diferentes

de instanciación de diagramas es necesario acceder a un tipo de información que sea

considera apropiado que la en la

de los diagramas BPMN a través de su lenguaje de (Business

implementará una en función de la herramienta utilizada para modelar.

es de representación, que usualmente que se

pueden encontrar en las herramientas comerciales se basan en lenguajes

sección es necesario establecer una serie de elementos funcionales especializados

Instanciador

modela en función de los elementos Manejador de

BPMN, Lector de Diagramas, Escritor

ector de Ontología y


El Manejador de Diagramas es el encargado de abstraer los conceptos del estándar BPMN de los niveles inferiores que lo sustentan. Depende principalmente de la tecnología usada en cada caso. Este elemento

permite al conversor trabajar con diferentes herramientas para la composición de diagramas a nivel gráfico sin que las particularidades de cada una de ellas afecten a la lógica del módulo. Este elemento necesita de un Lector de Diagramas, el cual leerá los diagramas implementados

por herramientas comerciales y hará de mediador entre un diagrama en una tecnología concreta y el Manejador de Diagramas. El Manejador de

Diagramas aceptará tantos tipos de Lectores de Diagramas como

diagramas sustentados por diferentes BPML acepte. Por otro lado, el Validador de Diagramas contiene las reglas recogidas en el punto 5.2.2, que garantizan que un diagrama escrito en notación BPMN cumpla con los requisitos mínimos para ser manejado por el sistema.

El Lector de Diagramas es el encargado de manejar los diagramas BPMN en su nivel más bajo. Para ello, contiene la información necesaria para

leer un tipo determinado de BPML, ya sea expresado en XML o en otro Lenguaje. De este modo, el lector de diagramas es capaz de interpretar el lenguaje de persistencia del diagrama y extraer la información demandada en cada momento.

Figura 5.29 Estructura del Instanciador de Procesos BPMN.

El Validador de Diagramas se encarga de validar que los elementos leídos

de un diagrama cumplan con las restricciones establecidas en el apartado 5.2.2. Es decir, se encargará de comprobar que un diagrama siempre tenga un solo evento inicio y un evento fin, que solo los elementos de control de flujo dividan o unan el flujo del proceso, etc.

Esto permite al manejador de diagramas disponer de diagramas bien formados para el sistema.


El Manejador de Ontología de Procesos cumplirá la función de recibir la información del proceso facilitada por el Instanciador de Procesos y

adaptarla a la ontología que contiene la conceptualización BPMN. Este elemento permite dotar al Instanciador de Procesos de un grado de abstracción respecto a la implementación de la ontología que conceptualiza el proceso. Teniendo en cuenta que las ontologías están en

continua evolución, puede que aparezca una ontología más evolucionada conceptualmente y que en un momento determinado sea aconsejable adaptar el sistema a ella. Por ello es aconsejable definir un módulo permita al Instanciador de Procesos desacoplarse de cualquier

implementación concreta.

El Lector de Ontología, es el encargado de leer la ontología terminológica

BPMN89:;. Las ontologías se pueden expresar en diferentes lenguajes, por este motivo se pueden encontrar varios tipos de lectores de ontología

que las interpreten en función del lenguaje en el que estén expresadas (OWL, WSML, Description Logics, etc).

El Razonador es el elemento que se encarga de interpretar una ontología

y extraer información de ella. Entre sus funcionalidades más básicas está la de comprobar la consistencia de una ontología. En el sistema propuesto, es el encargado de velar por una correcta instanciación del diagrama en la ontología, sin que se introduzcan aserciones

contradictorias con las propias especificaciones y restricciones de la ontología.

El Escritor de Ontología, es el encargado de hacer persistente en una

ontología de instancias BPMN?9:; los conceptos y relaciones facilitados

por el manejador de ontologías. La persistencia se puede realizar en diferentes lenguajes de representación de ontologías (OWL, WSML, Description Logics, etc).

La ontología BPMN?9:; es el resultado del proceso. Es la ontología en la

cual se contienen las instancias de los conceptos del proceso BPMN normalizado.

A partir de los elementos anteriores, se modela el comportamiento del

Instanciador de Procesos, Tabla 5.21, estableciendo un mecanismo que permita generar de forma automática la interpretación de un diagrama BPMN y su instanciación en una ontología consistente.


Tabla 5.21 Algoritmo de instanciación de procesos expresado en pseudo-código.

proceso InstanciadorDeProcesos(Objeto objeto ) si objeto = ∅ entonces objeto ← manejadorDiagrama.ObtenerObjeto( EIni ) fin si manejadorOntologia.EscribirElemento( objeto ) si objeto ∈ EFin entonces retorno ok; sino ejes ← manejadorDiagrama.ObtenerEjesSaliente(objeto); si validador.válido(objeto, ejes.número()) entonces Para todo F ∈ ejes hacer manejadorOntologia.EscribirEje( F); objetoSiguiente ← manejadorDiagrama.ObjetoFin( F) InstanciadorDeProcesos(objetoSiguiente) fin para sino retorno error ; fin si fin si

fin proceso

A lo largo de este capítulo se ha conceptualizado la información necesaria para componer y gestionar procesos de fabricación y de negocio a partir de información semántica. En el punto 5.1 se ha

desarrollado una ontología a partir de la metodología seleccionada, este desarrollo se corresponde con el proceso �� definido

dentro del ModConcetGSPI. Como resultado se ha obtenido una ontología terminológica IMaaS89:;que será usada por el resto de procesos

del presente trabajo de investigación. En el punto 5.2 se ha desarrollado el proceso ��. En ste caso, se ha definido la funcionalidad y

los elementos necesaros para que este proceso se pueda realizar de manera automática por el modelo propuesto. A partir de los estudios sobre el uso de procesos BPMN en sistemas informáticos y de la conceptualización BPMN se ha logrado definir aquellos elementos

necesarios para automatizar la validación e instanciación de procesos BPMN.

C a p í t u l o 6

Gestión Semántica de los Procesos de Fabricación

Siguiendo con la metodología propuesta en la introducción y haciendo

uso de marco formal definido durante el capítulo 4, a lo largo de este capítulo se estudia aquellas actividades relacionadas con la gestión de los procesos. Durante el capítulo 5 se ha establecido una ontología formal con los conceptos involucrados en el proceso productivo. También

se ha desarrollado un mecanismo para conceptualizar procesos y hacerlos entendibles a las máquinas, de forma que se independice la representación gráfica del procesamiento de su lógica.

Entre los objetivos de la presente tesis está el de automatizar el todas las actividades que forman parte del proceso de gestión semántica definido en el modelado conceptual ��#�. ��#�23. Para realizar las actividades

que componen ��#�. ��#�23 es necesario tener conocimientos sobre el

área de negocio y las tecnologías que lo sustenta. Esto hace que en muchos casos se vean implicados varios responsables en el gestión de un proceso, en el que cada uno tiene los conocimientos sobre una parte del proceso: negocio, tecnología, actores, etc. (Hepp et al., 2005).

En el caso de los procesos de fabricación, esta división de conocimientos se acrecienta aún más, ya que es necesario conocer cada una de las

siguientes áreas:

• El conocimiento físico de la planta industrial donde se va a

desarrollar el proceso. La posición de cada máquina, que operaciones puede realizar, e incluso si alguna máquina tiene


algún problema o se encuentra fuera de servicio. Esta información se define en cada una de las ontologías ABox de cada una de las plantas industriales.

• El conocimiento tecnológico de cada una de las máquinas

industriales. Protocolos de comunicación, tiempos de ejecución, sistemas de monitorización, etc. Este tipo de información se define en la descripción referente a los servicios y la descripción semántica de los mismos.

• El conocimiento productivo, donde se establecen los pasos necesarios para poder desarrollar un producto concreto. Las

operaciones mecánicas y los parámetros. Los criterios de calidad, etc. Esta información se define en la ontología de conceptos TBox.

• El conocimiento de negocio, donde se alinean los objetivos

productivos con los objetivos de negocio. Como pueden ser los

costes, uso de recursos, rentabilidad, tiempos, criterios de calidad. Esta información es la que condiciona el diseño del sistema de composición de procesos.

La idoneidad de un proceso de fabricación o de negocio se determina en

su fase de modelado. Es en esta fase donde se deciden los pasos necesarios a desarrollar, su orden y sus dependencias, y por lo tanto, donde se debe invertir un mayor esfuerzo en su correcto diseño (Polyvyanyy et al., 2010).

Por lo tanto, en el presente capítulo, haciendo uso de los diferentes niveles de información, se desarrollan las actividades identificadas para que la gestión del proceso se pueda realizar. El capítulo se estructura de

la siguiente manera:

• Modelo de Composición Semántica de Procesos.

• Modelo de Compilación Semántica de Procesos.

• Modelo de Ejecución y Monitorización.

Capítulo 6. Gestión Semántica de los Procesos de Fabricación 145

6.1 Modelo de Composición Semántica de Procesos En la presente sección se propone un Modelo de Composición Semántica

de Procesos que, haciendo uso de los niveles de información

identificados, permita la realización del proceso de modelado de procesos �� identificado durante el Capítulo 4. En la definición del

proceso se ha identificado las entradas, salidas y actividades que componen este proceso, durante el desarrollo de esta sección se desarrollará la forma de llevar a cabo cada una de las actividades que componen el proceso.

El modelo propuesto recibe como entrada la ontología con la especificación del nivel de planta ��TW*Vy el Proceso Funcional

S� TU*V con las operaciones productivas a realizar y, mediante procesos de inferencia sobre la ontología y cumpliendo las

especificaciones dadas en el Proceso Funcional, se genera un proceso de fabricación que a medida de una planta de fabricación concreta. Tal como se ve en la Figura 6.1, durante esta sección se desarrollará el elemento de Modelado Semántico de Procesos perteneciente al

��. Haciendo uso del modelo funcional �� se

modelará el funcionamiento de cada uno de los elementos implicados. Estos elementos tienen una correspondencia en el �� como se

ha visto en el capítulo 4.

Durante la composición de procesos existen una serie de decisiones a tomar para conseguir un proceso óptimo. Sin embargo, existe un amplio debate en la comunidad sobre qué se puede considerar un proceso de

fabricación óptimo y no existe una clara respuesta sobre este aspecto. Depende de los intereses de la propia empresa buscar el proceso más rápido, el que menos energía consuma, el que utilice un menor número de máquinas, el que busque un equilibrio entre diversos factores. Por lo tanto, el modelo propuesto debe permitir ser flexible en la composición

de procesos según los criterios que interesen en cada momento.

El Modelo de Composición de Procesos no puede romper la flexibilidad de un entorno de producción ágil, por lo que uno de los requisitos

principales es que ofrezca diferentes posibilidades para la selección de un proceso entre los posibles candidatos. Por este motivo, la selección del proceso idóneo se realizará de forma posterior a la composición de los posibles procesos candidatos.


Figura 6.1 Correspondencia entre el Modelo Conceptual y el Modelado Funcional del Proceso.

Entre los requisitos que debe cumplir el modelo de composición de

procesos se encuentran los siguientes:

• Permitir la composición de un proceso.

• Permitir la composición de procesos a partir de la unión de

varios procesos. De forma que se pueda desarrollar procesos paralelos que optimicen los recursos del nivel de planta.

• Re-generar procesos fallidos en su etapa de ejecución.

Atendiendo a los requisitos y diseño durante la etapa de modelado funcional (punto 4.2) del MPF (Modelador de Procesos de Fabricación). El

modelo propuesto se compone de los elementos funcionales expuestos en la Figura 6.2. El Compositor de Procesos es donde se contiene la lógica de composición de Procesos. El Manejador de Procesos es el encargado

de gestionar la información referente a los procesos, el Manejador de

Ontología de Planta es el encargado de obtener la información de la planta de fabricación donde se desarrollará el proceso. El Selector de

Procesos es el encargado de escoger entre los n-procesos posibles el que más se adecue al criterio especificado.


6.1.1 Manejador de Procesos

El Manejador de Procesos es el encargado de extraer la información de

los Procesos Funcionales. Uno de los objetivos marcados dentro de la investigación es el conseguir que el modelo que se propone sea capaz de obtener procesos compuestos que cubran objetivos de varios procesos a

la vez. Para ello se ha diseñado un mecanismo para obtener un proceso que cumpla los objetivos de los dos o más Procesos Funcionales. Tras el estudio de las características que ofrecen las ontologías, se ha llegado a la conclusión que la unión de los Procesos Funcionales que se quieren

desarrollar en paralelo se puede hacer, precisamente, haciendo uso de las propiedades de equivalencia de las ontologías. En la Figura 6.3 se muestra un ejemplo del objetivo a conseguir expuesto de forma gráfica en notación BPMN. El objetivo de esta etapa es lograr un proceso que

paralelice los objetivos de los procesos de forma que puedan ser llevados a cabo simultáneamente en una planta industrial.

Figura 6.2 Detalle de entradas y salidas del Compositor de Procesos.


Formalmente, se define la composición de un proceso como la unión de todos los elementos de un proceso P1 con los elementos de un segundo proceso P2, obteniendo un proceso resultante que contiene todos los

elementos de ambos procesos.

Figura 6.3 (a) Primer Proceso Funcional objetivo, (b) Segundo Proceso

Funcional Objetivo, (c) Proceso Funcional Resultante. Cada uno de los Procesos Funcionales originales, tienen su propio

elemento inicio y elemento fin. Estableciendo una equivalencia semántica entre los elementos de inicio y fin, se logra unir ambos procesos. La equivalencia, hablando de ontologías, consiste en establecer que todas las propiedades de un elemento lo son también de su elemento

equivalente y viceversa.

∀� ∈ �{ ∧ ∀� ∈ �|, � ∧ � ∈ �} (6.1)

∃��{ ∈ �cbc ∧ ��{ ∈ �{ (6.2)

∃��| ∈ �cbc ∧ ��| ∈ �| (6.3)

∃��{ ∈ �~cb ∧ ��{ ∈ �{ (6.4)

∃��| ∈ �~cb ∧ ��| ∈ �| (6.5)


��{ ≈ ��| → ∀- ∈ ��n��{p, - ∈ ��n��|p ∧ ∀/ ∈ ��n��|p, / ∈��n��{p (6.6)

��{ ≈ ��| → ∀- ∈ ��n��{p, - ∈ ��n��|p ∧ ∀/ ∈ ��n��|p,/ ∈ ��n��{p (6.7)

Sin embargo, tal como se ha visto en el punto 5.2.2, un proceso válido es aquel que su elemento inicio tiene un solo arco saliente y su elemento fin un solo arco entrante. Esta propiedad se incumple por el principio de

igualdad de los elementos semánticos (6.6) y (6.7). Para solucionar esto, se cambiarán estos elementos y se definirán como gateways paralelos (6.8) y (6.9). Se generará un elemento inicio nuevo de forma que para todo elemento inicio antiguo (y nuevo elemento paralelo) exista un nuevo

evento inicio que esté conectado e él (6.10). Sucederá lo mismo con el evento fin (6.11). El último paso de la composición del proceso funcional es establecer que aquellos elementos que son a su vez elementos paralelos y elementos de eventos dejen de pertenecer al conjunto de

elementos evento (6.12).

∀- ∈ �abc → - ∈ �l (6.8)

∀- ∈ �3cb → - ∈ �l (6.9)

∀- ∈ �abc ∧ - ∈ �l, ∃� ∈ �abc,��- (6.10)

∀- ∈ �~cb ∧ - ∈ �l, ∃ ∈ �~cb,-� (6.11)

∀x ∈ � ∩ G� → ��n-, �p (6.12)

El algoritmo que se ha diseñado para la unión de procesos, se apoya en los diferentes pasos identificados para lograr un nuevo proceso. Definido

en pseudo-código, la composición de los procesos se realizaría de la siguiente manera.

Tabla 6.1 Algoritmo de unión de procesos expresado en pseudo-código.

proce so Union(Proceso proceso1, Proceso proceso2) procesoNuevo ← Proceso procesoNuevo= ∅ si proceso1 != ∅ entonces Objeto ← proceso1.ObtenerObjetos() para todo x ∈ objeto hacer procesoNuevo.Incluir(x) fin para fin si si proceso2 != ∅ entonces Objeto ← proceso1.ObtenerObjetos() para todo y ∈ objeto hacer procesoNuevo.Incluir( y)


fin para fin si objetoInicio1 ← proceso1.ObtenerObjeto( EIni ) objetoInicio2 ← proceso2.ObtenerObjeto( EIni ) si objetoInicio1 = ∅ or objetoInicio2 = ∅ entonces error por proceso no válido; sino procesoNuevo.Iguales(objetoInicio1,objetoInicio2) objetoIniTmp ← procesoNuevo.ObtenerObjeto( EIni ) objetoIniTmp.PertenceA( Gp) nuevoInicio ← EIni relación ← F relación.Une(nuevoInicio, objetoIniTmp) objetoIniTmp.EliminarDe( EIni ) procesoNuevo.Incluir(nuevoInicio) procesoNuevo.Incluir(relación) fin si objetoFin1 ← proceso1.ObtenerObjeto( EFin ) objetoFin2 ← proceso2.ObtenerObjeto( EFin ) si objetoFin1 = ∅ or objetoFin2 = ∅ entonces error por proceso no válido; sino procesoNuevo.Iguales(objetoFin1,objetoFin2) objetoIniTmp ← procesoNuevo.ObtenerObjeto( EFin ) objetoIniTmp.PertenceA( Gp) nuevoInicio ← EFin relación ← F relación.Une(nuevoInicio, objetoIniTmp) objetoIniTmp.EliminarDe( EFin ) procesoNuevo.Incluir(nuevoInicio) procesoNuevo.Incluir(relación) fin si devolver procesoNuevo fin proceso

El resultado de la unión de ambos procesos es un nuevo Proceso

Funcional que cumple con todas las restricciones planteadas para ser un

proceso válido, tal como se ha visto en el punto 5.2.2. Este proceso ya puede ser tratado como un proceso único para la extracción de información, control de concurrencia, etc.

Una de las necesidades del Manejador de Procesos es poder realizar procesos de inferencia sobre la ontología. Para ello se han establecido una serie de procesos de extracción sobre la ontología haciendo uso de razonadores semánticos.

El Evento Inicio de un proceso se extrae buscando en la ontología, aquel elemento que está definido como tipo Evento Inicio. Expresado en

SPARQL se define la consulta como se ve en la Tabla 6.2.


Tabla 6.2 Consulta simple para obtener el evento inicio en SPARQL.

PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-synta x-ns#> PREFIX bpmn: <http://dkm.fbk.eu/index.php/BPMN_Onto logy#> SELECT ?X WHERE { ?X rdf:type bpmn:start_event }

Se ha definido la funcionalidad de obtener los elementos siguientes de

un objeto. Para ello se busca en cada elemento del tipo flujo de secuencia, los destinos del origen del que queremos obtener el objeto siguiente. Del mismo modo, se conoce el origen o el destino.

Tabla 6.3 Consulta de extracción de elemento siguiente de un nodo en SPARQL.

PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-synta x-ns#> PREFIX bpmn: <http://dkm.fbk.eu/index.php/BPMN_Onto logy#> SELECT ?X_ORIGEN ?Y WHERE { ?Y rdf:type bpmn:sequence_flow . ?Y bpmn:has_connecting_object_source_ref ?X_ORI GEN }

Otra funcionalidad básica definida es la de obtener el tipo de un objeto, para conocer si se trata de un evento, gateway o tarea y de qué tipo.

Tabla 6.4 Consulta que obtiene las instancias de un tipo de elemento expresado en SPARQL.

PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-synta x-ns#> PREFIX bpmn: <http://dkm.fbk.eu/index.php/BPMN_Onto logy#> PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema# > PREFIX owl: <http://www.w3.org/2002/07/owl#> SELECT DISTINCT ?ELEMENTO ?X WHERE { ?ELEMENTO rdf:type ?X . ?X rdf:type owl:Class }

Se han definido otra serie de utilidades para obtener información no estructural como nombres, condiciones, propiedades, etc. De esta forma,

el Manejador de Procesos dispone de todo el conocimiento para hacer procesos de inferencia sobre los elementos del diagrama.


6.1.2 Manejador de Ontología de Planta

Durante el desarrollo del ModFuncGSPI se ha identificado la necesidad de

tener un elemento funcional que sea capaz de cubrir la necesidad de extraer información e inferir conocimiento de la ontología de planta IMaaS?9:;. Para cubrir estas necesidades se ha diseñado el Manejador de

Ontología de Planta. Este elemento será el encargado de extraer la información necesaria de la ontología de Planta como: las relaciones

entre máquinas, las operaciones que ejecuta cada máquina, los servicios disponibles por máquina, etc.

El Manejador de Ontología de Planta es, por lo tanto, el encargado de

actuar como experto sobre el dominio industrial y proveer al resto de elementos implicados en el ModFuncGSPI.

El Manejador de Ontología de Planta se compone de una serie de operaciones de extracción e inferencia que le permiten obtener información. Entre estas operaciones, se encuentra las de obtener

instancias de un tipo de proceso, obtener máquinas que implementan operaciones, obtener máquinas de transporte asociadas a máquinas de procesado, obtener caminos entre máquinas.

Por ser una de las características más relevantes se profundiza sobre la definición de los procesos de inferencia para el cálculo de caminos dentro de los elementos de transporte del nivel de planta. Es especialmente relevante este cálculo ya que el 95% del tiempo de un

proceso de fabricación se emplea en el transporte de la materia por la planta (Groover, 2000). Dentro del proceso de inferencia se han establecido dos variantes: obtener el camino óptimo entre dos puntos y obtener todos los caminos posibles entre dos puntos. El camino óptimo

es aquel en el que se atraviesa un menor número de máquinas para llegar de un punto a otro. Una de las principales ventajas que tiene el uso de ontologías es que para lograr esta información, no es necesario establecer en el sistema informático un algoritmo que calcule este camino mínimo. A partir de la extracción del proceso de inferencia se

puede obtener los caminos entre dos máquinas a partir de las propiedades, siendo el proceso de inferencia más simple (que contiene menor número de reglas para explicar el proceso de inferencia) aquel que contiene el camino mínimo.

Para el cálculo del camino mínimo se pueden establecer tres tipos de razonamiento en función del número de reglas que evalúan. El caso base


sería en el que se peguntaría al sistema si existe camino entre dos máquinas contiguas. Tal como se muestra en la Tabla 6.5, existe camino si se satisface la propiedad de Tener conexión entre dos máquinas, y por

lo tanto, Hay_camino_entre las dos máquinas.

Tabla 6.5 Cálculo de camino entre máquinas contiguas.

DLSafeRule( Body( ObjectPropertyAtom( Tiene_conexion Variable(<urn:swrl#x>) Variable(<urn:swrl#y>) ) ) Head( ObjectPropertyAtom( Hay_camino_entre Variable(<urn:swrl#x>) Variable(<urn:swrl#y>) ) ) ) SubObjectPropertyOf([Prop.conexion] Tiene_conexion ) ObjectPropertyAssertion[Prop.conexion]?X ?Y )

En el caso de elementos separados por dos maquinas se debe satisfacer el conjunto de reglas recogidas en la Tabla 6.6. Traduciendo a lenguaje natural estas reglas se diría que si existe camino entre una máquina X con una máquina Z, si X está conectada a una máquina Y, y a su vez Y

está conectada a una máquina Z. Como por las reglas definidas, si una máquina Tiene_conexion con otra, entonces Hay_camino_entre las máquinas. Si hay camino de una máquina a otra, y también los hay de la segunda máquina a la tercera, entonces, existe un camino entre la

máquina X y la máquina Z.

Tabla 6.6 Cálculo de camino entre máquinas con distancia 2.

ObjectPropertyAssertion( [Prop. conexion] ?X ?Y ) ObjectPropertyAssertion( [Prop. conexion] ?Y ?Z ) SubObjectPropertyOf( Tiene_conexion_ejeX+ Tiene_c onexion ) DLSafeRule( Body( ObjectPropertyAtom( Tiene_conexion Variable(<urn:swrl#x> ) Variable(<urn:swrl#y> ) ) ) Head( ObjectPropertyAtom(


Hay_camino_entre Variable(<urn:swrl#x> ) Variable(<urn:swrl#y> ) ) ) ) DLSafeRule( Body( ObjectPropertyAtom( Hay_camino_entre Variable(<urn:swrl#x> ) Variable(<urn:swrl#y> ) ) ObjectPropertyAtom( Hay_camino_entre Variable(<urn:swrl#y> ) Variable(<urn:swrl#z> ) ) DifferentFromAtom( Variable(<urn:swrl#x> ) Variable(<urn:swrl#z> ) ) ) Head( ObjectPropertyAtom( Hay_camino_entre Variable(<urn:swrl#x> ) Variable(<urn:swrl#z> )) ) )

El tercer caso que se estudia, Tabla 6.7, es aquel en que las máquinas entre las que se busca el camino están distantes en más de dos

máquinas. El sistema de razonamiento está basado en el anterior, sin embargo, se extiende las relaciones entre máquinas hasta lograr obtener el camino. De esta forma, el camino óptimo es aquel que utiliza menos máquinas de transporte para satisfacer la propiedad que indica que

Hay_camino_entre dos máquinas.

Tabla 6.7 Cálculo de camino entre máquinas con distancia n.

ObjectPropertyAssertion( [Prop. conexion] ?X ?Y1 ) ObjectPropertyAssertion( [Prop. conexion] ?Y1 ?Y n ) . . . ObjectPropertyAssertion( [Prop. conexion] ?Y n ?Y n+1 ) ObjectPropertyAssertion( [Prop. conexion] ?Y n+1 ?Z ) SubObjectPropertyOf([Prop. conexion] tiene_conexion ) DLSafeRule( Body( ObjectPropertyAtom( Tiene_conexion Variable(<urn:swrl#x> ) Variable(<urn:swrl#y> )


) ) Head( ObjectPropertyAtom( Hay_camino_entre Variable(<urn:swrl#x> ) Variable(<urn:swrl#y> ) ) ) ) DLSafeRule( Body( ObjectPropertyAtom( Hay_camino_entre Variable(<urn:swrl#x>) Variable(<urn:swrl#y>) ) ObjectPropertyAtom( Hay_camino_entre Variable(<urn:swrl#y>) Variable(<urn:swrl#z>) ) DifferentFromAtom( Variable(<urn:swrl#x>) Variable(<urn:swrl#z>) ) ) Head( ObjectPropertyAtom( Hay_camino_entre Variable(<urn:swrl#x>) Variable(<urn:swrl#z>) ) ) )

6.1.3 Compositor de Procesos

El elemento funcional definido para llevar a cabo la coreografía del proceso �� es el Compositor de Procesos. Por lo tanto este

elemento será el central del Modelo de Composición de Procesos. Durante

la presente sección se identifican las necesidades para realizar la composición de procesos, y en función de estas necesidades se establece la funcionalidad del Compositor de Procesos.

La composición de procesos de fabricación, y de negocio en general, es una tarea compleja ya que existen diversos factores a tener en cuenta a la hora de diseñar un algoritmo que permita la composición de procesos. Por un lado hay que tener en cuenta alinear los objetivos con la

infraestructura TI de la organización. Por otro lado, las propias


restricciones de los sistemas utilizados, y por último minimizar el uso de recursos, de forma que se puedan reducir costes dentro de la organización.

Otro problema a resolver es el de garantizar la flexibilidad necesaria para adaptarse a diferentes objetivos a la hora de componer un proceso. La flexibilidad necesaria para desarrollar los procesos de producción debe

adaptarse a diferentes necesidades como son, por ejemplo, tiempo de procesamiento más corto, el tiempo de procesado ponderado más corto, la fecha de entrega más cercana, etc.

Como se ha comentado anteriormente, uno de los objetivos principales es abstraer el Nivel de Planta en el modelado de procesos de forma que se automatice la composición de procesos a partir de un Proceso Funcional.

Aunque la tarea de conocer el Nivel de Planta es del Manejador de

Ontología de Planta, será necesario establecer el mecanismo de comunicación con el Compositor de Procesos para que se pueda

desarrollar la composición de manera conjunta.

En base a lo estudiado, se considera que el Compositor de Procesos debe proveer las siguientes funcionalidades para garantizar la flexibilidad

necesaria en el modelado de procesos:

• Considerar todas las alternativas posibles en lo que a tareas de

procesado respecta. Si una tarea puede ser desarrollada en n máquinas, se generarán n-procesos, uno por posibilidad.

• Considerar el camino mínimo entre dos máquinas. Esta variante

debe permitir acotar el modelado de procesos a las mejores opciones locales.

• Considerar los n-caminos posibles entre máquinas. Esta

variante generará todos los procesos posibles, de forma que se garantice la evaluación de todos los procesos posibles.

Un problema asociado a modelar procesos en paralelo es el control de la concurrencia sobre elementos durante el modelado del proceso. A nivel de ontología se puede validar si un proceso viola las reglas de concurrencia o no, pero no se puede establecer un comportamiento

proactivo que sea capaz de variar el mecanismo de razonamiento para dar alternativas a las colisiones. Para mejorar el control de la concurrencia en el Modelo de Composición Semántica se identifican dos funcionalidades necesarias. Por un lado, un elemento pasivo que evalúe

la concurrencia y acredite si un proceso es válido o no. Por otro lado, un


elemento activo que, en base a algún criterio, modifique los procesos no validos para corregirlos y adaptarlos a las restricciones del dominio y transformarlos en procesos validos. En fábricas con pocos recursos la

probabilidad de que no se encuentre un proceso paralelo válido que es relativamente alta, por este motivo se define un elemento activo que mejore los procesos, ya que es posible que no se encuentre de manera automática un proceso valido mediante la explotación de todas las

posibilidades. A este elemento se le ha denominado Controlador de

Colisiones.

El objetivo bajo el cual se realiza el Compositor de Procesos es el de concebir un elemento que permita generar diferentes procesos de

fabricación candidatos y seleccionar el proceso que más se adecúe a unas circunstancias concretas.

En base a las necesidades identificadas para el Compositor de Procesos

se ha diseñado la funcionalidad de cada elemento como una serie de algoritmos que desarrollan las tareas identificadas y toman las decisiones que permiten componer procesos de fabricación. Sin embargo, debido a las diferentes posibilidades para el diseño y evaluación de

diversos algoritmos de composición de procesos basados en información semántica, este punto se ha identificado como una línea de investigación futura, ya que se pueden establecer diversos mecanismos para lograr el objetivo del Compositor de Procesos centrándose en distintos aspectos.

En el algoritmo propuesto se ha buscado la flexibilidad en el modelado de procesos y la posterior evaluación en función de criterios móviles.

En base a la lista de funcionalidades expuesta para el Compositor de

Procesos, el número de procesos resultantes será igual a la multiplicación de las posibilidades de cada una de las n actividades del proceso funcional por el número de caminos posibles entre cada una de

las m máquinas de transporte implicadas en el proceso:

#��#�# = �#��#��#n�bp ×� #��#nY,Y�{pY�{

c�{

b

c�{

El algoritmo planteado hace uso de la información semántica inferida por el Manejador de Ontología de Planta para calcular los caminos que debe tomar una determinada materia y para evaluar qué máquinas de procesado pueden desarrollar una determinada tarea. La función

definida para la composición de procesos actúa de forma recursiva, desdoblando el proceso en cada alternativa que encuentra, de forma que el número de procesos resultante sean todas las posibilidades


identificadas durante los procesos de inferencia. Por acotar los procesos posibles, ya que potencialmente tienden a infinito, se han definido las siguientes restricciones:

• Un camino posible entre máquinas implica que una máquina no

puede hacer más de una vez la transición entre las mismas máquinas. Es decir, avanzar, retroceder y volver a avanzar en el camino.

• No se contemplará introducir pausas en la generación del

proceso.

El algoritmo presentado tiene dos partes diferenciadas. La primera está relacionada con la inferencia de información y selección de caminos o procesos posibles sobre un objetivo. La segunda está relacionada con la

generación de las diversas estructuras posibles.

Por motivos estructurales se va a presentar el algoritmo en tres partes. En la primera se definen los elementos usados para el desarrollo del

algoritmo (Tabla 6.8). En la segunda se calculan las diferentes posibilidades de cada actividad y los diferentes caminos posibles y en la tercera se presenta el manejo de la estructura del proceso para desdoblarlo en un proceso por posibilidad.

Tabla 6.8 Esqueleto de la función utilizada

función Generar Camino(maquinaInicial, idElemento) //! Área de definición de elementos retorno ← ListaNodos manejadorBPMN maquinaFinal ← Máquina Transporte refNodoInicio [][] ← NodoBPMN refNodoFin [][] ← NodoBPMN maquinaFinal[] ← MaquinaTransporte manDiagrama ← DiagramaBPMN manSIMaaS ← OntologiaSIMaaS //!Área de generación de camino //!Área de generación de elementos siguientes fin funcion

En la segunda parte del algoritmo, Tabla 6.9, se realiza el proceso de inferencia y la identificación de las operaciones que implementan un

proceso en una planta determinada. En primer lugar se extrae información de la actividad del Proceso Funcional mediante el Manejador

de Procesos, se evalúa si se trata de un elemento de control de flujo o de


una actividad. Si es un evento fin el proceso ha terminado, por lo que se añade el nodo al proceso. Si se trata de un evento o gateway, el proceso no ha terminado pero no se puede extraer información adicional, ya que

son elementos de control de flujo. En este caso se genera el elemento y se referencia como elemento inicio y elemento fin de la cadena generada. Si se trata de una actividad, es donde entra en juego el potencial de la ontología para extraer la información necesaria. Navegando a través de

las utilidades definidas en el Manejador de Ontología de Planta, se obtiene qué instancias implementan un determinado tipo de proceso, qué máquina ejecuta cada una de esas instancias, y qué camino hay que seguir desde la máquina inicial (donde se encuentra la materia prima)

hasta la máquina que implementa el proceso. Al final de esta parte se tienen n-listas de actividades secuenciales con todas las acciones a realizar para mover una materia prima desde una máquina inicial hasta la máquina final y realizar actividad de procesado.

Tabla 6.9 Función de generación de proceso. Parte de generación de caminos.

función Generar Camino(maquinaInicial, idElemento) ... //!Área de generación de camino elemento ← manejadorDiagrama.Obtener(idElemento) si elemento ∈ E Fin entonces fin ← manejadorBPMN.CrearElementoFin(elemento) retorno.anyadir(fin) sino si elemento ∈ E or elemento ∈ G entonces elementoBPMN ← manBPMN.CrearElementoFin(elemento) maquinaFinal[0]=maquinaInicial refNodoInicio[0][0]=elementoBPMN refNodoFIn[0][0]=elementoBPMN si no si elemento ∈ Actividad entonces procesos ← manSIMaaS.ObtenerProcesos(elemento) numProcesos=numCaminos=0 para cada proceso ∈ procesos hacer maqProcesado ← manSIMaaS.ObtenerMaquina(proceso) maqTransporte ← manSIMaaS.ObtenerMaqTran(proceso) caminos ← ObtenerCamino(maquinaInicial,maqTransporte) maquinaFin[numProceso]=maqTransporte para cada camino ∈ caminos hacer para cada maq ∈ camino hacer si maq <> maquinaFinal entonces tarea ←manSIMaaS.ObtenerProcCruzarMaq(maq) fin si si maq = maquinaFinal entonces tarea ←manSIMaaS.ObtenerProcParareEn(maq) fin si nodo ←manDiagrama.CrearTask(tarea)


si maq <> maquinaInicial entonces nodoAnt.AñadirNodoSiguiente(nodo) sino refNodoInicio[numProceso][numCamin o]=nodo; fin si nodoAnt=nodo fin para nodo←manDiagrama.CrearTask(proceso) nodoAnt.AñadirNodoSiguiente(nodo) refNodoFin[numProceso][numCamino]=nodo; numCamino=numCamino+1 fin para numProceso=numProceso+1 fin para fin si fin si fin si //!Área de generación de elementos siguientes fin funcion

La tercera parte del algoritmo, Tabla 6.10, incluye la generación del resto

de los posibles procesos. Para ello se identifica cada una de las posibles máquinas finales asociadas a cada uno de los procesos. Para cada máquina final se obtienen los elementos siguientes del proceso funcional. Para cada una de las actividades siguientes se obtienen las

diferentes posibilidades en la llamada a la función recursiva. Cada uno de los n procesos siguientes tiene m posibilidades. Se calculan todas las combinaciones posibles de cada uno de los procesos con los demás y se añaden por la parte posterior, a la parte del camino calculada en la

segunda parte, y finalmente se añade cada una de las combinaciones a la lista de procesos posibles a devolver.

Tabla 6.10 Función de generación de proceso. Parte de generación de

todas las posibilidades.

función Generar Camino(maquinaInicial, idElemento) //!Área de generación de elementos siguientes i=0 para cada maqFinal ∈ maquinaFinal hacer elementosSig ←manejadorDiagrama.ObtenerSiguientes(idElemento) numElemSig=0 listaNodos[elementosSig.tamanyo] para cada elemSig ∈ elementosSig hacer listaNodos[numElemSig]=Generar Camino(maqFina l, elemSig) numElemSig=numElemSig+1 fin para totalCaminos=1 para k=0; k<elementosSig.tamanyo; k++ hacer totalCaminos=totalCaminos*listaNodos[k].tamanyo fin para


k=1 mientras k<=totalCaminos hacer l=0 mientras l<elementosSig.tamanyo hacer posicion=(k/elementosSig.tamanyo)%listaNodo s[l].tamanyo nodo=listaNodos[l].Obtener(posición) long=0; mientras long<punteroFin[i].tamanyo hacer refNodoFin[i][long].AnyadirEnEje(l,nodo) fin mientras long=0; mientras long<punteroInicio[i].tamanyo hacer nodoInicioPosibilidad=refNodoInicio[i][l ong] retorno.anyadir(nodoInicioPosibilidad) fin mientras fin mientras k=k+1 fin mientras fin para devolver retorno fin función

El resultado del algoritmo es un proceso completo pero no necesariamente válido, ya que tal como se ha definido en la ontología, una máquina no puede tener situadas dos materias a la vez. El motivo de que el proceso obtenido no necesariamente sea valido es debido a que no se ha controlado la concurrencia, por lo que cuando se instancie

sobre la ontología se podrían violar las reglas de control de concurrencia, por los motivos ya expuestos en la definición de la funcionalidad del Controlador de Colisiones.

Para la definición del algoritmo del Controlador de Colisiones las dos principales aproximaciones que se pueden plantear sobre la planificación del proceso para evitar colisiones son: sacar del camino las materias

primas que vayan a colisionar, lo cual implicaría tener una fábrica diseñada con escapatorias cada ciertas máquinas; o pausar ciertos procesos para evitar las colisiones.

La aproximación que se sigue es la de introducir pausas en el proceso para evitar las colisiones. Al tratarse de procesos secuenciales donde la introducción de un elemento de espera afecta al resto de actividades del proceso provoca que, a priori, no se pueda identificar el número de

esperas necesarias y en qué posición del proceso definirlos para obtener un proceso con el menor número de pausas.


Se ha definido un algoritmo basado en la aproximación de ramificación y poda, el cual se basa en dos factores para realizar la poda:

• Se conoce el número máximo de pausas necesarias en un

proceso. Por lo que cualquier proceso que sea pausado más de ese número de veces es descartado.

• En el momento que se consigue un proceso sin colisiones con un

número de pausas X y una longitud L. Se podarán todos

aquellos procesos que superen en longitud al proceso. Si se consigue un proceso de menor longitud L se actualiza el valor L.

Para conocer el número máximo de pausas necesarias se realiza un

algoritmo que evalúa la distancia entre cada máquina de X cadenas de procesos paralelos. De esta forma, se obtiene qué máquinas tienen una colisión en el proceso inicial, qué máquinas no colisionarán por no encontrarse en las otras cadenas de procesos y qué cadenas de procesos

tienen máquinas que colisionan a una distancia D. La máxima distancia

D será el número máximo de pausas necesarias para garantizar que un proceso no colisiona.

Este algoritmo consiste en obtener una serie de matrices que reflejan todas las combinaciones de caminos paralelos y obtienen sus distancias de colisión, se identificará también si existe colisión y dónde. Estas

matrices ayudarán a identificar en la composición de los procesos si se producen colisiones durante el desarrollo del algoritmo.

A modo de ejemplo, si se suponen dos secuencias de procesos paralelas

S1={M1,M2,M3,M4,M5} y S2={M7,M6,M5,M4,M5,M6}, la matriz de colisiones detectadas se correspondería con la mostrada en la Tabla 6.11. Como se puede ver existen dos colisiones en los puntos (4,4) y (5,5) y una posible colisión potencial en el punto (3,5) que indica que si el proceso S2

introduce dos esperas antes de su elemento en tercera posición se produciría una colisión. A su vez, como ya se ha comentado, la distancia máxima + 1 de la tabla garantiza un proceso sin colisiones, no necesariamente siendo el mejor.

Tabla 6.11 Matriz de colisiones de secuencias paralelas.

Posición 1 (M1) 2 (M2) 3 (M3) 4 (M4) 5 (M5) 1 (M7) x x x x x 2 (M6) x x x x x 3 (M5) x x x x 2 4 (M4) x x x 0 x


5 (M5) X x x x 0 6 (M6) X x x x x El primer proceso candidato es, por lo tanto, aquel que introduce una

espera de DMax+1 para iniciarse en una de sus secuencias paralelas. Sin embargo, el problema de esta aproximación es que, aunque se resuelve con un coste computacional muy bajo, no se centra en minimizar el impacto sobre la longitud del proceso. Es posible, por lo tanto, encontrar

un número de esperas inferior a DMax+1 que generen procesos sin colisiones y además impacten menos sobre el tamaño del proceso. Como se puede apreciar sobre la secuencia S1 se pueden obtener múltiples variantes que no generen colisiones en el proceso. Tales como

S1={Espera,M1,M2,M3,M4,M5}, S1={M1, Espera,M2,M3,M4,M5}, S1={M1, ,M2,Espera,M3,M4,M5}. En base a la funcionalidad concebida, se propone el algoritmo expuesto en la Tabla 6.12 como forma de lograr los objetivos propuestos.

Tabla 6.12 Cálculo de la distancia máxima a la que se obtiene un proceso sin colisiones.

funci on DistanciaMaxima() secuencia[] ← Secuencias disatanciaMaxima=0 colision=false i=0 cont=0; mientras i<secuencias.tamanyo hacer j=i+1 mientras j<secuencias.tamanyo hacer para cada maqina 1 ∈ secuencias[i] hacer para cada maquina 2 ∈ secuencias[j] hacer si maquina 1=maquina 2 entonces D=|(Posicion(maquina 1)-Posicion(maquina 2))| Mat[cont][maquina 1][maquina 2]=D; sino Mat[cont][maquina 1][maquina 2]=’X’; fin si si D>distanciaMaxima entonces distanciaMaxima=D fin si si D=0 entonces colision=true fin si fin para fin para

j=j+1 cont=cont+1 fin mientras fin mientras fin función


Para obtener los procesos candidatos sin colisiones se realiza un algoritmo basado en ramificación y poda en el cual se generan las diferentes posibilidades de espera en cada una de las secuencias y se

obtiene un proceso que minimiza el impacto en longitud del proceso y tiempos de espera. Para ello el algoritmo cuenta con las secuencias paralelas, la espera máxima necesaria y la longitud mínima obtenida en procesos no paralelos.

El Controlador de Colisiones se desarrollará en base al algoritmo propuesto en la Tabla 6.13. Para ello, se genera el árbol de procesos

posibles mientras que se mantenga la premisa de que no se está superando la longitud L de un proceso ya válido. Para ello, se generan todas las posibilidades introduciendo de 0 a numEspera estados de espera en la posición pos indicada como parámetro. Se genera en cada

caso el árbol correspondiente y se evalúa su longitud. Si la longitud ya excede a la longitud mínima encontrada, que se recibe como parámetro

como LMax (Longitud Máxima permitida). Se evalúa cada una de las posibilidades obtenidas y si es mejor que la anterior, será esa la que se devuelva como combinación de secuencias válidas.

Tabla 6.13 Función de resolución de colisiones.

funcion ControlColisiones(numEspera, pos, secuencias, L Max) secuencias[] ← Secuencias retorno ← Secuencias L Local = LMax+numEspera+1

para cada secuencia ∈ Secuencias hacer para i=0; i<=numEsperas; i++ hacer secuencia.IntroducirNumEsperas(i,posición); encontrado=EvaluarColisiones(secuencias) L=LongitudMax(secuencias) si encontrado=true entonces esperas=i si L<LMax entonces L Max=L fin si

si no si L <= L Max entonces secAux=ControlColision(numEspera-i,pos+1,se cuencia,L Max); fin si fin si si encontrado && L < L Local entonces retorno ←secuencias L Local =L si no si LongitudMax(secAux)< L Local entonces retorno ←secAux L Local =LongitudMax(secAux) fin si fin para


fin para devolver retorno; fin funcion

Como resultado, el Compositor de Procesos dispondrá de n-procesos candidatos válidos que se pueden llevar a cabo en una planta concreta. Cada uno de estos procesos candidatos satisfará los objetivos definidos en el Proceso Funcional.

Estos procesos se pueden alinear con los objetivos estratégicos de la organización a través de la selección del proceso a ejecutar, ya que en la

toma de decisión se podrá definir el que criterios, tiempo, coste, eficiencia, uso de máquinas, etc. Es el que más interesa a la organización en cada momento.

6.1.4 Selector de Procesos

La necesidad de seleccionar procesos en función de los intereses que más convengan en cada momento a la organización está cubierta por el

Selector de Procesos.

En este elemento será donde se definan los criterios a seguir para seleccionar un proceso u otro en función de los intereses de la

organización. En esta tarea se pueden tener en cuenta criterios definidos sobre la ontología. Los criterios como tiempo de ejecución, consumo eléctrico, etc. se podrían obtener a partir de un proceso de inferencia sobre la ontología, mientras que criterios como el proceso con un menor

número de pasos se obtendría únicamente atendiendo a criterios estructurales del proceso.

En el sistema propuesto pueden existir diversos selectores de procesos

que permitan seleccionar en cada momento un proceso en función de unas características determinadas. Es por tanto una parte que alinea los intereses de una organización con la generación automática de procesos, que explota las diferentes posibilidades sin atender a objetivos

específicos.

El Selector de Procesos recibe como entrada un conjunto de diagramas

BPMN, los cuales se pueden ver como grafos dirigidos. El visualizar los procesos como grafos permite utilizar técnicas específicas de la teoría de grafos para diseñar el algoritmo de selección de procesos. El algoritmo de Dijkstra, que consiste en encontrar el camino mínimo en un grafo

dirigido, es una buena aproximación para definir el Selector de Procesos


ya que se puede establecer como pesos dentro del proceso los objetivos de la organización que se desean maximizar o minimizar. El interés del Selector de Procesos es escoger el mejor proceso, del conjunto de

procesos, evaluando el peor caso de cada uno. Por ello se propone una modificación sobre este algoritmo para encontrar el camino máximo, en lugar del camino mínimo.

En los procesos expresados en BPMN no se dispone de un peso específico por vértice, en comparación con un grafo dirigido que suele tener un peso por vértice. El cálculo de este peso dentro del diagrama

BPMN estará directamente relacionado con el objetivo a evaluar en la selección del proceso. Al conocer cada una de las actividades del proceso, se puede inferir el peso en función del objetivo estratégico que se defina. Para ello, en el Manejador de Ontología de Planta se dispone de

las funcionalidades establecidas sobre la ontología IMaaS89:;, de forma que el selector sea independiente de conceptualización del proceso. En la

Tabla 6.14 se puede ver la propuesta del algoritmo expresada en pseudo-código y las relaciones con el Manejador de Ontología de Planta (manejadorSIMaaS) y el Manejador de Procesos (manejadorBPMN).

Tabla 6.14 Algoritmo de selección de procesos.

funcion SeleccionProcesos-Dijkstra (diagramaBPMN) manejadorBPMN ← diagramaBPMN manejadorSIMaaS ← OntologiaSIMaaS distancia ← distancia[manejadorBPMN.ObtenerNumVert()] visitado ← booleano[manejadorBPMN.ObtenerNumVert()] manejadorBPMN.ObtenerInicio(inicio); vertices ← manejadorBPMN.ObtenerSiguientes(inicio) para cada vertice ∈ diagramaBPMN hacer si vertice ∈ Actividad entonces //Criterio estrategico peso=manejadorSIMaaS.ObtenerTiempo(vertice) si no peso= ∅; fin si distancia[vertice]=peso fin para distancia[inicio]=0 visitado[inicio]=cierto; mientras visitados.Contenga(falso) hacer vertice=MaxDistanciayNoVisitado(distancia,visit ado) vistitado[vertice] = cierto; siguientes ← manejadorBPMN.ObtenerSiguientes(vertice) para cada vertice ∈ siguientes hacer //Criterio estrategico peso=manejadorSIMaaS.ObtenerTiempo(vertice) si distancia[vertice] < distancia[vertice]+peso entonces


distancia[vertice] = distancia[vertice]+peso fin si fin para fin mientras fin funcion

Como resultado, el Selector de Procesos proporciona el peso de cada uno de los procesos candidatos, por lo que la última fase de la selección del

proceso es precisamente seleccionar aquel que tiene una menor distancia máxima entre su inicio y fin. El resultado obtenido será el proceso que será la salida del proceso de Modelado de Procesos

�� definido en el ��.

6.2 Modelo de Compilación de Procesos El segundo elemento que forma parte del proceso de gestión

��#�. ��#�23 es el proceso �� definido en el capítulo 4. Este

proceso recibe como entrada el proceso S� TU*V,*Y%Z[\* resultante del

proceso de modelado �� y la ontología de planta ��TW*V. La

salida de este proceso es un elemento S��^ que pueda ser realizado

sobre una planta concreta. Desde un punto funcional ya se ha definido en el �� las necesidades de este proceso. Durante la presente

sección se propone un Modelo de Compilación de Procesos que especifique, en base al�� los elementos necesarios, la

comunicación entre ellos y su funcionalidad, de forma que se modelen una serie de elementos que puedan ser definidos sobre el modelo

arquitectónico ��. En la Figura 6.4 se muestra la correspondencia entre el �� y como los elementos que se

definen funcionalmente dan paso a los elementos propuestos en el

��.

Para definir el modelo de compilación se ha establecido un proceso basado en las 6 fases comúnmente aceptadas de un compilador: análisis léxico, análisis sintáctico, análisis semántico, generación de código intermedio, optimización del código intermedio y optimización del código.

Sin embargo, como el objetivo de esta investigación es el de lograr hacer transparente los conceptos tecnológicos del Nivel de Planta y lograr automáticamente un proceso ejecutable, será precisamente en estos aspectos en los que se centre el modelo propuesto. Por lo tanto el modelo

se centrará en aquellos aspectos fundamentales de las reglas de traducción, los aspectos referentes al descubrimiento de información y


automatización basadas en información semántica, que son los elementos diferenciadores y novedosos en el proceso de traducción.

Figura 6.4 Esquema general del modelo de Compilación de Procesos con sus entradas, salidas y la correspondencia con el ModConceptGSPI.

Para definir el Modelo de Compilación se ha establecido un proceso

basado en las 6 fases comúnmente aceptadas de un compilador: análisis léxico, análisis sintáctico, análisis semántico, generación de código intermedio, optimización del código intermedio y optimización del código. Sin embargo, como el objetivo de esta investigación es el de lograr hacer

transparente los conceptos tecnológicos del Nivel de Planta y lograr automáticamente un proceso ejecutable, será precisamente en estos aspectos en los que se centre el modelo propuesto. Por lo tanto el modelo propuesto se centra en aquellos aspectos fundamentales de las reglas de

traducción, los aspectos referentes al descubrimiento de información y automatización basadas en información semántica, que son los elementos diferenciadores y novedosos en el proceso de traducción.

Existen algunas propuestas para la traducción desde procesos BPMN a BPEL, como la propuesta BPMN2BPEL (Blox, 2009), o las implementaciones propietarias desarrolladas en herramientas comerciales como Intalio (Intalio ,2013), Bonita (BoitaSoft, 2013) u

Oracle (OBPM, 2013). Estas se basan en la traducción de la estructura del proceso, pero es el propio proceso el que debe contener la


información de los servicios utilizados, las variables y los parámetros de invocación. Lo que hace que en la práctica se esté mezclando el diseño del proceso con la ejecución del mismo sobre el diagrama BPMN. Uno de

los objetivos del Modelo de Compilación de Procesos es lograr la traducción entre procesos BPMN y BPEL sin que sea necesario establecer información de ejecución durante el diseño del proceso.

Una de las tareas principales en la elaboración de un compilador, y que por sí sola puede establecer un trabajo de investigación, es la definición de una gramática para un compilador. En esta gramática se establece

las reglas de traducción entre la representación gráfica del proceso y su lenguaje ejecutable. La gramática que se ha establecido se basa en un subconjunto de las diferentes equivalencias identificadas por Ouyang y su equipo en diversas publicaciones y que se resumen en (Ouyang et al., 2009).

En base a las necesidades identificadas en el modelo funcional ModFuncGSPI, el Modelo de Compilación de Procesos define las partes

necesarias para llevar a cabo el proceso de Traducción. Tal como se ve en la Figura 6.5, el Modelo de Compilación de Procesos se compone por elementos funcionales especializados en cada una de las tareas necesarias para realizar la traducción. El elemento central del modelo es

el Compilador de Procesos, el cual es el encargado de coreografiar todo el proceso de traducción. El Manejador de Procesos (definido en el punto 6.1.1) es el encargado de extraer información del proceso BPMN. El

Manejador de Ontología de Planta (definido en el punto 6.1.2) es el encargado de extraer la información de la planta donde se ejecutará el proceso, permite establecer que actividades se corresponden con que servicios y como afecta a cada uno de los servicios el entrono. El

Manejador de SWS (Manejador de Servicios Web Semánticos) permite realizar procesos de inferencia sobre la descripción semántica del servicio. El Manejador WSDL es un elemento que permite extraer información de la descripción del servicio referente al modo de conexión,

etc.

6.2.1 Manejador de Servicios Semánticos

Durante la revisión del estado del arte en el capítulo 2 se han visto las posibilidades que ofrece el uso de Servicios Web Semánticos, denominados SWS (Semantic Web Services) en adelante.


Figura 6.5 Elementos del Modelo de Compilación de Procesos.

En la presente sección se identifica y define la funcionalidad necesaria de este elemento para inferir la información necesaria acerca de los

parámetros, requisitos y consecuencias de la ejecución de un servicio.

Aunque la funcionalidad necesaria del Manejador SWS es general para el modelo propuesto, la presente sección se centra en la definición del

Manejador SWS sobre una ontología de servicios concreta, lo que permite centrarse en los mecanismos establecidos para la extracción de información. Los SWS que se han definido en la presente tesis, utilizan OWL-S (OWL-S, 2004) como ontología de descripción semántica del

servicios. Si bien, OWL-S es en sí misma una ontología descrita en el lenguaje OWL y no estrictamente un lenguaje, es habitual que se referencie a OWL-S como lenguaje de descripción de servicios. La ontología OWL-S está compuesta a su vez por tres ontologías, cada una

de las cuales está especializada en la descripción de un tipo de información: la ontología ServiceProfile (OWLProfile, 2014) contiene la descripción del servicio; la ontología ServiceGroundig (OWLGroundin,

2004) contiene la información de cómo acceder al servicio; y la ontología ServiceModel (OWLModel, 2004) describe como trabaja el servicio.


Para el propósito de extracción de información para la composición del proceso ejecutable las ontologías ServiceProfile y ServideGrounding son las que contienen la descripción de SWS con información relevante.

Sobre estas ontologías es sobre las cuales se han definido una serie de consultas que permitan la extracción de la información necesaria en cada momento.

La información referente a la conexión con el servicio se encuentra contenida en el ServiceGrounding por lo que es necesario que el sistema disponga, como mínimo, de las siguientes funcionalidades para

garantizar que se pueden realizar las inferencias necesarias. Por este motivo se definen procesos para la extracción de las siguientes propiedades:

• Obtener URI Grounding (URI Servicio): esta funcionalidad

obtiene el identificador único de la parte que describe la conexión de un servicio. Se realiza el proceso de inferencia a través de la propiedad supports

• Obtener URI Operación (URI Grounding): esta funcionalidad

permite obtener la dirección donde se encuentra la descripción

WSDL de cada operación. Se realiza a través de la propiedad wsdlOperation.

• Obtener URL WSDL Servicio. (URI Grounding): esta

funcionalidad permite obtener la dirección donde se encuentra la descripción WSDL de cada operación. Se realiza a través de la

propiedad wsdlDocument.

• Obtener URI Inputs. (URI Grounding): esta funcionalidad

permite obtener la URI del input Map donde se encuentra la descripción de cada parte de los parámetros de entrada del servicio. Se realiza a través de la propiedad wsdlInput.

• Obtener URI Outputs. (URI Grounding): esta funcionalidad

permite obtener la URI del input Map donde se encuentra la

descripción de cada parte del mensaje de salida del servicio. Se realiza a través de la propiedad wsdlOutput.

• Obtener URL wsdlMessagePart (URI Input): esta funcionalidad

obtiene la parte de la wsdl donde se define cada una de las partes que componen el mensaje con los parámetros de entrada

de un servicio. Se realiza a través de la propiedad wsdlMessagePart.


• Obtener URL wsdlMessagePart (URI Output): esta funcionalidad

obtiene la parte de la wsdl donde se define cada una de las partes que componen el mensaje con el resultado de un servicio.

La información referente a la parte funcional del servicio a partir de la

cual se obtiene el valor de los parámetros con los que se debe invocar a un servicio para que desarrolle la actividad bajo las condiciones correctas se extrae de la descripción del servicio, contenida en la ontología ServiceProfile.

La forma de calcular los parámetros es aquella en la que el efecto de la ejecución de un servicio está alineado con los objetivos del proceso. De forma que la ejecución de un servicio permite conseguir los objetivos

locales del proceso o actividad que implementa y, a su vez, genera en el contexto de ejecución del proceso las condiciones que permiten la ejecución del siguiente servicio. Cada servicio tiene una precondición que se debe cumplir para que se pueda desarrollar el servicio. Esta condición

se expresa en la descripción del SWS a través de la propiedad hasPrecondition, la cual pertenece al dominio del ServiceProfile. Estas condiciones deben estar expresadas conforme a una ontología que permita contextualizar la información y hacerla interpretable para un

sistema informático. La propiedad hasPrecondition expresan una serie de axiomas sobre una ontología de referencia que deben ser ciertas, y no generar inconsistencias en la ontología para que se pueda llevar a cabo el servicio.

En el caso concreto de una máquina de transporte que tiene un proceso de manejo de materia, el cual es implementado por un servicio de actuación, se debe dar la precondición de que la materia que va a

transportar este situada sobre la máquina de transporte. La propiedad Está_Situada es la precondición necesaria para que se pueda invocar al proceso. Tal como se ha definido en la ontología del capítulo 5, la

propiedad Esta_Situada es una propiedad funcional, de forma que una materia X solo puede tener un máximo de una propiedad Esta_Situada dentro de la ontología, tal como se ve en la Tabla 6.15. Para que un servicio que implementa un proceso de transporte se pueda invocar se

debe dar la condición de que la materia a mover se encuentre situada sobre la máquina de transporte para satisfacer esta condición, si se conoce el servicio, a través de la parte Process de OWL-S se puede conocer qué máquina lo ejecuta mediante la propiedad de objeto

performedBy.


Tabla 6.15 Precondición de servicio de transporte.

simaas: http://tesisSIMaaS:8080/plantaX.owl process:http://www.daml.org/services/owl-s/1.2/Proc ess.owl service: http://www.daml.org/services/owl-s/1.2/Ser vice.owl simaas:Máquina_de_Transporte (?M t ), simaas:Materia (?M), simaas:Esta_Situada (?M, ?M t ), process: performedBy (?Process, ?M t ), service: DescribedBy (?Service, ?Process) ----------- Donde -------------- ValueOf(?service,’Servicio a Invocar’) ValueOf(?M,’Materia a Mover’)

Junto a la precondición del servicio, existe en la descripción del SWS la información referente al efecto que produce la ejecución del mismo. De

este modo, mediante la propiedad de objeto hasResult está especificado el efecto que tiene la ejecución del servicio bajo ciertas condiciones. En la propia descripción semántica del servicio se pueden ver los efectos de invocar el servicio con un valor para el parámetro u otro. Un servicio

podrá tener tantos resultados como condiciones de ejecución diferentes se puedan dar sobre él.

Tal como se puede ver en la Tabla 6.16, expresado en pseudo-código, el

resultado de la invocación de un servicio de transporte depende del parámetro con el que se invoque. En este caso se muestra el ejemplo de un servicio que implementa el proceso Cruzar_máquina de una Cinta Transportadora, que puede tener conexión con dos máquinas de

transporte a través de las propiedades de objeto. Tal como se ve en la tabla, cuando se invoca el servicio con el parámetro “P” (Positivo), el efecto que tiene sobre el entorno es que la Materia pase de estar situada en la máquina de transporte que ejecuta el servicio (por precondición en

Tabla 6.15), a estar situada en la máquina de transporte que tiene conectada en el eje X +.

Tabla 6.16 Ejemplo de descripción de resultado en SWS para parámetro de dirección positivo sobre un proceso de transporte.

simaas: http://tesisSIMaaS:8080/plantaX.owl process: http://www.daml.org/services/owl-s/1.2/Pro cess.owl service: http://www.daml.org/services/owl-s/1.2/Ser vice.owl profile: http://www.daml.org/services/owl-s/1.2/Pro file.owl ----- profile:hasResult------ ValueOf(?Service,’Servicio a Invocar’) ValueOf(?idParam,’P’)


-----profile:inCondition------ service: DescribedBy (?Service, ?Process) process: performedBy (?Process, ?M t ), process: hasInput (?Process, ?Input) process: parameterType(?Input, ?paramType) simaas: Individual(?paramType, ?idParam) simaas: Valor(?idParam, ?valorParam) ------profile:hasEffect-------- Delete { simaas:Esta_Situada (?M,?M t ) } Insert{ simaas:Esta_Situada (?M,?M2 t ) } Where{ Tiene_Conexion_Eje_X+(?M t ,?M2 t ) }

Igualmente, el mismo servicio tiene otro efecto completamente diferente

si se invoca con otro parámetro. En la Tabla 6.17 se muestra el resultado de invocar al servicio con parámetro de dirección “N” (Negativo). En función del parámetro la materia se sitúa en la máquina situada el eje X positivo o X negativo.

Tabla 6.17 Ejemplo de descripción de resultado en SWS para parámetro de dirección negativo sobre un Proceso de Transporte.

simaas: http://tesisSIMaaS:8080/plantaX.owl process: http://www.daml.org/services/owl-s/1.2/Pro cess.owl service: http://www.daml.org/services/owl-s/1.2/Ser vice.owl profile: http://www.daml.org/services/owl-s/1.2/Pro file.owl ----- profile:hasResult------ ValueOf(?Service,’Servicio a Invocar’) ValueOf(?idParam,’N’) -----profile:inCondition------ service: DescribedBy (?Service, ?Process) process: performedBy (?Process, ?M t ), process: hasInput (?Process, ?Input) process: parameterType(?Input, ?paramType) simaas: Individual(?paramType, ?idParam) simaas: Valor(?idParam, ?valorParam) ------profile:hasEffect-------- Delete { simaas: Esta_Situada (?M,?M t ) } Insert{ simaas: Esta_Situada (?M,?M2 t ) } Where{


simaas: Tiene_Conexion_Eje_X-(?M t ,?M2 t ) }

Una de las necesidades del Manejador SWS es poder inferir qué parámetros son necesarios para llevar a cabo el proceso. Como se ha expuesto en la presente sección, esta información está disponible en los SWS. Sin embargo, para que se pueda calcular automáticamente los

efectos de la invocación de un servicio es necesario disponer de un mecanismo que permita simular los efectos que tendrá la ejecución de un servicio para ver si producirá los efectos que busca el proceso modelado.

Como forma de calcular los parámetros se propone el algoritmo definido en la Tabla 6.18. En él se ha definido un mecanismo de simulación que permite calcular, a partir de dos servicios secuenciales en el proceso, los

parámetros con los que se debe invocar al primero de ellos. Para ello se basa en la simulación del efecto que tendría la ejecución del servicio con cada uno de los parámetros posibles, y en validar en cada uno de los escenarios posibles (identificados por la propiedad hasEffect), cual

cumple con los prerrequisitos que hacen viable la ejecución del segundo servicio.

Tabla 6.18 Algoritmo de cálculo de parámetros basado en Información

Semántica.

procedure Calculo Parametros(s1 ← Servicio , s2 ← Servicio, m ← Materia){ ontología ← Ontología SIMaaS resultados ← s1.ObtenerHasResult() paramtros ← Prametro[] ontología.AñadirAxioma(EstaSituada(s1.máquina,m )); para todo resultado ∈ resultados hacer efecto ← resultado.ObtenerEfecto() ontología.Aplicar(efecto) condicion ← s2.Precondition() si ontología.Validar(condicion)==cierto entonces condiciones ← resultado.ObtenerInCondition(); para todo condicion ∈ condiciones hacer parametro.Id=condición.ObtenerParamt ro(); parametro.Valor=condición.ObtenerVal or(); parametros.Añadir(parametro); fin para fin si fin para devuelve parámetro


fin procedure

6.2.2 Compositor de Procesos

El Compositor de Procesos se define con el objetivo coreografiar el proceso de traducción. Para poder realizar esta coreografía es necesario

establecer una gramática de traducción y los mecanismos de traducción, descubrimiento de servicios, parámetros, etc. Por este motivo este elemento se definirá dos partes: Por un lado la definición de la gramática y las reglas de traducción que van a guiar el proceso, por otro lado las

funcionalidades necesarias y los mecanismos que se proponen para lograrlos.

Definición de la Gramática y Traducción

La mayoría de sistemas de traducción se basan en una gramática definida a partir de la cual se establece una traducción de una entrada a

una salida determinada. En la presente tesis se han utilizado las estructuras BPMN inidentificadas en (Ouyang et al., 2009) para establecer la gramática y las reglas de traducción del sistema propuesto.

Para componer esta gramática se han utilizado las estructuras de control identificadas por Ouyang, y que son las más comúnmente utilizadas en un proceso. Además, se dispone de la correspondencia entre las estructuras en procesos BPMN y su correspondiente estructura en BPEL.

Tal como se ve en la Figura 6.6, existen estructuras identificadas para las partes secuenciales (a) y paralelas (b), también estructuras de control como los switch (c) o los diferentes tipos de repetición (e, f, g). La gramática que se ha definido como soporte para la traducción de

procesos es un subconjunto de las estructuras de control más comunes que se pueden encontrar.

Sobre esta gramática se puede aplicar un mecanismo de optimización de

código basado en la reducción de elementos que, aunque son correctos desde un punto de vista funcional, introducen información redundante. Por este motivo se ha introducido una regla de reducción de forma que se eliminen los elementos sequence anidados, ya que desde un punto de

vista funcional tienen el mismo efecto, y simplifican el proceso. En la Figura 6.7 se ve el efecto de aplicar esta reducción sobre un proceso secuencial generado a partir de esta gramática.


La gramática aquí propuesta, así como la traducción, guía el proceso de compilación desde un punto de vista estructural. Esta estructura será la que guiará el sistema de traducción propuesto. Sin embargo, tratar la

traducción de procesos desde un punto de vista estructural, y más de una forma simplificada como esta, no supone un avance en el conocimiento de la comunidad científica. Esta definición se utiliza como elemento necesario en el proceso de traducción. Sin embargo, la

verdadera aportación del sistema propuesto consiste, precisamente, en completar la información del proceso ejecutable de manera automática, lo que se estudia en el punto siguiente.

Tabla 6.19 Gramática y Traducción propuestas.

Regla Traducción Programa � S S� Inicio T Fin <process> T.trad </process> Inicio � Evento_Inicio <request> </request> Fin � Evento_Fin <resply> </reply>

T � task T

<sequence> <invoke>task</invoke> T.trad <sequence>

T � task <invoke> task <invoke>

T � I T(n) F

<flow> T 1.trad T n.trad </flow>

T � IF T 1 ELSE T 2 ENDIF

<if> <condition> IF.trad </condition> T 1.trad <else> T 2.trad </else> </if>

T � DO T WHILE(X)

<repeatUntil> T.trad <contition> WHILE.trad </condition> </repeatUntil>

I � parallel_gateway in(1) out(n) ∅

F� parallel_gateway in(n) out(1)

∅

IF � exclusive_gateway, in(2) out(2) condition(X)

Traducción Condition

ENDIF � exclusive_gateway, in(2) out(1) condition( ∅)

∅

DO � excluisive_gateway , in(1) out(1) condition( ∅)

∅

WHILE � exclusive_gateway , Traducción Condition


in(1) out(2), condition(X)

Figura 6.6 Equivalencias entre estructuras BP


in(1) out(2), condition(X)

Equivalencias entre estructuras BPMN y BPEL. (Ouyang 2009).

et al.,


Figura 6.7 Imagen del proceso resultante de la gramática antes de la reducción (a) y después de la reducción (b).

6.2.3 Funcionalidad del Compilador de Procesos

El Compilador de Procesos es el encargado de guiar el proceso de traducción por la gramática definida anteriormente. La gramática provee la estructura del proceso ejecutable. Sin embargo, sigue siendo necesario identificar los servicios, parámetros y mensajes que completan el

proceso. El Compilador de Procesos usa el Manejador SWS y el Manejador de Ontología de Planta para inferir esta información a partir de la información semántica de cada planta y cada uno de los servicios implicados, realizando además de la traducción de la estructura BPMN-

BPEL, la creación de variables necesarias, inicialización de variables e invocación de servicios.


El objetivo del Compilador de Procesos es conseguir un proceso BPEL completamente funcional que pueda ser desplegado en cualquier motor de ejecución. Existe información importante dentro de una definición de

proceso BPEL que no se ha recogido en la gramática por no corresponderse con información estructural. Sin embargo, es necesario establecer dicha información en el proceso para que pueda ser ejecutado. Tal como se ve en la Tabla 6.20, el proceso BPEL resultante del proceso

de traducción debe tener como mínimo las siguientes áreas: el área de inclusión de namespaces, en la cual se define donde se encuentra cada servicio; el área de definición de PartenrLinks, en la que se indica el mecanismos de conexión con cada uno de los servicios; el área de

definición de variables, en la cual se define cada uno de los parámetros necesarios en la invocación de los servicios; el área de inicialización de variables, en la cual se asigna el valor que debe tomar cada uno de los parámetros en la invocación del servicio; por último, el área de proceso,

donde se contiene la coreografía del proceso, obtenida a partir de la gramática definida.

Tabla 6.20 Identificación de las áreas dentro de la estructura de un

proceso BPEL.

<?xml version="1.0" encoding="UTF-8"?> <bpel:process

xmlns:bpel=”http://docs.oasis- open.org/wsbpel/2.0/process/executable” name="2_process_1_12" <!—- Área de Namespaces --> > <bpel:partnerLinks>

<!—- Área de PartenrLinks --> </bpel:partnerLinks>

<bpel:variables>

<!—- Área de Definicion de Variables --> </bpel:variables>

<bpel:sequence name="main"> <bpel:assign>

<!—- Área de Inicialización de Variables --> </bpel:assign>

<bpel:receive name="start" /> <bpel:sequence>

<!—- Área de Proceso --> </bpel:sequence>

<bpel:reply name="reply-ack" />

</bpel:sequence>

</bpel:process>


El proceso de traducción se realiza siguiendo la gramática propuesta en el presente capítulo. Así, cada uno de los elementos identificados en la gramática se corresponde con una función dentro del proceso de

traducción, realizándose llamadas entre funciones al igual que se implementan la mayoría de Compiladores Descendentes Recursivos o CDR. Por motivos de simplificación, solo se muestran en el presente capítulo aquellos elementos fundamentales en el proceso de traducción.

El resto de elementos implicados en el proceso de traducción no se detallan, ya que se puede encontrar información genérica en el proceso de diseño de compiladores.

En base a los objetivos del Compilador de Procesos, los orígenes y el estudio del resultado del proceso se define el algoritmo de compilación de procesos que una todas las partes identificadas y logre como resultado el BPEL ejecutable.

El algoritmo propuesto comienza en el elemento Traductor. En esta función se crea el documento BPEL con cada una de las áreas

identificadas en presente apartado. Tras invocar a la función que da inicio al proceso de traducción, y que recorre todo el árbol de traducción hasta finalizar el proceso, se introducen todos los namespaces de los servicios detectados, los partnerLinks, y se crean las variables a utilizar.

Posteriormente se crea el elemento que contiene el bloque del proceso, lo que en programación se conocería como el main del programa. Sobre este elemento se inicializan las variables con los valores que necesiten y se introducen aquellos elementos resultantes del proceso de traducción.

Tabla 6.21 Definición de función inicial de traducción.

funcion Traductor namespaces ← Namespace[]; variables ← Variables[]; parterLinks ← ParterLink[]; documento ← DocumentoBPEL; S ← S() //Llamada al proceso de traducción. elementoProcess ← bpel.GenerarElementoProcess(); para todo namespace ∈ Namespaces hacer elementoProcess.añadirNamespace(namespace) fin para elementoPartnerLink ← bpel.GenerarElementoPartnerLink(); para todo parterLink ∈ parterLinks hacer elementoPartnerLink.añadirPartnerLink(parterLi nk) fin para elementoPrcess.Añadir(elementoParterLink)


elementoVariable ← bpel.GenerarElementoVariable(); para todo variable ∈ variables hacer elementoVariable.AñyadirVariable(variable) fin para elementoPrcess.Añadir(elementoVariable) elementoMain ← bpel.GenerarElementoVariable(); para todo variable ∈ variables hacer elementoMain.AñyadirInicializacionVariable(var iable) fin para para todo elemento ∈ S hacer elementoMain.Añyadir(elemento) fin para elementoProcess.Añadir(elementoMain) devolver elementoProcess; fin funcion

La función inicial definida, Tabla 6.22, es la encargada de comenzar el proceso de traducción propiamente dicho. Esta función extrae el elemento inicio y crea su traducción, el cual se corresponde con el

elemento que da inicio al proceso, normalmente un evento de recepción de mensaje que se corresponde con la invocación de proceso. Si el siguiente elemento no es un evento fin, se procederá con la traducción de la estructura del proceso. Al tratarse de un CDR, se evalúa el elemento

antes de decidir por qué regla de la gramática se continúa la traducción. Por este motivo cuando finalice la función ya se habrá extraído el elemento que se corresponde con el evento fin, y que será el que provoque el final de la recursividad de la función T(). El último paso es,

por lo tanto, el que genera la traducción del elemento final, el cual se corresponde con el mensaje reply en el que se informa del estado de ejecución del mismo. El resto de elementos del traductor identificados en la gramática propuesta se diseñan, al igual que las funciones

presentadas, conforme a las recomendaciones en el desarrollo de Compiladores Descendentes Recursivos (Chakraborty et al., 2011).

Tabla 6.22 Pseudo-Código de la función de traducción S.

funcion S() manejadorDiagrama ← DiagramaBPMN inicio ← manejadorDiagrama.ObtenerElementoInicio(); si inicio <> ∅ entonces tradInicio ← Inicio(inicio) sino error fin si


elemento=manejadorDiagrama.ObtenerSiguiente(inic io); si elemento <> ∅ entonces si elemento ∉ E Fin entonces tradT ← T(elemento) fin si sino error fin si //Al tratarse de un CDR, se evalúan los elementos a ntes de //invocar a la función siguiente, por lo que se obtiene el // último nodo evaluado que debe ser el fin elementoFin=manejadorDiagrama.ObtenerUltimoEleme ntoEval() si elementoFin <> ∅ && elemento ∈ E Fin entonces tradFin ← Fin(elementoFin) fin si devolver tradInicio ∩ tradT ∩ tradFin fin funcion

Como ya se ha comentado, el objetivo principal es el de hacer transparente la tecnología que sustenta el proceso. Para ello, es necesario descubrir los servicios que implementan las actividades que se

realizan durante el proceso, así como identificar bajo qué condiciones el servicio obtiene el resultado esperado por el proceso. El sistema de traducción hace uso del Manejador SWS y Manejador de Ontología de

Planta de forma que se puedan conseguir los objetivos planteados. Es

precisamente en este punto donde la integración de información semántica supone una novedad respecto a los sistemas de traducción BPMN-BPEL existentes actualmente y posibilita el llegar a los objetivos propuestos, tal como se ha visto durante el estudio de los antecedentes.

La integración semántica se realiza durante el proceso de traducción de cada una de las tareas (bpmn:task), identificando la tarea y obteniendo la

información referente a qué servicio la ejecuta. A partir de esta información se puede obtener por un lado la información necesaria para poder invocar al proceso y por otro inferir el valor necesario de los parámetros con los que se debe invocar al servicio para lograr los

objetivos locales de la actividad, y que llevarán a lograr el objetivo global del proceso.

En la Tabla 6.23 se define el algoritmo de extracción de información

semántica que se ha diseñado a partir de las partes modeladas anteriormente. El Manejador de Procesos cumple la función de permitir extraer información del proceso BPMN. El Manejador de Ontología de

Planta permite establecer las relaciones entre procesos y servicios y permite conocer el estado de la planta donde se va a desarrollar el proceso. El Manejador SWS permite extraer la información referente al servicio que se va ejecutar y calcular el valor de sus parámetros, tal


como se ha explicado en el punto 6.2.1. Por último, el Manejador WSDL permite extraer las características tecnológicas bajo las que se invoca el servicio, tales como tipo de datos, parámetros, dirección, etc. El

algoritmo se ha estructurado en cinco partes asociadas a cada una de las áreas que componen el proceso BPEL identificadas en la Tabla 6.20. De esta forma, las 4 primeras partes generan el código necesario en cada una de las áreas, mientras que la traducción de la quinta parte es la que

es devuelta por la función, al formar parte de la estructura del CDR. Como ya se ha visto, las cuatro primeras partes guardarán en el objeto los valores a crear y será, al finalizar el proceso de traducción cuando se genere el código necesario en cada una de las áreas.

Tabla 6.23 Algoritmo de generación de elemento invoke BPEL a partir de información semántica.

función GenerarElementoInvoke(idTárea) manejadorDiagrama ← DiagramaBPMN manejadorSIMaaS ← OntologiaSIMaaS manejadorSWS ← Ontología SWS lectorWSDL ← DocumentoWSDL proceso ← manejadorDiagrama.ObtenerProceso(idTárea) procesoSig ← manejadorDiagrama.ObtenerProcesoSig(idTárea) servicio ← manejadorSISaaS.ObtenerServicio(proceso) servicioSig ← manejadorSISaaS.ObtenerServicio(procesoSig) rutaSWS ← manejadorSISaaS.ObtenerSWS(servicio) rutaSWSSig ← manejadorSISaaS.ObtenerSWS(servicioSig) manejadorSWS.Cargar(rutaSWS) wsdl ← manejadorSWS.ObtenerWSDLDocument(); //1-Generar Namespace namespaces.Añadir(wsdl); //2-Generar PartenrLink lectorWSDL.Cargar(wsdl) partenrLink ← lectorWSDL.ObtenerPartnerLink(); partenrLinks.Añadir(partenrLink); //3-Generar Variables wsdlInputMessage ← manejadorSWS.ObtenerWsdlInputMessage(); variables.GenerarVariable(“nombre”, wsdlInputMess age); wsdlOutputMessage ← manejadorSWS.ObtenerWsdlInputMessage(); variables.GenerarVariable(“nombre”, wsdlOutputMes sage); //4-Inicializar Variables wsdlInput ← manejadorSWS.ObtenerWsdlInput() partesEntrada ← manejadorSWS.ObtenerwsdlMessagePart(wsdlInput)


para todo parte ← partesEntrada hacer tipo ←lectorWSDL.ObtenerElementType(parte); valor ←manejadorSWS.CalculoParam (parte,rutaSWS,rutaSWSSig ) variables.AsignarValor(partesEntrada,parte,val or,tipo) fin para //5-Generar Traducción Invoke operación ← manejadoeSWS.ObtenerwsdlOperation(); portType ← lectorWSDL.ObtenerPortType invoke ← bpel.CrearElemento(partnerLink, portType, operacio n, inputMessage, OutputMessage) devolver invoke; fin funcion

Como resultado del proceso de traducción definido se obtiene una hoja

bajo el estándar BPEL (BPEL, 2007) que contiene toda la información referente a la orquestación del proceso y que puede ser desplegada en cualquier motor de ejecución que trabaje bajo el estándar BPEL. Por lo tanto, puede ser desplegado el proceso en una fábrica IMaaS quedando

disponible para su ejecución.

6.3 Modelo de Ejecución y Monitorización de Procesos El último proceso implicado en el �� está relacionado con la

ejecución y monitorización de los procesos. En el modelado conceptual se ha definido el proceso ��c como elemento conceptual

donde se recogen las necesidades de ejecución. Su entrada se corresponde con el proceso BPEL resultante del proceso de compilación ��. La salida de este proceso es por un lado la pieza fabrica y

por otro información del Nivel de Planta. Durante la actividad de ejecución los procesos de fabricación y de negocio se llevan a cabo en la planta industrial. La ejecución del proceso se realiza según las

especificaciones existentes en el proceso y se monitorizan para poder mantener información del Nivel de Planta. En el proceso de monitorización se define la funcionalidad de comprobar que la ejecución de los procesos se realice satisfactoriamente conforme a las reglas

establecidas dentro del mismo. Estos elementos tendrán una correspondencia sobre el ModArqGSPI propuesto en el capítulo 4. Tal como se ve en la Figura 6.8, durante esta sección se define el


comportamiento de los elementos funcionales definidos en el

�� que desarrollan el proceso ��c.

Figura 6.8 Correspondencia de la definición funcional del modelo de

ejecución y monitorización con sus entradas, salidas y la correspondencia con el ModConceptGSPI.

Durante la definición del �� se ha identificado la necesidad de establecer un mecanismo de retroalimentación del modelo propuesto, de

forma que el sistema de monitorización pueda, a partir de la información de ejecución de cada uno de los procesos, mantener la información semántica de la planta donde se encuentre, indicando los posibles errores en las máquinas industriales. De esta forma se puede indicar que

se prescinda de su uso en posteriores modelados hasta que se corrijan los problemas existen sobre la maquina.

En la presente sección se modela el funcionamiento interno del Monitor

de Procesos conforme a la especificación funcional dada durante la

definición del modelo funcional �� del capítulo 4.

6.3.1 Monitor de Procesos

En el Monitor de Procesos se define la funcionalidad de comprobar la

correcta ejecución del proceso y el estado de entorno de ejecución en cada momento. Será el responsable de actualizar el estado del sistema si se detecta algún problema durante la ejecución de algún proceso. Otra


de las necesidades que debe aportar el Monitor de Procesos es la de la recuperación de procesos fallidos durante la ejecución. Durante la presente sección se detalla la funcionalidad y la forma de llevarla a cabo

conforme al modelado conceptual �� expuesto en la Figura

4.9. Como la regeneración de un proceso implica volver a pasar por todo el proceso de gestión definido en el elemento ��#�. ��#�23 (punto 4.1)

se ha establecido que la integración más natural es extrayendo del proceso BPEL el Proceso Funcional con los objetivos del proceso y volviendo a realizar el Modelado para la planta.

El Monitor de Procesos se compone de una serie de elementos funcionales específicos para cubrir las funcionalidades necesarias, tal como se ve en la Figura 6.9. El Monitor de Procesos es el encargado de llevar la

coreografía del proceso de monitorización. El Manejador de Procesos

BPEL es el encargado de extraer la información del proceso BPEL. Entre las funcionalidades de este elemento está la de extraer el elemento inicio, fin, obtener un servicio concreto o su predecesor y antecesor. Al usarse

tecnologías estándar para obtener información acerca de un servicio determinado dentro de un proceso BPEL, será necesario utilizar el elemento MatchMaker Semántico. Este elemento permite consultar en un sistema de información concreto todos los SWS e identificar cual se

corresponde con el Servicio Web que se busca. Una vez se identifico el SWS, se puede interconectar con la ontología del nivel de planta a través del Manejador de Ontología de Planta (punto 6.1.2) y extraer información

referente a las máquinas y procesos, para generar el Proceso Funcional y actualizar el nivel de planta.

El Monitor de Procesos se concibe como un servicio de monitorización, el

cual recibe como entrada la información de ejecución de un proceso, estado, identificador de proceso, etc. y actúa para actualizar y recuperar, si es necesario, la ejecución del proceso.

El Manejador de Errores es el encargado de identificar el estado de las máquinas IMaaS dentro de una fábrica IMaaS y determinar la acción que se debe tomar en cada momento. Hace uso de la información semántica

para obtener la información referente a una máquina industrial y poder realizar acciones de comprobación y corrección sobre las mismas, antes de determinar el estado global del sistema. Una vez identificado el problema se determina la acción a realizar sobre la ontología en el

Sistema de Información en función de los resultados obtenidos durante las comprobaciones.


Figura 6.9 Elementos del Monitor de Procesos.

Para poder acceder a los servicios de soporte, el manejador de errores

conoce la maquinaria industrial a través de la descripción semántica del servicio que ha fallado. El Manejador de Errores hace uso de los servicios de soporte definidos en cada máquina para realizar las comprobaciones

correspondientes. Para conocer que acción se debe realizar, se debe definir sobre el Manejador de Errores una política de actuación en caso de fallos. Estas reglas que se definan son las que guiarán la acción a tomar ante cada tipo de fallo.

La función principal del Manejador de Procesos BPEL es encapsular los procesos de extracción sobre el proceso ejecutable, de forma que se puedan obtener los servicios utilizados, los predecesores y antecesores,

la estructura del proceso y la llamada que ha causado el problema.

Se ha dado el nombre Matchmaker, por ser el término en la literatura, a

la parte del sistema capaz de buscar un servicio concreto entre un conjunto de SWS en función de alguna de sus características. El matchmeker es el encargado de encontrar qué descripción semántica se corresponde con cada Servicio Web.


El Manejador de SWS (definido en el punto 6.2.1) tendrá el rol de extraer información acerca de qué máquinas ejecutan que servicios de forma que se pueda identificar la fuente del problema que se ha encontrado

durante la ejecución.

El Manejador de Ontología de Planta (definido en punto 6.1.2) contiene la

funcionalidad encargada de manejar la ontología con información de la planta, a partir de cuestiones genéricas pre-establecidas sobre la ontología se puede obtener numerosa información en los procesos de inferencia, como ya se ha comentado anteriormente.

Por último, el Manejador de BPEL dispone de una gramática inversa a la definida en el compilador de procesos, para poder realizar la conversión desde el proceso BPEL a un proceso funcional BPMN.

La funcionalidad de actualización de la ontología de planta, concebida durante el modelado del proceso de monitorización, se basa en

identificar el origen del problema y actualizar la información que refleje este problema en la ontología de planta. Este proceso se realiza haciendo uso de la propia información semántica disponible en el sistema, tal como se muestra en Tabla 6.24. En un primer paso se identifica el origen

del problema durante la ejecución del proceso, se extrae la información de la descripción semántica del servicio y de la máquina que ejecuta dicho servicio. En función del tipo de error y de la máquina que ejecute el servicio, el Manejador de Errores selecciona la acción a tomar y se

aplica sobre la ontología.

Tabla 6.24 Pseudo-código de la función de actualización de la ontología.

function ActualizarOntologia(idServicio, bpel, tipoError) manejadorBPEL matchmakerSemantico manejadorSWS matchmaker manejadorError infoServicio ←maejadorBPEL.ObtenerInfoServicio(idServicio) uriSWS ←matchmaker.Buscar(infoServicio) uriProcess ←manejadorSWS.ObtenerProcess(uriSWS) uriMaquina ←manejadorSWS.ObtenerPerformedBy(uriProcess) manejadorOntologia.cargarOntologia(uriMaquina) acción ←manejadorError.CalcularAccion(uriMaquina, tipoError ) manejadorOntologia.Aplicar(accion, uriMaquina) manejadorOntologia.Publicar() fin funcion


Una de las necesidades del proceso de traducción desde un proceso BPEL a un proceso funcional BPMN es que cumpla las siguientes premisas:

• Mantener información estructural del proceso pendiente de

ejecutar.

• Identificar punto (o puntos) donde se ha producido el error, ya

que será desde donde se empiece el próximo proceso.

• Eliminar toda información referente a las características físicas

del proceso, incluyendo máquinas de transporte y procesado.

Extraer el objetivo del proceso concreto.

A partir de estas premisas se propone un algoritmo para extraer un Proceso Funcional en función de los objetivos pendientes por cumplir. Se extrae el proceso principal y se crea su evento. Como todo BPEL

comienza en un elemento sequence se envía este elemento a la función recursiva en la que se implementa la traducción.

Tabla 6.25 Función de extracción del proceso funcional a partir de un

proceso completo expresada en pseudo-código.

func ion ExtraerProcesoFuncional manejadorBPMN ← DiagramaBPMN manejadorBPEL ← DiagramaBPEL inicio ←manejadorBPEL.ObtenerInicio() inicioBPMN ← manejadorBPMN.CrearEventoInicio(inicio) elementoBPMN ← T(inicio,inicioBPMN) finBPMN ← manejadorBPMN.CrearEventoFin() manejadorBPMN.crearArco(elementoBPMN, finBPMN) fin funcion

La función de traducción es más simple que la función de compilación, ya que en BPEL los elementos se encuentran anidados, por lo que se encapsulan de manera más simple. Así, en función del tipo de elemento que se esté evaluando se crea su elemento en el diagrama BPMN y se

une los arcos. Todos los hijos de un elemento sequence son elementos que están unidos unos detrás de otros, por lo que el orden en el que se evalúen los hijos tiene importancia. El elemento flow conecta todos sus

hijos de manera paralela. El elemento invoke, que se corresponde con la ejecución de un proceso, es sobre el que se realiza el proceso de inferencia definido en las funciones siguientes. De esta forma se genera


la estructura de un proceso funcional BPMN que puede ser devuelto al compositor de procesos para generar un proceso alternativo.

Tabla 6.26 Elemento recursivo de extracción de elemento funcional a partir de proceso completo.

función T(elementoBPEL,antecesorBPMN) manejadorBPMN ← DiagramaBPMN manejadorBPEL ← DiagramaBPEL si elemento ∈ flow entonces parallelIni ← manejadorBPMN.crearParallelGateway() manejadorBPMN.crearArco(antecesorBPMN, parall elIni) parallelFin ← manejadorBPMN.crearParallelGateway() hijos ← manejadorBPEL.ObtenerHijosAnidados(elementoBPEL); para cada hijo ∈hijos hacer elemAux ← T(hijo,parallelIni) manejadorBPMN.crearArco(elemAux,parallelFi n) fin para retorno ← parallelFin fin si si elemento ∈ invoke entonces si EvaluarInvoke(elementoBPEL) = objetivo entonces elemetoBPMN ← manejadorBPMN.crearTask(elementoBPEL); manejadorBPMN.crearArco(elemAux,parallelFi n) retorno ← elementoBPMN fin si fin si si elemento ∈ sequence entonces elemAux=antecesorBPMN hijos ← manejadorBPEL.ObtenerHijosAnidados(); para cada hijo ∈hijos hacer elemSig ← T(hijo,elemAux) elemAux = elemSig fin para retorno elemAux; fin si ... IF... ... IF ELSE ... devolver retorno; fin funcion

La función definida como EvaluarInvoke recogida en Tabla 6.27 realiza el

proceso de inferencia para conocer de qué clase de proceso se trata y deducir, por lo tanto, si se trata de un proceso objetivo o de un proceso de transporte que no afecta al resultado del proceso. Si se trata de un proceso objetivo será seleccionado para mantenerse en el proceso


funcional. En caso contrario, la actividad será descartada por contener información estructural.

Tabla 6.27 Evaluación de cada tipo de servicio.

funcion EvaluarInvoke(servicio) manejadorSWS ← Ontología SWS matchmaker ← Matchmaker manejadorSIMaaS ← OntologiaSIMaaS uriSWS ←matchmaker.ObtenerServicio(servicio) manejadorSWS.cargar(uriSWS) uriProceso ←manejadorSWS.ObtenerServiceCategory(uriSWS) claseProceso ←manejadorSIMaaS.ObtenerClass(uriProceso) si claseProceso ∉ manejadorSIMaaS.ManejoDeMateria() entonces devolver ‘objetivo’ sino devolver ‘no objetivo’ fin si fin función

La funcionalidad definida para crear una tarea, Tabla 6.28, realiza la extracción del tipo de proceso que se corresponde con un servicio concreto y obtiene la clase genérica a la que pertenece, de forma que se elimina la información referente a una máquina concreta que lo

desarrolla y se puede volver a seleccionar cualquier máquina que sea capaz de cumplir el objetivo durante el proceso de composición.

Tabla 6.28 Función de creación de tarea a partir de un elemento.

funcio n crearTask(elementoBPEL) manejadorSWS ← Ontología SWS matchmaker ← Matchmaker manejadorSIMaaS ← OntologiaSIMaaS manejadorBPMN ← DiagramaBPMN uriSWS ←matchmaker.ObtenerServicio(elementoBPEL) manejadorSWS.cargar(uriSWS) uriProceso ←manejadorSWS.ObtenerServiceCategory(uriSWS) claseProceso ←manejadorSIMaaS.ObtenerClass(uriProceso) elementoBPMN ←manejadorBPMN.CrearTask(clasePrtoceso) devolver elementoBPMN fin funcion

Durante este capítulo se han definido las funcionalidades necesarias para llevar a cabo el proceso de Gestión Semántica de Procesos

Industriales ��#�. ��#�23. Como resultado de los puntos desarrollados

se obtienen todos los elementos necesarios establecidos en el marco


formal, que guía este trabajo de investigación. Durante el desarrollo de cada punto se han establecido, a partir de las necesidades conceptuales definidas en el ModConceptGSPI, las funcionalidades necesarias para

resolver los problemas identificados y lograr la Gestión Semántica de los

Procesos de Fabricación. Estas funcionalidades se han encapsulado en una serie de elementos especializados, los cuales se centran en resolver

partes de los problemas identificados. Mediante la definición de la colaboración entre estos elementos se ha logrado definir un modelo que cubra los objetivos propuestos. Finalmente, los elementos identificados tienen una correspondencia con elementos del modelo arquitectónico

ModArqGSPI definido, permitiendo situar los elementos modelados funcionalmente sobre el modelo arquitectónico propuesto.

C a p í t u l o 7

Implementación y Validación

En el primer capítulo se describió el marco metodológico científico

utilizado para llevar a cabo el presente trabajo, siendo el método

hipotético-deductivo el procedimiento general que ha guiado todo el proceso de investigación. En esta última etapa el objetivo es la validación

o refutación de la hipótesis a través de la experimentación. Para ello, es necesario definir un conjunto de experimentos derivados de la hipótesis que sirvan para validar el correcto diseño del Modelo de Gestión

Semántica de Procesos Industriales, y diseñar e implementar un

escenario en un entorno realista que permita llevar a cabo estos experimentos.

La primera parte del capítulo se centra en el diseño e implementación de

un prototipo del modelo propuesto que sirva como escenario de pruebas, disponiendo de un entorno productivo con un Nivel de Planta compuesto por más de una Fábrica IMaaS. En la segunda parte del capítulo, se

diseña y desarrolla un conjunto de experimentos sobre el escenario de pruebas implementado con el fin de validar o refutar el modelo propuesto en función del cumplimiento de los objetivos establecidos en el presente trabajo.


7.1 Diseño e Implementación del Escenario de Pruebas Para poder realizar la experimentación sobre un escenario realista es necesario diseñar e implementar un prototipo que recoja los componentes propuestos y los implemente de forma que sea posible

realizar una simulación de diferentes casos en la gestión de procesos industriales en entornos de producción ágil.

El prototipo se ha implementado de acuerdo con la arquitectura del

sistema propuesto en el capítulo 4. Concretamente, en la Figura 4.19 se mostraba el ModArqGSPI compuesto por los diferentes elementos del modelo en una típica arquitectura SOA. Cada uno de estos elementos se ha implementado haciendo uso de las tecnologías disponibles en el

mercado, con lo que se pueden realizar las simulaciones sobre un escenario realista.

Cada uno de los elementos identificados durante el modelado funcional ModFuncGSPI, y detallados durante los capítulos 5 y 6, se ha implementado bajo una tecnología concreta. Tal como se ve en la Figura 7.1, la parte de modelado y compilación de de procesos se ha

desarrollado haciendo uso de la herramienta ECLIPSE, creando una serie de plugins que permitan acceder a cada una de las funcionalidades propuestas en la presente tesis. Como sistema de información se ha utilizado un Servidor Web Apache con el servidor de Servlets Tomcat. El

sistema de ejecución, o Nivel de Planta, se ha implementado haciendo uso de la maquinaria industrial IMaaS implementada en (Gilart, 2010) y el motor de orquestación APACHE ODE.

En el Nivel de Planta se dispone de dos Plantas IMaaS. Mediante estas dos plantas se pueden realizar pruebas sobre la flexibilidad e independencia del modelado de procesos respecto al nivel de planta.

Durante las siguientes secciones se detalla los aspectos de la implementación de cada una de las partes de la arquitectura del sistema propuesto. Comentando las versiones utilizadas en cada uno de los

componentes.

Capítulo 7. Implementación y Validación 197

Figura 7.1 Tecnologías del prototipo del modelo ModArqGSPI propuesto.

7.1.1 Planta IMaaS

El objetivo de implementar diferentes sistemas de fabricación es

conseguir desarrollar diferentes prototipos de fábricas, donde cada una de las máquinas industriales IMaaS (Gilart, 2010) es ofertada como servicio. De esta forma se obtienen diversas plantas con características diferentes, lo que permite realizar pruebas sobre la composición de

procesos ad-hoc para cada planta.

Se han diseñado dos plantas industriales modulares, que permiten

diversas configuraciones según la colocación de sus módulos. La implementación del diseño propuesto ha sido realizado por la empresa STAUDINGER GMHB (Staudinger, 2010) donde cada uno de los componentes industriales incluye un controlador de la marca ICPDAS (ICPDAS, 2010), modelo I-7055D que ofrece una interfaz serie RS-485 y

16 canales digitales de entrada-salida independientes que permiten mediante el uso del protocolo propietario DCOM (DCOM, 2010) la gestión de la maquinaria. Además, se han utilizado otros dos controladores modelos ICPDAS I-7520 e ICPDAS I-7561, uno como transformador RS-


485 a RS-232 y otro como pasarela RS485 a USB debido a que estas interfaces son más comunes en los dispositivos computacionales.

Sobre estas máquinas industriales se ha utilizado la implementación del prototipo usado en (Gilart, 2010) basado en el dispositivo de la marca Lantronix denominado XPort (XPORT, 2010). Este prototipo tiene entre sus principales ventajas su bajo coste económico y de consumo

energético, su alta velocidad de respuesta, robustez, posibilidad de ampliar su funcionalidad mediante el uso del lenguaje C estándar. En este prototipo se han implementado las funcionalidades básicas, marcadas en amarillo en la Figura 7.2, como el módulo de persistencia,

el módulo de tiempo, un motor de orquestación WS-BPEL, el módulo de despliegue o el módulo SOAP, entre otros.

Figura 7.2 Implementación del prototipo IMaaS.

Sistema operativo

Middleware IMaaSWS-BPEL

WS-Transaction

WS-Coordination WS-ResourceFramework

WS-Notification

WS-Addressing

WS

-XA

CM

L

WS-Security

WS

-Po

licy

WS

-Metad

ataExchange

SOAP

HTTP

SSL/TLS

WS

-UD

DIR

egister

WS

-BusinessR

ules

WSDM WS

-Persistence

WS

-Tim

e

WS

-BP

MS

Dep

loyment

de Adquisiciónde AdquisiciónServicios de Actividad

Servicios de

Fabricación

Servicios de

Fabricación

Servicios de Producción Servicios

de Fabricació

n

Servicios de

Fabricación

Servicios Orientados a

la TareaServicios

de Fabricació

n

Servicios de

Fabricación

Servicios de Entidad

BPEL+

WSDL+

KPI

WSDL+

KPI

WSDL+

BRWSDL


La primera planta diseñada, Planta 1 en adelante, está compuesta por una serie de máquinas que permiten la simulación de diversos procesos de fabricación. La línea de fabricación flexible está compuesta por una

fresadora vertical (MT1), una Máquina Multi Herramienta de tres ejes (MMT1), una mandriladora-fresadora vertical (MT2) y una segunda mandriladora-fresadora vertical (MT3). Las Máquinas de Transporte de la

planta se dividen en nueve Cintas Transportadoras (de la CB1 a CB9) las cuales transportan una materia de inicio a fin o la paran en algún punto determinado de la cinta. Cuatro Mesas de Giro (de TT1 a TT4), las cuales funcionan como una Cinta Transportadora, pero tienen la funcionalidad

de girar en un ángulo de 90º, de forma que puede unir hasta cuatro líneas de elementos de transporte. Por último, dispone de de un Raíl de

Carga (RC1) que permite transportar una Materia entre diversas líneas

de elementos de transporte situados no contiguamente. En la Figura 7.3 se ve el plano de la Planta IMaaS 1, con la distribución de cada una de sus máquinas (a) y su apariencia real (b).

La segunda planta diseñada, Planta 2 en adelante, dispone de una estructura completamente diferente a la anterior. Está compuesta por cuatro Máquinas Herramienta (de MT1 a MT4), diez Cintas

Transportadoras (de CB1 a CB10), cuatro Mesas de Giro (de TT1 a TT4) y un Raíl de Carga (RC1). Las diferentes máquinas se distribuyen por una planta con una estructura rectangular, tal como se puede apreciar en la

Figura 7.4. La diferente estructura entre ambas plantas, permite realizar experimentos para comprobar la composición de procesos ad-hoc en función de la planta industrial donde se vaya a desarrollar el proceso.

Como se ha visto, el escenario de pruebas está compuesto por 5 tipos diferentes de máquinas industriales: Cintas Transportadoras, Mesas de

Giro, Raíles de Carga, Máquinas Herramienta y Máquinas Multi

Herramienta. Cada una de estas máquinas tiene una serie de

operaciones implementadas y ofertadas como servicio. Tal como se ve en la Tabla 7.1, las Cintas Transportadoras, Mesas de Giro y Raíles de Carga tienen servicios asociados con el desplazamiento de materia, mientras

que las Máquinas Herramienta y las Máquinas Multi Herramienta disponen de servicios relacionados con la transformación de materias.

Estas operaciones están ofertadas como Servicios Web bajo el protocolo

SOAP (SOAP, 2013), y disponibles a través de los servidores web incorporados en la maquinaria industrial.


Figura 7.3 Plano de la


Plano de la Planta 1 (a) y elementos de fabricación (b).

(b).


Figura 7.4 Plano de la Planta 2 (a) y elementos de fabricación (b).

Tabla 7.1 Servicios ofertados por cada tipo de Máquina Industrial.

Operación Parámetros Retorno Descripción

Cinta Transportadora: CB

MoverHastaElFinal Direction:char Boolean Mueve la materia de un extremo a otro en la dirección indicada.

MoverHastaElSensor Sensor:int Direction:char

Boolean Mueve la materia hasta el sensor

Mesa de Giro: TT

MueveEnDireccion DirectionX:char DirectionY:char

Boolean Mueve la mesa en la dirección X e Y indicadas.



GirarMesa Direction:char Boolean Realiza un giro de 90º en la dirección indicada.

Rail de Carga: RC

MoverHastaElFinal Direction:char Boolean Mueve la materia


de un extremo a otro en la dirección indicada.



MueveEnDireccion DirectionX:char DirectionY:char

Boolean Mueve la materia en la dirección X e Y indicadas, lo que implica un desplazamiento en uno o dos ejes.

Máquina Herramienta: MT

Procesar Segundos:int Boolean Procesa una materia durante los segundos indicados.

Máquina Multi Herramienta: MMT

Procesar Segundos:int Boolean Procesa una materia durante los segundos indicados.

ProcesarConHerramienta

Segundos:int Herramienta:int

Boolean Procesa una materia durante los segundos indicados con la herramienta indicada.

Además de la tecnología asociada a la ejecución de servicios y la interactuación con los elementos físicos del Nivel de Planta, se implementa también la ontología IMaaSTBox de los diferentes elementos

del Nivel de Planta. Para ello, como ya se ha visto en el capítulo 5 se utiliza una ontología terminológica establecida en el lenguaje OWL (Horridge & Patel-Schneider, 2012) sobre los conceptos del Nivel de

Planta. A partir de esta ontología se instancian las ontologías especificas de cada una de las plantas IMaaS. Obteniendo la ontología asercional IMaaSAbox PlantaX

La conceptualización de cada una de las plantas se corresponde con la instanciación de los diferentes elementos. A modo de ejemplo se visualizan las características instanciadas para una Máquina de

Procesado y una de Máquina de Transporte con sus Procesos y Servicios. Se puede encontrar las características completas de cada una de las instancias de planta en las tablas del Anexo I.


Como ejemplo, se utilizarán las máquinas de la Planta 1 recogidas en la Figura 7.3, etiquetadas como MT3 (Máquina Herramienta) y la Cinta

Transportadora que tiene asociada, denominada CB4. En la tabla se han definido alunas propiedades y expresadas como tripletas de RDF (RDF, 2004) objeto, sujeto, valor.

Tabla 7.2 Propiedades de la Máquina de Transporte CB4 y de la Máquina

Herramienta MT3 de la Planta 1.

Sujeto Predicado Objeto

CB4 type Cinta_Transportadora Tiene_conexion_eje_X+

RC1

Tiene_conexion_eje_X-

CB3

MT3 type Máquina_herramienta Esta_asociada

CB4

CruzarMaquina_CB4

type CruzarMaquina Es_realizado

CB4

Mover_hasta_el_sensor_CB4

type Parar_en_Punto_Determinado Es_realizado

CB4

TurningMT3 type Turning Es_implementado

MT3

Procesar_MT3 type Servicio_de_Actuacion Ejecuta TurningMT3 URL http://localhost:8080/fabrica1/MT3/MT

3_Service.owl#Process_Service WSDL http://localhost:8080/axis2/services/M

T?wsdl MoveToEnd_CB4

type Servicio_de_Actuacion Ejecuta CruzarMaquina_CB4 URL http://localhost:8080/fabrica1/CB4/CB

4_Service.owl#MoveToEnd_Service WSDL http://localhost:8080/axis2/services/C

B4?wsdl MoveToSensor_CB4

type Servicio_de_Actuacion Ejecuta Mover_hasta_el_sensor_CB4 URL http://localhost:8080/fabrica1/CB4/CB

4_Service.owl#MoveToSensor_Service WSDL http://localhost:8080/axis2/services/C

B4?wsdl


Estas propiedades se implementan en lenguaje OWL (Horridge & Patel-Schneider, 2012), basado en XML, quedando en un lenguaje que es fácilmente interpretable por un sistema informático.

Tabla 7.3 Ejemplo de instanciación de cinta transportadora.

<Declaration>

<NamedIndividual IRI="#CB4"/> </Declaration>

<ClassAssertion>

<Class IRI="#Cinta_Transportadora"/> <NamedIndividual IRI="#CB4"/> </ClassAssertion>

<ObjectPropertyAssertion>

<ObjectProperty IRI="#Tiene_conexion_ejeX-"/> <NamedIndividual IRI="#CB4"/> <NamedIndividual IRI="#CB3"/> </ObjectPropertyAssertion>


<ObjectProperty IRI="#Tiene_conexion_ejeX+"/> <NamedIndividual IRI="#CB4"/> <NamedIndividual IRI="#RC1"/> </ObjectPropertyAssertion>

Tal como se ve en la Tabla 7.4, se define el proceso CruzarMaquina_CB4, como un proceso realizado por la máquina CB4, a su vez se define que servicio implementa el proceso y su direccionamiento y descripción.

Tabla 7.4 Instanciación de proceso y servicio de la máquina CB4.

<Declaration>

<NamedIndividual IRI="#CruzarMaquina_CB4"/> </Declaration>

<ClassAssertion>

<Class IRI="#Cruzar_Máquina"/> <NamedIndividual IRI="#CruzarMaquina_CB4"/> </ClassAssertion>


<ObjectProperty IRI="#Es_realizado"/> <NamedIndividual IRI="#CruzarMaquina_CB4"/> <NamedIndividual IRI="#CB4"/> </ObjectPropertyAssertion>

<Declaration>

<NamedIndividual IRI="#MoveToEnd_CB4"/> </Declaration>

<ClassAssertion>

<Class IRI="#Servicio_de_Actuacion"/> <NamedIndividual IRI="#MoveToEnd_CB4"/> </ClassAssertion>


<ObjectProperty IRI="#Ejecuta"/> <NamedIndividual IRI="#MoveToEnd_CB4"/>


<NamedIndividual IRI="#CruzarMaquina_CB4"/> </ObjectPropertyAssertion>

<DataPropertyAssertion>

<DataProperty IRI="#URL"/> <NamedIndividual IRI="#MoveToEnd_CB4"/> <Literal datatypeIRI= "http://www.w3.org/2001/XMLSchema#anyURI"> http://localhost:8080/fabrica1/CB4/CB4_Service.owl#MoveToEnd_Service

</Literal>

</DataPropertyAssertion>

<DataPropertyAssertion>

<DataProperty IRI="#WSDL"/> <NamedIndividual IRI="#MoveToEnd_CB4"/> <Literal datatypeIRI= "http://www.w3.org/2001/XMLSchema#anyURI"> http://localhost:8080/axis2/services/CB4?wsdl

</Literal>

</DataPropertyAssertion>

La instanciación de cada una de las plantas se ha realizado usando la

herramienta PROTÉGÉ en su versión 4.2.0 (build 295) y siguiendo las especificaciones indicadas en el Anexo I. El resultado de la instanciación de cada fábrica es un fichero en formato OWL por fábrica, el cual queda disponible para el resto del sistema.

La ontología que contiene la información de la Planta 1 tiene un total de 546 axiomas y 146 individuos, uniéndose a los 551 axiomas, 55

propiedades de objetos y 9 propiedades de datos de la ontología terminológica. Por otro lado, la ontología de la Planta 2 está compuesta por 435 axiomas y 135 individuos que actúan también sobre los axiomas y propiedades de la ontología TBox de la planta industrial.

Cada uno de los servicios de cada máquina dispone de su descripción semántica de servicio especificada en lenguaje del W3C OWL-S (OWL-S, 2004). La especificación inicial de los servicios se ha realizado con la

herramienta PROTÉGÉ 4.2. La ontología OWL-S se basa a su vez en tres ontologías. La ontología OWL Process (OWLProcess, 2004) contiene la información semántica del proceso, como que conceptos son los parámetros, que máquina ejecuta el servicio, que prerrequisitos y que

etc. El OWL Grounding (OWLGrounding, 2004) especifica los datos de cómo acceder al servicio, más relacionados con datos de conexión, descripción de servicio, etc. EL OWL Profile (OWLProfile, 2004) identifica las condiciones para ejecutar el servicio, los efectos de su ejecución, etc.

A modo de ejemplo se visualiza en la Figura 7.5 la parte correspondiente al OWL Grounding del Servicio de la Cinta Transportadora 4 (CB4), donde se ve en las propiedades de datos las especificaciones de conexión del servicio y en las propiedades de objetos cómo se referencia a cada uno de

los parámetros de entrada o salida del servicio.


Figura 7.5 Datos de conexión en la descripción semántica del servicio de una Cinta Transportadora.

Por otro lado, se ha visto en la propuesta del modelo que cada una de las

Plantas IMaaS dispone de un motor de orquestación externo a la maquinaria industrial para aquellos procesos que necesiten de la ejecución de varios servicios ofertados por diferentes máquinas. Dicho motor de orquestación, el cual ejecuta los procesos mediante la

especificación WS-BPEL, se ha implementado utilizando el motor BPEL Apache ODE (ODE, 2012). Apache ODE implementa la especificación WS-BPEL 2.0. El motor de orquestación ofrece una capa de comunicación basada en Apache Axis2 que hace transparente su

integración. Además, ofrece un servicio de despliegue en caliente para instalar los nuevos procesos sin necesidad de reiniciar el servicio.

7.1.2 Sistema de Información

El Sistema de Información contiene la información de los servicios y de las ontologías implicadas en el prototipo. Se ha implementado en un

contendor de Servlets Apache Tomcat (7.0.27) (Tomcat, 2013), que puede funcionar como servidor web por sí mismo. La elección de Apache Tomcat como servidor a través del cual se ofertan tanto los servicios como la información necesaria es debido a que el servidor Apache es un


servidor de código abierto de los más populares en la actualidad. El servidor posee una arquitectura modular que permite la incorporación de nuevas funcionalidades.

El Sistema de Información cuenta con una interfaz desarrollada en JSP (JSP, 2013), la cual permite registrar información de las ontologías de las

plantas y las descripciones semánticas de cada servicio. Por otro lado, el sistema de despliegue de procesos BPEL se ha realizado sobre el sistema de orquestación de procesos Apache ODE v1.3.5 (ODE, 2012), el cual dispone de su propia interfaz para el despliegue de procesos a partir de

las hojas BPEL, su descripción WSDL y un fichero de despliegue en formato propio del servidor, denominado deploy.xml

La persistencia de la información se ha realizado propio sistema de

ficheros del servidor. Al tratarse de un prototipo se ha simplificado la estructura, prescindiendo de un Sistema Gestor de Base de Datos para hacer persistente la información.

7.1.3 Sistema de Gestión Semántica de Procesos de

Fabricación. BPMS Semántico.

Las funcionalidades identificadas en el modelo funcional ModFuncGSPI

relacionadas con la gestión de procesos de negocio se encuentran en el denominado BPMS Semántico. Todos los elementos que componen este nivel, desarrollados en el capítulo 6, se han implementado formando un BPMS. Este BPMS se ha implementado sobre la herramienta de Software

Libre ECLIPSE (Eclipse, 2014). Concretamente se ha desarrollado en ECLIPSE KEPLER en su versión 4.3.0 build id:20130614-0229. Sobre esta herramienta se han desarrollado una serie de plug-ins y se han utilizado plug-ins de terceros para implementar todas las

funcionalidades desarrolladas en la presente tesis.

Todos los plug-ins de ECLIPSE se han desarrollado mediante el lenguaje

Java, y se ha utilizado el entorno de ejecución jre1.7.0_23 (Java, 2012) durante el desarrollo de las pruebas.

El Modelador de Procesos se ha apoyado en el plug-in BPMN2 Modeler

(BPMNModeler, 2013) en su versión 0.2.6.201307252209. Este modelador soporta la especificación del estándar BPMN2. En el momento del desarrollo de la presente tesis, se encontraba en estado de incubación.


La parte correspondiente al Compilador de Procesos se ha desarrollado sobre Eclipse. Para visualizar de forma gráfica los procesos resultantes se ha utilizado el pluig-in BPEL Visual Designer en su versión

1.0.3v20130509-1351-CI (BPELDesigner, 2012). Esta herramienta permite visualizar la estructura y los detalles de una hoja BPEL a través de un diagrama gráfico y las ventanas de propiedades que implementa.

Se ha desarrollado un plug-in que permite la importación de ontologías al sistema para trabajar con ellas de forma local, este plug-in se ha desarrollado haciendo uso del API OWLAPI 3.4.3 (Horridge & Bechhofer,

2013). Mediante este API se han obtenido las funcionalidades básicas de manejo de la ontología.

Los razonadores que permiten extraer información, tanto de los

diagramas como de las plantas, se han desarrollado en J2EE haciendo uso del API OWLAPI y el razonador PELLET en su versión v.2.3.0 (Sirin et al., 2007). Se ha escogido el razonador PELLET por implementar soporte para el lenguaje de reglas SWRL y tener un tiempo de ejecución

menor que otros razonadores probados. PELLET es uno de los razonadores que implementa el protocolo DIG, por lo que podría ser sustituido por cualquier otro razonador DIG sin impacto sobre la funcionalidad del sistema.

Los plug-in de Composición de Procesos y de Compilación se han desarrollado en J2EE especificando el código necesario para cumplimentar las etapas que se han indicado en los capítulos 5 y 6.

Tanto los procesos BPMN como BPEL están basados en XML, por lo que se ha utilizado el API JDOM 1.1.1 (JDom, 2007) para la escritura y lectura de ficheros en los formatos .bpmn y .bpel.

7.2 Pruebas y Validación Para realizar las pruebas que permitan validar o refutar lo propuesto en el presente trabajo de tesis se ha diseñado una serie de experimentos que cubren los diferentes objetivos expuestos. Los experimentos se han diseñado teniendo en cuenta que hagan uso de todas las funcionalidades

identificadas e implementadas en el modelo propuesto, de forma que se valide el resultado y utilidad de cada una de las etapas desarrolladas.

Se diseñan tres tipos de experimentos para poder validar las diferentes

hipótesis propuestas:


• Experimentación T1: generación de un proceso para varias plantas a partir de un único proceso funcional. Para validar la hipótesis de que es posible crear un proceso ad-hoc para diversas plantas a partir de la ontología de ellas.

• Experimentación T2: generación de un proceso para varias plantas a partir de varios procesos funcionales. Para validar la hipótesis que se puede, además de componer el proceso ad-hoc, optimizar el uso de recursos en función de las reglas definidas de forma que se puedan componer de manera automática

procesos concurrentes sobre la misma planta.

• Experimentación T3: recuperación ante fallos de planta. Para validar la hipótesis de que se puede recuperar un proceso de fabricación actualizando la ontología del dominio.

Los experimentos se desarrollan en dos partes diferenciadas: en una

primera parte se expone el funcionamiento del sistema implementado de forma descriptiva utilizando un Proceso Funcional de ejemplo sobre el que se realiza la experimentación; la segunda parte se centra en validar y analizar de forma cuantitativa el funcionamiento del sistema

implementado, para ello se prueban quince Procesos Funcionales diferentes sobre ambas plantas.

La experimentación T1 está orientada a probar el modelado de procesos independiente de las infraestructuras de fabricación. Para ello se implementará un Proceso Funcional, a partir del cual se realizarán todas las fases para cada una de las plantas. El Compositor de Procesos

modelara un proceso a medida de cada una de las plantas, seleccionará el mejor según los criterios establecidos y se procederá a su despliegue en la Planta IMaaS que corresponda. Una vez desplegado se puede

invocar para que el proceso sea desarrollado. Este experimento se puede apreciar de forma esquemática en la Figura 7.6.

La experimentación T2 se corresponde con la composición automática de

procesos complejos sobre cada una de las plantas. Este experimento tiene como objetivo validar la composición ad-hoc de procesos compuestos a partir de procesos simples. Se pretende agilizar e incrementar el uso de los recursos de planta permitiendo el modelado y

ejecución de un proceso que cumpla con la especificación de varios Procesos Funcionales. Desde el punto de vista de la personalización masiva permite el modelado automático de diversos procesos en un único proceso que pueda ser llevado a cabo en el Nivel de Planta, con el

control de la concurrencia sobre los elementos de fabricación ya en la


tarea de modelado. En la Figura 7.7 se muestra el esquema del experimento.

La experimentación T3 se corresponde con la regeneración automática de procesos fallidos durante el tiempo de ejecución. Mediante las pruebas

de este tipo de situaciones simuladas, se pretende determinar la posibilidad de la regeneración de procesos, ya sea de forma automática o manual. De hecho, esta funcionalidad se podría extender para recomponer procesos en tiempo de ejecución si fuera necesario

combinarlos con otros procesos. Sería una extensión del segundo caso, en el que uno de los procesos funcionales que componen el proceso completo sería extraído de manera automática de la planta de fabricación en función del desarrollo del mismo.

Los dos primeros tipos de experimentos diseñados son realizados sobre ambas plantas industriales. El tercer tipo de experimento, que se basa en los dos tipos anteriores, solo se desarrolla para una planta ya que lo

que se valida es el mecanismo de retroalimentación del sistema, que es independiente de la planta donde se desarrolle. Durante la realización de los experimentos se han obtenido los objetos intermedios de cada fase, lo

Figura 7.6 Diseño de la experimentación T1 de composición para n-

plantas.


que permite comprobar, tarea a tarea, el desarrollo de la gestión del proceso propuesto.

Figura 7.7 Diseño de la experimentación T2 de composición de procesos

concurrentes.

Figura 7.8 Diseño de la experimentación T3 de recuperación ante errores.

Se utilizará una distribución estática de los procesos disponibles en cada una de las plantas industriales. En la Figura 7.9 se aprecia como la


Planta 1 (a) dispone de 4 tipos diferentes de procesos y algunos de ellos pueden ser ejecutados en más de una máquina. En la Planta 2 se

dispone de tres tipos diferentes de procesos (b).

Figura 7.9 Distribución de procesos y máquinas por la Planta 1 (a) y la

Planta 2 (b).


Aunque las plantas disponen de varias entradas y salidas, se considerará en las pruebas que las materias primas entran en la Planta

1 a través de la Cinta Transportadora etiquetada como CB9, y en la

Planta 2 a través de la Mesa de Giro TT1. Por otro lado, aunque el proceso finalizaría realmente con la salida de la materia de la planta industrial a través de alguna máquina de entrada/salida, por motivos de

brevedad en la exposición de los mismos, se finalizarán los procesos en el momento que se ejecute la última actividad del proceso.

7.2.1 Experimentación T1: Generación de un

Proceso para n-plantas

El primer tipo de experimento está enfocado a validar la composición de procesos de fabricación a medida de la planta de fabricación donde se

vayan a ejecutar a partir de un único Proceso Funcional introducido en el sistema. Como ya se ha comentado en la primera parte de la experimentación, se expone el desarrollo del experimento para un ejemplo concreto y, posteriormente, se realiza la experimentación sobre

quince procesos para evaluar su funcionamiento frente a diversas condiciones.

Ejemplo de experimento T1

Se desarrollará un proceso que realice las tareas de Fresado, Torneado y

Pulido de una pieza. Estas actividades se introducen en el sistema a partir de un diagrama expresado en notación BPMN, tal como se muestra en la Figura 7.10.

Figura 7.10 Proceso funcional utilizado para el experimento T1. El primer paso que se realiza en la generación del proceso es la conceptualización del diagrama funcional, de forma que se pueda establecer procesos de inferencia sobre él. El Normalizador de Procesos

de Fabricación genera una ontología que recoge todas las instancias del


proceso automáticamente a partir del Proceso Funcional. Se puede ver el resultado sobre la Figura 7.11.

Figura 7.11 Captura del resultado de la normalización del proceso

funcional y la importación de las ontologías de las plantas industriales. El modelado del proceso para la Planta1 se realiza de manera automática a partir de los algoritmos y funciones presentadas en el capítulo 6. Exponiendo el funcionamiento del algoritmo para esta composición, se

puede apreciar el mecanismo utilizado para la composición. El proceso de Fresado tiene 2 máquinas que realizan esta actividad (MMT1, MT2). Existen tres caminos desde la cinta de transporte inicial CB9, tanto a la máquina MMT1 como MT2. Los caminos para llegar a la máquina MMT

se corresponden con las secuencias {TT4, CB8, RC1, CB4, CB3}, {TT4, CB8, RC1, CB7, TT3, CB6, TT2, CB5, CB4, CB3} y {TT4, CB8, RC1, CB5, TT2, CB6, TT3, CB7, RC1, CB4, CB3}. Del mismo modo, para llegar a MT2 desde CB9 existen tres caminos {TT4, CB8, RC1, CB4}, {TT4, CB8,

RC1, CB7, TT3, CB6, TT2, CB5, CB4} y {TT4, CB8, RC1, CB5, TT2, CB6, TT3, CB7, RC1, CB3}. Por el momento existen 6 procesos posibles (2 posibles máquinas de procesado y 3 caminos a cada una de ellas). La siguiente actividad del diagrama funcional (Torneado) solo la realiza la

máquina MT3. Existen dos posibles máquinas de inicio en función de la máquina que haya realizado la primera de las actividades. Desde cualquiera de las dos máquinas existen también dos caminos a la máquina de procesado MT3 (pasando por CB7 o por CB5). A las 6

posibilidades que se tenían se le suman las dos posibilidades para llegar a la máquina MT3, lo que hace por el momento un total de 12 procesos posibles. La tercera actividad es la de Pulido. La máquina MMT1 es la única que realiza esta actividad, y existen dos caminos para llegar a ella

desde la cinta transportadora CB6, que es donde se ha quedado la materia después de la segunda actividad. Los dos caminos que unen CB6 con CB3 se corresponden con {CB6,TT2,CB5,RC1,CB4,CB3} y


{CB6,TT3,CB7,RC1,CB4,CB3}. El número total de posibles procesos se corresponde con el producto de todas las posibilidades. Por lo tanto, el resultado de la primera parte de la etapa de modelado son 24 procesos (2

posibilidades del primer proceso * 3 caminos posibles * 1 posibilidad para el proceso 2 * 2 caminos posibles * 1 posibilidad para el tercer proceso * 2 caminos posibles).

Al ser procesos secuenciales no es necesario aplicar el control de colisiones. La selección de procesos se realiza aplicando el cálculo del camino máximo desde inicio a fin desarrollado en el capítulo 6. En el caso de procesos secuenciales, obviamente el camino de más peso por

proceso se corresponderá con el único camino posible de inicio a fin.

La función utilizada para ponderar los pesos de cada actividad del

proceso se basa únicamente en obtener una unidad fija por máquina, de forma que no se consideran diferencias de peso en función del tipo de actividad, lo que simplifica la exposición del ejemplo. Tras aplicar el cálculo se obtienen cuatro procesos con un peso 17, cuatro procesos con un peso de 19, ocho procesos con un peso de 23, y ocho procesos con

peso de 25. Cualquiera de los cuatro primero procesos es un proceso ideal para cumplir los objetivos del proceso funcional sobre la Planta 1. En la Figura 7.12 se puede apreciar uno de los procesos candidatos, el

cual está compuesto por todas las actividades para llegar a un sitio determinado.

Figura 7.12 Proceso a medida de la Planta 1 a partir de proceso funcional.

Uno de los procesos de menor peso se corresponde con la trayectoria de la materia prima por la Planta 1 expuesta en la Figura 7.13. En el caso de esta planta concreta existen varios procesos con un mismo peso, por lo que se ha elegido uno de ellos sin atender a más criterios.


Se ha utilizado la Planta 2 para generar el mismo Proceso Funcional de la Figura 7.10. Al tratarse de una planta simétrica, existirá el mismo número de caminos entre cada máquina de procesado. Concretamente

los 4 caminos que se pueden identificar se corresponden con los mostrados en la Figura 7.14.

Figura 7.13 Trayectoria del proceso planteado sobre el plano de la Planta 1.

Figura 7.14 Caminos desde la máquina de procesado MT1 a otra máquina

MT2 de la Planta 2.


En lo referente a la composición del proceso a partir del proceso funcional, la primera actividad de Fresado la pueden desarrollar las máquinas MT1 y MT3. Como ya se ha comentado hay 4 caminos para

llegar a cada una de ellas. Las actividades de Torneado y Pulido las realizan las máquinas MT2 y MT4 respectivamente. El resultado es un total de 128 procesos candidatos antes de la selección de los mismos. El

desglose de los 128 procesos posibles viene determinado por las dos posibilidades para realizar la primara actividad por los cuatro caminos para llegar a cada una de las máquinas que realizan la primera actividad. Esto se multiplica por los cuatro caminos posibles para realizar el segundo proceso y por los cuatro caminos posibles para

realizar el tercer camino. En la Tabla 7.5se muestra el desglose de los 128 procesos en función del peso obtenido en la función de selección. Existe un único proceso óptimo según el criterio aplicado.

Tabla 7.5 Frecuencia por peso de los procesos candidatos para la Planta

2.

Frec. Peso Frec. Peso Frec. Peso. Frec. Peso

1 10 7 19 12 27 7 37

1 13 3 20 1 28 8 38

1 14 5 22 20 29 1 39

3 15 3 23 14 32 1 42

1 17 18 24 4 33 4 43

3 18 1 25 9 34

El proceso óptimo tiene un peso de 10, y se corresponde con el mostrado en la Figura 7.15. Si lo miramos sobre la planta industrial, se corresponde con la trayectoria trazada en la Figura 7.16.

Completada la etapa de composición de procesos, se pone a prueba el Compilador de Procesos. En un servidor Apache se almacena la descripción semántica de los servicios, de donde se saca la información

referente a los parámetros, prerrequisitos y efectos de la invocación de cada una de los servicios implicados.

Durante el proceso de compilación se consultan tanto los SWS como las

descripciones WSDL de las operaciones para, a partir de ellas, componer una hoja BPEL y su WSDL correspondiente. Junto a la generación de la hoja BPEL se generan todos los ficheros necesarios para desplegar el proceso en un motor de ejecución. Estos ficheros se corresponden con la

propia hoja BPEL, la descripción WSDL y la información de despliegue. Tal como se puede ver en la Figura 7.17, el proceso secuencial se realiza mediante una serie de llamadas a los servicios en modo síncrono. De


esta forma una actividad del proceso comenzará cuando finalice la siguiente.

Figura 7.15 Proceso a medida de la

Figura 7.16 Trayectoria del proceso

Durante el desarrollo del dentro del proceso BPELdefinición de PartenrLinksinicialización de variablescoreografía del proceso. Las tres primeras á


esta forma una actividad del proceso comenzará cuando finalice la

Proceso a medida de la Planta 2 a partir de proceso funcional.

Trayectoria del proceso planteado sobre el plano de la P2.

Durante el desarrollo del punto 6.2 se han identificado cinco dentro del proceso BPEL: el área de inclusión de Namespaces, el área de definición de PartenrLinks, el área de definición de variables, el área de inicialización de variables, y el área de proceso, donde se contien

del proceso. Las tres primeras áreas no se muestran en la

esta forma una actividad del proceso comenzará cuando finalice la

a partir de proceso funcional.

Planta

se han identificado cinco áreas el área de el área de

y el área de proceso, donde se contiene la reas no se muestran en la


Figura 7.17, ya que son características del proceso de forma global. Se puede acceder a ellas a través de las propiedades de la herramienta. Dentro del main se encuentra el área de inicialización de variables vista

en la Figura 7.17 como la sección “Assig” y el área de proceso, a partir de la sección “start”.

En la Tabla 7.6 se muestra un extracto del código generado automáticamente a partir de los SWS disponibles. Como se puede apreciar, la primera parte del bloque assig tiene creadas una serie de variables que contienen los parámetros para invocar a los procesos y que

produzcan los efectos deseados.

Figura 7.17 Captura del proceso generado automáticamente para el proceso de la Planta 1.

Tabla 7.6 Extracto del código de la hoja BPEL generada automáticamente para la Planta 1.

<?xml version="1.0" encoding="UTF-8"?> <bpel:process xmlns:bpel=http://docs.oasis-open.org/wsbpel/2.0/process/executable xmlns:tns="http://sample.bpel.org/bpel/sample" xmlns:wsdl0="http://localhost:8080/axis2/services/TT4" xmlns:wsdl1="http://localhost:8080/axis2/services/CB8" xmlns:wsdl2="http://localhost:8080/axis2/services/RC1" xmlns:wsdl3="http://localhost:8080/axis2/services/CB4" --Resto de Namespaces

> <bpel:partnerLinks>

<bpel:partnerLinkname="Cliente_1"partnerLinkType="wsdl0:TT4LT"/> <bpel:partnerLink name="Cliente_2”partnerLinkType="wsdl1:CB8LT"/>


<bpel:partnerLink name="Cliente_3"partnerLinkType="wsdl2:RC1LT"/> --Resto de PartnerLinks

</bpel:partnerLinks>

<bpel:variables>

<bpel:variable name="MoveToEndRequest1" messageType="wsdl0:MoveToEndRequest" /> <bpel:variable name="MoveToEndResponse1" messageType="wsdl0:MoveToEndResponse"/> <bpel:variable name="MoveToEndRequest2" messageType="wsdl1:MoveToEndRequest" /> <bpel:variable name="MoveToEndResponse2" messageType="wsdl1:MoveToEndResponse" /> <bpel:variablename="MoveToDirection3" messageType="wsdl2:MoveToDirection" /> --Resto de Namespaces </bpel:variables>

<bpel:sequence name="main"> --Asignacion de valores a parámetros <bpel:assign>

<bpel:copy>

<bpel:from><bpel:literal>P</bpel:literal></bpel:from>

<bpel:to variable="directionX1" /> </bpel:copy>

<bpel:copy>

<bpel:from><bpel:literal>N</bpel:literal></bpel:from>

<bpel:to variable="directionY1" /> </bpel:copy>

<bpel:copy>

<bpel:from variable="directionX1" /> <bpel:to variable="MoveToEndRequest1" part="directionX" /> </bpel:copy>

</bpel:copy>

<bpel:from variable="directionY1" /> <bpel:to variable="MoveToEndRequest1" part="directionY" /> </bpel:copy>

--Resto de Asignaciones </bpel:assign>

<bpel:sequence>

<bpel:invoke partnerLink="Cliente_1" portType="wsdl0:TT4PortType" operation="MoveToEnd" inputVariable="MoveToEndRequest1" outputVariable="MoveToEndResponse1" /> <bpel:invoke partnerLink="Cliente_2" portType="wsdl1:CB8PortType" operation="MoveToEnd" inputVariable="MoveToEndRequest2" outputVariable="MoveToEndResponse2" /> --Resto de Invokes

Se ha realizado el mismo experimento sobre la Planta 2 obteniéndose un

resultado similar, pero ajustado a la especificación del diagrama de la segunda planta industrial. En la Figura 7.18 se muestra la captura de la hoja BPEL generada automáticamente. También dispone de su inicialización de variables y de una secuencia de diez invocaciones

síncronas para el desarrollo del proceso.


En la Tabla 7.7 se recoge parte del código generado automáticamente. Al no existir demasiada diferencia entre el proceso de compilado para una planta u otra, se recoge en esta tabla un breve resumen que muestra

cómo se está accediendo a los servicios de otra planta industrial.

Figura 7.18 Captura de la hoja BPEL generada automáticamente a partir del proceso de menor peso para la Planta 2.

Tabla 7.7 Extracto del código de la hoja BPEL generada automáticamente para la Planta 2.

<?xml version="1.0" encoding="UTF-8"?> <bpel:process

xmlns:bpel="http://docs.oasis-open.org/wsbpel/2.0/process/executable" xmlns:tns="http://sample.bpel.org/bpel/sample" xmlns:wsdl0="http://localhost:8080/axis2/services/CB1" xmlns:wsdl1="http://localhost:8080/axis2/services/fabrica2/MT1" xmlns:wsdl2="http://localhost:8080/axis2/services/fabrica2/RC1" xmlns:wsdl3="http://localhost:8080/axis2/services/fabrica2/CB4" --Resto de namespaces de la planta 2 >

<bpel:partnerLinks>

<bpel:partnerLink name="Cliente_1" partnerLinkType="wsdl0:CB1LT"/> <bpel:partnerLink name="Cliente_2" partnerLinkType="wsdl1:MT1LT" /> <bpel:partnerLink name="Cliente_3" partnerLinkType="wsdl2:RC1LT" /> --Resto de PartnerLinks

</bpel:partnerLinks>

<bpel:variables>

<bpel:variable name="MoveToSensorRequest1" messageType="wsdl0:MoveToSensorRequest" /> <bpel:variable name="MoveToSensorResponse1" messageType="wsdl0:MoveToSensorResponse" />


<bpel:variable name="ProcessRequest2" messageType="wsdl1:ProcessRequest" /> <bpel:variable name="ProcessResponse2" messageType="wsdl1:ProcessResponse" /> --Resto de Variables

</bpel:variables>

<bpel:sequence name="main"> <bpel:assign>

<bpel:copy>

<bpel:from>

<bpel:literal>10</bpel:literal> </bpel:from >

<bpel:to name="segundos2" > </bpel:copy>

<bpel:copy>

<bpel:from variable="segundos2" /> <bpel:to variable="ProcessRequest2" part="segundos" /> </bpel:copy>

</bpel:assign>

<bpel:sequence>

<bpel:invoke partnerLink="Cliente_1" portType="wsdl0:CB1PortType" operation="MoveToSensor" inputVariable="MoveToSensorRequest1" outputVariable="MoveToSensorResponse1" /> <bpel:invoke partnerLink="Cliente_2" portType="wsdl1:MT1PortType" operation="Process" inputVariable="ProcessRequest2" outputVariable="ProcessResponse2" /> --Resto de inokes

</bpel:sequence>

</bpel:process>

En cada uno de los casos se ha empaquetado los objetos dentro de un archivo .zip y se han desplegado en el servidor Apache ODE, previamente

comentado, para que se pueda realizar la ejecución de los mismos.

Batería de Experimentos T1

Desde un punto de vista analítico se ha realizado el estudio del comportamiento ante diferentes procesos y plantas. Este estudio se basa

en utilizar quince Procesos Funcionales aleatorios y componer sus procesos a medida de las dos plantas disponibles. Se utilizaran las variantes de generar los procesos a partir del camino mínimo y generar los procesos para todas las posibilidades existentes.

Los procesos utilizados en las pruebas se corresponden con los recogidos en la Tabla 7.8, estos procesos se estructuran en cinco grupos en

función del número de actividades que componen el Proceso Funcional. Se ha utilizado esta distribución de procesos, para poder analizar cómo se comporta el modelo propuesto en función del incremento de complejidad de los Procesos Funcionales introducidos.


Tabla 7.8 Procesos funcionales utilizados experimento T1.

Código Grupo Proceso Funcional

1.1 1 Torneado 1.2 1 Fresado 1.3 1 Pulido 2.1 2 Torneado+Fresado 2.2 2 Fresado+Pulido 2.3 2 Pulido+Torneado 3.1 3 Torneado+Fresado+Pulido 3.2 3 Fresado+Torneado+Pulido 3.3 3 Pulido+Torneado+Fresado 4.1 4 Torneado + Fresado+Pulido+Torneado 4.2 4 Fresado+Pulido+Torneado+Fresado 4.3 4 Pulido+Torneado+Fresado+Pulido 5.1 5 Torneado+Fresado+Pulido+Torneado+Fresado 5.2 5 Fresado+Pulido+Torneado+Fresado+Pulido 5.3 5 Pulido+Torneado+Fresado+Pulido+Torneado

El análisis de los datos se estructura en base a siete componentes que deben permitir estudiar diferentes aspectos del comportamiento del sistema: el número de procesos candidatos (Nº Proc.) es el número de procesos que se generan por la herramienta antes de seleccionar el

mejor; el coste mínimo indica el coste del mejor procesos (Peso Proc. Óptimo); el coste máximo indica el coste del peor proceso (Peso Proc. Pésimo); el coste medio se establece a partir del coste de todos los procesos candidatos (Peso Proc. Medio); el tiempo generación se

corresponde únicamente con el tiempo invertido en generar los posibles procesos (T. Gen.); el tiempo total es el tiempo invertido desde que se solicita la generación de los procesos hasta que se han evaluado y materializado en disco (T. Total); finalmente, el tiempo medio por proceso se corresponde con el tiempo total dividido por el número de procesos

candidatos (T. Medio).

En la Tabla 7.9 se muestran los datos para la Planta 1 obtenidos a partir

de aplicar el algoritmo sobre todos los caminos posibles. En la Tabla 7.10 se muestran los datos obtenidos a partir de aplicar el cálculo de procesos únicamente a partir del camino mínimo entre máquinas. El tiempo está expresado en milisegundos y el coste de los caminos

óptimos, pésimos y medios en unidades de ejecución estimadas (una unidad equivale al tiempo de desarrollo de una actividad).


Tabla 7.9 Resumen de los datos obtenidos para la Planta 1 a partir de todos los procesos en experimentación T1.

Código Nº

Proc.

Peso Proc.

óptimo

Peso Proc.

Pésimo

Peso Proc.

Medio

T. Gen. (ms)

T. Total (ms)

T. Medio

(ms)

1.1 2 8 8 8 17 621 310,5 1.2 6 6 13 10,5 23 727 121,16 1.3 3 7 13 11 17 624 208 2.1 8 13 14 13,5 35 960 120 2.2 9 8 16 13,3 59 918 102 2.3 6 10 16 14 37 1019 169,833 3.1 12 15 17 16,3 115 1360 113,333 3.2 24 17 25 22 86 1267 52,791 3.3 24 18 25 22,5 65 1281 53,375 4.1 24 21 23 22,33 116 1511 62,958 4.2 72 19 38 24,66 187 2963 41,152 4.3 36 20 28 25,3 199 2165 60,138 5.1 96 26 29 27,83 285 3488 36,333 5.2 144 24 34 30,33 244 3289 22,840 5.3 72 26 34 31,33 238 3275 45,486

Tabla 7.10 Resumen de los datos obtenidos para la Planta 1 a partir del camino óptimo entre máquinas en experimentación T1.

Código Nº

Proc.

Peso Proc.

óptimo

Peso Proc.

Pésimo

Peso Proc.

Medio

T. Gen. (ms)

T. Total (ms)

T. Medio

(ms)

1.1 1 8 8 8 19 632 632 1.2 2 6 7 6,5 22 784 392 1.3 1 7 7 7 15 563 563 2.1 2 13 14 13,5 34 813 406,5 2.2 2 8 10 9 53 897 448,5 2.3 1 10 10 10 35 906 906 3.1 2 15 17 16 81 1302 651 3.2 2 17 19 18 92 1247 623,5 3.3 2 18 19 18,5 76 1519 759,5 4.1 2 21 23 22 123 1444 722 4.2 4 19 22 20,5 184 2265 566,25 4.3 2 20 22 21 128 1997 998,5 5.1 4 26 29 27,5 251 2413 603,25 5.2 4 24 28 26 238 1714 428,5 5.3 2 26 28 27 233 2622 1311


Tal como se ve en la Figura 7.19, en ambas aproximaciones se obtienen los mismos procesos óptimos. En las hipótesis planteadas a la hora de definir el algoritmo de composición se identificó que en los procesos

secuenciales se pueden obtener los procesos óptimos a partir de la suma de caminos mínimos, lo que se valida tras la experimentación.

Sin embargo, aunque los dos enfoques obtienen el camino óptimo sobre

la primera planta, el funcionamiento interno es muy diferente. El algoritmo basado en la generación de todos los procesos posibles utiliza un número exponencial de procesos, mientras que el que utiliza caminos mínimos mantiene un número de procesos casi lineal, tal como se ve en

la Figura 7.20. En consecuencia el tiempo de ejecución de cada uno de los enfoques evoluciona de forma similar al número de procesos, tal como refleja la Figura 7.21.

Figura 7.19 Gráfica de comparación de procesos óptimos calculados a

partir de todos los caminos y de los caminos mínimos.

El tiempo de ejecución mostrado en la Figura 7.21 se corresponde al tiempo total empleado en la generación y evaluación de los procesos. Esto implica que, además de la parte de composición semántica, se

contabiliza el tiempo de evaluación de cada proceso y de escritura en disco. Atendiendo únicamente al tiempo de composición semántica de procesos, el tiempo de cálculo de los procesos no dista significativamente entre ambas aproximaciones (Figura 7.22). Por lo tanto, el tiempo en la

aproximación de evaluar todos los procesos se ve afectado por la evaluación y almacenamiento de todos los procesos, aunque en la


composición se realice en prácticamente el mismo tiempo en ambas aproximaciones.

Figura 7.20 Gráfica de evolución del número de procesos candidatos de la Planta 1.

Figura 7.21 Gráfica de evolución del tiempo de ejecución para la Planta 1.


Figura 7.22 Gráfica del tiempo de composición de procesos.

Del mismo modo, se ha realizado la experimentación para la Planta 2 sobre los mismos procesos. En la Tabla 7.11 se ven los datos obtenidos para todos los caminos y en la Tabla 7.12 para los caminos mínimos.

Tabla 7.11 Resumen de los datos obtenidos para la Planta 2 a partir de todos los procesos en experimentación T1.

Código Nº

Proc.

Peso Proc.

óptimo

Peso Proc.

Pésimo

Peso Proc.

Medio

T. Gen. (ms)

T. Total (ms)

T. Medio

(ms)

1.1 4 5 14 9,75 19 582 145,5 1.2 8 3 17 10,65 28 582 72,75 1.3 4 6 14 10 19 599 149,75 2.1 32 8 28 18,37 41 1034 32,312 2.2 32 7 31 18,25 63 1115 34,843 2.3 32 9 31 21,75 48 1234 38,562 3.1 128 12 40 27,25 97 2434 19,015 3.2 128 12 43 28,26 101 2569 20,071 3.3 128 13 42 27,62 79 2245 17,539 4.1 512 16 54 36,35 153 9295 18,154 4.2 1024 14 57 37,11 241 9627 23,073 4.3 512 17 54 36,5 221 9378 18,316 5.1 4096 19 68 44,85 470 132596 32,372 5.2 4096 17 69 45,75 563 224741 54,868 5.3 2048 21 68 45,5 436 132596 64,744


Tabla 7.12 Resumen de los datos obtenidos para la Planta 2 a partir de los caminos mínimos en experimentación T1.

Código Nº

Proc.

Peso Proc.

óptimo

Peso Proc.

Pésimo

Peso Proc.

Medio

T. Gen. (ms)

T. Total (ms)

T. Medio

(ms)

1.1 1 5 5 5 17 667 667 1.2 2 4 5 4,5 21 664 332 1.3 1 6 6 6 17 537 537 2.1 2 8 9 8,5 38 776 388 2.2 2 7 11 9 61 929 464,5 2.3 1 9 9 9 39 905 905 3.1 2 12 14 13 93 1273 636,5 3.2 2 10 14 12 83 1116 558 3.3 2 13 14 13,5 70 1280 640 4.1 2 16 18 17 121 1385 692,5 4.2 4 14 19 16,5 201 2088 522 4.3 2 17 19 18 139 1984 992 5.1 4 19 22 20,5 313 2953 738,25 5.2 4 17 23 20 280 1942 485,5 5.3 2 21 23 22 310 4670 2335

Al igual que para la Planta 1, y confirmando la hipótesis planteada, en el

caso de procesos secuenciales la composición del proceso a partir del camino mínimo da como resultado el proceso óptimo, tal como se ve en la Figura 7.23. La tendencia identificada sobre la Planta 1, se confirma

sobre la Planta 2, tal como se muestra en la Figura 7.24, de igual forma que el número de procesos evoluciona de forma exponencial, también lo hace el tiempo de evaluar y escribir cada uno de esos procesos tal como se muestra en la Figura 7.25.

Por último, la tendencia del algoritmo de composición, al igual que para la Planta 1, no evoluciona de forma exponencial. Tal como se muestra en la Figura 7.26, para la generación de los N procesos posibles se obtiene

en un tiempo cercano a la linealidad. Esto es debido a que gran parte del tiempo consumido en la gestión del proceso está asociado a la evaluación y almacenamiento de los procesos, mientras que la parte de composición semántica se realiza de manera más eficiente.


Figura 7.23 Gráfica de comparación de procesos óptimos obtenidos sobre

la Planta 2.

Figura 7.24 Gráfica de evolución del número de procesos candidatos para

la Planta 2.


Figura 7.25 Gráfica de evolución del tiempo de ejecución Planta 2.

Figura 7.26 Gráfica de evolución del tiempo de composición de procesos en la Planta 2.


7.2.2 Experimentación T2: Generación de Procesos

Compuestos para n-plantas

Una de las funcionalidades principales del sistema propuesto es permitir gestionar varios procesos a la vez. Un sistema de fabricación orientado a la personalización masiva, y sustentado bajo un sistema de producción ágil, debe adaptarse a las demandas del mercado maximizando, en la

medida de lo posible, el uso de recursos y reduciendo el tiempo de respuesta ante las demandas de los clientes. Por ello, durante la realización de los experimentos T2, las pruebas se centran en la generación de procesos paralelos que se desarrollen simultáneamente a

partir de Procesos Funcionales independientes. Al igual que durante el primer experimento este apartado se divide en dos partes, en la primera se describe el funcionamiento de un proceso de ejemplo, y en la segunda se realizan diversas pruebas sobre 15 procesos paralelos para validar y

cuantificar el funcionamiento del sistema implementado. Se utilizarán procesos compuestos por dos ramas paralelas por diversos motivos. Por un lado el algoritmo se ve afectado por el número de tareas y no por la distribución de las mismas a efectos de rendimiento. Por otro lado

exponer de forma gráfica y entendible la composición de procesos de varias ramas es complejo.

Ejemplo de Experimento T2

El experimento escogido plantea la gestión de un proceso compuesto a

partir de dos procesos funcionales independientes. Para simplificar la explicación, el primer Proceso Funcional que se utilizará será el mismo mostrado durante el primer experimento. El segundo proceso se ha introducido buscando el uso de las mismas máquinas durante la

ejecución del proceso. Se ha diseñado expresamente así para validar la gestión de colisiones y probar el sistema de pausas implementado para la gestión de colisiones frente a la elección de caminos alternativos (no siendo el camino mínimo entre dos puntos). Los dos Procesos

Funcionales utilizados se corresponden con los mostrados en la Figura 7.27, en los que se aprecia cómo ambos necesitan realizar las operaciones de Tornado y Pulido.

Tras aplicar la unión de ambos procesos mediante la funcionalidad desarrollada en el punto 6.1.1, la conceptualización del diagrama que se obtiene es equivalente al diagrama mostrado en la Figura 7.28.


Figura 7.27 Captura de los dos Procesos Funcionales utilizados en la

composición del proceso del segundo experimento.

Figura 7.28 Unión conceptual de los procesos funcionales del experimento

tipo 2. En una primera aproximación se ha desactivado el control de colisiones,

para comprobar los diagramas candidatos antes de controlar las colisiones. Posteriormente se ha vuelto a ejecutar ya con el control de colisiones activo. Tras realizar la primera comprobación de generación de procesos se ha obtenido un número de 96 procesos posibles. Como ya se

ha visto en el primer experimento, el primer Proceso Funcional tenía 24 procesos posibles sobre la Planta 1. El segundo Proceso Funcional, de forma independiente, tiene 4 posibilidades. La actividad de Torneado la realiza únicamente la máquina MT3. Existen dos caminos posibles entre

CB9 (máquina inicial) y MT3. Del mismo modo, la actividad de Pulido solo la realiza la máquina MMT1 y existen dos caminos posibles entre MT3 y MMT1 (pasando por CB5 o por CB7). Los 96 procesos posibles se

corresponden con las 28 posibilidades del primer proceso por las 4 posibilidades del segundo proceso. Sin embargo, y como se ha comentado previamente, los procesos obtenidos no cumplen con los


requisitos de concurrencia sobre las máquinas industriales, por lo que no serán válidos a nivel de requisitos de la ontología de planta, tal como se muestra en la Figura 7.29.

Figura 7.29 Captura de proceso compuesto no válido por concurrencia

sobre las máquinas. Tras activar la función de control de colisiones en el sistema se han vuelto a generar los procesos para la Planta 1. El resultado es que se han obtenido el mismo número de procesos pero con un peso diferente en función de las pausas que se han tenido que crear para evitar colisiones.

El mejor proceso resultante ha obtenido un peso de 17. El peso se corresponde con el camino máximo dentro del proceso, que coincide con el mismo proceso candidato del experimento T1. Aunque se han tenido que introducir pausas dentro del proceso para evitar las colisiones, al

introducirse sobre el camino más corto, el camino máximo no se ha visto alterado.

En la Figura 7.31 se muestra la trayectoria del proceso completo, se

puede apreciar cómo cada uno de los Procesos Funcionales usados no coincide en una máquina en una unidad de tiempo, por lo que no existen colisiones en el proceso y puede ser llevado a cabo paralelamente. Se han identificado algunos puntos usados por ambos procesos y se ha

determinado en que instante de tiempo se hace uso de ellos, con lo que se comprueba que, por ejemplo, en el raíl de carga que es la máquina más usada del proceso, no se coincide en ninguna unidad de tiempo, ya que el primer proceso (marcado en rojo) la utiliza inicialmente en el

tercer paso, el segundo proceso lo utiliza en el cuarto instante de tiempo, mientras la materia del segundo proceso se encuentra en la máquina


TT3, el primer proceso vuelve a hacer uso del raíl de carga en el paso Finalmente el segundo proceso utiliza el raíl de carga con destino a la máquina final en el paso 11 y el primer proceso lo utiliza en el paso 13.

Figura 7.30 Captura de proceso compuesto vácontrol de la concurrencia

Figura 7.31 Trayectoria del proceso resultante de la unión de dos Procesos Funcionales

En la Figura 7.32, se muestra el cronogcaso, el proceso óptimo composición es el mismo. Se puede apreciar cunión de ambos procesos

el segundo procesos. El tiempo del proceso compuesto no se incrementa respecto al mayor tiempo de los procesos individuales.


TT3, el primer proceso vuelve a hacer uso del raíl de carga en el paso Finalmente el segundo proceso utiliza el raíl de carga con destino a la máquina final en el paso 11 y el primer proceso lo utiliza en el paso 13.

Captura de proceso compuesto válido con pausas para el control de la concurrencia para la Planta 1.

Trayectoria del proceso resultante de la unión de dos Procesos Funcionales. En rojo el proceso 1 y en verde el proceso 2.

, se muestra el cronograma de ambos procesos. En este caso, el proceso óptimo resultante de ambas modalidades de composición es el mismo. Se puede apreciar cómo el resultado es la unión de ambos procesos óptimos introduciendo una pausa inicial sobre

el segundo procesos. El tiempo del proceso compuesto no se incrementa respecto al mayor tiempo de los procesos individuales.

TT3, el primer proceso vuelve a hacer uso del raíl de carga en el paso 6. Finalmente el segundo proceso utiliza el raíl de carga con destino a la máquina final en el paso 11 y el primer proceso lo utiliza en el paso 13.

lido con pausas para el

Trayectoria del proceso resultante de la unión de dos

En rojo el proceso 1 y en verde el proceso 2.

rama de ambos procesos. En este resultante de ambas modalidades de

mo el resultado es la una pausa inicial sobre

el segundo procesos. El tiempo del proceso compuesto no se incrementa


Figura 7.32 Cronograma de los procesos independientes y del resultado de unirlos mediante los dos enfoques planteados en la presente tesis sobre

la Planta 1. Al igual que en el primer experimento, se ha compilado el proceso haciendo uso de la información semántica y se ha obtenido el proceso

calculado con sus parámetros, tal como se puede apreciar en la Figura 7.33

Figura 7.33 Resultado del proceso de compilado sobre el mejor proceso

para la Planta 1. El resultado de realizar el modelado para la Planta 2 del proceso ha dado

un total de 2048 procesos posibles. Este es el resultado de multiplicar los 128 procesos candidatos del primer experimento, que se corresponde con uno de los procesos a implementar, por los 16 procesos candidatos

del segundo proceso funcional (1 máquina x 4 caminos) x (1 máquina x 4 caminos).

Tal como se ve en la Figura 7.34, el primer proceso tiene un peso de 10 y

su camino óptimo es el indicado en el apartado (a). El segundo proceso


(b) tiene un peso de 9. La diferencia entre el primer y segundo proceso es la unidad de tiempo invertida en la máquina MT1.

Figura 7.34 Procesos óptimos para el primer Proceso Funcional (a) y el

segundo Proceso Funcional (b) para la Planta 2. Tras aplicar el algoritmo de composición y control de colisiones bajo los dos enfoques planteados en la presente tesis se obtiene que el mejor

proceso no se corresponde con el compuesto a partir de los dos procesos óptimos, sino que el mejor resultado encontrado es el que toma un camino alternativo.

Figura 7.35 Mejor proceso obtenido a partir de los caminos mínimos (a) y de la exploración de todos los caminos (b) para la Planta 2.

Tal como se muestra en el cronograma de los procesos obtenidos en la Figura 7.36, los dos procesos se hace un uso intenso del raíl de carga RC1 para ir y volver, esto genera varias posibles colisiones y que una de

las materias tenga que esperar a que se realice todo el recorrido por el tramo RC1, CB4, RC1 por la otra materia. Si a esto se suma que el primer proceso tiene que bloquear la cinta CB1 mientras se realiza la primera actividad, se obtiene que la mejor solución encontrada para el proceso generado a partir de los caminos mínimos consiste en

introducir tres pausas sobre el primer proceso para que puedan llevarse en paralelo, lo que hace que el tiempo de ejecución se prolongue. El


proceso seleccionado por el sistema, generado a partir de todos los caminos, solo introduce 2 pausas en el proceso. Mientras se realiza la operación sobre el primer proceso en la máquina MT2, el segundo

proceso espera en la cinta TT2 su turno para poder pasar a la máquina MT2 (CB4) y seguir su camino.

Figura 7.36 Cronograma de los procesos independientes y del resultado de unirlos mediante los dos enfoques planteados en la presente tesis sobre

la Planta 2. Tras realizar el proceso de compilación se ha obtenido la hoja BPEL con la secuencia de invocación a los servicios tal como se ha diseñado el proceso resultante. En la Figura 7.37 se muestra la equivalencia entre el proseo BPMN compuesto y su correspondiente proceso ejecutable.

Además del propósito del experimento de realizar un proceso compuesto para ambas plantas, en el presente experimento se ha podido validar la funcionalidad desarrollada para el control de colisiones, lo que permite

mantener la consistencia del proceso desde un punto de vista conceptual y funcional, tal como se ha visto en la ontología. Por otro lado, la opción de trabajar con un conjunto de procesos candidatos y no solo con el proceso óptimo en cada caso, ha permitido obtener un mejor proceso en

el caso de la Planta 2, mientras que en el caso de la Planta 1, el proceso óptimo se corresponde con la unión de ambos procesos sin afectar a su tiempo total de ejecución.

El objetivo del algoritmo es obtener el mejor proceso en función del criterio establecido para calcular el peso del proceso. Este objetivo solo es alcanzable a través del análisis de todos los procesos posibles, y a partir de ellos generar el proceso valido más próximo al proceso original.

Tal como se ve en la Figura 7.38, se ha obtenido un gran número de procesos válidos que no tienen el mismo peso que los procesos con colisiones por lo que el algoritmo de control de colisiones desarrollado


soluciona las colisiones con un bajo impacto temporal. Es decir, el algoritmo propuesto cumple la premisa con la que se ha diseñado. Sin embargo, se ve que el algoritmo ha analizado y operado sobre un gran

número de procesos que han sido descartados.

Figura 7.37 Captura del proceso modelado para la Planta 2 (a) y su

correspondiente estructura de ejecución (b).


Aunque el proceso óptimo dependerá de la estructura física de la planta y de las capacidades de cada una de las máquinas, se podría establecer un compromiso entre el número de procesos a evaluar (atendiendo a los

n procesos originales con menos peso) y el mejor proceso resultante de los mismos, ya que en un alto porcentaje, el proceso óptimo se encontrará entre los N procesos mejores. Esta solución no ha sido necesaria durante la presente tesis, pero hay que tener en cuenta que el

número de procesos candidatos crece exponencialmente por operación introducida en el proceso, por lo que para el caso de uniones de múltiples proceso o procesos con muchas actividades podría ser conveniente acotar el número de procesos a evaluar.

Figura 7.38 Dispersión de los procesos originales (con colisión) y los

procesos que satisfacen los requisitos del dominio (sin colisión).


Batería de Experimentos T2

Al igual que sobre el primer experimento, se han realizado una serie de pruebas analíticas sobre un conjunto de quince procesos paralelos para estudiar el comportamiento del sistema ante diferentes Procesos

Funcionales generados arbitrariamente. En la Tabla 7.13 se muestran los procesos funcionales utilizados en la generación de las pruebas. En las tablas Tabla 7.14 y Tabla 7.15 se muestran los datos obtenidos para la Planta 1 a partir de explorar todos los caminos y de explorar el camino

óptimo respectivamente.

Tabla 7.13 Procesos funcionales utilizados en los experimentos de tipo 2.

Código Núm. Proceso Funcional

1.1 2 {Pulido} {Fresado}

1.2 2 {Torneado} {Pulido}

1.3 2 {Torneado} {Fresado}

2.1 3 {Pulido +Torneado} {Fresado}

2.2 3 {Torneado + Torneado} {Fresado}

2.3 3 {Fresado + Pulido} {Torneado}

3.1 4 {Pulido + Torneado} {Fresado + Pulido}

3.2 4 {Torneado + Pulido} {Fresado + Torneado}

3.3 4 {Fresado + Pulido} {Fresado + Pulido}

4.1 5 {Fresado + Torneado, Pulido} {Torneado + Pulido}

4.2 5 {Torneado + Pulido + Fresado} {Fresado + Pulido}

4.3 5 {Torneado + Torneado + Pulido} {Fresado + Pulido}

5.1 6 {Pulido + Torneado + Fresado} {Fresado + Pulido + Torneado}

5.2 6 {Tornado + Pulido + Torneado} {Torneado + Fresado + Pulido}

5.3 6 {Torneado + Fresado + Pulido} {Torneado + Fresado + Pulido}


Tabla 7.14 Datos obtenidos para los procesos del experimento T2 para la Planta 1 explorando todas las posibilidades.

Código

Nº Proc.

Peso Proc.

óptimo

Peso Proc.

Pésimo

Peso Proc.

Medio T. Gen.

(ms)

T. Total (ms)

T. Medio

(ms)

1.1 18 7 20 14,3 514 5525 306,944 1.2 6 9 15 12,33 407 4471 745,166 1.3 12 9 15 12 507 4637 386,416 2.1 36 13 26 19,83 631 5749 159,694 2.2 48 12 22 15,41 683 6330 131,875 2.3 18 9 18 14,33 668 5590 310,555 3.1 54 15 26 21,62 837 7354 136,185 3.2 48 15 27 20,25 831 7282 151,708 3.3 81 10 23 17,85 1199 8205 101,296 4.1 96 18 33 25,2 1118 9913 103,260 4.2 108 17 24 20,01 1189 9191 85,101 4.3 144 18 28 21,16 1120 12382 85,986 5.1 432 24 41 31,34 1525 19216 44,4814 5.2 96 21 28 25,45 1213 10123 105,447 5.3 144 17 25 21,38 2441 13530 93,958

Tabla 7.15 Datos obtenidos para los procesos del experimento T2 para la Planta 1 explorando los caminos mínimos.

Código

Nº Proc.

Peso Proc.

óptimo

Peso Proc.

Pésimo

Peso Proc.

Medio T. Gen.

(ms)

T. Total (ms)

T. Medio

(ms)

1.1 2 7 9 8 553 6270 3135 1.2 1 9 9 9 397 4222 4222 1.3 2 9 9 9 508 4459 2229,5 2.1 2 13 15 14 635 5311 2655,5 2.2 2 12 12 12 611 5278 2639 2.3 3 9 11 10 671 5327 1775,66 3.1 2 16 18 17 863 6614 3307 3.2 2 15 15 15 834 6556 3278 3.3 4 10 15 12,75 1104 6896 1724 4.1 2 18 20 19 1029 7365 3682,5 4.2 4 17 18 17,5 1149 7790 1947,5 4.3 2 18 18 18 993 9597 4798,5 5.1 4 24 28 25,75 1459 9203 2300,75 5.2 2 23 25 24 1162 8526 4263 5.3 4 17 22 19,75 1539 9963 2490,75


Atendiendo a los mejores procesos que se han obtenido en cada caso, en la Figura 7.39 se puede apreciar cómejor proceso obtenido a partir del camino

proceso. Sin embargo, tal codiferencial de pesos, existen casos en los que alcanzable a través de la suma de caminos

Al igual que se ha visto en los experimentos T1, la evolución del número de procesos a evaluar cretodos los caminos posibles. A mayor número de caminos posibles, mayor número de combinaciones, por eso

mínimo, el número de procesos posibles se mantiene casi constante, solo viéndose modificado por el número de máquinas que implementan una misma operación. En consecuencia, la evolución del número de procesos y el tiempo necesario para evaluar todos los procesos crece, tal como se

muestra en las figuras

Los mismos procesos se han ejecutado para la

datos recogidos en las tablas

Figura 7.39 Gráfica de pesos de los mejores procesos obtenidos a partir de explorar el camino mínimo y de todos los caminos, y la diferencia entre


Atendiendo a los mejores procesos que se han obtenido en cada caso, en se puede apreciar cómo en la mayoría de los casos, el

mejor proceso obtenido a partir del camino mínimo coincide con el me

proceso. Sin embargo, tal como se ve en la línea que muestra el diferencial de pesos, existen casos en los que el proceso óptimo no es alcanzable a través de la suma de caminos mínimos.

Al igual que se ha visto en los experimentos T1, la evolución del número de procesos a evaluar crece de manera significativa cuando evaluamos todos los caminos posibles. A mayor número de caminos posibles, mayor

o de combinaciones, por eso cuando solo se evalúa el camino

mínimo, el número de procesos posibles se mantiene casi constante, solo ose modificado por el número de máquinas que implementan una

misma operación. En consecuencia, la evolución del número de procesos y el tiempo necesario para evaluar todos los procesos crece, tal como se

muestra en las figuras Figura 7.40 y Figura 7.41.

Los mismos procesos se han ejecutado para la Planta 2, obteniendo los

tos recogidos en las tablas 0y 0

Gráfica de pesos de los mejores procesos obtenidos a partir de explorar el camino mínimo y de todos los caminos, y la diferencia entre

pesos por proceso para la Planta 1.

Atendiendo a los mejores procesos que se han obtenido en cada caso, en mo en la mayoría de los casos, el

coincide con el mejor

mo se ve en la línea que muestra el ptimo no es

Al igual que se ha visto en los experimentos T1, la evolución del número ce de manera significativa cuando evaluamos

todos los caminos posibles. A mayor número de caminos posibles, mayor cuando solo se evalúa el camino

mínimo, el número de procesos posibles se mantiene casi constante, solo ose modificado por el número de máquinas que implementan una

misma operación. En consecuencia, la evolución del número de procesos y el tiempo necesario para evaluar todos los procesos crece, tal como se

, obteniendo los

Gráfica de pesos de los mejores procesos obtenidos a partir de explorar el camino mínimo y de todos los caminos, y la diferencia entre


Figura 7.40 Evolución del número de procesos en función del número actividades del Proceso Funcional para la Planta 1.

Figura 7.41 Evolución del tiempo de cálculo en función del número de actividades de los Procesos Funcionales para la Planta 1.

Se ha realizado el mismo procedimiento para la Planta 2 obteniéndose

los datos mostrados en las Tabla 7.16 y Tabla 7.17 para la exploración de todos los caminos y de solo los caminos óptimos respectivamente.


Tabla 7.16 Datos obtenidos en el experimento 2 para la Planta 2 explorando todos los procesos.

Código Nº Proc. Proc.

óptimo Proc.

Pésimo Proc.

Medio Gen(t) Total (t)

Por proceso

(t)

1.1 32 6 24 13,56 516 4771 149,09 1.2 16 6 21 12,75 449 5000 312,50 1.3 62 5 21 13,28 523 4727 76,24 2.1 128 10 35 20,7 700 7445 58,16 2.2 320 8 38 22,84 733 10958 34,24 2.3 128 7 33 20,9 694 7367 57,55 3.1 512 12 45 24,07 879 14230 27,79 3.2 512 10 42 24,24 889 15938 31,13 3.3 1024 9 50 24,96 1130 29904 29,20 4.1 2048 12 56 31,16 1293 64842 31,66 4.2 4096 13 60 31,58 1500 226946 55,41 4.3 5120 12 63 33,84 1325 446941 87,29 5.1 16384 16 75 35,41 4408 509282 31,08 5.2 8192 15 75 36,43 2313 232278 28,35 5.3 16384 16 76 36,03 3904 474610 28,97

Tabla 7.17 Datos obtenidos en el experimento 2 para la Planta 2 explorando los caminos óptimos.

Código Nº Proc. Proc.

óptimo Proc.

Pésimo Proc.

Medio Gen(t) Total (t)

Por proceso

(t)

1.1 2 6 7 6,5 512 4522 2261 1.2 1 6 6 6 409 4469 4469 1.3 2 5 6 5,5 495 4364 2182 2.1 2 10 11 10,5 622 5244 2622 2.2 2 8 9 9,5 707 6271 3135,5 2.3 2 8 12 10 718 5729 2864,5 3.1 2 12 13 12,5 973 6968 3484 3.2 2 10 12 11 869 6960 3480 3.3 4 9 17 12 1105 7225 1806,25 4.1 2 13 15 14 1035 7364 3682 4.2 4 15 18 16,5 1139 7731 1932,75 4.3 2 12 13 12,5 1009 9133 4566,5 5.1 4 16 16 16 1424 9065 2266,25 5.2 2 16 18 17 1176 8484 4242 5.3 4 16 20 17,75 1505 9742 2435,5

En la Figura 7.42proceso obtenido a partir de losel calculado a partir de todas las combinaciones.

de que en 11 casos coincidadistancia no sea muy grande, permite afirmar que la funcionalidad de control de colisiones Tampoco se aprecia una tendencia clara en el que

perfile como mejor solución en función del tamaño del proceso.

Respecto al número de procesos evaluadoaprecia que se consume muchos más recursos en el enfoque de explorar

todos los procesos, y se incremeejecución, resultado de evaluar y controlar las colisiones sobre cada proceso. El enfoque basado en el la exploración de solo los procesos compuestos por los caminos mínimos, mantiene un coste cercano a ser

constante. Esta información se puede apreciar en las Figura 7.44.

Figura 7.42 Gráfica del peso del mejor proceso obtenido para todos los

caminos y el camino óptimo y la diferencia entre pesos para la

Capítulo 7. Implementación y Validación

Figura 7.42 se puede apreciar cómo en 4 procesos de los 15proceso obtenido a partir de los caminos mínimos no se corresponde con

a partir de todas las combinaciones. Sin embargo, el he

de que en 11 casos coincida y en los 4 casos que no coincidendistancia no sea muy grande, permite afirmar que la funcionalidad de control de colisiones tiene un leve impacto sobre el proceso óptimo. Tampoco se aprecia una tendencia clara en el que un enfoque u otro se

perfile como mejor solución en función del tamaño del proceso.

Respecto al número de procesos evaluados y su tiempo de ejecución, se aprecia que se consume muchos más recursos en el enfoque de explorar

todos los procesos, y se incrementa de forma significativa el tiempo de ejecución, resultado de evaluar y controlar las colisiones sobre cada proceso. El enfoque basado en el la exploración de solo los procesos compuestos por los caminos mínimos, mantiene un coste cercano a ser

. Esta información se puede apreciar en las Figura 7.43

Gráfica del peso del mejor proceso obtenido para todos los caminos y el camino óptimo y la diferencia entre pesos para la Planta

Implementación y Validación 245

mo en 4 procesos de los 15, el no se corresponde con Sin embargo, el hecho

en los 4 casos que no coinciden la distancia no sea muy grande, permite afirmar que la funcionalidad de

tiene un leve impacto sobre el proceso óptimo. un enfoque u otro se

y su tiempo de ejecución, se aprecia que se consume muchos más recursos en el enfoque de explorar

nta de forma significativa el tiempo de ejecución, resultado de evaluar y controlar las colisiones sobre cada proceso. El enfoque basado en el la exploración de solo los procesos compuestos por los caminos mínimos, mantiene un coste cercano a ser

Figura 7.43 y

Gráfica del peso del mejor proceso obtenido para todos los Planta 2.


Figura 7.43 Evolución del número de procesos en función del número de

actividades del Proceso Funcional para la Planta 2.

Figura 7.44 Evolución del tiempo de cálculo de procesos en función del número de actividades del proceso funcional para la Planta 2.


7.2.3 Experimentación T3: Regeneración ante Fallos

de Planta

El tercer experimento diseñado está relacionado directamente con la regeneración de los procesos en tiempo de ejecución. Para la realización de este experimento se ha realizado una simulación de fallo sobre una máquina industrial. El objetivo del experimento es forzar un error por

timeout durante la invocación de uno de los servicios (simularía a la caída de una máquina), y a partir de este momento capturar la excepción y regenerar el proceso en función del estado en el que se encuentre. Al contrario que en los otros experimentos, este experimento solo se realiza

para un proceso, ya que el funcionamiento es exactamente igual en todos los casos, por lo que no aportaría información relevante.

La prueba realizada consiste en desconectar la máquina CB7 utilizada

en el proceso para llegar a la máquina de torneado MT3, tal como se muestra en la Figura 7.45.

Aunque durante este experimento se realizan los diferentes pasos del

proceso de forma manual para poder extraer los objetos intermedios, todas las actividades son vinculables entre sí. De esta forma se puede generar de automáticamente la regeneración del proceso, ya que la

Figura 7.45 Proceso a ejecutar y localización del fallo forzado.


intervención del usuario no es necesaria al existir una correspondencia completa entre la salida de una fase y la entrada de la siguiente.

Durante este experimento se utilizará nuevamente el proceso del primer experimento a modo de ilustración del mecanismo de gestión de errores implementado y cómo se identifican los errores y se regenera el proceso volviendo a pasar por todas las fases. Hay que tener en cuenta que en el

desarrollo de la herramienta utilizada para compilar los procesos se ha utilizado un indicador de control, que permite generar los procesos BPEL con la parte de control de errores o sin ella. El motivo de haber prescindido de esta parte en las primeras secciones es principalmente la

simplificación del código generado.

Las principales diferencias del proceso BPEL con el control de errores

incluido es que varía levemente su estructura respecto al BPEL sin control de errores. Se ha definido un ámbito global al proceso, y dentro de este ámbito se establecen las acciones necesarias a realizar ante un fallo en el mismo. Adicionalmente a este ámbito se genera automáticamente un capturador de errores por elemento del proceso

donde, una vez capturado el error, se procesa la información y se toma la acción a realizar.

En la Figura 7.46 se muestra cómo se estructura el proceso con el control de errores. Se contiene un elemento compensationHandler de BPEL dentro del scope global del proceso. También se muestra cómo todas las invocaciones a los servicios (b) tienen definido un capturador

de errores. El funcionamiento de la gestión de errores implementada se explicará conforme se produce el flujo de control de errores en un proceso BPEL.

Ante un fallo en la invocación de un proceso se captura la excepción en el elemento catch perteneciente al elemento invoke. En este fragmento se realiza la asignación de la información necesaria para identificar el punto

exacto del error. Por simplificación, y a efecto de las pruebas, se ha prescindido de la gestión de los diferentes tipos de errores y se tratan todos como caída del servicio. Tal como se ve en el código generado por la herramienta, en la Tabla 7.18, lo que se realiza en la captura del error es copiar la información sobre el error en la variable con la que se va a

invocar al servicio de monitorización que se ha definido en la presente tesis. Esta información está compuesta por el proceso que ha fallado (ruta accesible del despliegue del proceso), la operación que ha fallado y la secuencia en la que se encuentra. El motivo de introducir la secuencia


es eliminar posibles ambigüedades por que exista más de una llamada a la misma operación.

Figura 7.46 Imagen del proceso generado con control de errores (a) y detalle del manejador de errores global y capturador de error de un

elemento invoke (b). Por la lógica de la ontología no se pueden desarrollar dos o más actividades en un mismo instante de tiempo sobre una misma máquina. Una vez que se ha identificado el error, se propaga el error hacia el

ámbito general del proceso.

Tabla 7.18 Captura de la lógica de la gestión de errores en un elemento invoke del proceso.

<bpel:invoke>

<bpel:catchAll>

<bpel:sequence>

<bpel:copy><bpel:from>

<bpel:label>http://localhost:8080/ode/deployment/bundles/005_Experimento_


1_17/005_Experimento_1_17.bpel</bpel:label>

</bpel:from>

<bpel:to variable="InformarErrorRequest2" part="identProceso" /> </bpel:copy>


<bpel:label>MoveToEnd_OperationRef</bpel:label>

</bpel:from>

<bpel:to variable="InformarErrorRequest2" part="servicioError" /> </bpel:copy>


<bpel:label>3</bpel:label>

</bpel:from>

<bpel:to variable="InformarErrorRequest2" part="secuenciaError" /> </bpel:copy>

<bpel:rethrow />

</bpel:sequence>

</bpel:catchAll>

</bpel:invoke>

Dentro del ámbito general, como ya se ha visto en la Figura 7.46 (b), se ha definido la acción a realizar ante un error. Concretamente lo que se realiza es la llamada al servicio de monitorización propio del sistema de gestión semántica y, posteriormente, se forzará la finalización del

proceso. El motivo de forzar la finalización es el control de posibles flujos paralelos. Ante un fallo se paraliza todo el proceso y se regenerará desde el punto en el que se haya quedado.

Tabla 7.19 Captura del código compensationHandler del proceso.

<bpel:compensationHandler>

<bpel:sequence>

<bpel:invoke partnerLink="Cliente_2" portType="wsdl1:MonitorizacionPlanta1PortType" operation="InformarError" inputVariable="InformarErrorRequest2" outputVariable="InformarErrorResponse2" /> <bpel:exit />

</bpel:sequence>

</bpel:compensationHandler>

Mediante la implementación realizada se controlarán los posibles errores en tiempo de ejecución y se capturarán por el propio motor de ejecución.

Una vez capturados, el control sobre la gestión del error detiene el proceso para la regeneración del mismo.

Cuando se detecta el error, el Motor de Ejecución invocará al Sistema de

Monitorización, el cual gestionará el error extrayendo el Proceso Funcional pendiente y la máquina por la que ha fallado el proceso, regenerando un nuevo proceso. En la Figura 7.45 se ha mostrado la trayectoria del


proceso utilizado y la localización donde se ha forzado el error. Tras invocar al Servicio de Monitorización, se extrae qué máquina implementa el servicio que ha fallado y se actualiza la información de la ontología del

nivel de planta. En este caso se elimina la instancia correspondiente a la máquina CB7, con lo que desaparecerá de todos los procesos de inferencias y, a efectos prácticos, es como si no existiera, tal como se ve en la Figura 7.47.

Tras la invocación del servicio, y utilizando los razonamientos ya vistos, se obtiene qué máquina ejecuta qué servicio, y qué servicio se

corresponde con qué tipo de proceso. Se elimina toda la información de los procesos de transporte (que son los que contienen información estructural de la planta). Los servicios que se corresponden con procesos de manejo de materia se mantienen, pero se extrae la información del tipo de proceso. El resultado de este proceso es un proceso funcional que

recoge las especificaciones pendiente de ejecutar, tal como se muestra en la Figura 7.48 (a).

Figura 7.47 Captura de la ontología sin la Cinta de Transporte CB7. Sobre este proceso se vuelve a aplicar todo el ciclo definido en esta investigación. En primer lugar se generan los procesos candidatos para

el Proceso Funcional obtenido, estableciendo como máquina inicial del flujo la cinta anterior al fallo de invocación de servicio. Como se ha visto, en la Figura 7.45, será el raíl de carga RC1. El resultado es que solo existe una única alternativa para completar el proceso, que se

corresponde con la mostrada en la Figura 7.48 (b). Una vez se dispone del proceso completo se vuele a compilar y se obtiene todos los elementos necesarios para volver a desplegarlo, tal como se muestra en la Figura 7.49.


Figura 7.48 Captura del Proceso Funcional pendiente de ejecutar (a) y del

proceso

Figura 7.49 Captura del proceso BPEL regenerado para la Planta 1.


En el caso de procesos paralelos, el procedimiento a seguir es exactamente el mismo. La única consideración a tener en cuenta es que se toma como máquina de inicio de cada uno de los flujos la máquina

donde se ha parado el proceso, a diferencia que en el experimento 2 donde se asumía que ambos procesos empezaban en una misma máquina inicial.

7.2.4 Conclusiones de la Experimentación Realizada

Durante la presente sección se han realizado diversos experimentos con el propósito de validar las hipótesis de la presente tesis.

En la experimentación T1 se ha mostrado como haciendo uso de una ontología con la información de planta, se pueden modelar, compilar y

ejecutar de forma automática procesos a medida de una planta concreta a partir de Procesos Funcionales independientes de la infraestructura de la planta. Por lo tanto, se puede afirmar que haciendo uso de los razonamientos con información semántica se pueden componer procesos

ad-hoc para una o varias plantas industriales. Además, haciendo uso de la información semántica y los Servicios Web Semánticos se puede abstraer la visión tecnológica durante la creación del proceso, haciéndola transparente para el usuario final. También se ha confirmado la

hipótesis de que en el caso de procesos secuenciales, el mejor proceso es el resultante de la unión de todos los caminos mínimos entre máquinas. Esta confirmación permite ahorrar recursos en la búsqueda del proceso óptimo, ya que tal como se ha visto evaluar solo los caminos mínimos

resulta menos costoso.

Durante la experimentación T2 se ha puesto a prueba la generación de procesos paralelos y se ha estudiado cómo afecta el criterio de control de

colisiones a los procesos obtenidos. Esta experimentación se ha realizado desde dos enfoques diferenciados, por un lado obteniendo los procesos a partir de los caminos mínimos y por otro obteniendo los procesos a partir de la evaluación de todas las posibilidades. De esta forma se puede

estudiar tres aspectos relevantes como son: cómo evoluciona el número de procesos a evaluar el la generación de todos los procesos posibles; en qué medida el enfoque de componer procesos a partir del camino mínimo obtiene el mejor proceso; y finalmente, como afecta el criterio definido

para el control de colisiones a los procesos.

Durante el desarrollo de la experimentación se ha puesto de manifiesto la cantidad de procesos posibles para desarrollar las mismas actividades


sobre la misma planta. Sin duda, el diseño y evaluación manual de todas estas posibilidades se convierte en un cuello de botella para el ingeniero de procesos a la hora de desarrollar procesos dentro de un modelo de

producción ágil. En la segunda planta existían 2048 posibilidades para realizar dos procesos considerablemente simples. Por este motivo, el automatizar la composición y el control de procesos concurrentes permite agilizar la gestión de procesos, permitiendo reducir el tiempo de

respuesta de una organización manufacturera. Durante el desarrollo de la experimentación se ha visto como el número de procesos posibles crece exponencialmente conforme se incrementa la complejidad del Proceso Funcional. Se ha identificado de la mayor parte de este tiempo se

consume en la resolución de colisiones y evaluación del proceso, mientras que el tiempo de generación de las posibilidades a partir de información semántica se mantenía lineal. Por lo tanto, una alternativa sería estudiar un método de evaluación y control activa de colisiones

durante la generación semántica de los procesos y no a posteriori.

En el estudio analítico del segundo experimento se ha identificado el coste de evaluar todos los procesos y se ha comparado con el resultado

de aplicar solo los cálculos sobre los caminos mínimos. El resultado ha sido que en el 80% de los procesos estudiados el proceso óptimo es alcanzable a partir de la suma de caminos mínimos, y en el 20% restante la diferencia entre el proceso obtenido a partir del camino mínimo y del

obtenido mediante la generación de todas las combinaciones es escasa, siendo inferior al 10% del peso del proceso. Por otro lado, no se ha identificado una relación directa entre la complejidad del proceso y la necesidad de explorar todos los procesos o solo el obtenido a través de

los caminos mínimos, esto es debido a que las colisiones dependen de las máquinas usadas, el orden en que se usan y la estructura de la fábrica. Queda como una línea de trabajo futura él investigar qué elementos son los que determinan bajo qué circunstancias es adecuado utilizar qué

aproximación y mediante la exploración de cuantos caminos los procesos obtenidos por ambos enfoques convergen.

Respecto al algoritmo desarrollado para el control de la concurrencia, se

ha visto cómo comparando los pesos obtenidos para los procesos paralelos y los procesos sin resolver las colisiones la diferencia ha sido pequeña o nula. Esto demuestra que el planteamiento utilizado tiene un impacto mínimo sobre el coste original de los procesos. Por otro lado,

mediante la exploración de todas las posibilidades se han encontrado alternativas sin necesidad de introducir pausas hasta llegar a la cota máxima de pausas definida. Por este motivo, y debido al coste computacional del algoritmo basado en ramificación y poda, queda


abierto el estudio de otras formulas que permitan establecer una cota de poda más baja (ahora se sitúa en el peor caso posible), y permitan evaluar menos combinaciones de procesos. Tras la realización de los

experimentos se puede afirmar que el sistema, al permitir gestionar procesos paralelos, incrementa el uso de los recursos del Nivel de Planta, y al generarlo de manera automática incrementa la velocidad de respuesta, aliviando el cuello de botella comentado en la introducción.

Durante la experimentación T3 se ha mostrado un ejemplo de regeneración automática de un proceso ante un fallo en el Nivel de

Planta, demostrado cómo la realimentación del sistema permite la recuperación ante errores. Para ello se ha forzado un error sobre el Nivel

de Planta dando de baja un servicio implicado en el proceso. A partir de

este error el sistema ha actualizado la información del Nivel de Planta y ha vuelto a ejecutar el ciclo permitiendo obtener un proceso temporal para finalizar el proceso en ejecución. Con lo que el sistema propuesto permite la regeneración ante fallos del Nivel de Planta y la finalización de

procesos, siempre y cuando existan alternativas para desarrollarlos.

C a p í t u l o 8

Conclusiones

En esta investigación ha quedado patente que es posible de forma automatizada, la gestión de los procesos de fabricación integrados en el resto de procesos de negocio de la organización mediante la incorporación de información semántica a través de ontologías. Este

nuevo modelo de gestión permite, por un lado, tratar los procesos de fabricación desde una perspectiva de negocio, ya que los aspectos tecnológicos y del nivel de planta se gestionan de un modo trasparente; por lo tanto, se logra la integración de los procesos de fabricación dentro

de los sistemas de gestión de procesos de negocio de las organizaciones. Por otro lado, el automatismo logrado en las tareas de modelado, compilación, ejecución y monitorización de los procesos de fabricación permite resolver el cuello de botella producido por el incremento de

demanda de productos personalizados. Gracias a la conceptualización del dominio y al automatismo logrado, se minimizan la participación de diferentes expertos en cada una de las fases del proceso, lo que permite afirmar que se logra una gestión ágil de la fabricación.

Mediante la definición de un modelo de gestión de procesos de fabricación basado en ontologías, se han identificado, modelado y desarrollado los elementos que permiten hacer uso de la información

semántica para automatizar cada una de las fases del ciclo de vida BPM aplicado a los entornos manufactureros. Como resultado, se ha modelado una ontología específica con información del nivel de planta y se ha vinculado a ontologías de otros dominios como son ontologías de

BPM y ontologías de Servicios. También se ha creado un modelador de procesos que utiliza la información de la ontología para generar y evaluar los procesos de fabricación de forma automática, un compilador de


procesos que es capaz de inferir los servicios necesarios para componer ejecutables de manera autónoma y un sistema de monitorización que, además de capturar los errores, es capaz de extraer los objetivos no

satisfechos por el proceso y regenerar y lanzar un proceso que los cumpla.

8.1 Principales Aportaciones La presente tesis se ha centrado en la creación de un modelo de gestión

integral de los procesos de fabricación basado en información semántica como fuente formal de conocimiento para conceptualizar la información referente al dominio industrial. En este sentido, las aportaciones más relevantes de la presente tesis se corresponden con las siguientes:

• Se ha definido y formalizado el proceso de gestión semántica de

procesos de fabricación y de negocio, identificando cada una de las fases del proceso, sus entradas, salidas y objetivos a realizar en cada una de ellas. Esta definición aunque se ha orientado al dominio industrial, se puede aplicar a diferentes dominios, ya

que se basa en los aspectos fundamentales de BPM y como introducir la información semántica en cada una de las fases de estas fases.

• Se ha formalizado y conceptualizado una ontología que permita

establece relaciones entre el nivel de planta, negocio y servicios.

Estableciendo una serie de reglas que modelan el comportamiento del entrono y permiten establecer formalmente las acciones que se pueden realizar y las acciones que no en un dominio concreto. Adicionalmente se ha conectado la ontología

propuesta a una ontología definida para modelar procesos BPMN. Esta ontología es usada para el sistema de representación y modelado de procesos.

• Se ha concebido un algoritmo para la composición de procesos

de fabricación, en función de las reglas establecidas en la

ontología. Este algoritmo puede ser aplicado sobre otros dominios, realizando leves cambios, gracias a la independencia en la gestión de la información de procesos, de la información de planta y del propio mecanismo de composición.

• Se ha diseñado un mecanismo de extracción e inferencia de

información tecnológica a partir de información conceptual del

Capítulo 8. Conclusiones 259

nivel de negocio basado en la ontología propuesta y Servicios Web Semánticos.

• Se ha creado un sistema realista, basado en una arquitectura

SOA, que permita establecer el escenario donde validar cada

una de las actividades del proceso de gestión semántica de procesos de fabricación.

• Se ha contruido implementación de un sistema de gestión de

procesos de negocio BPM con información semántica basado en módulos de software libre que se corresponde con las siguientes implementaciones especificas:

o Implementación de un módulo de validación de procesos BPM.

o Implementación de un modulo de modelado semántico de procesos BPM.

o Implementación de un modulo de compilación de procesos BPM a procesos BPEL.

o Implementación de un sistema de monitorización de la información semántica.

• De forma transversal, se ha concebido un marco general para la

integración de información semántica en otros dominios. La modularidad establecida en el desarrollo de la presente tesis permite realizar cambios de dominio, realizando cambios únicamente sobre determinadas partes del sistema.

8.2 Problemas Abiertos Dada la transversalidad de la temática abordada, la presente tesis engloba una extensa variedad de ámbitos de diferente naturaleza dentro del ciclo de vida BPM. Una vez se han trazado los objetivos generales y validado la hipótesis de partida planteados para esta integración, queda

patente la idoneidad y viabilidad del planteamiento propuesto. De esta forma, queda también completamente justificada la pertinencia de la continuidad de la investigación a través de los aspectos complementarios que se han ido identificando a lo largo del trabajo pero que no han

podido ser abordados por quedar fuera de los objetivos trazados. Entre los aspectos, se identifican componentes tanto de investigación básica


como aplicada sobre los elementos presentados en la presente tesis. Los principales son:

• Realizar un estudio de diferentes métodos y algoritmos para el

modelado de procesos. Determinar factores que influyen en la obtención del proceso óptimo, como estructura de planta, número de caminos alternativos, etc.

• Realizar un estudio del rendimiento de los algoritmos en

procesos complejos y determinar los aspectos críticos en

función del volumen de los procesos. También realizar diversas pruebas de escalabilidad y rendimiento sobre diversas plantas con procesos realistas.

• Establecer un mecanismo de publicación de la información

semántica de cada máquina industrial de forma automatizada. De forma que se genere automáticamente la instanciación del

Nivel de Planta.

8.3 Líneas Futuras La presente memoria de tesis se enmarca dentro de la línea de investigación informática industrial y robótica del grupo de investigación

GrupoM: redes y middleware de la Universidad de Alicante. Este trabajo continua una de las líneas futuras identificadas dentro de la tesis doctoral “Metodología para la gestión integral de los procesos de fabricación. Modelado de la maquinaria industrial como un sistema de

gestión de procesos de negocio” (Gilart, 2010).

Asimismo, el presente trabajo de investigación abre una serie de líneas

de investigación que dan continuidad a la línea marcada dentro del grupo dentro del área de la informática industrial. Concretamente se han identificado las siguientes líneas de investigación que deseamos abordar durante los próximos años, alguna de las cuales incluso ya ha sido

inicializada:

• Desarrollo del concepto Cloud Agile Manufacturing, donde

gracias a la trasparencia obtenida del nivel de planta, se puede trabajar en el desarrollo de un modelo que ofrezca las plantas de fabricación como servicio, permitiendo integrarlas dentro del

modelo B2B.


• Estudio y evaluación de diferentes sistemas de composición de

procesos en función de dominios de diferentes naturaleza.

• Desarrollo de un protocolo de inter-comunicación semántica

entre dispositivos que permita el descubrimiento y población automática de una ontología.

• Estudiar qué factores del nivel de planta hacen que sea posible lograr una mayor flexibilidad en la gestión de los procesos.

Obtener un modelo que permita diseñar plantas industriales más flexibles y que permitan abordar simultáneamente un gran número de procesos de fabricación de diferente naturaleza.

Aunque todas las líneas identificadas considero que tienen un gran

recorrido, una de las líneas de investigación que me gustaría liderar en el futuro es la de extender el modelo propuesto a otros dominios, estudiar la idiosincrasia de los procesos según el sector donde se desarrollen, y proponer un modelo general de integración semántica de procesos.

Considero que la gestión semántica de procesos es una gran aportación para la construcción de Sistemas Informáticos especializados y que puede incrementar en gran medida la automatización y autonomía de las TI.

8.4 Publicaciones A partir de la investigación realizada en este trabajo se ha obtenido un conjunto de publicaciones en revistas internacionales y congresos nacionales e internacionales del ámbito. A continuación se recogen las publicaciones tanto en revistas como en congresos que se han

considerado más relevantes, junto con un breve análisis de sus indicios de calidad que permiten avalar dicha relevancia en el ámbito de la investigación.

Revistas

“Cloud agile manufacturing”. F. Maciá Pérez, J. V. Berná Martínez, D.

Marcos Jorquera, I. Lorenzo Fonseca, Antonio Ferrándiz Colmeiro. IOSR Journal of Engineering.

• Indicios de calidad: Revista de acceso libre con un ratio de

aceptación, según los editores, del 14,15%. Indexada por varios

buscadores científicos como NASA - Astrophysics Data System


(ADS) Digital Library, Google Scholar, Index Copernicus Journals, etc. Sistema de revisión por pares.

Congresos

“Semantic Processes Modelling Independent of Manufacturing Infrastructures” A. Ferrándiz Colmeiro, V. Gilart Iglesias, F. Maciá Perez. Proceedings of the 15th IEEE International Conference on Emerging

Technologies and Factory Automation (ETFA'10). 2010

• Indicios de calidad: Uno de los congresos internacionales del

IEEE más importantes en el ámbito de las tecnologías emergentes aplicadas a la industria y automatización industrial.

Sistema de revisión por pares.

“Semantic-driven Manufacturing Process Management Automation.” Maciá Pérez, V. Gilart Iglesias, A. Ferrándiz Colmeiro, J.V. Berná Martínez, J. Gea Martínez. Proceedings of the 14th IEEE International

Conference on Emerging Technologies and Factory Automation (ETFA'09). 2009.

• Indicios de calidad: Uno de los congresos internacionales del

IEEE más importantes en el ámbito de las tecnologías

emergentes aplicadas a la industria y automatización industrial. Sistema de revisión por pares.

“New Models of Agile Manufacturing Assisted by Semantic.” F. Maciá Pérez, V. Gilart Iglesias, A. Ferrándiz Colmeiro, J.V. Berná Martínez, J.

Gea Martínez. Proceedings of the IEEE EDOC 2009 workshops and short papers. 2009.

• Indicios de calidad: Congreso internacional del IEEE de tipo “B”

según la clasificación del CORE (Computing Research and

Eductaion) que incluye el ámbito de la gestión de procesos de negocio y tecnologías de la información.

“Management system for manufacturing components aligned with the organisation IT systems.” D. Marcos Jorquera, F. Maciá Pérez, V. Gilart

Iglesias, J. Gea Martínez, A. Ferrándiz Colmeiro. 7th International Conference on Practical Application of Agents and Multi-Agents Systems (PAAMS 2009). Advances in Intelligent and Soft Computing 55. 2009.

• Indicios de calidad: Situado entre sesenta y cinco congresos

más importantes en el ámbito de la inteligencia artificial,


aprendizaje de máquinas, robótica e interacción hombre-máquina según el Computer Science Conference Ranking (posición 52 con un índice de 0,56 sobre 1).

C a p í t u l o 9

Referencias

(Alting, 1993) Alting, L. “Manufacturing Engineering Processes”. Marcel Dekker Publishers, Nueva York (Estados Unidos). 1993.

(Arancón et al., 2008) Arancón, J.; Polo, L. Berrueta, D.; Lesaffre, F-M., De Abajo, N.; Campos, A. “Ontology-Based Knowledge Management in the Steel Industry: Arcelor’s use cases”. Cardoso, J.; Hepp M.; Lytras, M. (Editores). The Semantic Web. Real World Applications from Industry. Second edition, pp. 243-272. Springer, Heidelberg (Alemania). 2008.

(Avella & Vázquez, 2005)

Avella, L. and Vázquez, D. “Is Agile Manufacturing a New Production Paradigm”. Universia Business Review, 6, pp. 94-107, 2005.

(Awad et al., 2008) Awad, A., Polyvyanyy, A., Weske, M. "Semantic Querying of Business Process Models". 12th International IEEE Enterprise Distributed Object Computing Conference (EDOC), Munich (Alemania), pp. 85-94, 2008.

(Babiceanu & Chen, 2006)

Babiceanu, R. & Chen, F. "Development and applications of holonic manufacturing systems: a survey". Journal of Intelligent Manufacturing, 17, pp. 111–131, 2006.

(Barata et al., 2006) Barata, J.; Santana, P. F. & Onori, M. "Evolvable Assembly Systems: A Development Roadmap". Symposium on Information Control Problems in Manufacturing (IFAC), Saint-Etienne (Francia), 12(1), pp. 169-174. 2006.

(Barata et al., 2007a) Barata, J.; Frei, R. & Onori, M. "Evolvable Production Systems Context and Implications". IEEE International Symposium on Industrial Informatics, Vigo (España), pp. 3233-3238. 2007.

(Barata et al., 2007b) Barata, J.; Onori, M.; Frei, R. & Leitão, P. "Evolvable Production Systems: Enabling Research Domains". International Conference on


Changeable, Agile, Reconfigurable and Virtual Production, Toronto (Canadá). 2007.

(Barata et al., 2007c) Barata, J.; Ribeiro, L. & Colombo, A. “Diagnosis using Service Oriented Architectures (SOA)”. Proceedings of the 5th IEEE International Conference on Industrial Informatics, Viena (Austria), pp. 951-956. 2007.

(Barros, 2007) Barros, O. “Business process architecture and design”. Business Process Trends. 2007. http://www.bptrends.com/publicationfiles/05-07-ART-Business%20Processes%20and%20Design-Barros.pdf (acceso mayo 2014).

(Berners-Lee et al., 2001)

Berners-Lee, T.; Hendler, J.; Lassila, O. “The semantic web”. Scientific american, 284(5), pp. 28-37. 2001.

(Blox, 2009) Blox, J.; Eshuis R.; Mühlenberg, L.; van Gaalen J.C. “BPMN 2 BPEL research on mapping BPMN to BPEL”. Ph.D Thesis. Eindhoven University of Technology, 2009.

(Bock et al, 2012) Bock, C., Fokoue, A.; Haase, P.; Hoekstra, R.; Horrocks, I.; Ruttenberg; A.; Sattler, U; Smith, M. “OWL 2 Web Ontology Language. Structural Specification and Functional-Style Syntax” Motik, B.; Patel-Schneide, P.; Parsia, B. (Editores), Second Edition, 2012. URL: http://www.w3.org/TR/owl2-syntax/ (acceso enero 2014)

(Bonita, 2013) “BonitaSoft” http://es.bonitasoft.com/ (acceso: marzo 2014)

(Borgo & Leitao, 2006) Borgo, S.; Leitao, P. “Foundations for a core Ontology of Manufacturing”. Kishore, R.; Ramesh, R.; Sharman, R. (Editores) Ontologies: A Handbook of Principles, Concepts and Applications in Information Systems, Springer, Heidelberg (Alemania), pp. 751-775. 2006.

(Borst, 1997) Borst, W.N. “Construction of Engineering Ontologies for Knowledge Sharing and Reuse” CTIT Ph.D Thesis series 97-14. Universiteit Twente. 1997.

(BPEL ,2007 ) “Web Services Business Process. Execution Language Version 2.0 OASIS Standard” Abril 2007. URL: http://docs.oasis-open.org/wsbpel/2.0/wsbpel-v2.0.pdf (acceso febrero 2014)

(BPELDesigner, 2012) “BPEL Designer Project” URL: http://www.eclipse.org/bpel/ (acceso febrero 2014)

(BPMN, 2008) “Business Process Model And Notation (BPMN) 1.1”. Object Management Group. URL: http://www.omg.org/spec/BPMN/1.1/ (acceso marzo 2013)

Capítulo 9. Referencias 267

(BPMN2, 2011) “Business Process Model and Notation. Version 2.0” OMG Standard. URL: http://www.omg.org/spec/BPMN/2.0/PDF/ (aceso: abril 2014 )

(BPMN2Modeler, 2013)

BPMN2 Modeler. Eclipse SOA Project Community. http://eclipse.org/bpmn2-modeler/ (acceso: marzo 2014 )

(BPMNOntology, 2009)

https://dkm.fbk.eu/images/2/23/OntoBPMN.owl (acceso: febrero 2014)

(Burlton, 2001) Burlton, R.T. “Business Process Management. Profiting from process”. SAMS Publishing, Indianápolis (Estados Unidos). 2001.

(Bussmann & McFarlane, 1999)

Bussmann, S. & Mcfarlane, D. C. "Rationales for Holonic Manufacturing." Second InternationalWorkshop on Intelligent Manufacturing Systems, Leuven (Bélgica), pp. 177-184. 1999.

(Catsoulis, 2005) Catsoulis, J. “Designing embedded hardware”. O’Reilly Publishers, Second edition, Sebastopol (Estados Unidos). 2005.

(Chakraborty et al., 2011)

Chakraborty, P., Saxena, P. C., Katti, C. P., Pahwa, G. and Taneja, S. “A new practicum in compiler construction”. Computering Applications in Engineering. Education. DOI: 10.1002/cae.20566. 2011.

(Chang, 2005) Chang, J.F. “Business Process Management Systems. Strategy and Implementation”. Auerbach Publications, Estados Unidos. 2005.

(Christhensen et al., 2005)

Christensen, E.; Curbera, F.; Meredith, G., Weerawarana, S. “Web Services Description Language (WSDL) 1.1”. W3C Note. URL: http://www.w3.org/TR/wsdl (acceso enero 2014)

(Comisión Europea, 2008)

Comisión Europea.“Las TIC y las tendencias del negocio electrónico en 2008. Hacia el negocio electrónico 3.0”. URL: http://www.ebusiness-watch.org/key_reports/documents/ExecSum_2008_EU27languages/SeBW_Abstract_ES.pdf (acceso enero 2010).

(Davenport & Short, 1990)

Davenport, T. & Short, J.E. “The industrial engineering information technology and business process redesign”. Sloan Management Review, 15 de julio, 1990. URL: http://sloanreview.mit.edu/article/the-new-industrial-engineering-information-technology-and-business-process-redesign/ (acceso marzo 2014)

(Davenport, 1993) Davenport, T. “Process Innovation”. Harvard Business School Press, Estados Unidos. 1993.

(DCOM, 2010) DCOM industrial protocol. ICPDAS. http://www.icpdas.com/download/7000/whatisdconprotocol_eng.htm (acceso enero 2014)

(Delamer & Martinez- Delamer, I.; Martinez Lastra, J.L. “Ontology modeling of assembly processes and systems using semantic web services”. IEEE


Lastra, 2006) International Conference on Industrial Informatics, Singapur, pp. 611-617. 2006.

(Dentler et al., 2011) Dentler, K.; Cornet, R.; ten Teije, A.; de Keizer, N. “Comparison of reasoners for large ontologies in the OWL 2 EL profile”. Semantic Web, 2(2), pp 71-87. 2011.

(Di Pierri, 2006)

Di Pierri, C. “De la producción masiva a la personalización masiva: los deseos de los consumidores y las nuevas tecnologías como factores modeladores del cambio”. Argos, 23(44), pp. 21-31. 2006.

(Dillon et al., 2008) Dillon, T. S., Wu, C. & Chang, E. “Reference Architectural Styles for Service-Oriented Computing”. Proceedings of the 2007 IFIP international conference on Network and parallel computing, pp. 543-555. 2008.

(DOLCE, 2010) “Descriptive Ontology for Linguistic and Cognitive Engineering”. Institute of Cognitive Science and Technology, Italian National Research Council. URL: http://www.loa-cnr.it/DOLCE.html (acceso febrero de 2010)

(Elzinga et al., 1995) Elzinga, D.J.; Horak, T.; Lee, C. & Bruner, C. “Business Process Management: survey and Methodology”. IEEE Transaction of Engeneering Management, 42(2), pp.119-128. 1995.

(Eriksson & Penker, 1999)

Eriksson, H & Penker, M. "Business Modeling with UML: Business Patterns at work". Wiley & Sons Publishers, Hoboken (Estados Unidos). 1999.

(Erl, 2005) Erl, T. “Service-Oriented Architecture. Concepts, technologies and design”. Prentice Hall, New Jersey (Estados Unidos). 2005.

(Erl, 2009) Erl, T. “SOA Design Patterns.” Prentice Hall, New Jersey (Estados Unidos). 2009.

(eSONIA, 2010) Embedded Service Oriented Monitoring, Diagnostics and Control: Towards the Asset-Aware and Self-Recovery Factory. URL: http://www.esonia.eu (acceso: febrero 2013)

(Espinosa, 2003) Espinosa, M.M. “Introducción a los procesos de fabricación”. Cuadernos de la UNED, Madrid (España). 2003.

(Frei et al., 2007a) Frei, R. M.; Ribeiro, L.; Barata, J.; and Semere, D. "Evolvable Assembly Systems: Towards User Friendly Manufacturing". IEEE International Symposium on Assembly and Manufacturing, Ann Arbor (Estados Unidos), pp. 288-293. 2007.

(Frei et al., 2007b) Frei, R.; Barata, J. & Di Marzo Serugendo, G. "A complexity theory approach to evolvable production systems". Internacional Conferecene in informatics and control, automation and robotics, Angers (Francia), pp. 44-53. 2007.


(Ghidini et al., 2009) Ghidini, C.; Rospocher, M.; Serafini, L. “A formalisation of BPMN in Description Logics”. Technical Report TR. 2009-09-06. URL: https://dkm.fbk.eu/images/3/35/-3631-_BPMNOntology.pdf (acceso: febrero 2014)

(Gilart en al., 2006a) Gilart-Iglesias, V.; Maciá-Pérez, F.; Gil-Martínez-Abarca J.A. and Capella-D’alton, A. “Industrial Machines as a Service: A model based on embedded devices and Web Services”. Proceedings of the 4th International IEEE Conference on Industrial Informatics (INDIN'06). Singapur, pp. 630-635. 2006.

(Gilart et al., 2006b) Gilart Iglesias, V.; Maciá Pérez, F.; Mora Gimeno, F.J.; Berná Martínez, J.V. “Normalization of industrial machinery with embedded devices and SOA”. Proceedings of the 11th IEEE International Conference on Emerging Technologies and Factory Automation (ETFA'06), Praga (República Checa), pp. 173-180. 2006

(Gilart et al., 2007) Gilart-Iglesias, V.; Maciá-Pérez, F.; Marcos-Jorquera, D, and Mora-Gimeno, F.J. “Industrial Machines as a Service: Modelling industrial machinery processes”. Proceedings of 5th International IEEE Conference on Industrial Informatics (INDIN'07), Viena (Austria), pp. 737-742. 2007

(Gilart, 2010) Gilart Iglesias, V. “Metodología para la gestión integral de los procesos de producción. Modelado de la maquinaria industrial como un sistema de gestión de procesos de negocio”. Tesis Doctoral. Universidad de Alicante. 2010.

(Gill & Hobday, 1999) Gill, D. & Hobday, J. “Internet embedded devices for industrial applications”. ERA Technology, Reino Unido. 1999.

(Gomez-Perez et al., 2004)

Gómez Pérez, A.; Fernández López, M.; Corcho, O. “Ontological Engineering. With examples from the areas of knowledge Management, e-Comerce and the Semantic Web”. Editorial Springer-Verlag, Heidelberg (Alemania). 2004.

(Gou et al., 1998) Gou, L.; Luh, P. B. & Kyoka, Y. "Holonic Manufacturing Scheduling Architecture, Cooperation Mechanism and Implementation". Computers in Industry, 37(3), pp. 213-231, 1998.

(Groover, 2000) Groover, M.P. “Automation, production systems, and computer integrated”. Prentice Hall, second edition, Upper Saddle River (Estados Unidos). 2000.

(Gruber, 1993) Gruber, T.R. “A translation approach to portable ontology specification”. Knowledge Acquisition. 5(2), pp. 199-220. 1993

(Hammer & Champy, 1993)

Hammer, M. & Champy, J. “Reengineering the Corporation: A Manifesto for Business Revolution”. Harper Business, Nueva York (Estados Unidos). 1993.


(Hammer, 1990) Hammer, M. “Reengineering Work: Don't Automate, Obliterate”. Harvard Business Review, pp. 104-112, 1990.

(Harmon et al., 2001) Harmon, P.; Rosen, M. & Guttman, M. “Developing E-business Systems and Architectures: A Manager’s Guide”. Morgan Kaufmann Publishers, San Francisco (Estados Unidos). 2001.

(Harmon, 2003 ) Harmon, P. “Business Process Change. A Manager’s guide to improving, redesigning and automating processes”. Morgan Kaufmann Publishers, San Francisco (Estados Unidos) 2003.

(Heineken, 2014) Heineken Shop. URL: http://yourheineken.heineken.com/es (acceso: mayo 2014)

(Hepp et al , 2005) Hepp, M.; Leymann, F.; Domingue, J.; Wahler, A.; Fensel, D. "Semantic business process management: a vision towards using semantic Web services for business process management". IEEE International Conference on e-Business Engineering (ICEBE), Pekín (China), pp. 535-540. 2005.

(Horridge & Bechhofer, 2013)

Horridge, M.; Bechhofer, S. “The OWL API: A Java API for OWL”. Ontologies Semantic Web Journal 2(1), Special Issue on Semantic Web Tools and Systems, pp. 11-21, 2011.

(Horridge & Patel-Schneide, 2012)

Horridge, M.; Patel-Schneide, P. “OWL 2 Web Ontology Language. Manchester Syntax (Second Edition)” W3C Working Group Note, 2012. http://www.w3.org/TR/owl2-manchester-syntax/ (acceso enero 2014)

(ICPDAS, 2010) URL: www.icpdas.com (acceso enero 2014).

(INTALIO, 2011) INTALIO Business Process Management, URL: http://www.intalio.com/ (acceso mayo 2014)

(Java, 2012) URL: https://www.java.com/es/ (acceso febrero 2014)

(JDom, 2007) JDOM API. URL: http://www.jdom.org/ (acceso enero 2014)

(jDOM, 2013) The JDOM Project. URL: http://www.jdom.org/ (acceso noviembre 2013)

(Jeston & Neils, 2006) Jeston, J. & Neils, J. “Business Process Management. Practical guide to successful implementations”. Elsevier, Burlington (Estados Unidos). 2006.

(JSP, 2013) JavaServer Pages Technology. URL: http://www.oracle.com/technetwork/java/jsp-138432.html (acceso febrero 2014)

(Kamoun, 2007) Kamoun, F. “A roadmap towards the convergence of Business Process Management and Service Oriented Architecture”. Ubiquity, 8.


2007.

(Klinker et al., 1991) Klinker, G.; Bhola, C.; Dallemagne, G.; Marques, D.; McDermott, J. “Usable and reusable programming constructs”. Knowledge Adquisition, 3(2), pp. 117-135. 1991.

(Kogut et al., 2002) Kogut, P.; Cranefield, S.; Hart, L.; Dutra, M.; Backlawski, K.; Kokar, M.; Smith, J. “UML for Ontology Development”. The Knowledge Engineering Review, 17, pp 61-64. 2002.

(Koivunen & Miller, 2002)

Koivunen, M.R.; Miller E. “W3C Semantic Web Activity” Semantic Web Kick-Off in Finland - Vision, Technologies, Research, and Applications, HIIT Publications, Helsinki Institute for Information Technology (HIIT), Helsinki (Finlandia), pp. 27-41. 2002.

(Koren et al., 1999) Koren, Y.; Heisel, U.; Jovane, F.; Moriwaki, T.; Pritchow, G.; Ulsoy, A. G.; & Van Brussel, H. "Reconfigurable Manufacturing Systems". Annals of the CIRP, 2, pp. 1-13. 1999.

(Lee et al., 2004)

Lee, S-M.; Harrison, R. & West, A.A. “A component-based distributed control system for assembly automation” Proceedings of 2nd International Conference on Industrial Informatics, Berlin (Alemania), pp. 33-38, 2004.

(Lemaignan et al., 2006)

Lemaignan S.; Siadat A.; Dantan J-Y.; Semenenko A. “MASON: A proposal for ontology for Manufacturing Domain”. Proceedings of the IEEE Workshop on Distributed Intelligent Systems: Collective Intelligence and Its Applications (DIS’06), pp. 195-200. 2006.

(López de Vergara et al., 2009)

López de Vergara, J; Guerrero, A.; Villagrá, V.; Berrocal, J. “Ontology-Based Network Management: Study Cases and Lessons Learned”. Journal of Network and Systems Management, 17(3). 2009.

(Maciá et al, 2011) Maciá Pérez, F.; Gil Martínez Abarca, J.A.; Ramos Morillo, H.; Mora Gimeno, F.; Marcos Jorquera, D.; Gilart Iglesias, V; “Wake on LAN over Internet as Web Service System on Chip.” IEEE Transactions on Industrial Electronics, 58(3), pp. 839-849. 2011.

(Maciá et al., 2005) Maciá-Pérez, F.; Gilart-Iglesias, V.; García-Chamizo, J.M.; Hernández-Sáez, A. & Marcos-Jorquera, D. “Decoupling MVC: J2EE design patterns integration”. Proceedings of the 7th International Conference on Enterprise Information Systems, INTICC Press, Miami (Estados Unidos), pp. 280-287, 2005.

(Marcos et al., 2009) Marcos Jorquera, D.; Maciá Pérez, F.; Gilart Iglesias, V.; Gea Martínez, V.; Ferrándiz Colmeiro, A. “Management system for manufacturing components aligned with the organisation IT systems”. 7th International Conference on Practical Application of Agents and Multi-Agents Systems (PAAMS 2009). Y. Demazeau, J. Pavón, J. Corchado and J. Bajo, Springer, Heidelberg (Alemania), 55, pp. 480-489. 2009.


(Markovic & Kowalkiewicz, 2008)

Markovic, I.; Kowalkiewicz, M. “Linking Business Goals to Process Models in Semantic Business Process Modeling”. 12th International IEEE Enterprise Distributed Object Computing Conference (EDOC), Munich (Alemania), pp. 332-338. 2008.

(Martin & D´Acunto, 2003)

Martin, P. and D’Acunto, A. “Design of a production system: an application of integration product-process”. Int. J. Computer Integrated Manufacturing, 16(7-8), pp. 509–516, 2003.

(Martinez-Lastra & Delamer, 2006)

Martinez-Lastra, J. L. & Delamer, I. M. “Semantic Web Services in Factory Automation: Fundamental Insight and Research Roadmap”. IEEE Transactions On Industrial Informatics, 2(1), pp. 1-11. 2006.

(Martinez-Lastra & Delamer, 2008)

Martinez Lastra, J.L, Delamer, I.M. “Ontoligies for Product Automation”. T.S. Dilon et al. (Editores). Advances in Web Semantics I. LNCS 4891, pp. 276-289. 2008

(McFarlane & Bussmann, 2000)

McFarlane, D.C. & Bussmann, S. “Developments in Holonic Production Planning and Control” Intenational Journal of Production Planning and Control, 11(6), pp. 522-536, 2000.

(Mehrabi et al., 2000) Mehrabi, M. G.; Ulsoy, A. G. & Koren, Y. "Reconfigurable Manufacturing Systems and their Enabling Technologies." International Journal Manufacturing Technology and Management, 1, pp. 113-130, 2000.

(Moreno, 2004) Moreno, R.P. “Ingeniería de la automatización industrial.” Ra-Ma, Madrid (España), 2004.

(Motik et al., 2004) Motik, B., Sattler, U., Studer, R. “Query Answering for OWL-DL with Rules”. Proceedings of the 3rd International Semantic Web Conference (ISWC 2004), Hiroshima (Japón), pp. 549-563. 2004.

(Motik et al., 2009) Motik B.; Patel-Schneider P.F. , Parsia B. “OWL 2 Web Ontology Language. Structural Specification and Functional-Style Syntax”. W3C Recommendation. 2009.

(Neches et al., 1991) Neches, R.; Fikes, R.E.; Finin, T.; Gruber, T.R.; Senator, T.; Swartout, W.R. “Enabling technology for knowledge sharing”. AI Magazine, 12(3), pp. 36-56. 1991.

(Nike, 2014) Nike Personalization Store.URL: http://www.nike.com/nikeid (acceso marzo 2014)

(OBPMS, 2013) “Oracle Business Process Management Suite 11g”. http://www.oracle.com/us/technologies/bpm/suite/overview/index.html (acceso: marzo 2014)

(ODE, 2012) Apache ODE. Apache Orquestation Director Engine. URL: http://ode.apache.org/


(Onori et al., 2006) Onori, M.; Barata, J. & Frei, R. "Evolvable Assembly Systems Basic Principles". Conference on Information Technology for Balanced Automation Systems in Manufacturing and Services, Springer, Ontario (Canadá), pp. 317-328, 2006.

(Ontograf, 2011) OntoGraf Protege Plug-in URL: http://protegewiki.stanford.edu/wiki/OntoGraf Febrero, 2011. (acceso enero 2014)

(OPTI, 2009) “Oportunidades tecnológicas e industriales para el desarrollo de la economía española”. Fundación Observatiro de Prospectiva Tecnológica Industrial. Ministerio de Industria, Turismo y Comercio. 2009.

(Ouyang et al., 2006) Ouyang, C., Dumas, M., ter Hofstede, A.H.M., van der Aalst, W.M.P. "From BPMN Process Models to BPEL Web Services" IEEE International Conference on Web Services (ICWS'06), Salt Lake City (Estados Unidos), pp. 285-292. 2006.

(Ouyang et al., 2009) Ouyang C., Dumas M., Van Der Aalst, W.M. P., Ter Hofstede, A. H. M., Mendling, J. “From business process models to process-oriented software systems”. ACM Trans. Softw. Eng. Methodol.,19(1), Article 2. 2009.

(OWLGrounding, 2004)

Ontology Web Language Grounding URL: http://www.daml.org/services/owl-s/1.2/Grounding.owl (acceso enero 2014)

(OWLProcess, 2004) Ontology Web Language Process URL: http://www.daml.org/services/owl-s/1.2/Process.owl (acceso enero 2014)

(OWLProfile, 2004) Ontology Web Language Profile URL:http://www.daml.org/services/owl-s/1.2/Profile.owl (acceso enero 2014)

(OWL-S, 2004) “OWL-S: Semantic Markup for Web Services”. W3C Member Submission. 2004. URL: http://www.w3.org/Submission/OWL-S (acceso diciembre 2012)

(Polyvyanyy el al., 2010)

Polyvyanyy, A.; Smirnov, S.;Weske, M. “Business Process Model Abstraction”. Jan vom Brocke, Michael Rosemann (Editores). “Handbook on Business Process Management 1. Introduction, Methods, and Information Systems”. Springer, Heidelberg (Alemania). 2010.

(Protégé, 2012) Protégé Konoledge Editor. http://protege.stanford.edu

(Puttonen et al., 2013) Puttonen, J.; Lobov, A.; Martinez Lastra, J.L., "Semantics-Based Composition of Factory Automation Processes Encapsulated by Web Services Industrial Informatics”, IEEE Transactions on Industrial


Informatics, 9(4), pp. 2349-2359. 2013.

(RDF, 2004) RDF/XML Syntax Specification (Revised). W3C Recommendation 10 February 2004. URL: http://www.w3.org/TR/REC-rdf-syntax/ (acceso febrero 2014)

(RDFS, 2004) RDF Vocabulary Description Language 1.0: RDF Schema. W3C Recommendation 10 February 2004 URL:http://www.w3.org/TR/rdf-schema/

(Ren et al., 2007) Ren, W.; Chen, G.; Chen C.; Ping-Low, C.; Sun, C., Bing Zhang, J.; Yang, Z. “Searching for Service-Oriented Strategies of Dynamic Composition of Web Services: A Comparative Perspective”. The 33rd Annual Conference of the IEEE Industrial Electronic Society (IECON), Taipei (China), pp. 2615-2620. 2007

(Ribeiro et al., 2008) Ribeiro, L.; Barata, J. & Mendes, P. “MAS and SOA: Complementary Automation Paradigms.” International Federation for Information Processing. Innovation in Manufacturing Networks (IFIP), 266, pp. 259-268, Springer, Boston (Estados Unidos). 2008.

(Rummler & Brache, 1995)

Rummler, G. A. & Brache, A.P. “Improving Performance: How to Manage the White Space in the Organization Chart”. Jossey-Bass Publishers, Second edition, Michigan (Estados Unidos). 1995.

(Shen et al., 2005) Shen, J.; Yang, Y.; Zhu, Ch. Wan, Ch. “From BPEL4WS to OWL-S: Integrating E-Business Process Descriptions”. Proceedings of the 2005 IEEE International Conference on Services Computing (SCC’05), Oralndo (Estados Unidos), 1, pp. 181-188. 2005.

(SIRENA, 2003) The SIRENA project. URL: http://www.sirena-itea.org (acceso enero 2012).

(Sirin et al., 2007) Sirin, E.; Parsia, B.; Grau, B.; Kalyanpur, A.; Katz, Y. “Pellet: A practical OWL-DL reasoner”. Web Semantics: Science, Services and Agents on the World Wide Web, 5(2), pp. 51-53. 2007.

(Smith & Fingar, 2002)

Smith, H. & Fingar, P. “Business Process Management. The Third Wave.” Meghan-Kiffer Publishers, Tampa (Estados Unidos). 2002.

(Smith, 1776) Smith, A. “An inquiry into the nature and causes of the wealth of nations.” The University of Chicago Press, Chicago (Estados Unidos). 1976.

(SOAP, 2007) “Simple Object Access Protocol specification. W3C”. URL: http://www.w3.org/TR/soap12-part1/ (acceso diciembre 2013).

(SOCRADES, 2006) SOCRADES project. URL: http://www.socrades.eu/Home/default.html (acceso enero 2010).

(SODA, 2006) The SODA project. URL: http://www.soda-itea.org (acceso enero


2010).

(Staudinger, 2010) Staudinger GMHB. URL: http://www.staudinger-est.de/ (acceso febrero 2010).

(Studer et al., 1998 ) Studer, R.; Benjamins, V.R.; Fensel, D. “Knowledge Engineering: Principles and Methods”. Data & Knowledge Engineering, 25(1-2), pp. 161-197. 1998.

(SUPER, 2006) Semantics Utilised for Process Management within and between Enterprises. (FP6-026850). Proyecto Comisión Europea. 2006-2009.

(SWRL, 2004 ) “SWRL: A Semantic Web Rule Language Combining OWL and RuleML”. W3C Member Submission 21 May 2004 URL: http://www.w3.org/Submission/SWRL/ (acceso: abril 2014)

(Tomcat, 2013) Apache Tomcat. URL: http://tomcat.apache.org/ (acceso febrero 2014)

(Topp & Müller, 2002) Topp, U. & Müller, P. “Web based service for embedded devices”.. Web, Web Service and Database Systems (Lecture Notes in Computer Science), 2593, pp. 141-153. 2002.

(Transparent Factory, 2001)

Transparent Factory. Manual de usuario y planificación. 2001. URL: http://www.modicon.com (acceso: febrero 2014)

(Tsarkov & Horrocks, 2006)

Tsarkov, D.; Horrocks, I. “FaCT++ Description Logic Reasoner: System Description”. Automated Reasoning (Lecture Notes in Computer Science), 4130, pp. 292-297. 2006.

(UDDI, 2005) OASIS UDDI Specification TC. URL: https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=uddi-spec (acceso enero 2014)

(Ueda, 1992) Ueda, K. "A concept for bionic manufacturing systems based on DNA-type information". Proceedings of the IFIP TC5 / WG5.3 Eight International PROLAMAT Conference on Human Aspects in Computer Integrated Manufacturing. Tokyo (Japón), pp. 853-863. 1992.

(Van Brussel et al., 1998)

Van Brussel, H.; Wyns, J.; Valckenaers, P.; Bongaerts, L. & Peeters, P. "Reference Architecture for Holonic Manufacturing Systems: PROSA". Computers in Industry, 37, pp. 255-274. 1998.

(Villaseñor et al., 2008) Villaseñor, V.; Bepperling, A.; Lobov, A.; Smit, H.; Colombo, A. W. & Lastra, J.L. “Integration of Multi-Agent Systems and Service-Oriented Architecture for Industrial Automation”. Proceeding of the 6th IEEE International Conference on Industrial Informatics, Daejeon (Korea), pp. 768-773, 2008.

(White, 2005) White, S.A.; “Using BPMN to Model a BPEL Process”. BPTrends,


3(3), pp. 1-18. 2005

(Worthington & Boyes, 2002)

Worthington, S.L.S. & Boyes, W. “E-Business in Manufacturing: Putting the Internet to work in the industrial enterprise” ISA Press, Durham (Estados Unidos). 2002.

(XPORT, 2010) Lantronix. Embedded Device Servers - XPort®. URL: http://www.lantronix.com/device-networking/embedded-device-servers/xport.html (acceso febrero 2014).

(Younghwan et al., 2005)

Younghwan, C. Kwangsoo, K. & Cheolhan, K. “A design chain collaboration framework using reference models.” International Journal of Advanced Manufacturing Technology, 26(1), pp. 183-190. 2005.

A n e x o I

Especificación Ontologías Plantas

Las propiedades especificadas en la instanciación de cada planta se corresponden con las siguientes, expresadas como tripletas de RDF (Sujeto, Predicado, Objeto).

Planta 1



TT1


CB3


TT1


CB4


CB2


CB4


CB2


RC1


CB3



TT2


RC1


TT3


TT2


TT3


RC1


RC1


TT4

CB9 type Cinta_Transportadora Tiene_conexion_eje_X-

TT4

RC1 type Rail_de_carga Tiene_conexion_ejeX+Y+

CB7

Tiene_conexion_ejeX+Y-

CB5

Tiene_conexion_ejeX-Y+

CB8

Tiene_conexion_ejeX-Y-

CB4

TT1 type Mesa_de_giro TT_Tiene_conexion_ejeX+

CB2

TT_Tiene_conexion_ejeY-

CB1

TT2 type Mesa_de_giro TT_Tiene_conexion_ejeX-

CB5

TT_Tiene_conexion_ejeY+

CB6


CB7


CB6


CB8


CB9

MT1 type Máquina_herramienta

Anexo I. Especificación Ontologías Plantas 279

Esta_asociada CB2 MT2 type Máquina_herramienta

Esta_asociada CB3 MT3 type Máquina_herramienta

Esta_asociada CB4 MMT1 type Máquina_herramienta

Esta_asociada CB6 CruzarMaquina_CB1

type CruzarMaquina Es_realizado CB1

CruzarMaquina_CB2


CruzarMaquina_CB3


CruzarMaquina_CB4


CruzarMaquina_CB5


CruzarMaquina_CB6


CruzarMaquina_CB7


CruzarMaquina_CB8


CruzarMaquina_CB9


CruzarMaquina_TT1

type CruzarMaquina Es_realizado TT1

CruzarMaquina_TT2


CruzarMaquina_TT3


CruzarMaquina_TT4


CruzarMaquina_RC1

type CruzarMaquina Es_realizado RC1


type Parar_en_Punto_Determinado Es_realizado CB1















Mover_hasta_el type Parar_en_Punto_Determinado


_sensor_CB9 Es_realizado CB9 Mover_hasta_el_sensor_TT1

type Parar_en_Punto_Determinado Es_realizado TT1

Mover_hasta_el_sensor_TT2






Mover_hasta_el_sensor_RC1

type Parar_en_Punto_Determinado Es_realizado RC1

DrillingMMT1 type Drilling Es_implementado

MMT1

DrillingMT1 type Drilling Es_implementado

MT1

MillingMT2 type Drilling Es_implementado

MT2


MT3

TurningMMT1 type Turning Es_implementado

MMT1

MoveToEnd_CB1

type Servicio_de_Actuacion Ejecuta CruzarMaquina_CB1 URL http://localhost:8080/fabrica1/CB1/CB1_

Service.owl#MoveToEnd_Service WSDL http://localhost:8080/axis2/services/CB1

?wsdl MoveToEnd_CB2



?wsdl MoveToEnd_CB3



?wsdl MoveToEnd_CB4



?wsdl MoveToEnd_CB5

type Servicio_de_Actuacion Ejecuta CruzarMaquina_CB5


URL http://localhost:8080/fabrica1/CB5/CB5_Service.owl#MoveToEnd_Service

WSDL http://localhost:8080/axis2/services/CB5?wsdl

MoveToEnd_CB6



?wsdl MoveToEnd_CB7



?wsdl MoveToEnd_CB8



?wsdl MoveToEnd_CB9



?wsdl MoveToEnd_TT1

type Servicio_de_Actuacion Ejecuta CruzarMaquina_TT1 URL http://localhost:8080/fabrica1/TT1/TT1_S

ervice.owl#MoveToEnd_Service WSDL http://localhost:8080/axis2/services/TT1?

wsdl MoveToEnd_TT2



wsdl MoveToEnd_TT3



wsdl MoveToEnd_TT4



wsdl MoveToDirectio type Servicio_de_Actuacion


n_RC1 Ejectua CruzarMaquina_RC1 URL http://localhost:8080/fabrica1/RC1/RC1_

Service.owl#MoveToEnd_Service WSDL http://localhost:8080/axis2/services/RC1

?wsdl MoveToSensor_CB1

type Servicio_de_Actuacion Ejecuta Mover_hasta_el_sensor_CB1 URL http://localhost:8080/fabrica1/CB1/CB1_

Service.owl#MoveToSensor_Service WSDL http://localhost:8080/axis2/services/CB1






















?wsdl


MoveToSensor_CB9



?wsdl MoveToSensor_TT1

type Servicio_de_Actuacion Ejecuta Mover_hasta_el_sensor_TT1 URL http://localhost:8080/fabrica1/TT1/TT1_S

ervice.owl#MoveToSensor_Service WSDL http://localhost:8080/axis2/services/TT1?

wsdl MoveToSensor_TT2









wsdl Procesar_MMT1

type Servicio_de_Actuacion Ejecuta DrillingMMT1 URL http://localhost:8080/fabrica1/MMT1/MM

T1_Service.owl#Process_Service WSDL http://localhost:8080/axis2/services/MMT

1?wsdl Procesar_MT1 type Servicio_de_Actuacion

Ejecuta DrillingMT1 URL http://localhost:8080/fabrica1/MT1/MT1_

Service.owl#Process_Service WSDL http://localhost:8080/axis2/services/MT1

?wsdl Procesar_MT2 type Servicio_de_Actuacion

Ejecuta MillingMT2 URL http://localhost:8080/fabrica1/MT2/MT2_

Service.owl#Process_Service WSDL http://localhost:8080/axis2/services/MT2

?wsdl Procesar_MT3 type Servicio_de_Actuacion

Ejecuta TurningMT3 URL http://localhost:8080/fabrica1/MT3/MT3_

Service.owl#Process_Service WSDL http://localhost:8080/axis2/services/MT?


wsdl Planta 2



TT1


RC1


CB3


TT1


TT2


CB2


TT2


RC1


CB10


TT3


CB7


TT3


TT4


CB6


CB9


TT4


RC1


CB8


RC1


CB5


RC1 type Rail_de_carga Tiene_conexion_ejeX+Y+

CB1

Tiene_conexion_ejeX+Y-

CB9

Tiene_conexion_ejeX-Y+

CB4

Tiene_conexion_ejeX-Y-

CB10

TT1 type Mesa_de_giro TT_Tiene_conexion_ejeX.

CB2


CB1


CB3


CB4


CB6


CB5


CB7


CB8

MT1 type Máquina_herramienta Esta_asociada CB1




CruzarMaquina_CB1


CruzarMaquina_CB2


CruzarMaquina_CB3


CruzarMaquina_CB4


CruzarMaquina_CB5


CruzarMaquina_CB6


CruzarMaquina_CB7


CruzarMaquin type CruzarMaquina


a_CB8 Es_realizado CB8 CruzarMaquina_CB9


CruzarMaquina_CB10


CruzarMaquina_TT1


CruzarMaquina_TT2


CruzarMaquina_TT3


CruzarMaquina_TT4


CruzarMaquina_RC1

type CruzarMaquina Es_realizado RC1





























Mover_hasta_el_sensor_RC1

type Parar_en_Punto_Determinado Es_realizado RC1


MT1


MT2


MillingMT3

type Drilling Es_implementado

MT3


MT4

TurningMMT1 type Turning Es_implementado

MMT1

MoveToEnd_CB1


Service.owl#MoveToEnd_Service WSDL http://localhost:8080/axis2/services/fabri

ca2/CB1?wsdl MoveToEnd_CB2


















?wsdl MoveToEnd_CB8

type Servicio_de_Actuacion Ejecuta CruzarMaquina_CB8


URL http://localhost:8080/fabrica2/CB8/CB8_Service.owl#MoveToEnd_Service

WSDL http://localhost:8080/axis2/services/fabrica2/CB8?wsdl

MoveToEnd_CB9




type Servicio_de_Actuacion Ejecuta CruzarMaquina_CB10 URL http://localhost:8080/fabrica2/CB10/CB1

0_Service.owl#MoveToEnd_Service WSDL http://localhost:8080/axis2/services/fabri

ca2/CB10?wsdl MoveToEnd_TT1


ervice.owl#MoveToEnd_Service WSDL http://localhost:8080/axis2/services/

fabrica2/TT1?wsdl MoveToEnd_TT2


ervice.owl#MoveToEnd_Service WSDL http://localhost:8080/axis2/services/fabri

ca2/TT2?wsdl MoveToEnd_TT3

type Servicio_de_Actuacion Ejecuta CruzarMaquina_TT3 URL http://localhost:8080/

fabrica2//TT3/TT3_Service.owl#MoveToEnd_Service

WSDL http://localhost:8080/axis2/services/ fabrica2/TT3?wsdl

MoveToEnd_TT4


ervice.owl#MoveToEnd_Service WSDL http://localhost:8080/axis2/services/

fabrica2/TT4?wsdl MoveToDirection_RC1

type Servicio_de_Actuacion Ejectua CruzarMaquina_RC1 URL http://localhost:8080/fabrica2/RC1/RC1_


ca2/RC1?wsdl MoveToSensor_CB1


Service.owl#MoveToSensor_Service WSDL http://localhost:8080/axis2/services/fabri

ca2/CB1?wsdl


MoveToSensor_CB2



ca2/CB2?wsdl MoveToSensor_CB3



ca2CB3?wsdl MoveToSensor_CB4





Service.owl#MoveToSensor_Service WSDL http://localhost:8080/axis2/services

fabrica2/CB5?wsdl MoveToSensor_CB6






/fabrica2/CB7?wsdl MoveToSensor_CB8



/fabrica2/CB8?wsdl MoveToSensor_CB9




type Servicio_de_Actuacion Ejecuta Mover_hasta_el_sensor_CB10 URL http://localhost:8080/fabrica2/CB10/CB1

0_Service.owl#MoveToSensor_Service WSDL http://localhost:8080/axis2/services/fabri


ca2/CB10?wsdl MoveToSensor_TT1


ervice.owl#MoveToSensor_Service WSDL http://localhost:8080/axis2/services/

fabrica2/TT1?wsdl MoveToSensor_TT2


ervice.owl#MoveToSensor_Service WSDL http://localhost:8080/axis2/services/fabri

ca2/TT2?wsdl MoveToSensor_TT3



ca2/TT3?wsdl MoveToSensor_TT4



ca2/TT4?wsdl Procesar_MT1 type Servicio_de_Actuacion


Service.owl#Process_Service WSDL http://localhost:8080/axis2/services/fabri

ca2/MT1?wsdl Procesar_MT2 type Servicio_de_Actuacion




Ejecuta MillingMT3 URL http://localhost:8080/fabrica2/MT3/MT3_



Ejecuta TurningMT4 URL http://localhost:8080/fabrica2/MT4/MT4_


ca2/MT4?wsdl

A n e x o I I

Elementos Intermedios Methontology

El glosario de términos establecido se corresponde con el siguiente:

Nombre Sinónimo Acro Desc. Tipo

Máquina Industrial

Industrial Machine

--- Representa el concepto de maquinaria industrial genérica.

Concepto

Máquina de Transporte

Transport Machine

--- Representa el concepto de máquina de transporte.

Concepto

Máquina de Almacenaje

Storage Machine

--- Representa el concepto de máquina de almacenaje.

Concepto

Máquina de transformación de materia

Process Machine

--- Representa el tipo de maquinaria que procesa la materia prima.

Concepto

Mesa de Giro Turn Table TT Tipo especifico de cinta transportadora que gira sobre su eje, permitiendo mover la materia de manera recta o girándola 90º

Concepto

Rail de carga Rail Carriage RC Tipo especifico de cinta transportadora que se desplaza sobre

Concepto


un raíl permitiendo mover la materia sobre diferentes líneas. Horizontales

Cinta transportadora

Conveyor Belt

CB Cinta transportadora, que desplaza la materia de forma horizontal desde un extremo a otro.

Concepto

Máquina Herramienta

Tool Machine MT Máquina dotada con una herramienta para procesar la materia.

Concepto

Almacén en Rack

Pallet Rack Machine

--- Máquina de almacenaje en altura

Concepto

Carrusel de almacenaje

Storage Carousel Machine

--- Máquina de almacenaje móvil

Concepto

Máquina Multi Herramienta

Multi Tool Machine

MMT Máquina dotada con más de una herramienta.

Concepto

Actividad Activity --- Representa el Concepto actividad dentro de un proceso.

Concepto

Dirección Direction --- Representa una dirección

Concepto

Materia Material --- Representa el concepto materia

Concepto

Materia Logística

LogisticMaterial

--- Representa el concepto materia logística.

Concepto

Materia Procesable

ProcessMateria

--- Materia para fabricar. Concepto

Archivos File --- Documentos utilizados en las plantas industriales

Concepto

Repuestos Replacement --- Materias y piezas de máquinas industriales.

Concepto

Materia Despreciada

--- Materia que resulta excedente del proceso de fabricación.

Concepto

Materia en proceso

inProcessMaterial

--- Materia que está siendo transformada.

Concepto

Materia Prima Raw Material --- Materia antes de ser procesada.

Concepto

Materia Procesada

Processed Material

--- Materia que ha finalizado el proceso de transformación.

Concepto

Material Stuff --- Representa el concepto material

Concepto

Madera Wood --- Concepto de madera Concepto Metal Metal --- Concepto de metal Concepto Piedra Stone --- Concepto de piedra Concepto

Anexo II. Elementos Intermedios Methontology 293

Plástico Plastic --- Concepto de plástico Concepto Parte Maquinaria

Machine Component

--- Concepto de parte de una máquina

Concepto

Motor Engine --- Concepto de motor. Dispositivo de actuación.

Concepto

Sensor Sensor --- Dispositivo de captación.

Concepto

Sensor de giro Turn Sensor --- Sensor de captación de giro.

Concepto

Sensor de movimiento

Movement Sensor

--- Sensor de captación de movimiento.

Concepto

Proceso Process --- Representa el concepto de tipo de operación.

Concepto

Coordinación y Control

Control Process

--- Representa el tipo de operaciones de control.

Concepto

Control Costes Cost Control --- Representa a las operación de de control de coste.

Concepto

Control Inventario

Stock Control

--- Representa las operaciones de control de inventario.

Concepto

Mantenimiento Equipos

Maintenance --- Representa las operaciones de control de equipos.

Concepto

Ensamblaje Assembly --- Representa las operaciones de ensamblaje.

Concepto

Permanente Permanent Assembly

--- Representa las operaciones de ensamblaje permanente.

Concepto

SemiPermanente

Semi Permanent

--- Operación de ensamblaje semi permanente

Concepto

Fusionado Consolidation

Operación de unión por calor

Concepto

Pegado Adhesivo Adhesiove Bondering

Operación de unión por pegado adhesivo.

Concepto

Remachado Rivet Operación de unión por remaches.

Concepto

Soldadura Soldering Operación de unión por fundición de dos piezas con un tercer elemento.

Concepto

Atornillado Turn Unión de piezas por tornillos.

Concepto

Unión por presión

Pressure Unión por presión. Concepto

Inspección y Test

Test Process Proceso de inspección de materia

Concepto


Mecánica Mechanical Test

Consiste en la comprobación mecánica de las piezas

Concepto

Torno Test Control de la forma mediante torno digital

Concepto

Prueba Mecánica

Mechanical Test

Prueba mecánica Concepto

Visual Visual Test Control Visual Concepto Escaneado Scanner Test Control por escaneado Concepto Fotografía Photo Test Control por fotografía. Concepto Manejo de Materia

Material Manage

Proceso de manipulación de materia.

Concepto

Almacenaje Storage Concepto Almacenar Storage

Process Proceso de almacenaje Concepto

Desalmacenar UnStorage Proceso de desalamacenaje de una materia

Concepto

Cruzar Máquina Cross Machine

Proceso que mueve la materia a través de una máquina.

Concepto

Parar en punto determinado

StopOnMachine

Proceso que sitúa la materia en un punto de una máquina.

Concepto

Procesado Process Proceso de transformación de materia

Concepto

Tratamiento Treatment Procesos de tratamiento de la superficie

Concepto

Pintado Paint Proceso de pintado Concepto Pulido Polish Proceso de pulido Concepto Solidificación Solidification

. Procesos de creación

de materia por solidificación

Concepto

Fundido Melting Fundir piezas Concepto Moldeado Casting Solidificar en molde. Concepto Procesado de partículas

particles process

Proceso de modificación de la superficie

Concepto

Fusionado Fused Unión de materias mediante la mezcla de sus componentes

Concepto

Prensado Pressing Modificación de materia por presión

Concepto

Eliminación de materia

Remove Material

Procesos de eliminación de materia

Concepto

Descarga eléctrica

Electric Discharge

Eliminación de materia por intensidades de

Concepto


corriente. Energía electroquímica

Electrochemical Energy

Proceso de eliminación por aplicación de una descarga electroquímica.

Concepto

Erosión química Chemical Erosion

Erosión química Concepto

Fresado Milling Eliminación de materia por medio de una fresa

Concepto

Haz Laser Laser Electron Beam

Corte por medio de un haz laser.

Concepto

Taladrado Drilling Eliminación de materia con un taladro.

Concepto

Torneado Turning Turning Concepto Deformación Deformation Proceso por el cual se

alera la geometría de un objeto.

Concepto

Doblado Bend Proceso de Doblado Concepto Extrusión Extrusion Concepto Forja Forging Proceso de forjado Concepto Formado Forming Proceso de modelado Concepto Laminación Laminating Proceso de separación

en laminas Concepto

Servicio Service Servicio Concepto Servicio de Aplicación

Application Service

Servicio de aplicación Concepto

Servicio de infraestructura

Infraestructure

Servicio de infraestructura

Concepto

Servicio de negocio

Business Service

Servicio de negocio. Concepto

Servicio de orquestación

Orchestation Service

Servicio de orquestación.

Concepto

Servicio de soporte

Support service

Servicio de soporte. Concepto

Nombre Name --- Identificador de cada máquina

Atributo

Número de serie Serial Number

--- Identificador Único de cada máquina

Atributo

Posición Position --- Situación geográfica de un elemento

Atributo

Consumo Eléctrico

Power Consumption

--- Potencia que consume un elemento

Atributo

WSDL --- Contiene la ruta de descripción de un servicio.

Atributo

URL --- Contiene la dirección de la descripción semántica de un servicio.

Atributo


Secuencia Sequence Indica el número de secuencia de una actividad dentro de un proceso.

Atributo

Pasos Steps Tiempo de ejecución

Execution time

Tiempo que una máquina tarda en ejecutar un proceso.

Atributo

Esta ConectadaEje X+

isConnectedOnAxisX+

--- Indica qué máquina está situada justo al lado de otra por el eje X positivo

Relación

Esta ConectadaEjeX-

isConnectedOnAxisX-

--- Indica qué máquina está situada justo al lado de otra por el eje X negativo

Relación

Esta ConectadaEjeY+

isConnectedOnAxisY+

--- Indica qué máquina está situada justo al lado de otra por el eje Y positivo

Relación

Esta ConectadaEjeY-

isConnectedOnAxisY-

--- Indica qué máquina está situada justo al lado de otra por el eje Y negativo

Relación

Esta ConectadaEjeX+Y+

isConnectedOnAxisX+Y+

--- Indica qué máquina está conectada por el eje X positivo e Y positivo Y

Relación

Esta ConectadaEjeX+Y-

isConnectedOnAxisX+Y-

--- Indica qué máquina está conectada por el eje X positivo e Y positivo Y

Relación

Esta ConectadaEjeX-Y+

isConnectedOnAxisX-Y+

--- Indica qué máquina está conectada por el eje X negativo e Y positivo Y

Relación

Esta ConectadaEjeX-Y-

isConnectedOnAxisX-Y-

--- Indica qué máquina está conectada por el eje X negativo e Y negativo Y

Relación

Está Situada Sobre

--- Indica qué máquina de procesado está situada justo una cinta transportadora concreta.

Relación

TieneConexionEjeX+

hasConnectionOnAxisX+

--- Indica qué máquina de procesado tiene conexión con una máquina de transporte en el eje X+.

Relación

TieneConexionEjeX-

hasConnectionOnAxisX-

--- Indica qué máquina de procesado tiene conexión con una

Relación


máquina de transporte en el eje X-.

TieneConexionEjeY+

hasConnectionOnAxisY+

--- Indica qué máquina de procesado tiene conexión con una máquina de transporte en el eje Y+.

Relación

TieneConexionEjeY-

hasConnectionOnAxisY-

--- Indica qué máquina de procesado tiene conexión con una máquina de transporte en el eje Y-.

Relación

TieneConexionEjeX+Y+

hasConnectionOnAxisX+Y+

--- Indica qué máquina de procesado tiene conexión con una máquina de transporte en el eje X+Y+.

Relación

TieneConexionEjeX+Y-

hasConnectionOnAxisX+Y-

--- Indica qué máquina de procesado tiene conexión con una máquina de transporte en el eje X+Y-.

Relación

TieneConexionEjeX-Y+

hasConnectionOnAxisX-Y+

--- Indica qué máquina de procesado tiene conexión con una máquina de transporte en el eje X-Y+.

Relación

TieneConexionEjeX-Y-

hasConnectionOnAxisX-Y-

--- Indica qué máquina de procesado tiene conexión con una máquina de transporte en el eje X-Y-.

Relación

Compuesto Composed --- Un proceso está compuesto de actividades.

Relación

Desarrolla Develops --- Una máquina de almacenaje desarrolla el proceso de almacenaje

Relación

Ejecuta Execute --- Un servicio ejecuta un proceso

Relación

Es Ejecutado Is Executed --- Un proceso es ejecutado por un servicio.

Relación

Es medido isMeasured --- Un Proceso es medido por un KPI

Relación

Es realizado isPerformed --- Un proceso de manejo Relación


de materia es realizado por una máquina de transporte

Es transformada IsConverted --- Un material es transformado por una o varias herramientas

Relación

Es Usada IsUsed --- Una herramienta es usada por una máquina mutiherramienta

Relación

Está asociada Is associated --- Una máquina de procesado está asociada a una máquina de transporte

Relación

Está compuesta Is composed --- Relación Esta en Is on --- Herramienta está en

una máquina herramienta

Relación

Está situada Is located --- Una materia está situada en una máquina de transporte.

Relación

Forma Parte de Is Part of --- Un material forma parte de una materia.

Relación

Hay camino There are way

--- Hay camino entre dos máquinas de transporte

Relación

Implementa Implements --- Una máquina de procesado implementa el proceso de procesado.

Relación

Mide Measure --- Un KPI mide una actividad

Relación

Está en máquina

Is into machine

--- Un motor está en una máquina

Relación

Precede Before --- Una actividad precede a otra en un proceso.

Relación

Procesa Process --- Una máquina de procesado procesa una materia.

Relación

Puede Procesar Can Process --- Una herramienta puede procesar una materia.

Relación

Realiza Do --- Una máquina de transporte maneja una materia.

Relación

Sensor Esta en máquina

Sensor is into machine

--- Un sensor está situado en una máquina.

Relación

Sucede After --- Una actividad sucede a otra.

Relación


Tiene Has --- Una máquina herramienta tiene una herramienta

Relación

Tiene asociada Has associated

--- Una máquina de transporte tiene asociada una máquina de procesado

Relación

Tiene motor Has engine --- Una máquina tiene una serie de motores

Relación

Tiene sensor Has sensor --- Una máquina tiene una serie de sensores

Relación

Tiene Situada Has situated --- Una máquina de transporte tiene situada una materia

Relación

Transforma Transform --- Una herramienta transforma una materia

Relación

Usa Uses --- Una máquina multi herramienta usa una serie de herramientas.

Relación

Las relaciones binarias entre los elementos del nivel de planta establecen las relaciones básicas entre los conceptos implicados y son las que sirven como base para construir reglas más complejas que permitan

modelar las características del nivel físico de una planta industrial.

Siguiendo con la metodología establecida se muestra el detalle de las

relaciones identificadas anteriormente.

Nombre Relación

Concepto Origen

Card Orig.

Concepto Destino

Relación Inversa

Tiene conectada en eje X+

Cinta Transportadora

0..1 Máquina de Transporte

Está Conectada en eje X+

Tiene Conectada en eje X-

Cinta Transportadora


Está Conectada en eje X+

Tiene situada en eje X+

Mesa de Giro 0..1 Máquina de Transporte

Está situada en eje X+

Tiene situada en eje X-


Está situada en eje X-

Tiene situada en eje Y+


Está situada en eje Y+

Tiene situada en eje Y-


Está situada en eje Y-

Tiene conectada en eje X+Y+

Rail de carga 0..1 Máquina de Transporte

Está conectada en eje X+Y+

Tiene conectada en


Está conectada en eje


eje X+Y- X+Y- Tiene conectada en eje X-Y-


Está conectada en eje X-Y+

Tiene conectada en eje X-Y-


Está conectada en eje X-Y-

Tiene situada encima


0..1 Máquina de Procesado

Está Situada Encima

Tiene ensamblada

Máquina Herramienta

0..1 Herramienta Está Ensamblada

Usa Máquina Multi Herramienta

0..N Herramienta Es Usada

Transforma Herramienta 0..N Material Es Transfor-mado

Está Compuesta

Materia 1..N Material FormaParte De

Está Situada En

Materia Procesable


Tiene Situada

Desarrolla Máquina de almacenaje

0..N Almacenaje Es_desarrollado

Ejecuta Servicio 0..1 Proceso Es ejecutado Implementa Máquina de

procesado 0..N Procesado Es implementado

Mide KPI 0..1 Actividad Es medido Realiza Máquina de

transporte 0..N Manejo de

materia Es realizado

Tiene asociada

Máquina de transporte

0..1 Máquina de procesado

Está asociada

Forma parte de

Material 0..N Materia Está compuesta

Esta en Herramienta 0..1 Máquina Herramienta

Tiene

Está situada Materia 0..1 Máquina de transporte

Tiene Situada

Hay camino entre


0..N Máquina de transporte

Motor esta en máquina

Motor 0..1 Máquina industrial

Tiene motor

Sensor esta en máquina

Sensor 0..1 Máquina industrial

Tiene sensor

Precede Actividad 0..1 Actividad Sucede Procesa Máquina de

procesado 0..1 Materia

procesable

Transforma Herramienta 0..N Material Es transformada

Respecto a la definición de las propiedades de datos se definen como siguen:

Nombre Atributo Dominio Rango

Nombre Máquina Industrial String


Número de serie Máquina Industrial String Posición Materia

Máquina Industrial Char

Consumo Eléctrico Máquina Industrial float WSDL Servicio anyURI URL Servicio anyURI Secuencia Actividad integer

La descripción de las reglas de corresponde con las siguientes:

Nombre de Axioma PuedeProcesas Descripción Una Herramienta puede procesar una pieza si está

compuesta de un material que pueda Procesar. Expresión Forall( ?X ?Y ?Z )

(Material(?X) AND Materia(?Y) AND Herramienta(?Z) AND EstaCompuestaPor(?Y,?X) AND Transforma(?Z,?X) � PuedeProcesar(?Z,?Y)

Conceptos Material Materia Herramienta

Atributos --- Relaciones Binarias EstaCompuestaPor

Transforma Variables ?X

?Y ?Z

Nombre de Axioma Procesa Descripción Una Máquina puede procesar una materia si la

materia se encuentra situada sobre una cinta transportadora asociada a la máquina herramienta y además está compuesta por un material que pueda ser procesado por la herramienta que tiene conectada la máquina herramienta.

Expresión Forall( ?X ?Y ?Z ?I ) (Herramienta(?X) AND MaquinaHerramienta(?Y) AND Materia(?Z) AND MaquinaDeTransporte(?I) AND PuedeProcesar(?Y, ?Z) AND EstaSituadaEn(?Z, ?I) AND TieneSituadaEncima(?I, ?Y) AND Tiene(?Y,?X) � Procesar(?Z,?I)

Conceptos Herramienta MaquinaHerramienta MaquinaTransporte Materia

Atributos --- Relaciones Binarias PuedeProcesar

EstaSituadaEn TieneSituadaEncima Tiene


Variables ?X ?Y ?Z ?I

Nombre de Axioma Procesa Descripción Restricción por la que una máquina no puede

ejecutar dos actividades a la vez. Expresión FORALL(?X,?Y,?Z, ?A1, ?A2,?S)

MaquinaProcesado(?X) and Proceso(?Y) AND Actividad(?A1) AND Actividad(?A2) AND NUMBER(?S) AND EstaCOmpuesto(?P,?A1) AND Secuencia(?A1,?S) AND Secuencia(?A2,?S) AND Implementa(?M,?A1) AND Implementa(?M,?A2) � NOT EstaCompuesto(?P,?A2)

Conceptos MaquinaProcesado Proceso Actividad

Atributos Secuencia Relaciones Binarias EstaCompuesto

Implementa Variables ?X

?Y ?Z ?I

Nombre de Axioma Hay Camino Entre Descripción Establece la regla por la que se define si hay camino

entre dos máquinas. Expresión FORALL(?X,?Y,?Z)

Maquina_de_transporte(?X) AND Maquina_de_transporte(?Y) AND Maquina_de_transporte(?Z) AND Tiene_conexion(?X,?Y) AND Tiene_conexion(?Y,?Z) AND DifferentFrom(?X,?Z)�Hay_camino_entre(?x, ?z)

Conceptos Maquina_de_transporteProcesado

Atributos Relaciones Binarias Tiene_Conexion Variables ?X

?Y ?Z



Maquina_de_transporte(?X) AND Maquina_de_transporte(?Y) AND Maquina_de_transporte(?Z) AND Hay_camino_entre(?X,?Y) AND


Tiene_conexion(?Y,?Z) AND DifferentFrom(?X,?Z)�Hay_camino_entre(?X, ?Z)

Conceptos Maquina_de_transporteProcesado

Atributos Relaciones Binarias Tiene_Conexion

Hay_camino_entre Variables ?X

?Y ?Z



Maquina_de_transporte(?X) AND Maquina_de_transporte(?Y) AND Maquina_de_transporte(?Z) AND Hay_camino_entre(?X,?Y) AND Hay_camino(?Y,?Z) AND DifferentFrom(?X,?Z)�Hay_camino_entre(?X, ?Z)

Conceptos Maquina_de_transporte

Atributos Relaciones Binarias Hay_camino_entre Variables ?X

?Y ?Z

Modelo de gestión del proceso de fabricación basado en la ... · Mora, Felipe y Joan Carles. A...

Documents

Transcript of Modelo de gestión del proceso de fabricación basado en la ... · Mora, Felipe y Joan Carles. A...