DAMMAD

1. 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.

2. 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.

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

4. 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

5. Arquitectura del sistema

6. 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.

7. 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.

8. 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.

9. 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.

10. 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.

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

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

13. 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

14. 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.

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

16. Modelo de conocimiento • Acciones de agente • GiveService • ReceiveService • Negotiate • AskForReinforceService

17. Modelo de conocimiento • Problemas • Saturation • IndividualDelay • GeneralisedDelay • BreakDown • MultilineDelay • ServicesTogether

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

19. Modelo de conocimiento • Predicados • Arrive • Incident • Recommend • CanGiveReinforceService • CanNegotiateForReinforceService

20. 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.

21. Implementación del sistema • Funcionamiento general • Al iniciar el sistema lo primero que se lleva a cabo son las subscripciones. • Cada LMAi se subscribe a el DAi 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.

22. 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

23. Implementación del sistema

24. 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.

25. Implementación del sistema • Data Agent

26. 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.

27. 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))) • )

28. Implementación del sistema • LM Agent

29. 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) • )

30. 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))) • )

31. Implementación del sistema • LM Agent

32. 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.

33. 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.

34. Implementación del sistema • UI Agent

35. 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).

36. 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.

37. 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.