proyecto de grado presentado ante la ilustre universidad

.

Proyecto de Grado Presentado ante la Ilustre Universidad de Los Andes como requisito parcial

para obtener el título de Ingeniero de Sistemas

Autor: Br. Manuel I. Castellano C. Tutor: Prof. Dr. Francisco J. Hidrobo T.

Mérida, Noviembre 2008.

©2008 Universidad de Los Andes Mérida, Venezuela

Br. Manuel Castellano

Proyecto de Grado — , 79 páginas

Resumen: En este trabajo se implementó un sistema de simulación para un pozo de producción petrolera basado en el concepto de agentes. La simulación se generó a partir de los conceptos de la plataforma de automatización industrial con agentes; particularmente, mediante el agente de negocio (agente pozo), con el objeto de generar datos del comportamiento de un pozo petrolero como lo es su nivel de caudal (Q), que junto con la apertura de la válvula (β), constituyen variables útiles en el desarrollo de pruebas de funcionalidad para un agente pozo. El modelo generado cumplió con las expectativas dentro de la plataforma, así como con las condiciones de operación del mismo. Palabras clave: simulación; sistemas multiagentes (SMA), Plataforma de Automatización Industrial con agentes, ambiente distribuidos;

El proyecto de grado titulado “Diseño e Implementación de un sistema de simulación para un pozo de producción petrolera basado en agentes”, realizado por Br. Manuel Isaac Castellano Cifuentes, C.I.Nº 14365670 presentado el día xxxxx de Octubre de 2008, en salón de reuniones de la Escuela de Ingeniería de Sistemas de Facultad de Ingeniería de la Universidad de Los Andes. Mérida-Venezuela, ante el Jurado evaluador conformado por:

FIRMA

Tutor: Dr. Francisco J,- Hidrobo

…………………………………………...

Cotutor: Dr. Addison Ríos

…………………………………………...

Jurado: Profesora. Alejandra Matamoros

…………………………………………...

Jurado: Prof. José Aguilar

…………………………………………...

Agradecimiento

• A Dios.

• Al Prof. Dr. Francisco Javier Hidrobo, persona que con su moral, prudencia y

sabiduría hacen que otros seres humanos sean mejores.

• Al Prof. Dr. Addison Ríos por su ayuda y dedicación en la realización de este

proyecto.

• Al Prof. Dr. Julián Suárez por su contribución en conocimientos y optimismo a

este proyecto.

• Al personal del CEMISID por su inmensa calidad humana y profesional,

particularmente: al Prof. Gerald Páez; Germán, a Rafael, la Sra. Luisa.

• A mi entrañable amigo José Valera, porque sin usted no hubiese podido

cumplir esta meta de la vida, mucha suerte en tu camino.

• Con todo mi amor desde lo profundo de mi ser a mi Familia, mis padres ;

Gladys Cifuente, Jesús Castellano, mis hermanos: Ana Maria, Jesús, Leonardo,

Carlos y Glendys, les agradezco mucho la fuerza que me dieron.

A mi primo Jean Carlos Davalillo, por siempre estar presente , mucha suerte

• Al Fondo Nacional de Ciencia, Tecnología e Investigación (FONACIT) a través

del proyecto 2005000170, intitulado “técnicas emergentes para la

automatización integrada de procesos de producción “CDCHT-ULA por medio

del proyecto I-1103-08-02-A.

Índice General Pág.

Capítulo I: Introducción 1

1.1 Planteamiento del problema 3 1.2 Justificación 5 1.3 Antecedentes 6 1.4. Objetivos 7

1.4.1. Objetivo general 7 1.4.1. Objetivos específicos 7

Capítulo II: Marco Teórico 9

2.1 Teoría de los agentes 9 2.1.1 Definición 10 2.1.2 Características 11

2.2 Los sistemas multiagentes 13 2.2.2 Arquitectura para la representación de los agentes 16 2.3 Simulación con agentes 17 2.4 Uso de arquitectura multiagentes en la automatización 18

2.5 Ventajas de los sistemas multiagentes 19 2.6 Los SMA en ambiente distribuidos 20

Capítulo III: Diseño Descriptivo o Conceptual del Sistema 20

3.1 Modelo genérico del proceso de producción petrolera 21 3.2 Descripción del pozo petrolero 23 3.3 Marco general referencial de la plataforma 26

3.3.1 Descripcion de la plataforma funcional 37 3.4. Nivel superior 38 3.4.1 Identificación de los Agentes 38 3.5 Definición de los actores 39 3.5.1. Agente Repositorio de Datos 40 3.5.2 Agente Negocio (Agente Pozo) 40 3.5.3 Agente Aplicación (Agente de Monitoreo y Supervisión) 40 3.5.4. Agente Especializado 41 3.6 Modelado funcional del Agente Pozo 42 3.6.1 Casos de Uso para el Agente Pozo 44 3.6.2 Diagrama de Actividades 46

3.7 Diseño del modelo dentro del Agente Pozo 50

Capítulo IV Pruebas

4.1 Ambiente de validación de las pruebas 55 4.2 Codificación 57 4.3 Implementación y Pruebas funcionales del modelo 60 4.4 Pruebas de Integración del Agente en la Plataforma 60 4.4.1 Fase 1) Prueba para el Agente Pozo 62 4.4.2 Fase 2) Prueba conceptual 69 4.5 Análisis de los Resultados 71 Capítulo V. Conclusiones y Recomendaciones 73

VI. Bibliografía 75

Anexos 77

Índice de tablas. Pág. Tabla 1. Comunicación entre los agentes del nivel superior 41 Tabla 2. Descripción del Agente 46 Tabla 3. Pruebas funcionales del agente pozo 59

Índice de figuras. Pág. Figura 1.1 Marco generalizado de la plataforma de Automatización Industrial. 3 Figura 2.1 Estructura de un agente 10 Figura 2.2 Modelo de agente 11 Figura 2.3 Representación de una Arquitectura Hibrida 15 Figura 2.4: Características de los Agentes 16 Figura 3.1 Esquema mecánico para la producción de la arena 22 Figura 3.2 Representación analógica de una unidad de producción petrolera. 23 Figura 3.3 Agentes en una Arquitectura de Automatización. 24 Figura 3.4 Descripción de la Plataforma de Automatización Industrial 25 Figura 3.5 Arquitectura del Nivel base del MGS 28 Figura 3.6 Diagrama de casos de uso del agente de negocio 42 Figura 3.7 Agente de Negocio en el Nivel Superior 45 Figura 3.8 Diagrama del modelo de un tanque simple 49 Figura 3.9 Control Interfaz 49 Figura 4.1 Plataforma Instalada 54 Figura 4.2 salida del programa 58 Figura 4.3 Nivel de Caudal 62 Figura 4.4 Curvas de demanda de producción 71

Capítulo I

INTRODUCCIÓN.

En los últimos años, la tecnología de agentes de software se viene utilizando ampliamente dentro de ambientes académicos; como consecuencia en diversos campos de la industria ya se viene comenzando a dar pasos serios en adaptar esta tecnología para desarrollar sus propios productos acorde con sus necesidades, en nuestro país la industria petrolera ha venido dando pasos en esa dirección para contribuir al desarrollo nacional. [1]

La idea ha sido aplicar los sistemas multiagentes (SMA), en la automatización integrada de los procesos productivos con el objetivo de implantar funcionalidades inteligentes a los sistemas de producción petrolera. A la actualidad, se han propuestos una red de agentes autónomos con diferentes responsabilidades, distribuidos y organizados jerárquicamente. Cada agente funciona independientemente, pero comparten e intercambian información para cooperar en la realización de las tareas. Todo lo anterior así como el hecho de trabajar los sistemas multiagentes, nos permite contar con una plataforma de Automatización Industrial en agentes para ambientes distribuido [2].

Todo el contexto de la plataforma, con explicaciones detalladas de todo el Modelo Arquitectónico del Sistema multiagentes (SMA), con sus actores (Agentes) y casos de uso, ha sido mostrado en diferentes trabajos realizados por otras organizaciones e instituciones relacionadas con el tema en cuestión, si es de interés del lector ahondar sobre este punto se hace referencia al siguiente trabajo [3].

En esta plataforma, se describen a los Agentes de Negocios como modelos de los elementos de las unidades de producción, donde cada unidad de producción está representada por un Agente de Negocio. La composición de un Agente de Negocio está basada, por un lado, de una división física del proceso y por otro lado, de una división funcional de las tareas del agente. Así, un agente de negocio, posee la ventaja de ser una representación de un modelo de un pozo de producción petrolera.

Dicho esto surgen 2 necesidades:

1.1. Necesidad de tener un modelo de simulación para generar un comportamiento teórico del dispositivo de campo, que será implantado en el Agente de Negocio, ya diseñado y especificado en la plataforma.

1.2. Necesidad de realizar una prueba conceptual sobre la plataforma, siendo de especial interés el nivel superior, donde esta ubicado el Agente de Negocio, dicha prueba consistirá en la comunicación que establece este agente con otros que componen este nivel.

Este trabajo de investigación fue estructurado en 6 partes:

Capítulo I. Comprende la introducción, el planteamiento general del problema, los antecedentes y la justificación de la investigación, así como los objetivos generales y específicos.

Capítulo II, Comprende el marco teórico basado en el desarrollo de los conceptos de Agentes y Automatización.

Capítulo III, Comprende el diseño del sistema, conceptos generales, la descripción detallada del modelo del pozo, y la plataforma con la descripción de sus agentes.

Capítulo IV, Comprende la Prueba de Integración del Agente en la plataforma, la programación y el análisis y discusión de resultados obtenidos.

Capítulo V. Se ofrecen las conclusiones y recomendaciones logradas.

Bibliografía.

1.3. Planteamiento del problema.

Los sistemas multiagentes (SMA), son sistemas de software que ofrecen posibilidades para la gestión de un conjunto de agentes. La plataforma de Automatización Industrial con agentes, se ha desarrollado para funcionar en ambientes distribuidos, esta potencialidad ofrece la posibilidad de regular a los agentes para comunicarse y entenderse entre ellos. De esta manera, cada agente posee 2 funciones básicas, por un lado, una comunicación con los otros agentes de la comunidad y por otra parte realizar un funcionamiento interno, para realizar sus propias tareas.

Para conocer más la plataforma, veremos un gráfico para ilustrar, aquí se especifica básicamente 2 conceptos, el agente desde donde se implementará el pozo de producción petrolera y el nivel donde el agente tiene comunicación y procesa información con los otros agentes.

Figura 1.1 Marco generalizado de la plataforma de Automatización Industrial.

Es importante señalar que la plataforma, ha utilizado la metodología MultiAgent Systems for

INtegrated Automation (MASINA), desarrollada para especificar sistemas multiagentes en ambientes de automatización industrial [4].

Esta metodología usa el Lenguaje de Modelado Unificado (UML), como un lenguaje gráfico que permite visualizar, especificar y documentar cada una de las partes que comprende el diseño del software, es de notar, que MASINA es una extensión del modelo orientado a objetos MAS-CommonKADS, y se basa en el mismo ciclo de desarrollo, conceptualizado aquellos componentes que serán considerados agentes, así como especificar los aspectos de comunicación, coordinación e integración en una arquitectura preliminar del SMA.

