DAMMAD Diseño y Aplicación de Modelos Multiagente para Ayuda a la Decisión Demostrador para la gestión de flotas de autobuses Universidad de Málaga.

Introducción Descripción del problema La red de autobuses urbanos se descompone en líneas con varios servicios. Normalmente ocurren problemas en el comportamiento de los servicios que son resueltos por inspectores de línea o por el centro de control. Objetivos Construir un sistema de ayuda a la decisión que provea a los operarios del centro de control información acerca del estado y los problemas de las líneas, aparte de recomendaciones para subsanar dichos problemas.

Índice Arquitectura del sistema Modelo de conocimiento Implementación del sistema Conclusión

Arquitectura del sistema Basada en la arquitectura SKADS Adaptada al problema particular de la gestión de flotas de autobuses Se identifican cuatro grupos de agentes Conexión con la flota de autobuses Gestión de la flota de autobuses Centro de control Agentes externos

Arquitectura del sistema

Data Agent (DA) Hay uno por línea. Se encarga de su propia línea y no conoce nada acerca de otras. Conoce el estado de la línea y las posiciones de los autobuses. Oferta información al resto del sistema (llegadas, averías, saturaciones). Envía esta información a cualquier agente que se subscriba a él.

Arquitectura del sistema Line Management Agent (LMA) Hay uno por línea. Se encarga de su propia línea y por defecto no conoce nada de otras. Oferta información al resto del sistema (identificación de problemas, acciones de control para solucionar problemas). Envía esta información a cualquier agente que se subscriba a él. Obtiene el estado de la línea subscribiéndose a un Data Agent y razona a partir la información que este le envía.

Arquitectura del sistema User Interface Agent (UIA) Puede haber tantos como se desee (uno por línea, uno para todas las líneas). Muestra información sobre el estado de una línea (si se subscribe a su Data Agent). Muestra información sobre las acciones que hay que ejecutar para resolver los problemas de la línea. Es el encargado de aceptar (o rechazar) esas acciones de control y de informar al resto del sistema en caso de que se acepten.

Arquitectura del sistema Broker Agent Es un agente externo que se encarga de negociar entre los LMA’s del sistema la petición de un servicio de refuerzo. Cuando un LMA decide que su línea necesita un servicio de refuerzo, se pone en contacto con el Broker para que este “subaste” la petición entre los demás LMA’s y devuelva el resultado al LMA que hizo la petición.

Arquitectura del sistema Broker Agent Cuando un LMA necesita otro servicio, estima el estado que va a tener la línea desde ese momento hasta el final de la jornada. Considerando esa estimación como un coste (o precio) se va a tratar de encontrar un LMA cuyo coste de perder un servicio sea menor que el coste que tiene el LMA interesado. La negociación se hace por rondas, empezando por un precio más bajo que el precio real y buscando agentes cuyas líneas estén en un rango de distancia especificado con la línea interesada. Se empieza a negociar con las líneas más próximas y se va aumentando la distancia sucesivamente. Si en una ronda ningún LMA está dispuesto a ofrecer un servicio a ese precio, primero se incrementa el rango de distancia y cuando no hay más agentes se incrementa el precio y se vuelve a las distancias más cercanas.

Arquitectura del sistema Broker Agent. Ronda 1 En la primera ronda se trata de sacar el servicio de las líneas que comparten cabeceras

Arquitectura del sistema Broker Agent. Ronda 2 Si ninguno de los anteriores acepta, se incrementa el rango de distancia con el mismo precio.

Arquitectura del sistema Broker Agent. Ronda 3 Si ningún agente ha aceptado y no hay agentes a más distancia, se incrementa el precio y se vuelve a preguntar a las líneas que comparten cabecera

Modelo de conocimiento Generado a partir de sesiones de extracción del conocimiento con los técnicos del centro de control de la EMT. Está basado en una ontología JADE modelada con Protégé. Genéricamente, se tienen conceptos, acciones de agente, problemas, acciones de control y predicados.

Modelo de conocimiento Conceptos AID (Agent Identifier) Bus Service Stop Line Time

Modelo de conocimiento Acciones de agente GiveService ReceiveService Negotiate AskForReinforceService

Modelo de conocimiento Problemas Saturation IndividualDelay GeneralisedDelay BreakDown MultilineDelay ServicesTogether

Modelo de conocimiento Acciones de control ChangeFrecuency ChangeToFrecuencyRegulation ChangeToTimetableRegulation DecreaseSpeed IncreaseSpeed JumpStops HelpBetweenServices AdvanceFollowingService AdvanceHeadServiceStart LineHeadRetention GetServiceFromAnotherLine

Modelo de conocimiento Predicados Arrive Incident Recommend CanGiveReinforceService CanNegotiateForReinforceService

Implementación del sistema Especificaciones y herramientas Se sigue la especificación FIPA sobre agentes, mensajes y protocolos. Se han utilizado los protocolos Subscribe, Request y Brokering. Esta especificación se modela en el lenguaje JAVA mediante el marco de desarrollo JADE. Para el razonamiento de los LMA’s se ha utilizado Jess, que proporciona un modelo de razonamiento CLIPS para integrar con JAVA. Se trabaja con los datos reales de tres líneas completas (3, 12 y 15) que forman parte de la red de autobuses de Málaga.

