DAMMADDiseñ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ónDescripció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 sistemaModelo de conocimientoImplementación del sistemaConclusión

Arquitectura del sistemaBasada en la arquitectura SKADSAdaptada al problema particular de la gestión de flotas de autobusesSe 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

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 sistemaUser 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 sistemaBroker 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 sistemaBroker Agent. Ronda 1

En la primera ronda se trata de sacar el servicio de las líneas que comparten cabeceras

Arquitectura del sistemaBroker Agent. Ronda 2

Si ninguno de los anteriores acepta, se incrementa el rango de distancia con el mismo precio.

Arquitectura del sistemaBroker 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 conocimientoAcciones de control ChangeFrecuency ChangeToFrecuencyRegulation ChangeToTimetableRegulation DecreaseSpeed IncreaseSpeed JumpStops HelpBetweenServices AdvanceFollowingService AdvanceHeadServiceStart LineHeadRetention GetServiceFromAnotherLine

Modelo de conocimientoPredicados 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 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.

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

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.