Hasta este momento el agente pozo no contiene un modelo, que pueda simular datos teóricos del comportamiento de un pozo petrolero, específicamente sus niveles de caudal (Q), he aquí uno de los aportes de esta investigación; para realizar esto se implementara una función específica que permitirá observar la curva de Q, así como generar un archivo con los datos obtenidos de la simulación.

También nos concierne ampliar un poco mas el conocimiento del funcionamiento de la plataforma, para ello usaremos como factor principal evaluador una prueba de los conceptos involucrados en el nivel superior, compuesto por 4 agentes, básicamente esta prueba conceptual consistirá en evaluar el pase de mensajes, así como las comunicaciones y las funcionalidades de cada agente contenidos en dicho nivel.

Valdría destacar que la plataforma, ha sido soportada en una versión de Linux o en ambiente GNU

programada usando el lenguaje de uso general C++ estándar.

.

1.2 Justificación.

El desarrollo de aplicaciones de software, especialmente diseñada para manejar procesos como por ejemplo, el control de la producción, porque son capaces de funcionar de forma automática desde la pantalla del ordenador. Buscar dentro de otros objetivos, proporcionar toda la información posible que se genera en los procesos productivos, especialmente en interés de esta investigación como lo es el dispositivo pozo petrolero. Otra ventaja, es que permitirá construir nuevas tecnologías propias que se adapten a las necesidades de nuestra Industria y que existan bajo la premisa de Freeware y GNU (General Public License). Otra ventaja, para el caso del sistema de simulación que plantea esta tesis es minimizar los riesgos globales que se incurren al operar un pozo.

La realización de esta tesis nos permitirá realizar mayores test en la plataforma y de esta manera establecer precedentes en otras investigaciones que lleguen a usarla.

Por todo lo expuesto anteriormente, se deduce que el campo de aplicación de este trabajo y de la Plataforma de Automatización Industrial en agentes es bastante amplio.

1.3 Antecedentes.

El desarrollo de software basado en agentes representa uno de los paradigmas computacionales mas recientes. Los primeros estudios característicos de este campo de investigación tuvieron lugar, aproximadamente, hace dos décadas. A mediados de la década pasada, los agentes y los sistemas multiagente alcanzaron una amplia popularidad entre los miembros de la comunidad investigadora, especialmente, entre los pertenecientes al campo de la inteligencia artificial [5].

Los agentes proceden de los campos de la inteligencia artificial (IA) y de la ingeniería del software (en particular, de la orientación a objetos). Desde un punto de vista conceptual los agentes provienen del modelo de actores concurrentes que propusieron en [6]. Los actores, directos predecesores de los agentes, fueron definidos en 1977 como "objetos auto contenidos, interactivos y que se ejecutan concurrentemente, que poseen estado interno y capacidad de comunicarse". Los actores se comunican mediante un intercambio de mensajes y llevan a cabo sus acciones concurrentemente (es decir, sus acciones pueden ejecutarse en paralelo, sin secuencias fijadas de antemano). La principal diferencia entre los actores y los agentes es que estos últimos suelen tener restricciones relacionadas con metas o propósitos.

Ahora bien, debido a lo cambiante del mundo que rodea el desarrollo de software y que cada vez más, se necesitan programas o aplicaciones flexibles, que sean capaces de anticiparse a las necesidades de los usuarios de sistemas informáticos. Los agentes son una solución a esa necesidad. Por eso ha de mantenernos actualizado, y estar atento a cualquier cambio en los paradigmas, esto nos hace estudiar a los agentes.

1.4 OBJETIVOS.

Como objetivos de este trabajo, se planteo desarrollar software en agentes, usando modelos más específicos, por ello se propone lo siguiente

1.4.1 Objetivos Generales.

• Diseñar e Implementar un Sistema de Simulación para un Pozo de Producción Petrolera mediante el empleo de Agentes.

• Elaborar un modelo del proceso producción petrolera implantada en el agente para comprender este proceso.

1.4.2 Objetivos Específicos.

• Realizar la instalación de la Plataforma de Automatización Industrial en agentes, en La Universidad de Los Andes, con la finalidad de usarse en futuros trabajos de investigación.

• Probar la funcionalidad de los agentes del nivel superior de la plataforma.

• Demostrar los conceptos involucrados en la Plataforma, para el caso especial del Agente Pozo.

• Establecer la aplicabilidad de herramientas con la premisa de Freeware y GNU (General Public License), en el manejo de problemas de Control y Automatización Industrial.

CAPÍTULO II

Marco Teórico.

Para el desarrollo de la investigación y el alcance de los objetivos planteados, es necesario abordar las áreas de estudio siguientes: La teoría de Agentes, los Sistemas multiagentes, Los Agentes en Control y Automatización.

2.1 Teoría de Agente.

Desde hace varios años hemos podido observar como ha crecido vertiginosamente la inteligencia artificial, con el surgimiento de nuevas técnicas computacionales que aprovechan a otras disciplinas como la filosofía en donde se involucran teorías del razonamiento y del aprendizaje; de las matemáticas aprovecha las teorías formales relacionadas con lógica, probabilidad, toma de decisiones y computación. De la psicología toma las herramientas que permiten la investigación de la mente humana, así como el lenguaje científico para expresar las teorías que se van obteniendo. La lingüística le ofrece teorías sobre la estructura y significado del lenguaje. Y por último de la ciencia de la computación, toma las herramientas que permiten que la inteligencia artificial sea una realidad, todas estas disciplinas han permitido la construcción de programas autónomos, adaptativos, capaces de aprender de las experiencias y de adaptarse a nuevas situaciones permitiendo realizar actos por si solos y dependiendo de la situación dada pueden emprender cualquier tipo de acción, de manera que en muchos de los casos no sabemos si la acción realizada fue ejecutada por un ser humano o por una maquina.

En líneas generales estos programas los podemos denominar agentes y aunque pueden emprender algunas acciones, poseen limitaciones, por no poder sustituir en su totalidad todas las tareas realizadas por un ser humano. Sabemos que en muchos de los casos se está trabajando para que estos al menos puedan emprender acciones de manera racional [6].

2.1.1 Definición de Agentes.

Según [7], un agente es todo aquello que sea capaz de percibir su ambiente mediante sensores y que responde y actúa en tal ambiente por medio de efectores.

En el caso de los seres humanos, los sensores son los órganos de los sentidos y demás órganos perceptivos, en tanto que; los efectores vendrían a ser manos, piernas, boca, entre otros.

En el caso de los agentes de software, donde nosotros nos centraremos sus percepciones y acciones vienen a ser las cadenas de bits codificados que reciben y envían el programa. En la figura 2.1 se muestra un modelo, bastante simple, de un agente y entre sus características más importantes se encuentran, la forma de capturar lo que esta ocurriendo en el ambiente por medio de los sensores y una manera de causar cambios a través de sus efectores. Existe una dinámica entre los sensores y los efectores y el trabajo actual de muchos investigadores se concentra en esta dinámica, ¿como es?, ¿como se construye?, ¿como se le puede programar si es un programa?.

Entre los detalles más interesantes en estos agentes, es que los sensores son más efectivos que nuestros sentidos humanos, cámaras que pueden ver detalles que nosotros no podemos capturar, micrófonos que pueden escuchar cosas que nosotros no podemos escuchar y además tenemos efectores mucho más efectivos que los nuestros, mucho más poderosos, mucho más fuertes, resistentes a condiciones ambientales mucho más extremas.

Figura 2.1 Estructura de un agente

Es decir; por un lado el construir un agente, pareciera estar bastante adelantado, el asunto es de integración , y es que conectar los mecanismos que utiliza para percibir con los que utiliza para actuar se ha vuelto muy difícil, claro hay que tener una incisión de lo que hay en nuestro caso entre la percepción y la ejecución de acciones, es que hay un estado interno, hay una mente, dicen unos en el camino, hay que meterles un programa, ese software es la mente, leen (percibe) cosas que es la entrada , el programa muestra(actúa) una salida y unos podrían considerar que el asunto fue resuelto.

El ejemplo de la figura 2.2 de [8] es de hecho el primer ejemplo que muestran estos autores en el libro Inteligencia Artificial, este modelo practico es el más elemental, yo tengo los sensores y los efectores, ellos me reportan la información que me aparecen en los cuadros, como es el mundo ahora me dicen los sensores, que debo hacer es lo que yo le comunico a los efectores, los conectan por medio de una tabla un sistema que en inteligencia artificial es llamado un conjunto de reglas de condición- acción. Una lista de condiciones que están puestas en una tabla y una lista de acciones que normalmente es una sola acción que están en columnas contiguas por nosotros y entonces yo reviso cuales son las condiciones que se cumplen en el ambiente, disparo una acción y funciona.

Este es un agente que se le denomina reflectivo o que funciona por reflejos simples y en mucho de los casos no tiene la capacidad de medir las consecuencias que pudieran generar sus acciones.

El asunto es que esa dinámica interna basada en el conjunto de reglas de condición y acción se queda corta muy rápida mente, esto es porque cuando queremos que el agente haga algo que tenga un poco más de sentido humano, nos vemos en problemas para tratarlo de codificarlo con reglas de condición y acción; incluso hay estudios sistemáticos de lo que significa codificar cualquier aplicación más o menos regular en términos de regla de condición y acción , son demasiadas reglas, sin contar con el esfuerzo de escoger cual es la que sirve, entonces este modelo sirve para ver cuales son los componentes esenciales; pero no nos podemos engañar de que el cuerpo del agente y el ambiente son cajitas, estas cajitas pueden ser software, puede ser intangible, o simplemente ser una sensación digital y esta separación psicológica-psiquiátrica con la cual separamos la mente y cuerpo del agente hay que manejarla con mucho cuidado; entonces podemos hablar de que el ambiente puede ser solamente software por ejemplo; y lo que estamos programando es la mente, el controlador del agente; y un detalle bien importante referir el agente a algo que nosotros conozcamos, referir a funciones matemáticas que se supone que todos los ingenieros saben algo de eso y de esta forma , el agente se puede representar de esta manera en la figura 2.2

Figura 2.2: Modelo de un agente según Russel y Norvig (1973)

2.2. Los Sistemas multiagentes (SMA).

Los sistemas multiagentes (SMA): Acrónimo en inglés de Multi Agent System), son un conjunto de agentes autónomos, generalmente heterogéneos y potencialmente independiente que trabajan en común resolviendo un problema.

2.2.1 Características de los agentes.

De las diversas características de los agentes, se pueden mencionar con las que debe contar un SMA [9]:

• Autonomía. La autonomía permite a los agentes que puedan operar sin la intervención directa de nadie, ya sea de humanos o de software. Es quizá la característica más importante identificada en los agentes, ya que de no presentar esta cualidad, se estaría ante un simple ejecutor de acciones. Además la mayoría de los agentes autónomos pueden seguir una agenda independiente a la de su usuario, y esto requiere aspectos de periodicidad, espontaneidad, e iniciativa en las acciones, debiendo ser capaces incluso de tomar decisiones por sí solos que puedan beneficiar al usuario.