Implementación del sistema Funcionamiento general Al iniciar el sistema lo primero que se lleva a cabo son las subscripciones. Cada LMA i se subscribe a el DA i para obtener información de la línea. Cada DA se subscribe al UIA para obtener información sobre las acciones de control que se llevan a cabo. El UIA (un solo UIA centralizado para todas las líneas) se subscribe a todos los DA’s y a todos los LMA’s.

Implementación del sistema Funcionamiento general Cada DA comienza a generar datos de llegadas e incidentes. El LMA correspondiente utiliza estos datos para detectar problemas y generar soluciones. El UIA los usa para representar la línea en pantalla Cada recomendación que genera un LMA se envía al UIA para ser revisada y eventualmente aceptada por un usuario. Las acciones de control aceptadas en el UIA se envían al LMA y al DA para ser ejecutadas

Implementación del sistema

Data Agent La parte más importante es el simulador. El simulador sigue los horarios reales de los servicios de la línea y genera la información correspondiente. Aunque se pueden producir incidentes (retrasos, saturaciones, averías) aleatoriamente, lo más apropiado para tratar escenarios de prueba es generarlos a mano. Muestra en todo momento la posición y el retraso de todos los servicios y el modo de funcionamiento de la línea (regulación por horario o por frecuencia). Se puede ver información específica de cada servicio como su horario, la velocidad a la que va o su número de pasajeros. Se puede regular la velocidad de simulación en todo momento. Se puede resetear a cualquier fecha y hora que se desee probar.

Implementación del sistema Data Agent

Implementación del sistema LM Agent Su parte más importante es el motor de inferencias CLIPS. Cada vez que recibe una llegada o un incidente, aserta la información correspondiente en el motor de inferencias, aparte de guardar otra información acerca del estado del servicio. Cada vez que se hace un aserto, el motor de inferencias dispara las reglas correspondientes (si las hay). Hay reglas que identifican soluciones a partir de problemas asertados y reglas que ejecutan las soluciones que se han tomado (se ejecuta notificándolo al agente, que a su vez informa al UIA). Las reglas se organizan por soluciones, hay reglas para identificar todas las soluciones.

Implementación del sistema LM Agent Ejemplo de regla de identificación de problema  (defrule identify-jump-stops  ?delay <- (individualDelay (minutes ?m) (service ?ds))  (test (> ?m 3)) ;Un retraso medio o severo  (inMainStop (service ?mss))  (followedServices (service1 ?fs1) (service2 ?fs2))  (test (= (call ?fs1 getCode) (call ?mss getCode)))  (test (= (call ?fs2 getCode) (call ?ds getCode)));Van seguidos  =>  (assert (jumpStops (service ?ds)))  (assert (lineHeadRetention (service ?mss) (minutes 2)))  )

Implementación del sistema LM Agent

Implementación del sistema LM Agent Ejemplo de regla de ejecución de solución  (defrule resolve-jump-stops  ?h<-(jumpStops (service ?s))  =>  (bind ?o (new JumpStops))  (call ?o setService ?s)  (call ?*agente* notify ?o)  (retract ?h)  )

Implementación del sistema LM Agent Ejemplo de regla de identificación de problema  (defrule identify-help-between-services  ?delay1 <- (individualDelay (minutes ?m1) (service ?s1))  ?delay2 <- (individualDelay (minutes ?m2) (service ?s2))  (test (> ?m1 3))  (test (> ?m2 3));Un retraso medio o severo  (followedServices (service1 ?fs1) (service2 ?fs2))  (test (= (call ?fs1 getCode) (call ?s1 getCode)))  (test (= (call ?fs2 getCode) (call ?s2 getCode)));Van seguidos  =>  (assert (helpBetweenServices (service1 ?s1) (service2 ?s2)))  )

Implementación del sistema LM Agent

Implementación del sistema UI Agent Es una herramienta centralizada para controlar todas las líneas. En cada momento se puede visualizar el estado de la línea que se desee, mostrando en pantalla la posición de todos los servicios y los mensajes de recomendación que se han enviado para esa línea. Tiene dos modos de trabajo, uno automático, donde todas las recomendaciones que llegan se aceptan automáticamente y otro confirmado, donde por cada recomendación el usuario debe pulsar un botón si quiere aceptarla.

Implementación del sistema UI Agent Cada vez que se produce una llegada, el LMA genera acciones de control si hay algún problema. Para no llenar la consola de mensajes, es posible restringir la frecuencia con la que se muestran mensajes referidos a un mismo servicio. Así, si se establecen 3 minutos, solo se muestran mensajes de control referidos a un mismo servicio como mínimo 3 minutos después del último que llegó referido a ese servicio.

Implementación del sistema UI Agent

Implementación del sistema Broker Agent Se encarga de negociar la petición de un servicio de refuerzo entre LMA’s. Se basa en el protocolo FIPA-Brokering. Es el LMA interesado el que se encarga de configurar las rondas de negociación (rango de distancia y precio). Este agente recibe esta información y contacta con todos los LMA’s en el rango de distancias especificado mediante el protocolo Request. Devuelve el resultado de una sola ronda al LMA interesado, que debe lanzar la siguiente (si existe).

Conclusión El sistema es potente y versátil. Es muy parecido visualmente al sistema que se utiliza en el centro de control de la EMT de Málaga. Permite configurar escenarios de prueba específicos.

Conclusión Trabajo restante: Evaluación basada en escenarios de prueba. Evaluación externa del prototipo por parte de la EMT. Redacción de informes.