Este Trabajo Fin de Grado (TFG) se centra en el diseño e implementación de una plataforma de agentes basada en la nube para IOA. La implementación de la plataforma de agentes se basará en los estándares propuestos por FIPA (Fundación para Agentes Físicos Inteligentes).
Arquitectura de una Plataforma de Agentes según FIPA
Un Identificador de agente (AID) etiqueta a un agente para que pueda distinguirse dentro de la misma PA. El diseño interno de un agente es responsabilidad de los desarrolladores del sistema de agentes y no es un estándar FIPA propuesto.
Estructura del documento
Objetivo general
Objetivos específicos
Se utilizará el protocolo Message Queue Telemetry Transport (MQTT) [16] a través de un broker ubicado en la nube de IBM para enviar mensajes. Además, se presentan las plataformas más populares tanto para sistemas multiagente como para Internet de Agentes.
Sistemas Multiagentes
Agente inteligente
Autonomía: Un agente tiene la capacidad de actuar sin intervención humana directa u otros agentes. Reactividad: Un agente se sitúa en un entorno y es capaz de obtener percepciones del mismo y responder en consecuencia a los cambios que se producen en él.
Estándar FIPA
Un protocolo es un patrón utilizado para mantener el orden de los mensajes en una conversación. Solicitud FIPA cuando: este protocolo es similar a Solicitud FIPA, excepto que el agente receptor realizará la acción solicitada cuando se cumpla una determinada condición.
Plataformas de Sistemas Multiagentes
Una de sus principales características es que la plataforma del agente se puede distribuir entre diferentes máquinas, pudiendo tener diferentes sistemas operativos debido a que Java es un lenguaje multiplataforma. Un agente en JADE puede estar en cinco estados diferentes, como se ve en la Figura 3.5: iniciado, en espera, en tránsito, suspendido y activo. En la Figura 3.7 puede ver la estructura de una plataforma de agente usando SPADE.
JADE facilita que los programadores que ya han programado con JADE se familiaricen rápidamente con esta plataforma de agentes.
Internet de las Cosas
ESP8266[28]: Este dispositivo es un microcontrolador (Figura 3.9), que tiene 1 MB de memoria flash y conectividad Wi-Fi. Un ejemplo de un proyecto IOT desarrollado con Raspberry Pi es un sistema que mide la temperatura. Para ello, la Raspberry Pi será la encargada de realizar la función de servidor web y también de obtener las lecturas de los sensores, permitiendo así controlar la temperatura de una casa desde cualquier lugar, ordenador o dispositivo (Figura 3.10).
Este fue solo un ejemplo de proyecto, aunque dada la potencia de esta placa, la posibilidad de conectar sensores y la multitud de lenguajes de programación que hay.
Internet de Agentes
Además, los vehículos envían mensajes de RESPUESTA a todos los mensajes de SOLICITUD que estén en lista de espera. La primera es la seguridad, es decir, no habrá dos procesos al mismo tiempo en el tramo crítico. El segundo, vivacidad, cualquier proceso que quiera entrar en el tramo crítico lo consigue, es decir, no muere por inanición.
Cuando un proceso quiere acceder a la sección crítica, envía un mensaje de SOLICITUD al resto de procesos y espera hasta que todos los procesos le den permiso para acceder a la sección crítica.
Extreme Programming
- Roles
- Prácticas relevantes
- Proceso
- Historias de usuario
Cliente: Es responsable de escribir historias de usuario y pruebas funcionales para validar su implementación. Exploración: En esta primera fase, los clientes planifican las historias de usuario de interés para la primera entrega del producto. La Tabla 4.1 muestra el formato de historia de usuario que se utilizará en este TFG.
Descripción Una descripción de lo que desea obtener al completar esta historia de usuario.
Software de apoyo a Extreme Programming
Github
Overleaf
Kanban
Respeto: Tanto en un proceso de producción como en un proyecto de desarrollo de software, es fundamental que cada miembro del equipo sepa qué tiene que hacer en el momento adecuado y cuáles son sus funciones. En este tablero se insertarán las tarjetas identificativas de cada tarea, y se colocará la tarjeta en una columna según el estado en el que se encuentre. Por hacer: Se sugiere desarrollar la tarea de esta columna más adelante en el proyecto.
En el desarrollo de este TFG se decidió utilizar el tablero Kanban proporcionado por GitHub (Figura 4.6).
Medios a utilizar
Medios Hardware
Es la herramienta que se utiliza para visualizar las tareas a realizar y mejorar el trabajo en un equipo de desarrollo. En Progreso: La tarea ha sido asignada a un equipo de trabajo para ser desarrollada. Listo: la tarea se ha completado con éxito para que pueda pasar a la fase de producción final.
Medios Software
Javascript [1]: Es un lenguaje de programación interpretado, orientado a objetos, basado en prototipos, imperativo, débilmente tipado y dinámico. WebStorm: Es un entorno de desarrollo que soporta JavaScript, HTML, CSS, Vue.js y una amplia gama de tecnologías web actuales. Vue.js [31]: Es un marco de desarrollo front-end escrito en Javascript diseñado para organizar y simplificar el desarrollo web.
Flask[26]: Es un marco de desarrollo web escrito en Python que permite crear aplicaciones web de manera eficiente.
Funcionalidades del sistema
EN este capítulo se presentan los resultados de cada una de las fases de desarrollo. TFG desde su inicio hasta su finalización, así como las decisiones clave tomadas.
Iteración 1: Configuración inicial de servicios
Diseñar e implementar el ACC de la nueva plataforma de agentes utilizando el protocolo MQTT y el estándar FIPA ACL para mensajes de plataforma. Implementación del broker MQTT en la plataforma IBM, la primera versión de la biblioteca de agentes que permite la comunicación de mensajes FIPA ACL sobre mensajes MQTT. Debido a la extensa documentación disponible, se decidió implementar este estándar en la plataforma de agentes ya que es un estándar que se integra en la mayoría de las plataformas de agentes actuales.
Además, la plataforma IBM Watson IoT se ha configurado correctamente para utilizar su intermediario para comunicarse a través de la plataforma.
Iteración 2: Diseño e implementación del Sistema de Gestión de Agentes ( AMS )Agentes (AMS)
El funcionamiento de AMS estará diseñado para funcionar sobre la plataforma de agentes con todas sus funciones, ofrecer un AID único para cada agente, registrar y eliminar agentes de la plataforma. Luego puede ver todos los registros de la aplicación y cualquier error en el sitio web de IBM (Figura 5.7) en la pestaña Registros. Cada agente de la plataforma enviará un mensaje ACL a través de MQTT a AMS antes de ejecutarlo para intentar registrarse en la plataforma.
Se ha creado una aplicación utilizando el framework Flask que realiza las funciones AMS de la plataforma.
Iteración 3: Diseño e implementación del servicio de páginas ama- rillas ( DF )rillas (DF)
Configurar el servicio IBM MongoDB, modificar AMS y DF para almacenar su información en dicha base de datos. Una aplicación Flask que se ejecuta en la nube donde se ejecutarán las plataformas de agentes AMS y DF. Al final de esta iteración, se desarrolló el DF de la plataforma del agente.
Además, AMS y DF han sido configurados y conectados a la base de datos MongoDB (Listado 5.13).
Iteración 4: Diseño de la ejecución de agentes basados en com- portamientos
Descripción Se diseñará el comportamiento de los agentes de la plataforma y su ciclo de ejecución. En la Figura 5.12 se puede ver la estructura interna del agente de plataforma. El uso del método block() moverá el comportamiento de la cola de comportamiento activo a la cola de comportamiento bloqueado.
Además, se implementan dos métodos para recuperar mensajes de la cola de mensajes.
Iteración 5: Registro y ejecución de Agentes en la plataforma
Definir el ciclo de vida que tendrán los agentes en la plataforma, así como la estructura. La primera tarea de esta iteración es diseñar el ciclo de vida de los agentes para que puedan registrarse e inicializarse en la plataforma. El listado 5.16 muestra un ejemplo de un agente trabajando en la nube de IBM.
Implementación en la nube de Heroku: Otra opción sugerida (no solo para implementar agentes en la nube, sino para ejecutar agentes en cualquier máquina incluso si no tiene Python instalado) es usar Docker.
Iteración 6: Gestión de la plataforma
Se iniciará la comunicación del sitio web con la plataforma del agente para que el sitio web se actualice a medida que los agentes comiencen a ejecutarse o finalicen. Se agregará persistencia de información al sitio web para que durante la actualización no se pierdan todos los datos de la plataforma. El primer paso de esta iteración es diseñar la interfaz gráfica del sitio web para poder controlar a los agentes.
La Figura 5.22 muestra un esquema de la estructura de la plataforma del agente final.
Conclusiones
En este capítulo se presentan las conclusiones alcanzadas durante la realización de este TFG, además de describir direcciones de trabajo futuras para este trabajo. Al tratarse de un trabajo académico, es posible obtener beneficios en el ámbito educativo, como la oportunidad que se ofrece al programador de afrontar un trabajo de largo plazo utilizando metodologías que nunca ha utilizado en ningún trabajo, y afrontar el aprendizaje de nuevas tecnologías. y lenguajes de programación en el tiempo limitado del proyecto y explorar la resolución que se propuso durante el desarrollo del proyecto. TFG, todo ello ha ayudado al programador en su formación como Licenciado, lo que le será de gran ayuda en futuros proyectos en los que participará.
Trabajo Futuro
Trabajo futuro Crear la biblioteca de agentes en otros lenguajes de programación: Actualmente, este TFG sólo permite la ejecución de agentes utilizando el lenguaje de programación Python. Por este motivo se sugiere crear la biblioteca de agentes en lenguajes como microPython o Arduino para poder trabajar en una mayor cantidad de dispositivos.
ANEXOS
Agent(apikey,name): Constructor de la clase Agent, que acepta dos parámetros, el primero "apikey" hace referencia a la clave de la plataforma del agente en la que se encuentra, y el otro "name", que hace referencia al nombre de el agente. ServiceDescription(nombre=Ninguno,tipo=Ninguno): Constructor de la clase “ServiceDescription”, que define la descripción del servicio a ofrecer. AID(nombre=Ninguno,dirección=Ninguno): Constructor de la clase que describe el AID del agente de plataforma, el parámetro "nombre" define el nombre del agente y el parámetro "dirección" es el "tema" al que está suscrito.
Finalmente, si hacemos clic en la cruz del agente, el agente se verá obligado a ser eliminado de la plataforma, finalizando así la ejecución del agente.