• Sociabilidad. Esta cualidad permite a los agentes interactuar con otros agentes y/o con humanos, y según sea con unos o con otros la sociabilidad o cooperación puede ser descrita de dos maneras diferentes. En el caso de la cooperación usuario-agente, esta puede ser vista como una forma de colaboración mediante contrato, es decir, el usuario especifica qué acciones se pueden llevar a cabo en su nombre, y el agente realiza todas o algunas de esas acciones, proporcionando los resultados al usuario. Se puede decir que es algo semejante a una conversación, en la que cada parte puede hacer preguntas a la otra para verificar que las dos están de acuerdo en lo que está pasando. Sin embargo, la cooperación entre

agentes se puede ver como una colaboración de igual a igual, un mecanismo por el cual los agentes intercambian sus conocimientos, opiniones, y planes, pudiendo decir que trabajan juntos para resolver problemas que por sí solos serían incapaces de solucionar.

• Reactividad. Un agente no se debe limitar a realizar acciones para responder a eventos que se produzcan directamente sobre él, sino que también debe estar atento a los posibles cambios que se puedan producir en su entorno. Debe percibir su entorno y responder de forma oportuna a los cambios que allí ocurren. Cuando se produce una transformación en el entorno en donde reside un agente, este puede ser sensible a dicha transformación o no. Si así fuera, el agente debe realizar las acciones necesarias para adaptarse a ese nuevo ambiente en el que se encuentra y actualizar su espacio de opinión, enviando mensajes relativos a dicho cambio a otros agentes del entorno para que también lo hagan.

• Movilidad. Es una de las características imprescindibles en los cada día más extendidos agentes destinados a Internet. La movilidad proporciona a los agentes la cualidad de transportarse, de cambiar de localización de unos entornos a otros ya sea dentro del mismo equipo o a través de una red de computadoras. Este cambio de localización no altera en el agente otra cosa que no sea su ubicación, ya que a su nuevo entorno el agente llega con los mismos conocimientos que poseía en el anterior, pasando a ejecutarse remotamente si su cambio de ubicación así lo exige.

• Inteligencia. Generalmente, la cualidad de inteligencia es asociada directamente con el concepto de agente. Debido a que un agente debe analizar y tomar una acción de forma autónoma, es necesario implementar esta característica utilizando alguna tecnología o técnica computacional, para lo cual generalmente se utilizan técnicas inteligentes. Los sistemas expertos es la técnica predilecta para imprimir inteligencia a los agentes, ya que permiten a través de un conjunto de reglas finitas, las cuales pueden estar asociadas a variables del ambiente, llegar a una conclusión que genere o inhibe una determinada acción. Esto encaja con la noción de inteligencia que se les atribuye a los agentes; pero no es la única técnica que puede ser utilizada cuando se diseñan sistemas multiagentes. El paradigma basado en agentes nace como una extensión de la inteligencia artificial, y no como un caso particular de los sistemas expertos. Se pueden utilizar un conjunto variado de técnicas inteligentes en la construcción de agentes, entre las cuales se pueden nombrar a las reglas difusas para analizar situaciones dinámicas, las redes neuronales para predecir comportamientos y variables del ambiente, las colonias de hormigas como una técnica de coordinación entre agentes, los algoritmos genéticos como método de búsqueda, entre otros.

2.2.2. Arquitectura para la representación de los agentes

La arquitectura de un agente consiste en una metodología particular para construir agentes. Esta especifica como puede descomponerse un agente en un conjunto de módulos y como deben interactuar estos módulos. El conjunto total debe responder a cómo la data de los sensores y el estado interno del agente determinan sus acciones y el futuro estado interno del agente. Una arquitectura abarca técnicas y algoritmos que soportan esta metodología.

Una clasificación de la arquitectura de agentes, según lo que se considera como motor de acción del agente. Se ubica dentro de tres categorías principales: arquitecturas deliberativas, arquitecturas reactivas y arquitecturas híbridas.

Arquitectura para agentes deliberantes; se define una arquitectura de agente deliberativo, como una que contiene un mundo representado explícitamente y un modelo lógico del mismo, y en la cual las decisiones (por ejemplo acerca de las acciones a realizar) son hechas por medio de un razonamiento lógico (o por lo menos pseudo-lógico), basado en concordancia de patrones y manipulación simbólica.

Arquitectura para agentes reactivos; reactivo es aquella que no incluye ningún tipo de modelo simbólico central del mundo, y no utiliza razonamiento simbólico complejo.

Arquitectura para agentes Híbridos; es un enfoque que esta compuesto por dos subsistemas: uno deliberativo, que contiene un módulo simbólico del mundo, que desarrolla planes y efectúa decisiones de la manera propuesta por la inteligencia artificial simbólica; y uno reactivo, que es capaz de reaccionar a eventos que ocurren en el ambiente sin necesitar un razonamiento complejo.

La arquitectura de los agentes se representaran bajo el esquema de capas de interacción vertical, o sea las capas (en los extremos) tendrán acceso a sensores y actuadores, como se muestra en los siguientes diagramas [10]:

Figura 2.3 Representación de una Arquitectura Híbrida

Una vez analizados los conceptos básicos y las arquitecturas que permiten representar los agentes, se realizó el siguiente diagrama con la intención de reunir todas esas características. Ver Figura 2.4

Figura 2.4: Características de los Agentes

2.3 Simulación con Agentes

A través de la simulación de sistemas se ha logrado representar diversos procesos reales, en los que intervienen elementos relacionados entre sí, que definen la estructura y el funcionamiento en tales procesos. Definiéndose como el proceso mediante el cual se diseña, se implementa y se experimenta con un modelo que representa un sistema real, generando el comportamiento del sistema, con el fin de comprender mejor el sistema bajo estudio[11].

Existen tres aspectos principales que han contribuido a su crecimiento durante la última década:

• Incremento en la velocidad del computador y la reducción de los costos en los sistemas de hardware.

• Adición de salidas graficas y de animación: este desarrollo tecnológico permitió llevar la simulación a las salas de sesiones, en donde los resultados se presentan por medio de instrumentos de animación en forma natural en la pantalla del computador, en vez de presentarlos como informes en papel. De esta forma la audiencia puede absorber información de una manera más rápida, ya que la representación del problema que se esta investigando es más familiar.

• Desarrollo de herramientas de simulación fáciles de usar, las cuales proporcionan resultados estadísticos completos.

La simulación mediante agentes es un acercamiento para simular el comportamiento de un sistema complejo, en el cual los agentes obren recíprocamente uno con el otro y con su ambiente, usando reglas locales simples. La simulación mediante agentes se utiliza ya en varias categorías de las áreas de aplicación por ejemplo: Ingeniería Eléctrica, Sistemas de Irrigación, Sistemas de Fabricación, Redes, Robótica, Software, así como en transportes logísticos. Gerencia/Económica: Economía, Comercio, y Gerencia; Sistemas sociales y comportamiento humano: Sistemas Sociales, comportamiento de psicología/humana, fisiología, negociación y teoría de organización.

2.4. Uso de Arquitectura multiagentes en la automatización.

El problema de manejo de fallas en sistemas industriales puede resultar un problema altamente distribuido, en el caso de sistemas complejos, por lo cual el uso de SMA para implementar sistemas de manejo de fallas resulta ideal, puesto que este enfoque permite abordar problemas distribuidos de manera eficiente gracias a las características ya mencionada de los agentes tales como cooperación, inteligencia y autonomía.

La implantación de sistemas de automatización permite realizar una supervisión de los diferentes procesos y variables de operación de manera dinámica y permite, además, conocer el estado del proceso supervisado a fin de garantizar un buen desempeño. En el caso de la presencia de fallas, el desempeño del proceso se puede degradar de manera importante. Estas consideraciones conllevan a proponer y desarrollar sistemas integrados para el manejo de fallas, que deben cohabitar en los niveles de control y supervisión, para apoyar la planificación de las tareas de mantenimiento en el proceso de producción. La autonomía de los agentes y el comportamiento basado en servicios, hace de los sistemas multiagentes una alternativa de modelado adecuada para desarrollar sistemas en ambientes distribuidos, abiertos y heterogéneos, con herramientas precisas para su implantación.

La incorporación adicional de comportamientos inteligentes permite que afloren consideraciones desconocidas propias del problema abordado, lo que se traduce en nuevas tareas del sistema multiagente que apunten al mejoramiento del servicio ofrecido para lograr el objetivo del sistema. El modelo de referencia aquí presentado permite la gestión de los planes de mantenimiento preventivo, usando la información proveniente de las tareas asociadas a la de detección, localización y diagnóstico de fallas en las diferentes instancias del proceso de producción, de acuerdo con las demandas actuales [12].

2.5 Ventajas que ofrecen los sistemas multiagentes

Entre las ventajas más importantes que ofrecen los sistemas multiagentes al ser comparados con técnicas tradicionales para resolver problemas se encuentran:

• Permiten solucionar problemas con mayor rapidez, gracias a las facilidades para procesamiento en paralelo.

• Comunicación mínima, es decir, se transmiten únicamente soluciones parciales de alto nivel entre los agentes, evitando así enviar datos e información a un sistema central.

• Ofrecen mayor flexibilidad, pues los agentes poseen diferentes habilidades, entre los cuales se tiene la operación entre agentes para la solución de problemas.

• Mayor confiabilidad en el caso de que algunos agentes puedan hacerse responsables por las operaciones de otros agentes si estos llegasen a fallar.

2.6 Los SMA en ambientes distribuidos

Un ambiente distribuido lo consideramos como un conjunto de recursos distribuidos en una red y accesibles a un usuario o programador aunado a un conjunto de herramientas para la programación de aplicaciones distribuidas compuestas por dichos recursos distribuidos en una red. Los recursos pueden ser periféricos, archivos y programas y entre las herramientas deberá haber mecanismos que permitan programar aplicaciones distribuidas. En cuanto a la red, ésta podría ser desde un arreglo de procesadores hasta la red mundial Internet. Los problemas complejos son físicamente distribuidos (una red de transporte, un sistema de control industrial, una línea de ensamblaje, un sistema de producción petrolera, etc.). Igualmente, el diseño de productos industriales (autos de Fórmula 1, lanzamiento de un cohete, etc.) implican el desarrollo de procesos en paralelo. Por lo anterior, se requiere de un enfoque que tenga en cuenta los aspectos de modelamiento de los diversos actores participantes, la representación del conocimiento que se maneja y los protocolos de comunicación que intervienen entre procesos. Los SMA son una aproximación óptima para la solución de problemas complejos con características distribuidas [13].

Capítulo III

Diseño descriptivo o Conceptual del Sistema

En la primera parte de este capítulo se muestra un resumen que contiene los aspectos más relevantes que definen el modelo descriptivo, considerando a todos los conceptos involucrados para el desarrollo de esta investigación.

Luego de presentar el modelo genérico del proceso de producción petrolera, se define la Plataforma de Automatización Industrial en agentes, realizando una descripción de la comunidad de agentes que intervienen en ella, así como la estructura general del agente que se uso en esta investigación, con la finalidad de desarrollar el estudio.

3.1 Modelo genérico del proceso de producción petrolera

Smart wells o pozos con completaciones inteligentes son aquellos pozos en producción que poseen tecnología de instrumentación y control en fondo de pozo. Uno de los principales aspectos de este tipo de completaciones es el empleo de válvulas ajustables en fondo de pozo, lo que permite el aislamiento o control de reservorios de manera independiente (o zonas individuales dentro de un mismo reservorio). Las válvulas permiten entonces controlar el caudal de las diferentes zonas a lo largo del pozo, ajustando las caídas de presión en cada zona, véase [14] y sus referencias, en particular, [15].

Esto genera que estos esquemas de completación inteligente sean de interés. Las completaciones inteligentes de pozos representan una alternativa viable a la producción en commingled (en conjunto) de dos o más reservorios. El problema de este tipo de tecnología es su alto costo, lo cual hace absolutamente necesario ser capaces de modelar y predecir el comportamiento de estos complejos sistemas.

3.2.1 Descripción del Pozo Petrolero.

El esquema mecánico mostrado en la figura 3.1 representa la arena. En este se puede apreciar la interconexión de las tuberías de producción, la arena y las válvulas de control.

Modelo de producción preliminar

Figura 3.1 Esquema mecánico para la producción de la arena

Este esquema mecánico, mostrado en la Figura 3.1., tiene algunas simplificaciones:

• Se considerara que la arena produce solo flujo monofásico incompresible. • El modelo de caída de presión usado en las tuberías de producción es la ecuación de

conservación de la energía mecánica en una sola fase, por ejemplo [16]. • El flujo en medio poroso de las arenas productoras no es considerado. • El flujo que entrega la arena productora a la tubería de producción será simulado como el

flujo que sale de un tanque presurizado por un volumen de gas.

• La energía necesaria para producir el fluido desde los tanques hasta la superficie será suministrada por la expansión de la capa de gas del tanque.

Figura 3.2 Representación analógica de una unidad de producción petrolera.

Nomenclatura.

En letras latinas:

Pwh Presión en el cabezal [Pa] H1 Altura del tanque [m] L1 Longitud vertical de la tubería [m] Pwf1 Presión en el fondo [Pa] Q1 Caudal [m3/s] h1 Nivel de fluido en el tanque [m]

Será de importancia los datos del comportamiento de los niveles de producción (Q), así como gráficos que ilustran estos comportamientos del pozo ya nombrado.

3.3. Marco general referencial de la plataforma. 3.3.1 Descripcion de la plataforma funcional

Los Sistemas de Producción Petrolera (SPP), son sistemas de producción continua que involucran una serie de actividades complejas como es la exploración, extracción, transportación, refinación y almacenamiento, así como la producción.

De acuerdo con todo esto, y basándonos en lo que hemos planteado, debemos pensar que para el desarrollo y compresión de dicho sistema lo más adecuado es la utilización de una filosofía basada en Agentes, o una comunidad de agentes SMA [17].

Figura 3.3 Agentes en una Arquitectura de Automatización.

SMA

Desde el punto de vista topológico, relativo al funcionamiento de esta arquitectura de automatización, los agentes descritos anteriormente se implantan en diferentes niveles y de manera distribuida, usando para ellos un núcleo computacional básico ; el cual comprende el MGS (medio de gestión de servicios) que esta compuesto por 2 niveles: El nivel Base y nivel Interfaz . Y un nivel Superior compuesto por 4 tipos de agentes, entre ellos el agente Negocio (Agente Pozo), donde esta capa sirve para probar la funcionalidad del SMA. Se presentan descriptivamente de los diferentes subsistemas que conforman a la plataforma en la figura:

3.4 Descripción de la Plataforma de Automatización Industrial

M.G.S

Nivel Superior

Sus características son:

• El sistema operativo base permita el manejo en tiempo real. Para efectos prácticos en el laboratorio donde se hizo la instalación de la plataforma, diversos expertos en el manejo de Linux recomendaron la versión Slackware 12.0, por ser catalogada como la mejor en aplicaciones real time.

• El nivel base, el cual contiene dos subsistemas: el que se manejan todas las comunicaciones entre los diferentes sitios (Communication Manager), y el que permite administrar los agentes en la plataforma computacional (Agent Manager), el cual, entre otras funcionalidades, permite localizar agentes y asociar agentes a procesos.

• El nivel interfaz, el cual esta compuesto por los agentes definidos por la especificación FIPA 1 para brindarles servicios a las comunidades de agentes (SMA). Está conformado por cinco agentes: Agente Administrador de Agentes (AAA), Agente Gestor de Recursos (AGR), Agente Gestor de Aplicaciones (AGA), Agente Gestor de Datos (AGD) y Agente de Control de Comunicación (ACC).

• El nivel superior, existen una comunidades de agentes. En la comunidad se encuentran los Agentes de Negocio, los cuales describen los diferentes objetos de negocio (abstracciones lógicas y funcionales de los procesos reales). También los Agentes de Aplicaciones y Especializados, estos realizan funciones específicas a nivel de supervisión, control, optimización, visualización, y otras aplicaciones especializadas y/o legadas. Estos brindan servicios a la comunidad de agentes de negocios. Ambas interactúan con el MGS a través de la capa de interfaz.

1 FIPA (Foundation Intelligent Phisical Agent), es el estándar más ampliamente reconocido y extendido en tecnologías de agentes, El estándar

FIPA divide la comunicación entre agentes en actos de comunicación, protocolos de interacción y lenguajes de contenido. Los actos de

comunicación se componen de bloques constituyentes de dialogo entre agentes donde se define el significado de los mensajes

independientemente del contexto. Los protocolos de interacción definen una secuencia de mensajes que representan un diálogo completo

entre dos agentes. Finalmente los lenguajes de contenido establecen el lenguaje para el contenido del mensaje., ver http://www.fipa.org

A partir del marco referencial y su núcleo básico, procederemos a describir las funcionalidades del MGS, así como una descripción genérica de los 2 niveles contenidos en el mismo, así también los agentes definidos en el nivel Superior, siguiendo las especificaciones FIPA y la metodología MASINA2. El Medio de Gestión de Servicios (MGS) es el conjunto básico de módulos de software que implantan las abstracciones mínimas para la especificación, implantación y manipulación de agentes [18]. Servicios Prestados por los Agentes del MGS

• Manejo de Servicios. El MGS debe proveer un mecanismo que permita a los Agentes del nivel superior:

o Conocer los servicios disponibles: Agrupados por niveles, por tipos de servicio, o en

alguna otra clasificación, se encargan de esto (AAA, AGR, AGA, AGD). o Cuáles agentes prestan un determinado servicio y dónde están (AAA, AGR) o Mecanismos para acceder a esos servicios. ¿Cómo se invocan?, ¿Qué

requerimientos se deben cumplir para accederlos?, etc.

• Movilidad de Agentes. El MGS debe proveer los mecanismos de movilidad y controlar el proceso de migración (AAA).

• Manejo de comunicaciones entre agentes.

Servicios requeridos por el MGS • Acceso a las tablas de proceso para mantener control de los agentes en ejecución. • “Copiar” el estado de un agente para manejo de migración. • Mecanismo para controlar las comunicaciones. • Esquema de manejo de seguridad (por usuario, por servicio, por recurso, etc.). Esquema de virtualización de recursos

Manejo general del MGS. Esto involucra: activación y desactivación de agentes (AAA)

2 MASINA es una extensión a la metodología MAS-CommonKADS, para la especificación de sistemas multiagentes. MASINA permite describir las características de los agentes, utilizar técnicas inteligentes para la realización de tareas (p.e., redes neuronales artificiales), y especificar esquemas de coordinación emergentes, entre otras cosas.

Figura 3.5 Arquitectura del Nivel base del MGS

EL MGS en su nivel inferior está estructurado en dos módulos que deben ser instanciados, obligatoriamente, por los agentes del Nivel Interfaz para la realización de sus actividades: el manejador de agentes y el manejador de comunicación.

• Agent Manager (Manejador de Agentes): Se encarga de corresponder agentes hacia procesos Linux. Contempla funciones como creación, destrucción y manejo de recursos del sistema operativo para la manipulación de agentes. La creación de identificadores únicos sería también su responsabilidad. El Agent Manager también debe implantar la invocación de agentes bajo los esquemas dinámicos; de igual manera, la localización de agentes.

Este módulo está estructurado en los tres submódulos siguientes:

o Despachador: Se encarga de despachar invocaciones a los agentes. Del lado superior, recibe invocaciones desde los procesos y las hace llegar al despachador remoto a través del manejador de comunicación. Del lado inferior, recibe invocaciones remotas y se las hace llegar al proceso que contiene el agente. El despachador puede implantar despacho dinámico; es decir, un agente puede construir, en tiempo de ejecución, infraestructura para recibir invocaciones.

o Mapper: se encarga de otorgar identificadores únicos y de gestionar los recursos del sitio para los agentes y procesos. Este módulo es pues responsable de la creación y destrucción de agentes. Similarmente, este módulo gestiona la migración de agentes.

o Localizador: Se encarga de localizar agentes respecto a sus identificadores únicos.

• Communication Manager (Manejador de Comunicación): Este módulo se encarga de proveer comunicación confiable de red orientada a invocación. La semántica queda a decidir entre “a lo más una vez'' o “exactamente una vez'', según las suposiciones de fallas que se consideren para los agentes. Probablemente, los componentes del MGS estarán implantados mediante procesos privilegiados Linux.

Por ultimo el MGS, lo compone el nivel Interfaz, aquí se han nombrado a 5 agentes que componen este nivel, en esta sección se conceptualiza dichos agentes:

• Agente Administrador de Agentes (AAA): Se encarga de crear, eliminar, localizar, mover y cambiar los estados de los agentes con dos funciones principales: 1) localización de agentes: Este agente conoce la localización y estado de todos los agentes que existan en el sistema. Cada agente que se mueva de un nodo a otro debe notificar al AAA el movimiento que ha efectuado; de manera que siempre se tenga una vista ajustada al estado del sistema en tiempo real.

2) migración de agentes: Para lograr migración de agentes es necesario contar con una plataforma comunicacional con ciertas características, que permita utilizar el protocolo ( XML3). En el caso de los sistemas multiagentes se proveen canales que permiten que los agentes viajen a través de los diferentes nodos de la red.

• Agente Gestor de Recursos (AGR): Los agentes del sistema requieren de recursos para realizar sus tareas, por ello debe existir quien gestione el uso de dichos recursos a fin de optimizar las tareas de los agentes. Este agente puede ser accedido por cualquier agente de la comunidad de agentes y del MGS.

• Agente Gestor de Aplicaciones (AGA):

Este agente se encarga de ubicar las aplicaciones que puedan ser requeridas por algún agente entre éstas: programas de cálculo numérico o simbólico, aplicaciones de inteligencia artificial, envío y recepción de mensajes. Dichas aplicaciones pueden estar en cualquier servidor al que se tenga acceso y su registro se maneja a través de un esquema distribuido.

3 XML (Extensible Markup Language), es un metalenguaje que permite establecer protocolos para compartir información de una manera segura, fácil y fiable.

• Agente Gestor de Datos (AGD): Se encarga de administrar y supervisar el intercambio de datos, provenientes de bases de datos o cualquier otro dispositivo o aplicación que pueda almacenar datos. Este agente también realiza la gestión de los medios de almacenamiento de los datos. Además, el agente permite el traslado de los datos entre los diferentes dispositivos y/o aplicaciones de una manera transparente, para lo cual realiza las transformaciones requeridas.

• Agente de Control de Comunicación (ACC): El ACC es el encargado de mantener y controlar la comunicación. Se encarga de traducir, manipular ontologías4, y mantener un estado confiable del canal de comunicación. Para el ACC se modelan dos diagramas de casos de uso; el primer caso es para solicitar a otro agente, recurso o aplicación; el segundo de los casos muestra las búsquedas local al ser solicitado.

4 Ontología, indica para nosotros el nivel en que se encuentran algún agente “ns”, indica que dicho agente esta invocado desde el nivel superior.

3.4. Nivel superior

El interés de esta sección es señalar a los agentes que componen el nivel superior, así como dar un marco conceptual para realizar la implantación práctica, para de esta forma poder probar la operatividad de estos agentes dentro de la plataforma. La especificación de los agentes en este nivel sigue la misma metodología empleada para el Medio de Gestión de Servicios (M.G.S), al utilizar MASINA. El procedimiento de especificación incluye Conceptualización (en esta fase se usa los diagramas de casos de uso), Modelos de Agente, Modelo de Tareas, Modelos de coordinación y Modelos de comunicación, todo este procedimiento ya ha sido realizado, y esta tesis no tocara todos estos tópicos, si hay algún interés por parte del lector hacemos referencia a [19]. 3.4.1 Identificación de los Agentes

Señalamos los nombres de los agentes que componen el nivel superior:

Nombre genérico: Agente de Negocio Nombre específico: Agente Pozo

Nombre genérico: Agente de Aplicaciones Nombre especifico: Agente de Monitoreo y Supervisión

Nombre genérico : Agente repositorio Nombre específico: Agente Repositorio de Datos

Nombre genérico: Agente Especializado

3.5 Definición de los actores

Conceptualización de los agentes que definen el nivel superior de la plataforma:

3.5.1 Agente Repositorio de datos: Es un agente que caracteriza e identifica los sitios donde pueden almacenarse datos de interés generados en la simulación de un proceso.

Nos permite consultar (insertar, almacenar) datos en un repositorio de datos asociado a los procesos generados por el Agente Negocio (Agente Pozo).

3.5.2 Agente de Negocio (Agente Pozo):

El agente de Negocio, modela a las unidades de producción; abstrayendo una de las instalaciones típicas más importantes en una Unidad de Explotación de Yacimientos: Pozo Petrolero. Debido a esto, es necesario que éste agente cuente con la capacidad de desarrollar tareas de generación de datos, así como también tener la capacidad de arrojar gráficos del proceso y de requerir servicios a otros agentes de su nivel. Sus salidas es información acerca del proceso (niveles de Caudal “Q”).

Una ventaja que se extrae de esta representación es que, a partir de un modelo, el agente puede ser usado para simular el comportamiento del proceso en estudio.

A partir de aquí adoptaremos en el nivel superior, al Agente Negocio en su prototipo de Agente Pozo, y lo tomaremos como el modelo para la construcción del sistema de simulación.

3.5.3 Agente Aplicación (Agente de Monitoreo y Supervisión)

Los Agentes de Aplicación, fueron concebidos para coordinar, ejecutar y evaluar las tareas de monitoreo, control y supervisión necesarias en el procesamiento de la información.

El agente de monitoreo y supervisión, se encarga de supervisar el desempeño del proceso de producción a partir de los datos, también puede solicitar de ser posible, parámetros de control con el fin de compensar desempeños no deseados en el proceso.

3.5.4. Agente Especializado:

Este agente se encarga de ejecutar tareas específicas de procesamiento de información a partir de datos proporcionados.

Aplica métodos que permiten ejecutar tareas específicas de procesamiento de datos/información de acuerdo a necesidades específicas hecha por una solicitud. Este procesamiento de datos/información es de tipo numérico, lógico.

Tabla 1. Comunicación entre los agentes del nivel superior

Evento Respuesta Esperada

Respuesta Obtenida Observación

Generar datos

Del Agente Negocio

Simulación del comportamiento del pozo.

El agente simula la curva del nivel de caudal y este se los envía al Agente Repositorio, donde serán almacenados en un archivo, pasa esta información al Agente Aplicación y obtiene una respuesta.

Solicitud de Datos

Del Agente Repositorio

Almacena los valores según lo hecho por el Agente Negocio

El Agente Negocio envía un conjunto de datos al Agente Repositorio y este almacena la información correspondiente que le haya enviado al Agente Negocio.

Realizar Aplicación

Del Agente Aplicación

Monitorea y grafica la operación realizada por el Agente Negocio

El Agente Negocio solicita una aplicación al Agente Aplicación y le proporciona los datos adecuados, el Agente Aplicación realiza la operación adecuada y devuelve el resultado.

Realizar Actividad Especifica

Del Agente Especializado

Operación realizada según solicitud de algún agente

El Agente Especializado devolvió la respuesta adecuada ante la solicitud de cierta operación deseada por un agente.

En base a la conceptualización del Agente de Negocio, se puede notar que este genera y transmite información (conocimiento).La generación de la información (conocimiento), puede demandar implementar otras tareas propias a el agente. Por ejemplo, a partir de la implementación de un modelo del proceso de producción petrolera, el agente de negocio puede ser usado para establecer un comportamiento emulado. Así, el estaría en capacidad de arrojarnos observaciones en el manejo de condiciones operacionales en los diferentes parámetros involucrados en el pozo, como por ejemplo, seria la apertura de la válvula (β). Hasta el momento, ya se han realizado pruebas para el Medio de Gestión de Servicios (MGS), en estas se requiere establecer una dinámica básica con el nivel superior, esto es de suma importancia porque serán la base de la aplicación de software que se diseñara, todo ello nos permitirá realizar pruebas conceptuales en el nivel superior, dichas pruebas consistirán en 2: pruebas funcionales y de integración, en especial las del caso del Agente de Negocio(Agente Pozo), mas adelante ahondaremos en este tópico . La sección que prosigue va orientada a explicar más detalladamente todo lo relacionado con el Agente de Negocio (Agente Pozo), esto tiene por intención dar mayor soporte teórico a las pruebas que se realizaron sobre este agente, aquí ahondaremos en la dinámica del agente, sus funcionalidades y las tareas propias de el mismo.

3.6 Modelado funcional del Agente de Negocio (Agente Pozo) 3.6.1 Casos de Uso para el Agente Pozo

En la fase de conceptualización se busco obtener una idea general del funcionamiento del agente. Se identificaron los agentes que intervienen en el nivel. Ahora nombraremos a los casos de uso que corresponden a la descripción de acciones necesarias que el agente debe ejecutar para producir un resultado útil para él o los otros agentes. Los casos de uso pueden combinarse, indicando que un caso de uso extiende otro caso o usa un caso previo. Esta fase puede verse como una especificación.

El análisis mediante casos de uso consiste en:

• Identificar los agentes. Este paso ya fue realizado en el apartado anterior y esto nos sirvió para poder visualizar la comunicación que va a tener el agente dentro de su nivel.

• Identificar los casos de uso. Para esto, podemos hacernos las siguientes preguntas: - ¿Cuáles son las principales tareas o funciones realizadas por el agente? - ¿Qué información del sistema adquiere, produce o cambia el agente? - ¿Qué información desea generar el agente?

• Describir los casos de uso. Los casos de uso se suelen describir informalmente empleando lenguaje natural o por notación gráfica.

• Buscar relaciones entre casos de uso: factorizar partes comunes e indicar si un caso de uso agrega las interacciones de otro (relación “usa”) o añade información de otro caso (relación “extiende”). Esto significa que usa el mecanismo de herencia.

En consecuencia, la descripción de los casos de uso del Agente de Negocio se puede visualizar, a grosso modo, de acuerdo a esta Figura.

Figura 3.6. Diagrama de Casos de uso del Agente de Negocio. Por otro lado , es importante ejecutar y solicitar tareas dependiendo de los roles y funciones del agente. El solicitar solicitudes se vinculan a las comunicaciones asincronicas (dependientes de eventos). El generar y trasmitir información (conocimiento) es una actividad que puede ser asíncrona5 o sincrónica6, dependiendo de las exigencias del proceso y del rol del agente. Esta actividad esta vinculada a por ejemplo, establecer comportamientos. 5 Cuando el receptor de una comunicación no da una respuesta en directo, por ejemplo el caso de una carta enviada a una persona. 6 Cuando la comunicación entre dos entidades lleva un diálogo conjuntamente a una hora determinada.

3.6.2 Diagrama de Actividades Sin importar de cual agente se trate (Negocio, monitoreo y Supervisión, Repositorio, Especializado). Se define entonces que un agente del nivel superior necesita soportar las siguientes necesidades:

• Comunicarse con otro agente.

• Requerir/generar un dato o informacion .

• Solicitar un servicio o solicitud prestado por otro agente.

Estas necesidades generan, entre otros, los siguientes eventos:

1. Enviar un mensaje a otro agente: este mensaje puede ser una orden para otro

agente, ó la entrega de un dato ó de información solicitada. En este caso se considera

que el agente conoce el identificador del agente con quien se quiere comunicar.

2. Solicitar un dato: en este caso se considera que el agente no conoce el

identificador del agente (repositorio u otro agente).

3. Ubicar un agente de aplicaciones: en este caso claramente el agente no conoce

el identificador del agente sino el servicio requerido.

4. Localizar un agente: Sólo se conoce el nombre genérico del agente y se requiere su

UID.

Todo esto nos dice el funcionamiento fundamental de el agente negocio y se describe a traves del siguiente macroalgoritmo: Registro: Registrarse con el AAA. Identificacion: Localizar el repositorio (usar AGD). Operación: Mientras esta activo

• Almacenar datos al repositorio de datos en tiempo real.

• Realizar una solicitud al Agente Aplicación .

Figura 3.7 Agente de Negocio en el Nivel Superior

Operaciones con el M.G.S

Operaciones en el nivel superior

Dinámica del Agente de Negocio ( NIVEL SUPERIOR)

AgenteRepositorio de Datos

Agente Pozo

Agente de Monitoreo y

Supervisión

Simulación del comportamiento del pozo

Almacenar _Datos()Monitorear_simulación

(graficas)

De la grafica anterior nos queda claro que la dinámica del agente de negocio, será prestar un servicio, en la cual se almacena los datos en el repositorio, luego se solicita un servicio al agente de aplicación con los datos simulados y espera la respuesta. Una vez obtenida la respuesta, la envía al agente que solicitó el servicio y queda a la espera de una nueva solicitud. De lo dicho anteriormente, se contextualiza al Agente de Negocio, usando en lenguaje ya conocido MASINA, para tener la idea general del ambiente en donde opera dicho agente.

Tabla 2. Descripción del Agente

ESPECIFICACIÓN CON MASINA DEL AGENTE DE NEGOCIO

Valores de nivel de caudal “Q”Datos

Generación de datos, mostrar gráficos.Tareas especificas

Generar datos/informaciónServicio

Lograr la simulación del comportamiento de un pozo.

ObjetivoNivel SuperiorPosición

Agente PozoNombre

3.7 Diseño del modelo dentro del Agente Pozo En la sección 3.1, hicimos referencia a los llamados pozos de completación inteligente o smart wells, la principal características de ellos es el empleo de válvulas ajustables en fondo de pozo, lo que permite el control de reservorios o tanques. Las válvulas permiten entonces controlar el caudal de las diferentes zonas a lo largo del pozo. Bueno conocido este punto, se hace una acotación de suma importancia para realizar las pruebas en esta investigación, la acotación es la siguiente, si bien el modelo presentado en 3.1, posee sus ecuaciones propias, presentaba el inconveniente de no ser implementado y codificado en C++ ,para poder ser trabajado sobre la plataforma, para solucionar este inconveniente se decidió por accesoria del tutor , conseguir un modelo mas idealizado y de mas fácil manejo, que nos permitiría cumplir con nuestros objetivos , poder observar una curva de caudal (Q), dependiendo de la apertura de una válvula (β); el modelo que se consiguió fue el siguiente , hacemos referencia a este [20]. Descripción del modelo de un tanque de agua con descarga (Gravity Drained Water Tank) Se caracteriza por tener un nivel que es controlado por una válvula en la entrada. La posición de entrada de la válvula es controlada desde 0% hasta 100%. La presión esta relacionada con el caudal de agua en el tanque. Una simple ecuación diferencial, derivada de un balance de energía, describe como esta el nivel del tanque de agua cuando se ajusta la válvula en la entrada.

QopendtdQ 25.0%14.0 −−= ………………………………………(1)

La siguiente figura ilustra:

Figura 3.8 Diagrama del modelo de un tanque simple Figura 3.9 Control Interfaz

Este modelo será implementado en el agente pozo como una función auxiliar dentro del mismo, y esto será la base para la prueba de funcionalidad dentro del agente. En el capitulo siguiente veremos como se codifico, y con que herramientas dentro de ambientes GNU, todo esto para cumplir el objetivo de poder observar comportamiento para el posterior análisis del pozo.

Capítulo IV

Pruebas

El presente capítulo está dedicado a comprobar la funcionalidad del modelo así como la integración del mismo en la plataforma. Para ello, se procedió en primer lugar a la instalación de las librerías usadas, se ha de recordar que la plataforma funciona bajo ambiente distribuido y por esa razón se hizo la especificación de las máquinas usadas en el laboratorio por cada agente del nivel superior, en esta primera etapa se especifica con detalle como realizar la descarga, compilación e instalación de cada uno de los programas necesarios para el funcionamiento en este ambiente de la plataforma, también se da los posibles errores de compilación que se puedan generar al realizar la instalación y la forma en que se puedan solucionar dichos errores. Esta primera etapa, se encuentra bien especificada de manera que pueda servir de ayuda para próximos trabajos.

En segundo lugar, se procedió con la codificación del agente en el lenguaje de programación de uso general C++, así como cuales fueron nuestros criterios para realizar dichos códigos para poder alcanzar nuestros objetivos, por ello mostramos los resultados obtenidos al realizar estas corridas y en función de eso realizar algunas conclusiones con respecto al cumplimiento de las pruebas conceptual del nivel superior, estas serán elaboradas en el último capítulo de esta investigación.

Por último mostraremos algunos resultados obtenidos de las simulaciones, como por ejemplo ciertos coeficientes, que nos arrojan conocimientos acerca de las operaciones del pozo.

4.1 Ambiente de validación de las pruebas.

Ambiente de Validación de las pruebas

Cada agente contaba con el siguiente equipo, cuyas especificaciones son estas:

• Procesador Intel (R) Pentium 4 CPU 3.20 GHZ.

• 1 GB de Memoria RAM

• Disco Duro de 80 GB.

Software Requerido:

• S.O: Linux Slackware 12.0

• G++, compilador de C++.

• Libxml, librería para el manejo de lenguaje XML.

• ACE para el manejo de colas de mensaje

• Gnuplot: librería para manejo de interfaces gráficas.

• GDB: depurador de Linux.

Pruebas de Desempeño Local.

Esta fase de la prueba se ejecuto en el mes de Mayo del 2008. A continuación sus resultados:

1. Se utilizaron máquinas del CEMISID (Centro de Microelectrónica y Sistemas Distribuidos) todas con la distribución “Slackware 12.0”

2. La versión de ACE usada es 5.6.4. Esta versión es más reciente que la usada por la cooperativa AY3J para sus pruebas.

3. Todas las pruebas se ejecutaron en todas las máquinas para verificar el funcionamiento de la Plataforma.

Nivel Base

La versión de ACE utilizada (5.6.4) presento un error con el archivo de cabecera “os_byteswap.h”; este archivo se busco en la carpeta de ubicación así:

#~/fuentes/ACE_warppers/ace $find . –iname “*byte*”,

consiguiéndose el archivo en esta carpeta

#./ace/os_include/os_byteswap.h

y ubicado ahí se manda a copiar en el directorio necesario de la siguiente manera:

#cp /ace/os_include/os_byteswap.h /usr/local/incluye/ace/os_include

Con esa modificación correspondiente ya realizada, con make all se compila toda la librería en el sistema y con make install, se instala por completo.

• El personal del CEMISID, en especial el Profesor Francisco Hidrobo, tutor de esta tesis, proporcionó todos los archivos del nivel base, interfaz y superior de la Plataforma, así como la versión del MGS.

Nivel Interfaz

Para las pruebas del nivel interfaz se utilizó el simulador desarrollado por la cooperativa. En este caso existen 4 Agentes: Negocio (Pozo), Aplicación, Repositorio y Especializado. Estos cuatro agentes son activados a través del AgentePruebas.

Pruebas de Funcionamiento distribuido

Esta fase de pruebas se realizó en el mes de Junio del 2008. En las pruebas de funcionamiento distribuido se utilizaron 4 computadores del CEMISID; todas ellas con distribución Slackware.

Para la realización de las pruebas se uso el siguiente procedimiento:

En cada nodo que se usó para las pruebas:

1. Instalación del software del MGS: Descomprimir el archivo MGS.tar.gz en la carpeta de preferencia.

~$ tar -xzvf MGS.tar.gz

2. Creación del directorio de destino para el funcionamiento del MGS:

Crear el directorio /etc/mgs asignándole los permisos de lectura y escritura para el usuario que se desee usar para ejecutar el sistema.

~ # mkdir /etc/mgs

~ # chown -R usuario /etc/mgs

3. Ingreso al sistema con la cuenta que se definió para las pruebas (Login: usuario)

4. Descarga, compilación e instalación: Para esto se ejecuta el script install.sh que se encuentra en el subdirectorio Archivos-Fuentes/interfaz ubicado donde descomprimieron los archivos. Este script se encarga de compilar el nivel base, crear la estructura de directorios necesaria para instalar el sistema, compilar el nivel interfaz y los agentes de nivel superior.

~/ Archivos-Fuentes/interfaz: ./install.sh

5. Configuración del nodo. Ahora se deben modificar los archivos de configuración de la manera siguiente:

a. De acuerdo a las instrucciones provistas por Guatire Gas se debe modificar el archivo /etc/mgs/base/sysconfig.xml en la sección correspondiente al IP de cada equipo:

<var>

<name>LocalIPAddress</name>

<value>192.168.1.IP (asignado)</value>

</var>

b. Sustituir el valor que allí se encuentra por el correspondiente, IP(asignado) a cada nodo.

c. Se debe modificar el archivo /etc/mgs/usuarios.txt para agregar los usuarios con el que se está ejecutando el sistema en ese momento, simplemente se agrega una línea especificando el nombre del usuario.

d. Como los agentes del sistema deben tener uids diferentes y los AAA deben conocer los uids de sus homólogos en otros nodos deben modificarse los archivos de configuración ubicados en ./interfaz/xml para adaptarlos a la configuración. Como ya se dispone de dichos archivos lo único que debe hacerse es copiar el contenido de las carpetas EquipoX al equipo que se está configurando (X puede tomar los valores A, B, C y D). Dichos archivos se encuentran en ./interfaz/archivos.

De la siguiente manera:

~/Archivos-Fuentes/interfaz $cp –R Equipo(X)/* /xml

Luego de configurar los 4 equipos, el sistema está listo para ser evaluado; antes de realizar la prueba de desempeño e integración se debe ejecutar el script limpiar.sh que se encuentra en la carpeta interfaz incluso, este script limpia los archivos xml de agentes creados, registrados, etc.. Una vez ejecutado el script limpiar.sh, se procede, en cada uno de los nodos, a ejecutar el programa llamado Server que se encuentra en ./base/trunk/lib/bin, es importante que ejecute el archivo desde el directorio.

~/ Archivos-Fuentes $ cd interfaz

~/ Archivos-Fuentes /interfaz $ sh limpiar.sh

~/ Archivos-Fuentes /interfaz $ cd ../base/trunk/lib/bin

~/ Archivos-Fuentes /base/trunk/lib/bin & ./server

A continuación se escoge uno de los nodos de prueba y se ejecuta en éste el programa AgentePruebas ubicado en el directorio /etc/mgs/agentes.

~ $ cd /etc/mgs/agentes

~ $ ./Agente pruebas

Resultados de las pruebas

Los resultados de las pruebas del funcionamiento integrado arrojaron resultaron satisfactorios, ya que se pudo verificar:

1. La creación local y remota de agentes con identificadores únicos.

2. La comunicación local y remota entre agentes.

3. La prestación de servicios de localización local y remota.

4. La transferencia de mensajes.

5. La interrelación entre los niveles base e interfaz de modo distribuido.

6. El intercambio masivo de mensajes.

Equipo AIp:41

Equipo BIp:29

Equipo AIp:32

Equipo AIp:56

M.G.S

A.A A.R A.N A.E

Escenario del Laboratorio

Figura 4.1 Plataforma Instalada

4.2 Codificación

Tomando como punto de partida la sección 3.7, donde se especifica el modelo que se usó, notamos que este posee una ecuación simple diferencial, por accesoria y experiencia de los tutores se decidió, usar el método de runge-kutta de segundo orden, para solucionar la ecuación correspondiente, este es un método genérico de resolución numérica de ecuaciones diferenciales. Este conjunto de métodos fue inicialmente desarrollado alrededor del año 1900 por los matemáticos C. Runge y M. W. Kutta [21].

Este método poseía varias ventajas , necesita una condición inicial y(t0)=y0, para efectos de nuestro problema era el volumen inicial del tanque (Q0), se asignó un valor predeterminado y la segunda ventaja el ser un método iterativo, lo cual nos permite ver que sucede en el gráfico punto por punto, la ejecución de este gráfico es la solicitud de servicio “monitorear_simulación()” que le hace el Agente de Negocio (Agente Pozo) al Agente Aplicación (Agente de Monitoreo y Supervisión ).

Para poder realizar la codificación se hizo el siguiente escenario:

Pre-condición:

Debe estar programado en lenguaje C++.

Usar el Compilador de C++, g++.

El nombre del archivo donde es validado el modelo debe ser extensión .cpp

(caso particular: “modelo _ producción.cpp”).

Pasos:

(a) Se debe ejecutar dentro de la consola, pasándole el programa con la extensión .cpp y el nombre del archivo_ejecutable , ejemplo:

g++ modelo_produccion.cpp –o pozo

salida:

Un archivo ejecutable de nombre pozo y que se ejecuta desde la consola , en el directorio donde se esta ubicado así:

. /pozo

El programa despliega por pantalla los datos generados por el modelo, en el caso de que el usuario oprima la opción de “s”, especificando que desea ver la salida.

Un archivo de extensión .dat llamado “Q_t1.dat”, si se desea consultar se accede desde el directorio donde se esta ejecutando.

La salida arrojada por el programa en pantalla y escrita en el archivo Q_t1.dat seria:

Figura 4.2 salida del programa

El código del programa “modelo_producción.cpp “, se encuentra en el Anexo 1.

4.3 Implementación y Pruebas funcionales del modelo

Las pruebas se encargaran de asegurar que el modelo producido hace lo que se ha pedido para cumplir con los objetivos.

Se elaboran las pruebas funcionales, porque ellas aseguran que el modelo integrado ejecute sus funciones de acuerdo a lo planteado en los objetivos.

Las pruebas funcionales ignoran la estructura de la plataforma y se concentran en las funciones que debe satisfacer el agente.

En cierta forma son pruebas similares a las pruebas tipo caja negra, excepto que en lugar de considerar las entradas y salidas, las pruebas funcionales se centran en las funciones que debe ejecutar el agente.

Caso de prueba funcional para el agente pozo

En la prueba funcional se debe verificar que el agente funciona correctamente ante la solicitud de servicio realizada por otro agente.

Los servicios que le solicitan al agente pozo son:

generar_datos ();

solicitar_grafico_aplicacion ();

almacenar_datos_repositorio ();

La siguiente tabla ilustra como es la prueba:

# caso de prueba

Objetivo de la prueba Agente solicitante

Datos de entrada

Salida obtenida

Observaciones

1 Verificar que la salida del método

“generar_datos”

Sea la esperada

Agente Pozo

Simulación del pozo

Es la implementación de los códigos del “modelo_produccion.cpp”en el agente pozo.

2 Verificar que la salida del método “solicitar_grafico_aplicacion”

Sea la esperada

Agente Aplicación

Los datos de la simulación hecha por el agente negocio

Un grafico con el monitoreo de la simulación

Se realiza por medio de una librería implementada en el nivel superior

3 Verificar que la salida del método “almacenar_datos_repositorio”

Sea la esperada

Agente repositorio

Un archivo de datos teóricos históricos

Tabla 3. Pruebas funcionales del agente pozo

Para poder realizar el caso de prueba #1 se implanta el modelo como una función local, dentro de los códigos del agente pozo, se declara de esta forma: “int generador_datos()”, y es invocado desde AgentePruebas.cpp por ser este el archivo ejecutable cuando se realiza la corrida de la plataforma, el cuerpo de la función se encuentra en el Anexo 2. Para poder realizar el caso de prueba #2, se implementa una librería de Linux llamada Gnuplot, dicha librería, se utiliza especificando la dirección del archivo de datos generados por el agente pozo, para que el agente de monitoreo y supervisión, realice la grafica. Para poder realizar el caso de prueba #3, se implementa una función local tipo string declarada como “string leerArchivo ()”, donde esta especifica que el archivo debe ser almacenado

en el agente repositorio.

4.4 Pruebas de Integración del Agente en la Plataforma

Para explicar este apartado aclaramos que las pruebas de integración, representan la manera de cómo se integran los programas que ya han sido probados. Existen varias maneras de hacerlo:

- Incrementales (implican una secuencia de integración).

- Integrar todas al mismo tiempo.

En el apartado anterior especificamos, las funciones que se incorporan a el agente pozo para que el pueda cumplir con sus funcionalidades en el nivel superior, estas funciones o programas, fueron probados fuera de la plataforma, para poder verificar las salidas que se buscan antes de ser implementados en la plataforma.

La prueba de integración consta de 2 fases, y se realiza de esta forma:

Primero se hace la observación:

a) para compilar el agente negocio, nos ubicamos en el directorio ~/Archivos-Fuentes/interfaz, y desde ahí make agentenegocio, de esta manera se verifican los errores, antes de realizar la corrida de la plataforma.

Para correr la plataforma:

a) Ubicados en el directorio ~/Archivos-Fuentes/interfaz, activamos el archivo ./limpiar, en cada una de las 4 maquinas.

b) Ubicados en el directorio ~/Archivos-Fuentes/base/trunk/lib/bin , activamos el archivo ejecutable ./server

c) Y parados en el nodo de prueba donde esta asignado el IP para el agente negocio , nos ubicamos en /etc/mgs/agentes y activamos el archivo ejecutable ./AgentePruebas

Las corridas realizadas arrojan las siguientes salidas:

En la primera etapa, se observa el comportamiento del pozo en la grafica.

En la segunda la etapa, el comportamiento del nivel superior.

4.4.1 Fase 1) Prueba para el Agente Pozo

Figura 4.3 Nivel de Caudal

Q= caudal (m3/seg).

4.4.2 Fase 2) Prueba conceptual

root@cemisid2:/etc/mgs/agentes# ./AgentePruebas

(3391|3080976608) Configuration:: Parseando archivo /etc/mgs/base/sysconfig.xml

(3391|3080976608) Configuration:: Obteniendo Datos...

(3391|3080976608) Configuration:: Obteniendo configuracion ...

(3391|3080976608) Configuration:: Obteniendo configuracion del Sistema ...

(3391|3080976608) MGSLibBase:: Iniciando Libreria

(3391|3080976608) MGSLibBase:: Conectando al Sistema ..... (3391|3080976608) OK

(3391|3080976608) MGSLibBase:: Activando Threads para transmision de Mensajes ..... (3391|3080976608) OK

(3391|3080976608) MGSLibBase:: Registrando Agente ..... (3391|3080976608) OK

Plataforma

c0a80138-6763845e-48e4deba-360be000

c0a80138-4353d0cd-48e4deba-36754000

c0a80138-71f32454-48e4deba-36dea000

c0a80138-3a95f874-48e4deba-3747e000

****************** ACC::Constructor

DEBUG : Thu Oct 2 10:46:18 2008

* se cumplio plazo

* APLICACION: ./interfaz/src/AgenteControlComunicaciones.cpp

* ACC::registrarPuerto()

* LINEA : 144

DEBUG : Thu Oct 2 10:46:18 2008

* Puerto registrado

* APLICACION: ./interfaz/src/AgenteControlComunicaciones.cpp

* ACC::registrarPuerto()

* LINEA : 161

Agente Pruebas ejecutandose desde : 192.168.1.41

Su UID es : c0a80138-2d1d5ae9-48e4deba-35f01000

+ Primera fase de las pruebas : Solicitar la creación de los agentes de Nivel Superior

Receptor : AAA

Mensaje : crearAgente

* Agentes gestores locales :

- AAA A : c0a8013c-4e6afb66-4728bd9b-1368f000

- AAA B : c0a80165-2d1d5ae9-38c9e88e-5a6ad000

- AAA C : c0a8013c-2443a858-47448fde-36cb4000

- AAA D : c0a8013c-0836c40e-4745a09b-a45a8000

- AGA : c0a8013c-1e7ff521-4745a09b-a4d48000

- AGD : c0a8013c-22221a70-4745a09b-a55aa000

- AGR : c0a8013c-419ac241-4745a09b-a5c7a000

Se envia mensaje de creacion a : c0a8013c-4e6afb66-4728bd9b-1368f000

304 : Se obtuvo una respuesta al crear el AgenteRepositorio :

Respuesta : agenteCreado

Uid : c0a80129-4353d0cd-48e4a5e1-00cfe000

Se envia mensaje de creacion a : c0a80165-2d1d5ae9-38c9e88e-5a6ad000

334 : Se obtuvo una respuesta al crear el AgenteEspecializado


Uid : c0a8011d-4353d0cd-48e4a6bc-4592e000

Se envia mensaje de creacion a : c0a8013c-2443a858-47448fde-36cb4000

363 : Se obtuvo una respuesta al crear el AgenteAplicacion


Uid : c0a80120-79838cb2-48e4df04-c772b000

Se envia mensaje de creacion a : c0a8013c-0836c40e-4745a09b-a45a8000

392 : Se obtuvo una respuesta al crear el AgenteNegocio


Uid : c0a80138-5e884adc-48e4dec0-76e9f000

+ Primera fase de las pruebas : Exito

+ Segunda fase de las pruebas : Solicitar la localización de los agentes de Nivel Superior

* Localizar agentes

Receptor : AAA

Mensaje : localizar

Linea : 461 :: Se obtuvo una respuesta al localizar el AgenteRepositorio

Respuesta : c0a80129-4353d0cd-48e4a5e1-00cfe000 : CORRECTO

Linea : 461 :: Se obtuvo una respuesta al localizar el AgenteAplicacion

Respuesta : c0a80120-79838cb2-48e4df04-c772b000 : CORRECTO

Linea : 461 :: Se obtuvo una respuesta al localizar el AgenteEspecializado

Respuesta : c0a8011d-4353d0cd-48e4a6bc-4592e000 : CORRECTO

Linea : 461 :: Se obtuvo una respuesta al localizar el AgenteNegocio

Respuesta : c0a80138-5e884adc-48e4dec0-76e9f000 : CORRECTO

* Localizar agentes por Uid

Receptor : AAA

Mensaje : localizarAgenteUid

Linea : 491 :: Se obtuvo una respuesta al localizar el AgenteRepositorio

Respuesta : 192.168.1.41

Linea : 491 :: Se obtuvo una respuesta al localizar el AgenteAplicacion

Respuesta : 192.168.1.32

Linea : 491 :: Se obtuvo una respuesta al localizar el AgenteEspecializado

Respuesta : 192.168.1.29

Linea : 491 :: Se obtuvo una respuesta al localizar el AgenteNegocio

Respuesta : 192.168.1.56

+ Segunda fase de las pruebas (localización por Uid) : Exito

+ Tercera fase de las pruebas : Solicitar servicios a los agentes de Nivel Superior :

* Solicitar Repositorio :

Linea : 549 :: Se obtuvo una respuesta del AgenteRepositorio

Respuesta variables : 231.711889| 221.975155| 212.48175| 203.21705| 194.165871| 185.316127| 176.656551| 168.176868| 159.867866| 151.721167| 143.729419| 135.886178| 128.185576| 120.622881| 113.193872| 105.895242| 98.7245423| 91.680178| 84.7616762| 77.9694015| 71.3052247| 64.7721492| 58.3749215| 52.1206019| 46.0186165| 40.080935| 34.3239706| 28.7699007| 23.4460199| 18.3926383| 13.6637427| 9.3379275| 5.53552049| 2.45697543| 0.478840931| 0.0222984793| -0.0188090233| 0.0170127188| -0.0145530197| -0.0131200233| -0.00758034594| -0.0047589463| -0.00788911033| -0.0103270351| -0.00827721749| -0.00776822421| -0.0102143467| -0.00893423683| -0.00677653807| -0.00868346761| -0.0104382279||

+ Tercera fase de las pruebas : Exito

* Solicitar Aplicacion :

- Solicitando operaciones al AgenteAplicacion :

Linea : 569 :: Se obtuvo una respuesta al leer el AgenteAplicacion

Respuesta : 5

* Solicitar Negocio :

Linea : 658 :: Se obtuvo una respuesta al leer el AgenteNegocio

Respuesta : 400

+ Tercera fase de las pruebas : Exito

(3391|3080976608)

MGSLibBase:: Finalizando Libreria

(3391|3080976608) MGSLibBase:: Deregistrando Agente ..... (3391|3080976608) OK

(3391|3080976608) MGSLibBase:: Cerrando Conexion con el Sistema ..... (3391|3080976608) OK

(3391|3080976608) MGSLibBase:: Deteniendo Threads para transmision de Mensajes ..... (3391|3080976608) OK

Thu Oct 2 2008 10:46:50.841432

(3391|3080976608) Port::Error Libreria no inicialiada

4.5 Análisis de los Resultados

%Parámetros del sistema: %Diámetro de la tubería: d=2.54e-2*3; %inches a SI %Rugosidad relativa de la tubería: epsd=0.0018; %Densidad del fluido: rho=1000; %kg/m^3 %Viscosidad del fluido: visc=1e-3; %Pa*s rho=1000kg/m^3 L1=0;%m L2=500;%m L3=4500;%m g=9.81;

%Tanque o reservorio: %========= %Sección Transversal: A1=1e4; %m^2 %Altura del Tanque: H1=1.5; %m %Nivel Inicial: h1o=1.3; %m %Masa de la cámara de aire: ma1=12.e5; %Kg %Temperatura del aire: Ta1=300; %K %Coeficiente politrópico: k1=1; %Posición vertical Tanque: z1=-5000; %m Estas fueron las consideraciones físicas y mecánicas para las simulaciones

Aquí se desarrollo la correlación de Hagedorn y Brown, tomando como dato de entrada los caudales, esto con el fin de analizar la productividad del pozo o el potencial del pozo.

Se obtuvieron los siguientes valores de presión de fondo fluyente:

p_wf_1 = [6473, 4453, 4657, 4939, 5288, 5694, 6156, 6676, 7253, 7887, 8584, 9360, 10185, 11077, 12036]

Figura 4.4 Curvas de demanda de producción

Curva Hagedorn & Brow n - Yacimiento B4

0

2000

4000

6000

8000

10000

12000

14000

0 10000 20000 30000 40000 50000 60000

Qo (BBL/d)

Pwf (

psi)

Capítulo V. Conclusiones

Al finalizar la presente investigación, se da por bien sabido que el estudio de los pozos de producción petrolero mediante agentes, no es tarea fácil, debido a que implica el entendimiento de extensos conocimientos en el área de programación, así como de sistemas de control, no obstante esta investigación permitió revisar, ampliar y ahondar todos los conocimientos aprendidos durante toda la carrera referente a modelado y simulación , codificación en lenguaje c++ y desarrollo de sistemas multiagentes.

Sin embargo se cumplió con el objetivo principal, al obtener un modelo de simulación de un sistema de producción petrolera, y lograr exitosamente implementar dicho modelo en una plataforma de automatización industrial en agentes, ofreciendo una herramienta que puede ser usada para futuras investigaciones.

Los resultados hechos sobre la plataforma comprobaron que ella es de utilidad, en aplicaciones para el área de control, demostrando que puede ser usada en ambientes mas amplios, de mayor riesgo y con manejo de operaciones en tiempo real, esto es un gran aporte para el desarrollo de las nuevas tecnologías emergentes en el país, por parte de la Industria Petrolera.

Y además abarcaría el principio para la construcción de instalaciones como salas de control, vinculando a instituciones de carácter nacional, como sería la Universidad de los Andes y la Industria Petrolera ubicado en el estado Barinas, hecho que seria un gran aporte al desarrollo nacional.

Recomendaciones

Se recomienda realizar mas pruebas a la plataforma de automatización industrial en agentes, con nuevos modelos de pozos de producción petroleros, en especial implantado en el agente de negocio, con la finalidad de obtener mejores aproximaciones en el comportamiento de los pozos.

Se recomienda indagar sobre los otros modelos y realizar experimentos de simulación con ellos para su comparación con el estudiado en este proyecto.

VI. BIBLIOGRAFÍA.

[1] Técnicas Emergentes para la Automatización Integrada de Procesos Industriales. (2006) Lisbeth Carolina Pérez Rivas, Trabajo Especial de Grado. Escuela de Ingeniería de Sistema, Facultad de Ingeniería, Universidad de Los Andes- Mérida, Mérida. Venezuela. [2] Desarrollo de la ingeniería conceptual de software para la definición de una arquitectura sistémica que permita implementar las funcionalidades y tecnologías identificadas en las mesas corporativas de Arquitectura y de Aplicaciones sobre la plataforma Net-DAS 2.0. (2005). Fundacite – Escuela de Ingeniería de Sistema, Facultad de Ingeniería, universidad de Los Andes, Mérida- Mérida. Venezuela. [3] Descripción Funcional del Medio de Gestión de Servicios, Modelo Arquitectónico del Sistema Multiagentes, con la descripción de los Actores y Casos de Uso de los mismos. Fundacite- ULA, Julio 2005 [4] Una Metodología para el Modelado de Sistemas de Ingeniería Orientado a Agentes (2006) Aguilar, J., Besembel I., Cerrada M., Hidrobo, F.J.; Narciso, F., Universidad de Los Andes Mérida, 5101. Venezuela, [5] Panorama General de la Tecnología de Agentes José Aguilar, 2008 Universidad de Los Andes Mérida, 5101. Venezuela. [6] A Universal Modular Actor Formalism for Artificial Intelligence IJCAI'73. Carl Hewitt, Peter Bishop (1973). [7] Desarrollo de un prototipo del módulo Agente para la plataforma de simulación GALATEA. Erasmo Gómez Molina, Mérida, Septiembre 2002 Universidad de los Andes [8] Russell, S. J. y Norvig, P. (1996). Inteligencia Artificial: un enfoque moderno. Prentice Hall, Inc. [9] Propuesta para un sistema de gestión de servicio multiagente para el SCDIA Víctor Bravo

Tutor: Dr. José Aguilar Mérida -2003 [10] Computación Imprecisa Basada en Agentes Enfoque ULA – UDO. Equipo del Proyecto, Puerto La Cruz, Noviembre de 2007 [11] MODELO MULTIAGENTE DEL PROCESO DE OCUPACION DE LA RESERVA FORESTAL DE CAPARO Johana del Álvarez .C. Tutor: Oswaldo Terán Mérida Abril-2005 [12] Forgionne, G.A. (1978) “Corporate Management Science Activities: An Update” Interfaces, vol.13, pp.257-260.

[13] Sistemas multiagentes (SMA) e Inteligencia Artificial distribuida. Demetrio Arturo Ovalle Carranza, Ph.D. Universidad Nacional de Colombia Junio de 2005

[14] Valvatne, P., Serve, J., Durlofsky, L. & Aziz, K. (2003), ‘E_cient modeling of nonconventional wells with downhole inflow control devices’, Journal of Petroleum Science and Engineering 39, 99–116. [15] Lie, O. & Wallace, W. (2000), Intelligent recompilation eliminates the need for additional well, in ‘IADC/SPE Drilling Conference’, number IADC/SPE 59210, New Orleans, LA.USA. [16] Modelado de la producción simultánea de dos arenas y Desempeño de los algoritmos de control Realizado por : Equipo de Completación Inteligente Universidad de Los Andes Junio 2007 [17] Reporte de Validación de Pruebas de Integración del Nivel Interfaz y Nivel Base Fundacite - ULA, Diciembre 2007. [18] Conceptualización de la Arquitectura de Automatización Industrial para Producción, Descripción Funcional del Medio de Gestión de Servicios Fundacite - ULA, Julio 2005. [19] Documento de Especificación del Nivel Superior Fundacite-ULA, Noviembre 2005. [20] Gravity Drained Water Tank http://apmonitor.com/water_tank.aspx [21] Método de Runge-Kutta http://es.wikipedia.org/wiki/M%C3%A9todo_de_Runge-Kutta

Anexos Anexo 1

// CODIFICACION DE RUNGE-KUTTA DE SEGUNDO ORDEN

#include <iostream> #include <stdio.h> #include <iomanip> #include <fstream> using namespace std; int main(void){ double k1=0.14, k2=0.25, L1 <- constantes; double T=0,Q=236 <-condicion inicial; int N; double H=1 <-paso; int _step_time=100 <- #iteraciones ; ofstream file; char ver; double beta= 99 <- % open_valvula; cout<<"*****************************************************************************\n"; cout<<"\nMetodo Runge-Kuta de segundo orden"; cout<<"\nSolucion de un modelo de un tanque simple de 0 hasta t."; cout<<"*****************************************************************************\n\n"; while(ver != 's' && ver !='S' && ver !='n' && ver !='N'){ cout<<"\nDesea ver los resultados (s/n)? "; cin>>ver; } if(ver == 's' || ver =='S'){ cout<<"\n T Q "; cout<<"\n"<<setw(6)<<T<<setw(14)<<Q; } file.open("Q_t1.dat", ios::out); <- archivo_salida file<<" "<<T<<" "<<Q; for(N=1; N<=_step_time; N++){ T=T+H; L1=-k1*beta-k2*Q;<- ecuacion diferencial Q=Q+L1/4; file<<" "<<T<<" "<<Q<<endl; if(ver == 's' || ver =='S') cout<<"\n"<<setw(6)<<T<<setw(14)<<Q; cin >> ver; } file.close(); cout<<"\n"; return 0; }

Anexo 2 { double k1=0.14, k2=0.25,T=0,Q=236,H=1, L1; int N, step_time=100; //char ver; double beta=0.99; ofstream file; cout<<"*****************************************************************************\n"; cout<<"\nMetodo Runge-Kuta de segundo orden"; cout<<"\nSolucion de un modelo para un POZO DE PRODCUCCION PETROLERA desde t=0 hasta t=100."; cout<<"*****************************************************************************\n\n"; file.open("/root/Archivos-Fuentes/interfaz/superior/Q.txt", ios::out); file<<T<<" "<<Q<<endl; for(N=1; N<=step_time; N++){ T=T+H; L1=-k1*beta-k2*Q; Q=Q+L1/4; file<<T<<" "<<Q<<endl; } file.close(); system("echo 'set grid; plot \"/root/Archivos-Fuentes/interfaz/superior/Q.txt\" with point 3; pause 10'| gnuplot"); return 0; }

proyecto de grado presentado ante la ilustre universidad

Documents