1

Capítulo 1

INTRODUCCIÓN

Un reporte de la United Nations Conference on Trade And Development (UNCTAD) del año 2005 [1]

situó a Chile en el Top 20 mundial en tráfico marítimo de contenedores, traspasando en el 2003, los 1.2 millones de TEUS (twenty foot equivalent units, unidad de medida de un contenedor) transportados, siendo superado en América Latina sólo por Brasil. Ese mismo año, el puerto de San Antonio alcanzó el top 12 de puertos de América Latina y el Caribe, alcanzando los 0.52 millones de TEUS anuales. Sin embargo, si bien la cantidad de tráfico de TEUS ha ido en aumento, el porcentaje de variación año a año ha ido disminuyendo, desde un 8.1% en 2001-2002, a un 7% en 2002-2003 y se espera que esta tendencia se mantenga en los años que vienen. Esto último debido en gran parte al escenario económico mundial.

Lo anterior, nos revela la importancia que significa el tráfico marítimo para nuestro país y para el mundo,

y el enorme potencial de desarrollo que implicaría si esa tendencia de disminución de tráfico lograra revertirse, teniendo como principal arma la optimización de los procesos asociados, de manera de poder sacar ventaja competitiva en el mercado. No es nada sencillo. Por cierto, las operaciones involucradas en el tráfico marítimo y específicamente en las labores realizadas en los puertos, están dentro de las más complejas en la industria del transporte. Esto, básicamente por tres razones: el amplio espectro de entidades involucradas, la interacción con un ambiente altamente dinámico y la naturaleza distribuida propia del problema. [2]

De la vasta cantidad de problemas presentes en la logística portuaria, existe uno referido como el Berth

Allocation Problem (BAP), que se puede definir como un problema de planeamiento táctico, en donde el objetivo es asignar, idealmente de manera óptima, el posicionamiento de barcos dentro del puerto para su carga/descarga, de manera de minimizar los costos de movimiento de los contenedores dentro del puerto.

Figura 1 – Etapas de resolución del BAP.

2

El problema en la forma más completa, contempla dos etapas, como muestra la Figura 1. Una primera etapa de asignación de los barcos a cada sección del puerto y luego una segunda etapa, de “empaquetamiento” de cada barco en el espacio temporal de las distintas secciones. Este proyecto contemplará sólo el problema visto desde el punto de vista de la segunda etapa, considerando la presencia de solo una sección en el puerto.

Tomando en cuenta la complejidad del problema, su naturaleza distribuida y dinámica como se ha

expuesto anteriormente, este proyecto argumentará el uso de una arquitectura multiagente para el desarrollo de un sistema flexible, adaptable y robusto, que brinde una solución que apoye a entregar una mejor “calidad de servicio”, más que intentar obtener una solución al problema cercana a lo óptimo.

1.1 Definición de objetivos

Para darle foco al desarrollo de este trabajo, se han definido los siguientes objetivos:

1.1.1 Objetivo general

Desarrollar un sistema basado en una arquitectura multiagente (MA) para la resolución del Berth Allocation Problem (BAP).

1.1.2 Objetivos específicos

Como objetivos específicos, en los que se puede desglosar el objetivo general, figuran:

• Analizar en profundidad el problema de BAP, conociendo sus características específicas. • Investigar a fondo la arquitectura MA, comparándola con otras aplicables al problema. • Obtener una visión del estado del arte del problema. Experiencias anteriores, implementaciones y

resultados. • Estudiar y documentar los requerimientos propios de una implementación del sistema en el país. • Generar el diseño detallado de la solución, con la documentación respectiva. • Validar, implementar la solución e iterar sobre el proceso según sea necesario. Proponer futuras

mejoras.

1.2 Estructura del documento

El contenido de este documento es el resultado de una investigación analítica y una posterior implementación de una solución, teniendo en mente los objetivos presentados anteriormente. Esta estructurado en capítulos y de la siguiente forma.

El capítulo 2 presenta la tecnología de agentes, partiendo por la definición de agente, las arquitecturas para su construcción, las arquitecturas multiagentes, la forma en que los agentes se comunican y se coordinan, las principales metodologías de desarrollo de los sistemas multiagentes y algunas aplicaciones de ellos.

En el capítulo 3 se profundiza en el Berth Allocacion Problem, presentando lo que se puede encontrar en la literatura sobre él y sus principales variantes. Se presentan además algunos modelos matemáticos del problema. Culmina el capítulo presentando distintas alternativas que se han hecho en materia de multiagentes para el BAP.

3

El capítulo 4 expone la especificación funcional y diseño técnico del sistema, donde se muestran los detalles de qué debe realizar el sistema y cómo lo debe realizar, mediante la exposición de distintos modelos realizados siguiendo la metodología adoptada y la presentación del algoritmo de inserción.

En el capítulo 5, se muestran los resultados de la implementación. Se muestran los agentes

implementados, sus métodos y la forma en que van a interactuar. Además se presenta el algoritmo de inserción que es la base para obtener la solución del sistema.

En el capitulo 6 se analizan los resultados obtenidos de la simulación, mostrando los detalles de las pruebas y los gráficos de salida.

Por último, en el capítulo 7 se concluyen las ideas principales como resultado del trabajo. Finalmente

las referencias son encontradas en el Capítulo 8.

4

Capítulo 2

TECNOLOGÍA MULTIAGENTES

En este capítulo, se presentan los agentes y sistemas multiagentes, sus definiciones y características de arquitectura e interacción y metodologías de desarrollo y aplicaciones.

2.1 Definición de un agente

En la literatura, no existe una definición exacta de lo que es un agente. Basta tomar el diccionario de la RAE [5] para dar con distintos significados, entre ellos: “persona o cosa que produce un efecto” o “persona que obra con poder de otra” pero si bien el debate sobre aquella definición continua, se ha podido llegar a un acuerdo sobre ciertos criterios que permitan al menos distinguir lo que es un agente de lo que no es, brindando un modelo razonable de sus características y de su comportamiento.

Una de las definiciones más citadas es la de Wooldridge [6]: “un agente es un sistema informático

situado en un entorno y que es capaz de realizar acciones de forma autónoma para conseguir sus objetivos de

diseño”. Si bien esta definición identifica algunas características de un agente, no es claramente distinguible con la de un sistema distribuido convencional. Sin embargo, esta definición menciona la principal característica en la que existe consenso: autonomía. En el resto, suele haber muy poco acuerdo, pues muchas de las características tienen distinta importancia para dominios distintos. Por ejemplo, la característica de aprender puede ser deseable para cierta aplicación, mientras que para otra no solo poco importante, sino incluso indeseable.

A pesar de las diferencias, nos podemos olvidar de una definición exacta, para definir ciertas

propiedades comunes, como:

• Autonomía: agentes tienen capacidad de selección de tareas, priorización, comportamiento orientado a objetivos, y capacidad de decisión sin intervención humana.

• Persistencia: el código no es ejecutado por demanda, pero corre continuamente y decide por sí mismo cuando debe realizar alguna tarea.

• Habilidad social: pueden “contratar” a otros componentes, mediante cierta comunicación y coordinación, y cooperar en la resolución de alguna determinada tarea.

• Reactividad: pueden percibir el contexto donde operan y reaccionar apropiadamente.

Figura 2 - Categorización de los agentes software [7]

5

2.2 Arquitecturas para construir agentes

A continuación se exponen los tres grandes tipos de arquitecturas para construir agentes, las deliberativas, las reactivas y por último las híbridas que resultan ser una mezcla de las dos anteriores.

2.2.1 Deliberativas

Estas arquitecturas utilizan modelos de representación simbólica del conocimiento, donde sus

agentes son capaces de generar planes desde un estado inicial para lograr sus objetivos. Para esto, se acepta la idea que los agentes cuenten con un sistema de planificación que determine los pasos a seguir. Por tanto cada agente deliberativo cuenta con un modelo simbólico de su entorno, que le permite tomar decisiones a través de un razonamiento lógico basado en la correspondencia de patrones y la manipulación simbólica.

Un par de ejemplos de este tipo de arquitecturas son:

• Arquitectura BDI (Belief, Desire, Intention): en esta arquitectura [8], los agentes cuentan con

distintos estados mentales como creencias, deseos e intenciones. Básicamente, la creencia representa el conocimiento del agente, el deseo representa sus objetivos y la intención le brinda deliberación. Esta arquitectura ha tenido gran éxito y puede deberse al hecho de que combina un modelo filosófico del razonamiento humano fácil de comprender, posee un número razonable de implementaciones y una semántica lógica abstracta y elegante.

Figura 3 – Arquitectura BDI [8]

6

• Arquitectura Abstracta: esta arquitectura [9], se basa en lo tres estados mentales mencionados en BDI, pero con una construcción de una estructura de datos dinámica de comportamiento FIFO por cada uno de los componentes BDI. Esto último para poder lograr cumplir con la reactividad que debe poseer el agente para garantizar una reacción en tiempo real ante un entorno cambiante, y que no se lograría con una implementación basada en métodos tradicionales como la demostración de teoremas. Se trabaja además con una secuencia de eventos ocurridos en el entorno.

2.2.2 Reactivas

Esta arquitectura nace luego de numerosos estudios que intentaban dar con modelos más efectivos de representación de conocimiento y así solucionar los numerosos problemas asociados al uso de una representación simbólica. Ésta se caracteriza por no poseer como elemento central de razonamiento un modelo simbólico y por no utilizar además, un razonamiento simbólico complejo.

Un ejemplo de este tipo de arquitectura es la arquitectura de subsunción [10]. Ésta se basa en las

hipótesis de que la inteligencia es una propiedad emergente en ciertos sistemas complejos y por tanto se puede generar comportamientos inteligentes sin necesidad de construir un modelo simbólico, sino mas bien mediante una jerarquía de tareas organizadas en capas de distinto grado de abstracción, que permiten definir un comportamiento.

Aplicaciones de este tipo de arquitecturas se pueden encontrar vastamente en el campo de la robótica,

pues estos pueden ser considerados como agentes reales (físicos) que realizan labores dentro de un entorno cambiante, por tanto las necesidades de adaptación y replanificación continuas, hacen de esta arquitectura una posibilidad mucho más adoptable que una arquitectura deliberativa.

2.2.3 Híbridas

Las arquitecturas híbridas nacen de las limitantes que poseen ambas arquitecturas descritas anteriormente. Es por esto, que se origina este tipo de arquitectura que busca combinar aspectos de ambos modelos: deliberativos y reactivos. Resultan ser propicias, dado su naturaleza, a la estructuración por capas, que puede ser vertical si solo una capa tiene acceso a los sensores y actuadotes; u horizontal, en donde todas las capas tiene el acceso.

Al igual que en las arquitecturas de subsunción, en estas se origina una jerarquía de capas con

información del entorno, pero con distinto grado de abstracción. Generalmente se encuentran tres niveles que resultan ser suficientes: Reactivo, o de más bajo nivel, que reacciona a los estímulos del entorno, y que suele implementarse con una arquitectura de subsunción; Conocimiento, o nivel intermedio. Posee información del medio generalmente a través de una representación simbólica; y Social, o de alto nivel. En esta se manejan los aspectos sociales tanto del entorno como de los otros agentes presentes.

2.3 Sistemas Multiagentes

Las arquitecturas multiagentes nacen de la necesidad de desarrollar aplicaciones complejas

compuestas por un sinnúmero de subsistemas que por supuesto interaccionan entre si para lograr distribuir la inteligencia entre diversos agentes, dando origen a la creación de sistemas multiagentes (MAS). El empleo de una arquitectura multiagente aparece como una solución apropiada cuando estamos en presencia de problemas físicamente distribuidos, o donde se requiera de experiencia heterogénea para su solución o cuando el problema en cuestión se define sobre una red de computadores. El uso de una arquitectura MA aparece en estos casos como la más adecuada en crear una solución distribuida, adaptable a cambios estructurales y de

7

entorno. Además, una metodología asociada permitirá construir un sistema total a partir de distintas unidades autónomas.

En un MAS, se definen subsistemas con capacidad de decisión local absoluta, y por tanto una

definición de políticas que permitan cooperar, negociar y coordinar sus acciones es completamente necesaria. Las siguientes, son en general características de un MAS cooperante:

• Formado por un grupo de agentes autónomos en cuanto a sus habilidades de adquisición de datos, comunicación, planificación y actuación.

• Un MAS persigue un objetivo común. Debe para esto, y con ese objetivo en mente, asignar una o varias tareas independientes a distintos componentes, permitiendo su ejecución en paralelo.

• Cada agente posee un conocimiento limitado del entorno, del objetivo global y de las intenciones de los demás agentes.

• Cada agente es especializado en lo que debe hacer, en función de lo que conoce, la capacidad de proceso y la habilidad requerida.

El hecho de distribuir las acciones permitirá que cada agente mantenga su autonomía, que se elimine

el que un sólo agente posea toda la información, que se logre descentralizar las decisiones, aun cuando puede existir un agente de mayor “importancia” y por ende de mayor “influencia” en las acciones. Esto permite obtener una solución más robusta y permite una adaptación a cambios del entorno en tiempo real, mediante acciones coordinadas. Con respecto a esto último, la comunicación es otro aspecto a considerar. Definir el proceso de comunicación en términos de qué y el cómo es parte vital en la creación de un MAS.

Si de análisis organizacional se trata, en la definición de un MAS, se deben considerar tres tipos:

• Análisis funcional: el que permite describir las distintas funciones del MAS en sus variadas dimensiones.

• Análisis estructural, el cual intenta ordenar el conjunto de interacciones entre agentes,

analizando su relación abstracta y la evolución de ésta en el tiempo.

• Análisis de parámetros concretos, que toma en cuenta los detalles que surgen en el paso de una estructura abstracta a una concreta de agentes.

En esta parte del desarrollo, el análisis se realiza bajo dos perspectivas: vertical, en donde se analiza la descomposición de las funciones; y la horizontal, en donde se describen las funciones que son compartidas por los agentes.

Luego de realizado esto, se puede llegar al análisis de las relaciones abstractas, las cuales pueden ser

dinámicas o estáticas, que describen las formas de interacción entre distintas clases de agentes y que se pueden encontrar de los siguientes tipos:

• Relación de conocidos: relación mínima, en donde ambos poseen una representación del

otro y su dirección. • Relación de comunicación: se indica que se pueden enviar mensajes entre un agente y otro. • Relación de subordinación: describe la transferencia de una tarea entre dos agentes. • Relación operativa: representa una dependencia operacional entre un agente y otro. • Relación de información: valida la dependencia entre lo que un agente conoce gracias a

otro, generando un lazo de confianza. • Relación de conflicto: refleja la necesidad de negociación entre dos agentes que tienen

acceso a recursos compartidos. • Relación competitiva: indica una incompatibilidad de objetivos entre dos agentes.

8

Además de existir el análisis funcional y estructural, existe también el análisis de la distribución de habilidades entre agentes, la cual depende fundamentalmente del tipo de problema en cuestión. Esta distribución se realiza bajo dos índices: el grado de especialización y el grado de redundancia. A partir de estos índices se pueden identificar cuatro casos extremos: organización no redundante e hiperespecializada; organización redundante y especializada; organización redundante y general; y por último, una organización no redundante y general.

2.4 Arquitectura FIPA

Esta arquitectura nace de la necesidad de contar con estándares para facilitar la aplicabilidad de la tecnología de agentes, resolviendo para esto los problemas de interoperabilidad (integración de sistemas basados en la tecnología) y de apertura (posibilidad de extensión). FIPA es el acrónimo de Foundation for

Intelligent Physical Agents [11], y resulta ser la organización que más ha trabajado en el tema. En sus especificaciones se definen las características que deben cumplir las plataformas de gestión de sistemas multi-agentes, aunque a la hora de definirlas se ha centrado únicamente en definir el comportamiento externo (interfaz), dando libertad a cada equipo de desarrollo de decidir acerca el diseño.

La Plataforma de Agentes, es el núcleo de FIPA y proporciona la infraestructura para el desarrollo y uso de agentes tanto de hardware como software (sistema operativo, software de comunicaciones, middleware y software de gestión de agentes). Los componentes de la plataforma presentes en la Figura 4, son los siguientes:

• Sistema de Gestión de Agentes (AMS): Es el elemento de gestión principal, el cual conoce en todo

momento el estado de su plataforma y de los agentes que pertenecen a ella. Ofrece servicios de gestión del ciclo de vida de los agentes. Además permite registrar nuevos a la plataforma, y ofrece también un servicio de nombres (ANS) para conocer el nombre y dirección de cualquier agente.

• Facilitador de Directorio (DF): Apoya al ANS dando la posibilidad de buscar un agente no solo por

su nombre, sino por los servicios que ofrece.

• Sistema de Transporte de Mensajes (STM): este componente se encarga de gestionar el envío de mensajes entre agentes ubicados en plataformas distintas. Para comunicación remota, se envía el mensaje del STM “emisor” al STM “receptor” en forma asíncrona.

Figura 4 – Modelo de Arquitectura FIPA

9

Pirámide de lenguajes de la WEB Semántica

XML

RDF(S)XOLSHOE

OIL DAML + OIL

OWL

Cada uno de estos componentes o servicios serán suministrados por agentes especializados, lo que implica que la comunicación entre ellos será a través de mensajes ACL que se verán más adelante. Además el estándar define que debe existir un sistema encargado del transporte de mensajes (Internal Platform Message

Transport).

2.5 Infraestructura de agentes

La infraestructura de agentes es un aspecto básico a considerar dentro de una arquitectura multiagente, pues es la que me permitirá definir las regulaciones que deben cumplir los agentes para comunicar y entenderse. Estas regulaciones se componen de tres tipos:

• Ontologías: se preocupa de brindar un significado común de los conceptos para lograr acuerdo y entendimiento entre los agentes.

• Lenguajes de Comunicación (ACL’s): permite a los agentes comunicar y entenderse a través del

intercambio de mensajes, mediante protocolos de comunicación definidos.

• Protocolos de Interacción (AIP’s): Proporcionan convenciones para las interacciones entre agentes, las cuales permiten a estos poder conversar, es decir intercambiar mensajes estructurados.

2.5.1 Ontologías

Una ontología corresponde a un modelo que determina una comprensión compartida de un cierto dominio de interés, y define conceptos de un dominio en particular (visión de mundo), la cual puede ser entregada en forma de lenguaje natural, lo que resultaría en una definición informal. Para poder darle formalidad a esta definición, se debe ocupar un lenguaje de formulación de ontología. Estos deben cumplir con permitir compartir ontologías, considerar el ciclo de evolución de ellas, apoyar la interoperabilidad, detectar inconsistencias y brindar expresividad. La figura 5 muestra los lenguajes de ontología más comunes.

Generalmente una ontología posee: • Clases: elementos generales en los dominios interesados. • Propiedades: cualidades de estas clases. • Relaciones: interrelaciones entre los elementos (clases) involucrados.

Figura 5 – Pirámide de lenguajes de la Web Semántica

10

• XOL: Ontology eXchange language, US bioinformatics community. • SHOE: Simple HTML. Ontology extension, university of Maryland. • OML: Ontology markup language, university of Washington. • DAML: DARPA Agent Markup Language, DARPA project. • OIL: Ontology Interchange Language, OntoKnowledge project. • DAML + OIL: W3C • OWL: Web Ontology Language, W3C.

2.5.2 Lenguajes de Comunicación entre Agentes

Una segunda parte importantísima dentro de los agentes, corresponde a la necesidad cierta de entender y ser entendido por otros, objetivos básicos de toda comunicación, la que en definitiva posibilita su interoperación. Dentro del estudio de la comunicación podemos encontrar tres aspectos relacionados:

• Sintaxis, que define la estructura de los símbolos de la comunicación. • Semántica, que indica qué cosas los símbolos denotan. • Pragmática, indica cómo se deben interpretar estos símbolos.

El significado incluye tanto la semántica como la pragmática. Muchos investigadores se han equivocado al referirse al lenguaje sólo como una forma de describir el estado del mundo, cuando lo cierto es que a diario las personas realizan comentarios en donde no describen un acto, sino lo realizan (por ejemplo “le pido disculpas”). A estas declaraciones se les llama performativas [12]. En éstas, es posible distinguir:

• Locución: la uterancia de lo comunicado (hablado o escrito). • Ilocución: lo que la performativa realiza. • Perlocución: el efecto causado en el receptor.

Para la comunicación, la FIPA define el Agent Communication Language (ACL). Éste define la

estructura que deben tener los mensajes que se envíen los distintos agentes. Un mensaje que ocupe este estándar contiene un conjunto de uno o más elementos de mensaje, de los que sólo el elemento “Performative” es obligatorio de incluir, pues define el tipo de acto comunicativo del mensaje. Una lista de los elementos de los mensajes ACL se puede ver en la Tabla 1.

Elemento del mensaje Categoría de elementos

Performative Tipo de acto comunicativo Sender Participante en la comunicación Reciever Participante en la comunicación Reply-to Participante en la comunicación Content Contenido del mensaje Language Descripción del contenido Encoding Descripción del contenido Ontology Descripción del contenido Protocol Control de la conversación Conversation-id Control de la conversación Reply-with Control de la conversación in-reply-to Control de la conversación

Reply-by Control de la conversación

Tabla 1 – Elementos de mensaje de FIPA ACL

11

Existe también un segundo estándar llamado Knowledge Query Manipulation Language (KQML), el cual es muy similar en sintaxis a ACL, pero su ventaja es que posee mecanismos que permiten traducción semiautomática desde y hacia los principales lenguajes de representación de conocimiento, como Prolog. La Tabla 2 muestra los elementos de un mensaje KQML.

Elemento del mensaje Descripción

:sender Nombre del emisor del mensaje :reciever El receptor del mensaje :in-reply-to La etiqueta para la respuesta a un mensaje anterior :reply-with Si el emisor espera respuesta, la etiqueta para dicha respuesta :language Nombre del lenguaje de representación del parámetro :content :ontology Nombre de la ontología usada en el parámetro :content

:content Información sobre la que la performativa expresa una actitud

Tabla 2 – Elementos reservados de un mensaje KQML

2.5.3 Protocolos de Interacción

La estructura de la comunicación entre agentes con frecuencia corresponde a patrones típicos de secuencias de mensajes, a los cuales se les denomina protocolos de comunicación o interacción (interaction protocols o IP). Para esto, FIPA ha definido igualmente ciertos protocolos (como el FIPA IPL, Interaction Protocol Library) que así como todas las recomendaciones FIPA, está abierta a que cada diseñador añada sus propios protocolos.

FIPA para definir estos protocolos ocupa una notación llamada AUML que se basa en diagramas de UML, para dar origen a los diagramas de protocolo. En estos se pueden encontrar:

• Roles de los agentes: identifican el papel de cada agente dentro de la comunicación. Su notación corresponde a un rectángulo con el nombre del rol o roles.

• Línea de vida: define el tiempo de participación de un agente en la comunicación. • Hilos de interacción: muestra el período de tiempo en el que un agente realiza una tarea como

reacción a un mensaje entrante. Se representa como un rectángulo alargado dibujado sobre la línea de vida.

• Mensajes: Es la acción de comunicación entre un agente y otro, representada por una flecha horizontal etiquetada con el nombre del acto comunicativo.

La Tabla 3, nombra los distintos protocolos de comunicación del estándar FIPA, junto con una descripción.

12

Nombre

protocolo Descripción

Request A un agente se le pide que realice cierta acción.

Request when A un agente se le pide que realice cierta acción siempre que cumpla la precondición. Query A un agente se le pide que informe sobre algo.

Contract Net

Un agente pide la realización de cierta tarea a un conjunto de agentes. Estos dan su propuesta basada en unos costos y el iniciador elige quién la realiza finalmente.

Brokering

Un agente (broker) ofrece las funcionalidades de otros agentes o reenvía las peticiones al agente apropiado

English

auction

Varios agentes participan en una subasta que se inicia con un precio más bajo y progresivamente se va subiendo.

Dutch auction

Varios agentes participan en una subasta que se inicia con un precio más alto y progresivamente se va bajando.

Recruiting

Es como el brokering, pero las respuestas sobre el servicio van directamente al agente que lo necesita (no a través del broker).

Propose

El iniciador propone a una serie de agentes la realización de una tarea y estos aceptan o no.

Subscribe Un agente pide ser notificado si cierta condición se vuelve verdadera.

Tabla 3 – Protocolos de comunicación estándar FIPA

2.6 Metodologías de Desarrollo

Toda tecnología de desarrollo de software necesita de metodologías y herramientas que guíen el proceso, y la tecnología de agentes no es la excepción. Existen variadas metodologías para el desarrollo de sistemas multiagentes y mucho se habla de la relación que tienen con las orientadas a objetos. Lo cierto es que se parecen bastante, y muchas de las metodologías de desarrollo de agente adaptan algún modelo orientado a objetos, generalmente el Proceso Unificado [13]. Incluso, últimamente están apareciendo propuestas para aplicar metodologías ágiles, como eXtreme programming [14]. En el modelado con agentes, la gran mayoría de las metodologías proponen hacerlo desde diversos puntos de vista complementarios, a fin de poder gestionar de mejor manera la complejidad del sistema multiagente. A continuación se expondrán algunas metodologías utilizadas, en función de los puntos de vistas que utilizan:

2.6.1 Metodología AAII/BDI

Esta metodología, considera y refina dos puntos de vista, externo e interno, desarrollados con anterioridad por el Instituto de Inteligencia Artificial Australiano [15]. El proceso consta de considerar en primer lugar el desarrollo del punto de vista externo en donde se intenta identificar la jerarquía de clases de agentes (el modelo de agentes) y un conjunto de relaciones entre agentes (el Modelo de Interacciones), seguido del desarrollo del punto de vista interno, basado en esta metodología por el modelo BDI, buscando encontrar el Modelo de Creencias, el Modelo de Objetivos, y el Modelo de Planes, los que describirán el

13

comportamiento de cada uno de los agentes. Esto se utiliza a la vez para realimentar los modelos externos dando origen a un proceso iterativo.

2.6.2 Ingeniería de las Vocales

Esta metodología propone considerar cinco puntos de vista, que corresponden a las vocales: Agente,

Entorno, Interacciones, Organización y Usuario. Para cada uno de estos aspectos es posible aplicar diferentes técnicas. Por ejemplo, los Agentes pueden concebirse como autómatas o complejos sistemas. Las Interacciones pueden considerar modelos físicos. Las Organizaciones pueden aplicar modelos biológicos o normas de modelos sociológicos. El objetivo de esta metodología es poder considerar librerías de componentes que den soluciones para cada uno de estos aspectos, permitiendo instanciar cada modelo de Agentes o modelo de Organización, por ejemplo.

Además, se propone considerar las vocales (aspectos) en un orden distinto según la necesidad de cada sistema que se desarrolla. Si en el sistema a desarrollar, las relaciones sociales son el aspecto más importante, entonces el proceso de desarrollo debería comenzar con el modelo de Organización.

2.6.3 MAS-CommonKADS

Esta metodología se basa en la llamada CommonKADS para el desarrollo de sistemas de gestión del conocimiento [16], en la que ya se tenían en cuenta varios puntos de vista, considerando seis modelos:

1. La organización en la que trabaja el sistema de gestión del conocimiento. 2. Tareas 3. Agente, refiriéndose al sistema experto. 4. Comunicaciones, especialmente entre el agente y el usuario 5. Experiencia, que incluye el conocimiento del dominio y conocimiento de resolución del problema. 6. Diseño, esencialmente la arquitectura del sistema de gestión de conocimiento.

La propuesta se combina con CommonKADS, incorporando la utilización de una notación orientada

a objetos para estructurar el MAS, la definición de casos de uso para la captura de requisitos, y técnicas de ingeniería de protocolos para especificar las interacciones entre lo agentes.

2.6.4 MESSAGE e INGENIAS

MESSAGE (Methodology for Engineering Systems of Software Agents) [17], es una metodología que incorpora técnicas de ingeniería de software cubriendo el análisis y diseño de sistemas multiagentes. También provee un lenguaje, un método y unas guías de cómo aplicar la metodología, tiene muy bien definidas las etapas de análisis y diseño, pero ayuda con unas pocas líneas las otras fases de implementación, pruebas y puesta en marcha. La metodología INGENIAS considera por su parte, cinco puntos de vista para el modelado de un MAS: Agente, Organización, Entorno, Tareas y Objetivos, e Interacciones.

2.6.5 MASSIVE y ODAC

Son metodologías que consideran modelar un MAS a través de varios puntos de vista. MASSIVE considera siete: entorno, tareas, roles, interacciones, sociedad, arquitectura y sistema. ODAC considera cinco: empresa, información, computacional, tecnología e ingeniería. Estos puntos de vista los toma del estándar Open Distributed Processing, ODP [18].

14

2.6.6 GAIA

La metodología GAIA [19] considera un sistema basado en agentes como una sociedad u organización. Ésta consta de una colección de roles, con cierta relación entre sí y que toman parte en patrones de interacción institucionalizados con otros roles. A su vez, cada rol se define por cuatro atributos: Responsabilidades, Permisos, Actividades y Protocolos.

El análisis de la metodología consiste en: Identificar roles; para cada rol identificar y documentar los protocolos asociados; a partir de la información anterior, se elabora el modelo de roles. Se iteran estos pasos según sea necesario. El diseño produce tres modelos: Modelo de Agente; Modelo de Servicios y Modelo de Conocidos.

2.6.7 MaSE

La arquitectura MaSE (Multi-agent Systems Software Engineering) [20] a diferencia de otras, como la de GAIA, involucra a todo el ciclo de desarrollo, desde la descripción del problema hasta la implementación. Ocupa UML como notación, y adopta el paradigma de orientación a objetos, considerando a los agentes como una especialización de ellos, refiriéndose a ésta como la capacidad de coordinación de los agentes y su naturaleza preactiva. En MaSE, como otras, considera importante la asignación de roles, a partir de los cuales se estudian las interacciones y tareas concurrentes que determinarán los tipos y estructuras de los agentes del sistema.

2.6.8 Passi

La metodología PASSI [41] es una metodología muy interesante, la cual se compone de cinco

modelos, como se puede ver en la figura 6. Dichos modelos brindan información respecto al diseño desde distintas vistas y doce pasos para obtener un modelo completo de un sistema multiagente.

Esta metodología utiliza el lenguaje UML, específicamente la variante de AUML, como lenguaje de

modelado debido a su aceptación masiva tanto en ambientes industriales como académicos.

Figura 6 – Elementos de la metodología PASSI

15

En donde:

• D.D: Domain Description

• A.Id.:Agents Identification

• R.Id.:Roles Identification

• T.Sp.:Task Specification

• A.S.D.:Agents Structure Definition

• A.B.D.:Agents Behaviour Description

• D.O.D.:Domain Ontology Description • R.D.:Roles Description • P.D.:Protocols Description • C.R.:Code Reuse • C.C.:Code Completion • D.C.:Deployment Configuration

Con respecto a los cinco modelos y sus fases, estos se pueden detallar a continuación:

Modelo de requerimientos del sistema: consiste en la representación de los requerimientos en base a la identificación de agentes y objetivos. Sus fases son:

• Descripción de dominio: una descripción funcional del sistema representado en casos de uso. • Identificación de agentes: la separación de las responsabilidades vistos como paquetes de agentes. • Identificación de roles: mediante diagramas de secuencia se intenta identificar los distintos roles que

adopta cada agente en cada escenario. • Especificación de tareas: describir las capacidades de los distintos agentes mediante casos de uso y

descripciones auxiliares Modelo de sociedad de agentes: es un modelo de las interacciones sociales y dependencias entre agentes involucrados en el sistema. Los pasos de este modelo son tres, sumados a un paso del modelo anterior: • Identificación de roles: del modelo anterior • Descripción de la ontología de dominio: se definen los conceptos, mediante diagramas de clases, que

generan la base conocimiento que poseen los agentes sobre el dominio del sistema. • Descripción de roles: se muestran los distintos roles jugados por los agentes, las tareas involucradas

a estos roles, las capacidades de comunicación y la interdependencia entre los agentes. • Descripción de protocolos: la descripción de la gramática de los distintos protocolos de

comunicación utilizados

Modelo de implementación de agentes: un modelo de la arquitectura de la solución en términos de clases y métodos. Incluye dos pasos: • Definición de estructuras de agentes: se definen estas estructuras mediante el uso de diagramas de

clases. • Descripción de comportamientos de agentes: se describen los comportamientos de los agentes

mediante diagramas de actividad.

Modelo de código: modelo del sistema a nivel de código, involucrando los siguientes dos pasos:

• Librería de reutilización de código: una librería de clases y diagramas de actividad con código reutilizable asociado.

• Bases completas de código: código fuente del sistema.

16

Modelo de deployment: un modelo con el detalle de las partes del sistema en donde se ejecutará el sistema, representado en unidades de hardware. Involucra un paso: • Configuración del deployment: mediante diagramas de deployment se asignan los agentes a las

distintas unidades de procesamiento y se establecen restricciones de movilidad.

Por último, debe considerarse que PASSI además es iterativo al igual que muchas de las

metodologías encontradas, con la diferencia que estas iteraciones no son secuenciales y de arriba-abajo como comúnmente se presentan. Éstas se presentan en dos formas asociadas a cambios en los requerimientos y la implementación del sistema multiagente, respectivamente. La Tabla 4, muestra un cuadro comparativo de algunas de las metodologías vistas.

Metodologías

Atributo Gaia MAS-C.Kads Massive MaSE Message

Fases consider AD AD ADI AD(I) AD

UML -

Empleo notación OO en algunas fases Sí Sí (UML+ OCL) Sí

Tipo Sistema Cerrado, no dinámico

Cerrado, no dinámico

Cerrado, no dinámico Cerrado, no dinámico No dinámico

Orientación - Ing. del Conocimiento

Iterative View Engineering Basada en el objetivo

Ing. Software + Teoría Agentes

Movilidad No No No No No

Tiempo Real No No No No No

Herramiento de desarrollo -

Sí, AgentEditor - Sí, AgentTool

Guía herramientas a emplear

Limitaciones Diseño Alto Nivel

Complejidad Common-KADS -

Max 10 clases de agentes -

Guías resto fases No Pequeños trazo -

Implementación en un futuro Sí

Características

Modelado de interacc. Independ.

Empleo KQML Empleo KQML

Independiente, no broadcast AUML

Arquitectura agente Independiente Independiente Independiente Independiente Según diseño

Tabla 4 – Cuadro comparativo de metodologías de desarrollo de agentes

2.7 Aplicaciones

En cuanto a aplicaciones en el área de los sistemas multiagentes, podemos encontrar un sinfín de ellas en distintos campos [42]. Es importante tener en cuenta que los agentes no son una panacea para el software industrial, y frente a cada problema en donde se piense utilizar la tecnología de agentes, es necesario tener ciertas consideraciones, antes de decidirse finalmente por el desarrollo en base a tal arquitectura. Como se ha visto, la naturaleza de los problemas en donde conviene utilizar agentes, generalmente reúne características de ser: modulares, descentralizados, cambiables, difíciles de estructurar y complejos.

17

En el último tiempo, la tecnología de agentes se ha estado aplicando en la integración de empresas de fabricación, en la gestión de la cadena de suministros, en el control de ejecución, en la planificación y asignación de tareas y recursos (scheduling), en el manipulado de materiales y en la gestión de inventario. A continuación, se listan sectores donde se ha aplicado la tecnología de agentes:

• Aplicaciones Industriales: Control, Scheduling y Planificación de la fabricación, Control Aéreo

(Oasis), Transporte Marítimo. • Aplicaciones en sector médico: HeCase • Recuperación de la información: Leticia, Amaltea,Citeseer, ExpertFinder. • Comercio Electrónico: Comprante, iBundler, MASFIT. • Telecomunicaciones: Gestión de redes, tecnología del habla, mejora procesos de negocios, etc.

18

Capítulo 3

EL BERTH ALLOCATION PROBLEM

En este capítulo se profundiza en la problemática del Berth Allocation Problem (BAP), centrándose en definir las variantes, los modelos matemáticos y los algoritmos de solución.

3.1 Descripción del problema

En el transporte marítimo de contenedores, el modelo “Hub and Spoke” [7] se adopta extensamente.

Los naves de alta mar, llamados también naves madre (mother vessels), funcionan entre un número limitado de terminales de trasbordo (hubs). Buques más pequeños (alimentadores) ligan los hubs a los otros puertos (spokes). Estos últimos años, las mother vessels han aumentado fuertemente de tamaño logrando transportar hasta 8000 “twenty foot equivalent units (TEU) y se planean tamaños más grandes. Los puertos de trasbordo son plataformas de transporte intermodal grandes y sólo un número limitado de ellos maneja una importante parte del tráfico mundial. Tanto así, que en 2002 los primeros 20 “puertos de contenedor” manejaron el 48% del tráfico total. Los barcos “ultra-grandes” de contenedor reducen costos de transporte. Sin embargo, los puertos hub son forzados a invertir pesadamente para acomodar estas naves aumentando el calado, ensanchando los canales y construyendo nuevas instalaciones de atraque de suficiente profundidad y longitud. Estas tendencias requieren una mejora continua en las prácticas de gestión de los terminales de trasbordo.

Ahora bien, cuando una nave llega un puerto, ésta debe esperar por un espacio para amarrarse en el muelle. Éste ultimo, para esto cuenta con distintas secciones de punto de atraque o “Berth”. Además, se cuentan con grúas gigantes (Gantry Cranes) para la carga/descarga, y vehículos más pequeños para el resto de las labores de traslado, como las grúas horquilla .Una vez atracado en el muelle, los contenedores destinados para el puerto deben ser descargados y los contenedores “nuevos” con dirección hacia otros puertos deben ser cargados antes de que la nave pueda reasumir su curso. Las demandas en tales puertos para que la estiba/desestiba se ejecute con un máximo de eficacia llegarán a ser mayores a medida que las compañías de transporte marítimo continúan aumentando el tamaño de sus flotas y según la capacidad de las nuevas naves que se vayan sumando.

El problema con este aumento es que las autoridades portuarias alrededor del mundo están

prediciendo que quedarán “cortos” de espacio para ampliar sus áreas operacionales. Por lo tanto, solucionar el problema quedaría por el lado de la reducción de la cantidad de tiempo que una nave necesita para permanecer en el muelle. La manera de hacer esto, es asegurarse que el proceso de asignación de sitio de atraque y los procesos posteriores de desestiba/estiba de la carga se realice lo más rápido posible, y esto puede ser alcanzado asegurándose que la asignación de recursos necesarios para estos procedimientos funcione en un nivel óptimo. Es claro que lograr lo anterior es de una alta complejidad, puesto que las operaciones portuarias involucran diversas entidades y problemas asociados a cada una de las operaciones.

La logística que implica planear el atraque de las naves/contenedor recibe el nombre de Berth

Allocation Problem (BAP). En el BAP, la gestión del puerto debe tratar de que:

1. Las naves atraquen lo antes posible para asegurar una rápida rotación. 2. Las grúas horquilla carguen/descarguen los contenedor necesarios en el menor tiempo

posible 3. El costo del trasbordo de contenedores sea mínimo.

19

Bajar el costo de trasbordo tiene vital importancia porque la mayoría de los contenedores descargados van a ser transferidos a otras naves. Si se atracan muy lejos, el costo variable del trasbordo crece en proporción con la distancia que deben viajar dentro del terminal. Cuando la gestión del puerto atraca las naves que intercambian muchos contenedores cerca el uno del otro, las distancias de recorrido y el costo del trasbordo descienden. Si no ha llegado el barco receptor, estos contenedores deben ser puestos en áreas de almacenamientos temporales considerando, en lo posible, la eventual posición de atraque a futuro de la nave entrante. Este problema, en la literatura recibe el nombre de Strategic Yard Allocation Problem (SYAP) [4]. Un problema recurrente asociado a éste último, tiene que ver con la asignación de las grúas horquillas a cada una de las naves que llegan, que está directamente asociado al tiempo de manejo y produce un fuerte impacto en el BAP, conocido como el Crane Scheduling Problem [21].

Existen en la actualidad tecnologías avanzadas de comunicación e información que atacan el

problema, y el paso siguiente será la introducción de técnicas modificadas para requisitos particulares de optimización. Cada terminal marítimo es distinto a otro, por tanto la “costumización” para cumplir con requisitos particulares es un factor preponderante. La intención del proyecto, en primera instancia, es poder abordar el problema desde una visión más genérica, pero teniendo en cuenta la posibilidad de “customizarlo” para implementaciones en terminales del país, siempre que sus requisitos no involucren modificaciones tan críticas. La Figura 7 muestra el layout del puerto de Valparaíso, el cual representa uno de los terminales más importantes del país donde eventualmente podría aplicarse la solución.

Figura 7 – Layout Puerto Valparaíso

20

El problema se puede representar en un espacio de dos dimensiones como muestra la Figura 8, donde los rectángulos simbolizan las naves cuyas dimensiones son la longitud de la nave, incluyendo un margen de seguridad, y el tiempo de “manejo”. Estos rectángulos deben posicionarse en el espacio de decisión sin traslaparse y satisfacer ciertas restricciones. En la dimensión espacial, se dan restricciones relativas a la profundidad del agua (calado permitido) y a la distancia máxima en relación a la localización más favorable a lo largo del muelle, calculado respecto de la localización de los contenedores de salida y del espacio reservado para los de entrada. En la dimensión temporal las restricciones se expresan como ventanas de tiempo. Algunas de ellas son suaves y pueden ser relajadas mediante un costo de penalización apropiado.

Figura 8 – BAP, representación bidimensional (Tiempo vs Espacio).

3.2 Literatura del problema y variantes

En la literatura, podemos encontrar diversos estudios de distintos grupos acerca del problema, lo que se ha traducido en distintas variantes sobre el problema en términos de enfoque y restricciones. En primer lugar, el BAP puede modelarse en un caso discreto si el muelle es visto como un conjunto finito de puntos de atraque (berths). En este caso, los berths se describen como segmentos de longitud fija, o si se ignora la dimensión espacial, como puntos. Cuando se considera que la longitud de los barcos es muy variable, se podría dividir el muelle en secciones para poder hacer la asignación, aunque resultaría difícil, pues los requerimientos variarían dinámicamente. Si se segmenta muy grande, en ciertos casos se subutilizaría el espacio mientras que segmentos más pequeños dificultarían encontrar soluciones factibles. Para superar esto, se considera un modelo dinámico, el cual define que los barcos pueden atracar en cualquier lugar del muelle. Para el caso discreto, el BAP puede ser modelado como un problema de scheduling en máquinas paralelas no relacionadas (Unrelated Parallel Machine Scheduling) [22], donde cada barco es visto como un trabajo y cada punto de atraque como una máquina. El tiempo de llegada de cada barco es el “release time”

21

del trabajo. En el caso continuo, el BAP es un problema bidimensional del Cutting Stock Problem con restricciones adicionales. En cualquiera de los dos casos, BAP resulta ser de complejidad NP-Hard [23]. Para el BAP, en [24] se ha propuesto una formulación dinámica del BAP o Dynamic Berth

Allocation Problem (DBAP), en el cual se representa el muelle como sistema finito de puntos de atraque y la llegada de los barcos se considera en forma aleatoria. En otras palabras, la dimensión espacial de las naves y de los puntos de atraque no es considerada. Esta formulación se llama “dinámica” en comparación con la anterior llamada Static Berth Allocation Problem (SBAP) [25], la cual considera que todas las naves ya están en el puerto cuando los puntos de atraque están disponibles. El SBAP se puede resolver en tiempo polinómico con el método húngaro propuesto en [26], puesto que es reducible a un problema de asignación. Para el DBAP, los autores se aprovechan de esta característica y proponen una relajación Lagrangeana conveniente para llegar a un subproblema de asignación. Sus resultados de cómputo demuestran que DBAP es relativamente fácil de solucionar mientras los casos estén “cercanos” al caso estático, en el sentido de que la mayoría de las naves están ya en el puerto cuando los puntos de atraque comienzan a estar disponibles. La función objetivo es la suma de los tiempos de servicio de las naves y no se consideran la existencia de prioridad de ciertos barcos sobre otros. También en [27], se ha presentado un programa no lineal entero y un algoritmo genético basado en una distinta representación de la dimensión espacial en la cual el muelle es una colección de segmentos, en donde hasta dos naves pueden compartir un segmento al mismo tiempo siempre que las longitudes sean compatibles con la longitud del segmento. Restricciones adicionales relativas a la profundidad de los puntos de atraque son introducidas.

Luego, en [28] la formulación DBAP fue ampliada para considerar las prioridades de servicio que son manejadas introduciendo en la función objetivo un término que corresponde al tiempo del servicio. La prioridad, basada por ejemplo en el volumen, se puede también incorporar en el modelo. La formulación que resulta es no lineal. Los autores demuestran que con una relajación Lagrangeana conveniente se obtiene un subproblema de asignación cuadrática. Puesto que este problema no está bien solucionado por métodos exactos, los autores han desarrollado una heurística basada en algoritmos genéticos.

En [29] el muelle se representa como línea continua. Una heurística soluciona el problema de decidir los puntos de atraque dados los tiempos de llegada de las naves, asumiendo tiempos de procesamiento constantes. Este acercamiento no soluciona el problema general en el cual el tiempo de atraque es una variable de decisión y el tiempo de procesamiento varía a lo largo del muelle.

Más recientemente, en [30] se ha introducido un modelo no lineal de programación entera que

considera la asignación de “Quay Cranes”, y por último [31] ha formulado un modelo “mixed integer linear

programming” para el caso continuo. Una solución comercial es capaz de encontrar óptimos para instancias que consideran siete barcos y un horizonte de tres días. Se propone además, una heurística simulated

annealing para resolver instancias reales.

3.3 Formulación matemática

Para el proyecto, se han considerado distintas formulaciones para el caso discreto, en donde se trata

cada punto de atraque como un conjunto finito de puntos. En [32] podemos encontrar dos formulaciones: Relative Position Formulation (RPF) y Position Assignment Formulation (PAF). Luego en [3], encontramos dos formulaciones más: Dynamic Berth Allocation Problem (DBAP) y la asociación del BAP con una variante del VRP (Vehicle Routing Problem). Sobre esta última a continuación se hará una revisión en detalle.

En [3], se observó que el problema podía ser modelado como un Multi-Depot Vehicle Routing Problem

with Time Windows. En este modelo los barcos son vistos como clientes, y los puntos de atraque como depósitos en donde cada vehículo esta ubicado. Existen entonces m vehículos, uno para cada depósito. Además, cada vehiculo parte y termine el tour en su propio depósito. Los barcos son modelados como vértices de un multigrado. Cada depósito es dividido en vértices de origen y destino y ventanas de tiempo pueden ser consideradas en cada vértice. En el origen y destino, la ventana corresponde al período disponible de

22

determinado punto de atraque. Los datos de entrada son los mismos que los de DBAP, sumados a los siguientes:

• bi : límite superior de la ventana de tiempo de servicio en el barco i; • vi : el valor del tiempo de servicio para el barco i.

El problema se modela como un multigrafo Gk = ( Vk, Ak), ∀k ∈ M, donde Vk = N ∪ {o(k), d(k)} y

Ak ⊆ Vk x Vk.

Las siguientes variables y constantes son definidas:

• Xipk ∈{0.1} k ∈ M, (i , j) Ak , Xipk = 1, sí y sólo sí el barco j esta programado después del barco i en el punto de atraque k;

• Tik k ∈ M, i ∈ N : el tiempo de atraque del barco i en el punto de atraque k.

• To(k)-k , k ∈ M : el tiempo de comienzo de operaciones del punto de atraque k, dado por el primer barco que atraca en ese punto.

• Td(k)-k , k ∈ M : el tiempo de cese de operaciones del punto de atraque k, dado por el tiempo de salida del último barco en ese punto.

• Mijk : max { bi + tik – aj, 0} , k ∈ M , i y j ∈N

El MDVRPTW se modela de la siguiente manera:

Minimizar ( 9 )

Sujeto a:

(10)

(11)

(12)

(13)

(14)

(15)

(16)

(17)

(18)

(19)

23

La función objetivo es la minimización de la suma de los tiempos de servicio con un cierto peso asignado. Cuando la nave i no esta asignada al punto de atraque k, el término correspondiente en la función objetiva es 0 puesto que y Tik = ai, por lo tanto, el objetivo es - minimizado. La restricción (10) indica que para cada barco i existe exactamente un arco activo (i; j) ∈ Ak., k

∈ M. Las restricciones (11) y (12) definen el grado de los depósitos, mientras que la conservación del flujo para los restantes vértices está asegurada por la restricción (13). La consistencia de las Tk variables con la secuencia en el punto de atraque se logra mediante la restricción (14). Las ventanas de tiempo de servicio en los barcos son fijadas por las restricciones (15) y (16), y las ventanas de tiempo de la disponibilidad en los puntos de atraque por (17) y (18).

3.4 Algoritmos de solución

A continuación se presentan algunos algoritmos de solución que se han propuesto y aplicado a las distintas formulaciones presentadas en el punto anterior. Para resolver el BAP, se han presentado métodos exactos que resuelven el problema [32], entre ellas la aplicación de CPLEX para las formulaciones de RPF y PAF, y un procedimiento de árbol de búsqueda. Con respecto a este último procedimiento, los rectángulos de los barcos se van ingresando al diagrama tiempo-espacio uno a uno. El árbol posee N niveles (correspondientes al número de barcos). Cada nivel k representa una solución k-parcial. Como cada ingreso de un barco puede hacerse en distintas posiciones dentro del espacio, los hijos de cada nodo en un nivel k podrían ser más que N-k, resultando en una gran cantidad total de nodos. Para contrarrestar esto, se aplican una técnica de branching, límites inferiores y superiores (lower and upper bounds) para cada nodo que reducen el esfuerzo del branching y por último, una técnica de reducción de duplicados.

Alternativamente, y asumiendo que los barcos llegan por lotes, se exponen heurísticas para resolver el problema:

• Heurística H: [35], donde se aplica para cada lote. Primero, las naves son ordenadas ascendentemente

según el tamaño de los barcos. Segundo, se van tomando grupos ordenadamente donde el tamaño total a lo más sume S. Luego, se le asigna espacio a los rectángulos de los barcos de forma “zig-zageante”, de tal forma que en un lote impar (lote 1,3,5,etc) la sección S sea ocupado por el rectángulo de mayor tamaño, y en un lote par la sección 1 sea ocupado por el rectángulo de mayor tamaño.

• Heurística Pair-Wise Exchange: Para cada par de lotes consecutivos, se intercambian cada par de rectángulos de uno y otro, para analizar si se obtiene una mejor solución. En cada intercambio, los demás rectángulos se pueden mover para dar cabida al intercambio.

• Heurística HB: Constituye una heurística en donde se obtiene una solución inicial mediante la heurística H. Luego, se aplica la heurística de intercambio de pares (pair-wise exchange), y por último se aplica la técnica de árbol de búsqueda para cada lote para optimizar el valor objetivo. Finalmente el proceso puede ser repetitivo, hasta que no pueda optimizarse más.

Igualmente se han propuesto soluciones para las formulaciones de DBAP y MDVRPTW [3]. Desde un punto de vista computacional se plantea que DBAP es mejor que MDVRPTW pues puede resolver instancias más grandes, aunque de cualquier forma ninguna de las dos se puede ocupar para obtener soluciones óptimas para instancias de tamaño real. La ventaja que posee MDVRPTW es que se puede adecuar al uso de la suma ponderada de los tiempos de servicios de los barcos, al uso de ventanas de tiempo y puede prestarse fácilmente para el desarrollo de heurísticas. Éstas últimas se han desarrollado en base a la metaheurística de búsqueda tabú (Tabu Search), dando origen a la heurística T^2S (time based tabu search) para el caso discreto y la (TS)^2 (time and space based tabu search) para el caso continuo, explicadas a continuación:

24

3.4.1 T2S – Time based Tabu Search: Caso discreto.

Para el caso discreto, se propone esta heurística en donde el objetivo es minimizar la suma ponderada

total de los tiempos de servicios de los barcos, en opuesto al de distancia recorrida del MDVRPTW. Se denota a S como el conjunto de soluciones para el BAP, que cumplen con las restricciones

expuestas en el punto 3.3.3, donde se formula la variante del VRP. La heurística explora el espacio de solución moviéndose en cada iteración desde la solución actual s ∈ S hacia la mejor solución posible en la

vecindad N(s). Cada solución s ∈ S se compone por conjuntos de m secuencias de atraque, en donde cada barco pertenece a una y sólo una secuencia. Esta solución, sin embargo, puede no cumplir con las ventanas de tiempo, ya sea de las naves o de los puntos de atraque. Las ventanas de tiempo de un barco i exigen que el tiempo de atraque Tik + t ik no sobrepasen el límite superior bi de la ventana. Atracar antes de ai (tiempo de arribo) tampoco esta permitido por tanto Tik >= ai. De igual forma, una ventana de tiempo de un punto de atraque k es violada si el tiempo necesario para procesar el barco i asignado a él es mayor que el límite superior de la ventana de tiempo del punto de atraque k. Si se toma a c(s) como el costo de la solución s y w(s) el total de violación a las ventanas de tiempo que ocurre ya sea en las naves o en los puntos de atraque, se define la función de penalización f(s) = c(s) + αw(s) donde α es un parámetro positivo, que permite evaluar cada solución.

En la búsqueda tabú, se busca caracterizar las soluciones mediante atributos. En este caso para cada

solución s ∈ S se le asocia un conjunto de atributos B(s) = { (i,k): el barco i esta asignado al atraque k}. La vecindad N(s) se define aplicando un simple operador el cual se saca un atributo (i,k) y es reemplazado por otro (i,k’), donde k != k’. Cuando se saca un barco i de una secuencia, ésta es reconectada simplemente juntando el predecesor con el sucesor de i. El insertar al barco i en la secuencia k’ se realiza entre dos barcos consecutivos, de manera de minimizar el costo de f(s). El volver a insertar i a la secuencia k esta prohibido por las siguientes θ iteraciones. Para esto se le asigna un “status tabú” al atributo (i,k).

Para lograr revocar algún atributo con “status tabú” que permitiría encontrar una mejor solución que

la encontrada hasta ahora con el atributo, se crea un criterio de aspiración. Para diversificar la búsqueda, una solución s’ ∈ S en la vecindad N(s) tal que f(s’ ) >= f(s), se penaliza por un factor proporcional a la cantidad de veces que se ha sumado cada atributo y por un factor de escalamiento (scaling factor). El primer factor se define como ρij y corresponde a la cantidad de veces que se ha sumado el atributo (i,k) a la solución durante todo el proceso, el segundo factor se define como c(s’ ) y añade una corrección de ajuste a las penalidades con respecto al coste total de la solución. Además se define la variable ζ como el número de iteraciones actual.

Por tanto, se le suma a la función f(s’ ) un costo de penalidad definido por p(s’ ) = λc(s’ ) ρij / ζ . El

parámetro λ sirve para controlar la intensidad de la diversificación de la búsqueda. Cabe señalar que la penalidad para el caso en que f(s’ ) < f(s), es p(s’ ) = 0. En primer lugar, esta heurística tiene dos formas distintas para crear la solución inicial. El primero de ellos es el llamado Random Greedy (RG), el cual guarda los barcos en forma aleatoria en una cola. Al primer barco en la cola se le establece en la posición que brinda menor tiempo de procesamiento. Para cada barco que sigue, se analiza cada posibilidad y se determina la posición a insertar de acuerdo al mínimo aumento en el costo total. El segundo procedimiento es llamado First-Come, First-Served – Greedy (FCFS-G), en el cual son guardados en una cola de acuerdo a su tiempo de llegada. Luego, la cola es procesada de igual manera que en R-G. Lo más probable es que las soluciones obtenidas por ambos procedimientos no sean factibles. La figura 9 muestra los pasos del algoritmo. La búsqueda comienza obteniendo una solución inicial con el procedimiento R-G. Luego selecciona en cada iteración, la mejor solución no tabú s’ Є N(s). Luego de cada iteración, el valor del parámetro α se

modifica por un factor 1 + δ, donde δ > 0. Si la solución actual es factible con respecto a las ventanas de

tiempo, el valor de α se divide por 1 + δ; de lo contrario, se multiplica por 1 + δ. El proceso se repite n veces, y la mejor solución factible s* se actualiza a lo largo de la búsqueda. Finalmente el algoritmo reinicia, utilizando esta vez el procedimiento FCFS-G para la solución inicial.

25

T2S – Time-Based Tabu Search

1. Sea h := 1

2. Fase de iniciación: Obtener una solución s S usando el procedimiento R-G, si h = 1;

de otra forma ocupar el procedimiento FCFS-G.

3. Sea := 1. SI s es factible, setear s* := s y c(s*) := c(s); de otra forma c(s*) :=

4. Para j:= 1,..,n, hacer:

(a) Elegir una solución s’ N(s) que minimice f(s’) + p(s’), que no sea tabú o que

satisfaga el criterio de aspiración.

(b) Si la solución s’ no es factible y c(s’) < c(s*), setear s* := s’ y c(s*) := c(s’).

(c) Computar w(s’) y actualizar según corresponda.

(d) Setear s := s’.

5. Si h = 1, setear h := 2, s1* := s* . Ir al paso 2.

6. Setear s* := min{s1*, s*} y parar.

Figura 9 – Algoritmo T2S : Time-Based Tabu Search.

3.4.2 TS2 – Time and Space based Tabú Search: Caso continuo.

Una segunda heurística se ha establecido en [3], esta vez para el caso continuo, el cual considera que los puntos de atraque pueden cambiar de tamaño dinámicamente, según sea necesario. Este caso se da cuando el factor de la dimensión del muelle o de la zona de atraque no es factor en el desempeño del puerto. Esto no ocurre en los grandes terminales de trasbordo.

Para tal efecto, es necesario conocer en primer lugar cómo se distribuyen los tamaños de los barcos

que generalmente atracan en el puerto, para decidir cómo se considerarán los cambios o el dinamismo de las asignaciones de secciones. Para el caso en que los tamaños no varíen mucho, se tiene que el muelle se subdivide en m segmentos de atraque, donde cada segmento k tiene un largo cercano a la media del largo de los barcos. Luego, a excepción del segmento inicial y final, cada uno de ellos es dividido en dos segmentos más pequeños de igual tamaño. Por tanto cada segmento k, que no sea el inicial o el final, tendrá dos vecinos: la parte derecha del segmento k-1 y la parte izquierda del k+1, como muestra la figura 10. Luego, si las dimensiones del barco lo ameritan, la asignación de sección de atraque para tal puede expandirse uno o dos bloques de sus vecinos, así como un barco más pequeño puede quizás sólo necesitar la mitad de una sección.

Para obtener una solución para este caso, se hacen modificaciones a la heurística aplicada en T2S.

Las modificaciones se hacen en base a las consideraciones que son necesarias para eliminar o insertar un nuevo barco, pues tienen implicancias para los vecinos. Para el caso de eliminar un barco, son necesarios los siguientes pasos:

• Liberar el espacio ocupado por el barco i durante el tiempo que esté en proceso. Como es posible que el

barco ocupe secciones de sus vecinos, es necesario actualizar la información de éstos. • En forma iterativa, realizar el proceso de eliminación para los barcos sucesores de i en la secuencia k. • Reinsertar todos los barcos eliminados en el paso anterior en la secuencia k, considerando el mínimo

costo.

La reinserción mencionada en el último punto anterior se realiza de la siguiente forma. Considerando a r el número de barcos que ya han sido asignados a la sección de atraque k, para insertar un barco i en k, se evalúan las posibles r + 1 secuencias generadas a partir de la inserción de i en la secuencia original. Las secuencias difieren sólo en la “cola”, en como termina la secuencia. Para hacer la inserción en el caso

26

discreto, ésta resulta más directa pues tan sólo se evalúan las r + 1 secuencias en términos del tiempo. Cuando se incorpora la dimensión del espacio y las interacciones que surgen con sus vecinos, además de considerar el tiempo, es necesario realizar más cálculos. Si se decide por ejemplo insertar un barco i en la posición q , con q <= r, es necesario borrar de la secuencia los barcos desde la posición q hasta r. Luego, el barco i y todos los r-q+1 eliminados, son insertados nuevamente, para lo cual se busca una solución factible como se ha explicado, buscando si es necesaria la posibilidad de expandir el espacio asignado a sus vecinos y lógicamente respetando los espacios ya ocupados por asignaciones a otros barcos.

(TS)2 - Segmentación del muelle

Máxima extensión permitida para un barco en la sección k

Figura 10 – Ejemplo de segmentación del muelle por TS2 Una última modificación para esta heurística es la de sólo ocupar FCFS-G, pues las modificaciones

hechas demandan más iteraciones para manejar la fragmentación, por tanto se deja de ocupar el procedimiento R-G, para de alguna manera suplir este aumento de cálculo. Además, es la estrategia que se asemeja más a lo que se hace en la realidad. Finalmente, el mecanismo de búsqueda Tabú es el mismo para el caso discreto.

3.4.3 Otras alternativas

Obviamente además de los métodos presentados, distintos grupos de investigación han desarrollado

estudios para resolver el problema bajo distintas heurísticas. Entre ellas podemos encontrar por ejemplo, el uso de algoritmos genéticos (Genetic Algorithms) para resolver el problema BAP considerando prioridad de servicios [28]. Por su parte, en [31] se propone encontrar una solución cercana a lo óptimo mediante el uso de algoritmos de Simulado Recocido (Simulated Annealing) en base a un modelo de programación lineal entera mixta (mixed-integer-linear-programming). En fin, la lista puede continuar y sería bastante engorroso buscar y presentar todas las variantes y métodos para resolver el BAP. Se ha presentado en detalle la heurística de búsqueda tabú, pues es la que hasta el momento asoma como la más posible de seleccionar para el proyecto.

27

Arquitectura MADARP

VehicleAgent

Schedule Agent

Client Agent

Trip-request Agent

Account Agent

Planner Agent

Broker Agent

Traffic Agent

Map Agent

Payment Agent

Content Ontology

Interaction Ontology

Vehicle Side Client SideInterface

Layer

Planning Layer

ServiceLayer

ServiceOntology

3.5 Arquitecturas Multiagente para el BAP.

3.5.1 Arquitectura MADARP

Como señalamos anteriormente, BAP puede ser visto como una variante al problema del Vehicle

Routing Problem, por tanto para este trabajo se tomó en cuenta una arquitectura para el VRP, planteada por [33] que recibe el nombre de MADARP donde se presenta una arquitectura multiagente para aplicarse a problemas de transporte de pasajeros. En la Figura 11 se presenta la arquitectura donde se identifican las distintas capas y los agentes asociados a cada uno de los actores: cliente y vehículo, y por otra parte los agentes que son parte del sistema mismo de transporte.

Desde el punto de vista de las capas, es posible identificar en primer lugar la capa de interfaz, que es

la que se preocupa de todo lo que tenga que ver con la interacción del sistema con los actores “externos”, en el caso de MADARP, cliente y vehiculo; en el caso de este proyecto, barco y punto de atraque, respectivamente. Luego, encontramos la capa de planeación, en donde se ubican los agentes que logran resolver la planeación de las rutas de los vehículos y la asignación de clientes a ellos. En el caso de este proyecto, en esta capa se desarrollaría la planeación y asignación de barcos a sus correspondientes puntos de atraque. La capa de servicio tiene como misión la de apoyar la labor de la capa superior de planeación. Para esto, se pueden encontrar agentes que proveen servicios o funcionalidades complementarias que apoyan las decisiones del agente de planeación. Por último, la capa inferior de servicio de ontología provee un medio para que los agentes superiores puedan integrarse e interactuar.

Figura 11 – Arquitectura MADARP [33]

Es posible además visualizar los agentes presentes en el sistema y agruparlos según los actores que están involucrados. En este caso el agente vehículo y el agente programador (schedule) actúan bajo el actor vehículo. Por otro lado el agente cliente y el agente solicitar-viaje (trip-request), actúan bajo el actor cliente. Un último actor, el de la empresa de transporte, se compone de agentes y estructuras que brindan soporte para la planificación del servicio de transporte.

Además, esta arquitectura forma parte de un modelo de capas que permite ocuparlo para

implementar distintas variantes de problemas de transporte de pasajeros. Esto se realiza añadiendo agentes

28

nuevos, estructuras y ontologías que permitan brindar la funcionalidad específica necesaria para el tipo de problema a solucionar.

Figura 12 – Infraestructura Agente. En la Figura 12, se presenta este modelo, donde se pueden ver las tres capas que lo componen. La

capa de más bajo nivel es la de la plataforma de agentes JADE (Jade Agent Platform), la que brinda en primer lugar un conjunto de librerías para crear agentes y que se puedan comunicar mediante el lenguaje FIPA ACL, y se organiza en contenedores donde los agentes pueden trabajar, comunicarse y migrar. Esta plataforma, tiene tres componentes esenciales:

• Sistema de Gestión de Agentes (Agent Management System): sistema que se encarga de brindar un

servicio de “páginas blancas” en donde se identifica a cada uno de los agentes presentes, sus nombres y donde se ubican.

• Directory Facilitator (DF): Brinda un servicio de “páginas amarillas” donde se listan los servicios que brinda cada agente.

• Sistema de transporte de mensaje (Message Transport System): este servicio se dedica a dar soporte a las comunicaciones entre agentes y contenedores.

En la capa superior a la plataforma JADE se encuentra la arquitectura MADARP presentada

anteriormente, de la que forman parte agentes básicos, estructuras y ontologías. Sobre estas dos capas, se encuentra el sistema de transporte concreto, el cual puede lograrse extendiendo la funcionalidad de los agentes básicos o haciendo uso de la ontología, integrando nuevos agentes con roles, interacciones y características definidas bajo esta misma.

Estas dos últimas arquitecturas se presentan como alternativas para plantear una arquitectura para

BAP en base a alguna de ellas. En el próximo capítulo, se expondrán las decisiones relativas al diseño e implementación, incluyendo ésta última.

3.5.2 Arquitecturas alternativas

Existen arquitecturas de agentes que igualmente ofrecen una alternativa para considerar en el desarrollo de este sistema. Entre ellas, se encuentra una propuesta de arquitectura basada en agentes usando una estrategia llamada Distributed Omni Search Strategy (DOSS) [36], la cual propone una arquitectura de dos agentes:

29

• Agente subasta: que recibe las demandas de los clientes desde un archivo o base de datos. Envía la información a cada uno de los agentes vehículos. Recibe las ofertas, las compara y asigna el cliente al vehículo de mejor oferta o menor costo. Despliega las rutas finales por cada agente ofertante. Despliega la lista de puntos no asignados.

• Agente vehículo: que recibe la información de los clientes por parte del agente subasta, uno por uno.

Calcula el costo mediante algún método o heurística y se lo envía de vuelta al subastador. Acepta al cliente, si es asignado por el subastador. Despliega el listado de clientes asignados y calcula la distancia y la carga total de su ruta.

Esta arquitectura se plantea con flexibilidad para atacar distintas variantes del VRP y con la destreza

de poder reescribir algoritmos para esas variantes en donde se requieran distintas heurísticas como algoritmos genéticos, búsqueda tabú, simulated annealing y estrategias de búsqueda en vecindades.

Una segunda alternativa encontrada de aplicación de agentes para problemas del estilo de BAP, donde se propone una arquitectura multiagente como solución al problema de automatización de operaciones en un terminal portuario [2]. La Figura 13 muestra la arquitectura del sistema, en la que se divide el problema en sub-problemas, los cuales son resueltos por agentes específicos. Estos agentes se caracterizan principalmente por su independencia del resto de los elementos del sistema. Pueden coordinar y comunicar decisiones al resto del sistema.

Figura 13 – Ejemplo Arquitectura MA sobre BAP La comunicación entre los agentes se realiza por medio de los mensajes asincrónicos, que se basan

sobre el estándar de FIPA-ACL. El acercamiento distribuido que se propone asegura realzar flexibilidad, eficacia y robustez.

30

En esta arquitectura, se encuentran cinco clases de agentes:

• Agentes de nave: determinan la secuencia de carga/descarga de los barcos. • Agentes estibadores: manejan el proceso de cargar/descarga de las naves. • Agentes de Servicio: distribuyen los contenedores en el terminal portuario. • Agentes Transtainers: optimizan el uso de estas máquinas. • Agentes de Pórtico: interactúan con el transporte terrestre (entrada/salida de contenedores

por tierra). A continuación, se definen objetivos y características de los agentes nombrados anteriormente:

Agentes de la nave

En respuesta a la llegada de una nave, el sistema crea un nuevo agente para esta nave y su perfil de carga. Sus metas son reducir al mínimo el tiempo ocioso de las grúa pórtico, el tiempo de carga/descarga de la nave, y los costos asociados al proceso de estiba. Su labor se relaciona de cerca con el de los agentes estibador, con los cuales el agente de la nave debe coordinar. Cada agente de nave hace frente a un problema en el cual recursos (grúas) deben asignarse a las diversas operaciones (carga/descarga de contenedores), estableciendo así un tiempo de uso del recurso. Esto requiere que todos los agentes de nave que estén activos en un determinado momento, deban coordinarse para reducir al mínimo choques entre las grúas asignadas.

Agentes Estibadores

Para cualquier grúa de pórtico dada, los agentes estibadores intentan obtener la programación (scheduling) más apropiada para la estiba de contenedores. El agente debe conocer la secuencia de carga/descarga de las grúas pórtico, qué grúas horquillas o vehículos tienen asignados cada grúa y la posición de los diversos contenedores dentro del terminal (información proporcionada por los agentes de servicio). El agente por tanto coordina con los agentes activos de Nave y los agentes de Servicio, y procura reducir al mínimo tanto movimientos vacíos de la maquinaria empleada como el número de máquinas necesarias para la operación.

Agentes de Servicio

El terminal se divide en servicios, donde cada uno de ellos tienen asignados rangos de apilamiento. La meta principal de un agente de Servicio es la asignación apropiada de espacio para los contenedores dentro del “campo” (yard) del terminal de un servicio específico, y la configuración más conveniente para la porción del campo controlada por el agente. Para esto, el agente debe conocer el mapa de su porción asignada, de las características del contenedor (tipo, longitud, peso, destino, nave) y del factor de apilamiento. El agente debe también coordinarse con otros agentes de Servicio para resolver conflictos, tales como reasignación de contenedores cuando la pila asignada este llena. Para resolver el problema de la configuración, los agentes de Servicio deben maximizar la densidad de las pilas. Para esto, pueden lanzar el proceso de reconfiguración cuando lo estimen conveniente, basado en criterios tales como el tiempo, conflictos de asignación, baja densidad de pila, etc.

Agentes Transtainer

Cada transtainer se modela como un agente autónomo cuya meta es realizar operaciones de apilamiento de forma eficiente. Además, el agente debe reducir al mínimo los movimientos vacíos de la máquina. Para esto, obtiene la secuencia más eficiente para mover el contenedor desde o hacia su posición correcta. Cada agente espera peticiones de apilamiento desde los agentes de Servicio, los cuales le informan sobre la localización de contenedores que deben ser cargados en barcos o en carros externos, o donde deben ser ubicados contenedores que estén siendo descargados de barcos o vehículos terrestres.

31

Agentes de Pórtico

Un agente de pórtico controla la llegada/salida de una carga por tierra. El agente maneja una puerta

asignada, informando al agente correspondiente de servicio la llegada de nuevos contenedores (para almacenar), y de la llegada de vehículos que necesiten retirar contenedores. En cuanto a aspectos de implementación, la Figura 14, muestra las distintas interacciones internas y externas. Los estándares FIPA son seguidos lo más fielmente posible, y para esto se crean otros agentes de apoyo: Agentes Wrapper, que brindan acceso a BD y software externo; el UDMA como interfaz de interacción humana; y por último el UPA que maneja los perfiles y preferencias de los usuarios.

Figura 14 – Modelo Interacción I/O de un MAS para BAP

La arquitectura presentada anteriormente resulta interesante, pues plantea en forma general una aproximación de aplicación de agentes para las operaciones generales de un terminal portuario multimodal, aunque se escapa al objetivo del problema que enfoca este proyecto que resulta ser más específico.

32

Capítulo 4

ESPECIFICACIÓN Y DISEÑO TÉCNICO En este capítulo, se presenta la especificación funcional de la solución, así como el diseño técnico del

proyecto que servirán de base para el posterior proceso de implementación. En primer lugar, se presentan especificaciones básicas relativas al BAP. Luego, se presentan especificaciones relativas al proceso de desarrollo del sistema, mediante la definición de la metodología a ocupar y lo relativo a la infraestructura.

4.1 Especificaciones funcionales sobre el BAP

Con respecto al BAP, las especificaciones relativas a los requerimientos y restricciones consideradas para el problema, que sirven de pilar para el desarrollo de la implementación de la solución, son las siguientes:

• Se considerará el caso discreto del problema, en el que los puntos de atraque del muelle son considerados de tamaño y número fijo. Para nuestro caso el número de sitios estimado será de cuatro.

• Cada barco debe poseer asignado además de su ETA (tiempo estimado de arribo), un tiempo de

procesado estimativo y ventanas de tiempo permitidas para su manejo. Esto debe ser considerado para evaluar las alternativas brindadas por los sitios de tal manera de filtrarlas, y optar por la que brinda una mejor calidad de servicio acorde a la petición de cada barco.

• La prioridad de cada barco no será tomada en cuenta. • Se ha acordado que el tiempo para procesar la carga de un barco es directamente proporcional al

tamaño de éste. • Los puntos de atraque poseen ventanas de tiempo que limitan su disponibilidad. • El horizonte de tiempo es de una semana como mínimo, para realizar la asignación y un mes de tope

para recibir peticiones de los barcos. Este requerimiento por el momento no tiene relevancia para la fase de implementación y pruebas de la solución. Simplemente aporta información que debe ser considerada a posterior.

• La implementación debe considerar la existencia de dinamismo en el problema. Problemáticas como

la cancelación de llegada de un barco, atrasos del barco, el “cierre” de algún sitio de atraque por alguna emergencia, entre otros, deben ser tomados en cuenta. En lo que a diseño se refiere, se plantea que la generación de alguno de estos sucesos sea realizada en forma manual en la fase de pruebas.

• Los puntos de atraque difieren unos de otros en el tamaño de su sección y en la velocidad de

procesamiento (que puede suponerse como grúas dedicadas para cada punto).

• Se acuerda que la velocidad de procesamiento en una sección es inversamente proporcional al largo

de su sección.

33

• El largo de cada barco no excede al largo de la sección más grande dentro del muelle.

• La información de llegada de los barcos, se sabe con mínimo una semana de anticipación.

• Se define como “atraque-en-cuanto-llega” (berth-on-arrival), si el barco a lo sumo espera dos horas para atracar. Esto en la etapa de pruebas debe ser tomado en cuenta aplicando una escala correspondiente en segundos.

• Una sección sólo puede procesar a los barcos uno por uno, y como se sabe estos no deben

traslaparse (overlap) en el diagrama tiempo-espacio.

4.2 Especificación técnica sobre multiagentes

4.2.1 Metodología de desarrollo

Para la metodología de desarrollo del sistema, se optó por la Metodología PASSI por dos motivos

principales:

• Actualmente la organización FIPA se encuentra trabajando en la obtención de una metodología estandarizada para el desarrollo de proyectos relacionados con tecnología agentes. Para esto, diversas otras metodologías han sido consultadas para el desarrollo un estándar en este ámbito, obteniendo de alguna manera un y por esto respaldo por parte de FIPA. Entre éstas no figura la metodología INGENIAS, y si la metodología PASSI.

• Es relativamente más simple e intuitiva de utilizar pues además cuenta con una herramienta Add-in

para utilizar Rational Rose para conformar los modelos, herramienta de la cual se tiene mayor conocimiento y experiencia. Por tanto estas razones hacen que esta metodología sea más rápida de adoptar.

4.2.2 Arquitectura multiagente propuesta

Se propone una arquitectura basada en la arquitectura MADARP presentada en el punto 3.5.1. Por

tanto, el trabajo considera realizar una adaptación de esta arquitectura al problema particular de BAP intentando mantener la estructura teniendo agentes con similares funciones. Vale decir, para este proyecto se consideran a los barcos como “clientes” que solicitan un servicio, en este caso no de traslado sino de asignación de un punto de atraque. Por otra parte, se consideran a los puntos de atraque o secciones de ellas como “vehículos” que ofrecen un servicio, no de transporte, sino de procesado de barcos mediante descarga/carga. Por tanto, surgió de manera directa la necesidad de contar con Agentes Barcos y Agentes

Berth, como agentes de la capa de “interfaz”, más sus “pares” Agentes Petición-de-Atraque y Agentes

Programador-de-Atraque, como “representante” de las partes en el proceso de evaluación y asignación de los sitios. También se decidió tener un agente que represente el servicio de la empresa portuaria, para actuar de intermediario entre los agentes barcos y los agentes berth, el Agente Muelle. Como muestra la Figura 15, la arquitectura MABAP propuesta considera tener una capa de servicio más una de ontología, apoyando las labores de la capa superior.

34

Arquitectura MA-BAP

Agente Berth

Agente Programador-Atraque

Agente Barco

Agente Petición-AtraqueAgente Muelle

Agente Optimizador

Ontología de Contenido

Ontología de Interacción

Capa deInterfaz

Capa de Planificación

Capa Servicio

Servicio deOntología

Agente Consultor

Agente de Cuenta

Agente Registro

Agente Historial-Barco

Arquitectura MA-BAP

Agente Berth

Agente Programador-Atraque

Agente Barco

Agente Petición-AtraqueAgente Muelle

Agente Central

Capa deInterfaz

Capa de Planificación

Figura 15 - Arquitectura Multiagente para BAP.

La figura anterior muestra la arquitectura lógica que sirve de base para definir la arquitectura que

definitivamente se implementará, presentada en la Figura 16.

Figura 16 - Nueva arquitectura multiagente para BAP. Con esta nueva arquitectura en mente, el proceso básico de funcionamiento de la arquitectura, sin

considerar complicaciones se desarrolla en la siguiente secuencia:

• Un barco, ante la necesidad de hacer uso del muelle, envía una petición de atraque a través del agente petición-atraque, pasando antes por el agente barco correspondiente, al agente muelle por intermedio de un perfil de petición, en donde incluye la información relativa al nombre del barco, su tiempo aproximado de procesamiento y las fechas (tiempo) estimativas de arribo y salida.

• El agente muelle, envía la petición reunida al agente central, pidiéndole un listado de las secciones

candidatas que cumplen con el perfil de la petición. Éste genera el listado y lo envía de vuelta al agente muelle.

35

• Luego, el agente muelle envía la petición entrante al agente programador-atraque de cada una de las secciones listadas. Éste procesa un algoritmo de inserción para el barco entrante dentro de su diagrama espacio-tiempo, y envía de vuelta un perfil de propuesta.

• De las propuestas que llegan, el agente muelle selecciona la mejor alternativa en términos del tiempo

mínimo total de “estadía” del barco en el puerto Luego comunica al agente programador-atraque seleccionado, para que inserte el barco en su secuencia, comunica a los demás agentes del rechazo de sus propuestas, y comunica al agente barco sobre el resultado de su petición.

4.2.3 Herramientas de desarrollo

Para el desarrollo del sistema, serán utilizadas las siguientes herramientas:

Para la infraestructura, se utilizará la plataforma JADE v3.4 [37]. JADE simplifica la puesta en práctica de los sistemas multiagentes proporcionando un middleware en conformidad con las especificaciones FIPA y a través de un sistema de herramientas gráficas que apoya las fases de eliminación de errores y del deployment. Tiene completamente implementado el modelo de comunicación FIPA, ocupando al FIPA ACL como lenguaje para representar mensajes. Se ocupa de aspectos no particulares dentro del desarrollo de agentes, como los de transporte de mensajes, análisis y codificación, y el ciclo de vida del agente. Para la adopción de la metodología y la generación de los modelos, serán utilizados Racional Rose 7.0 versión Visual Basic más el Add-in de PASSI, Passi Toolkit. Como IDE será utilizado Netbeans v5.0 y JAVA SDK 1.5.

4.3 Modelamiento del sistema

En el punto anterior 4.2.1 se expuso la nueva metodología de desarrollo adoptada. A continuación se

presentan los modelos logrados asociados a las distintas fases. Los modelos presentados no son todos los generados por la herramienta, debido al espacio y porque se considero que ciertos modelos eran menos relevantes en términos de la información que proporcionaban, se decidió no incluirlos todos y sólo mostrar aquellos más importantes.

Dentro de la fase de Descripción de Dominio, en primer lugar se generó el diagrama de contexto

que básicamente permite identificar los actores que interactúan con el sistema multiagente. Luego, en la misma fase se conformó el diagrama de descripción de dominio propiamente tal, el cual muestra a los distintos actores interactuando con los diferentes casos de usos. Mediante el uso de este modelo, y realizando un análisis iterativo de los casos de uso en su funcionalidad y objetivos, sacando y añadiendo nuevos, se logra agruparlos en distintos paquetes de casos de usos con objetivos y funcionalidad similares, los que luego serán convertidos en agentes. Mediante el uso de la herramienta PASSI Toolkit, esta generación es automática una vez identificados las agrupaciones de casos de uso. La Figura 17 muestra el diagrama, perteneciente a la fase de Identificación de Agentes. Este diagrama es uno de los principales, sirve de base para las futuras fases y para realizar trazabilidad. Cualquier cambio posterior en cualquiera de los modelos, será advertido por el sistema y será necesario refrescar este diagrama para aceptar los cambios.

36

Bar

co<<

Agen

t>>

Agen

t Ide

ntifi

catio

n D

iagr

am

Ber

thR

eque

st<<

Agen

t>>

Doc

kCen

tral

<<Ag

ent>

>

Doc

kPla

nner

<<Ag

ent>

>

Ber

th<<

Agen

t>>

Ber

thP

lann

er<<

Agen

t>>

Ent

idad

E

xter

na(fr

om 0

1-D

omai

n D

escr

iptio

n ph

ase)

...)

Con

sulta

r A

sign

acio

n

(from

Doc

kCe

nt...

Reg

istr

ar N

uev

o S

itio

(from

Be.

..

Con

sulta

r S

ecue

ncia

(from

Be.

..

Gen

erar

Pro

pues

ta

(from

Ber

thPl

an...

Sis

tem

a de

Reg

istr

o de

A

sign

acio

n(fr

om 0

1-D

omai

n D

escr

iptio

n ph

ase)

...)

Sis

tem

a de

R

egis

tro

de S

itios

(from

01-

Dom

ain

Des

crip

tion

phas

e)...

)

Info

rmar

Asi

gnac

ion

de

Bar

cos

(from

Be.

..

Reg

istr

o de

S

ecue

ncia

s(fr

om 0

1-D

omai

n D

escr

iptio

n ph

ase)

...)

Gua

rdar

Reg

istr

o de

Siti

os

(from

Doc

kCen

t...

<<co

mm

unic

ate>

>

Elim

inar

Siti

o

(from

Be.

..

Mod

ific

ar S

itio

(from

Be.

..

Sec

cion

(from

01-

Dom

ain

Des

crip

tion

phas

e)...

)

Sol

icita

r P

ropu

esta

s

(from

Doc

kPla

n...

<<co

mm

unic

ate>

>

Ran

kear

Pro

pues

tas

(from

Doc

kPla

n...

Reg

istr

ar A

sign

acio

n

(from

Doc

kCen

t...O

bten

er S

itios

Ad-

hoc

(from

Doc

kCe

nt...

Reg

istr

ar S

ecue

ncia

(from

Be.

..

Ges

tiona

r S

itio

(from

Be.

..

<<co

mm

unic

ate>

>

<<ex

tend

>>

<<ex

tend

>>

Pro

cesa

r P

etic

ione

s

(from

Doc

kPla

n...

<<in

clud

e>>

<<in

clud

e>>

<<co

mm

unic

ate>

><<

com

mun

icat

e>>

Sis

tem

a de

Reg

istr

o de

Bar

cos

(from

01-

Dom

ain

Des

crip

tion

phas

e)...

)

Gen

erar

Sec

uenc

ia d

e B

arco

s(fr

om B

erth

Plan

...

<<co

mm

unic

ate>

>

<<co

mm

unic

ate>

>G

estio

nar

Ev

entu

alid

ades

de

l Siti

o(fr

om B

erth

Plan

...

<<co

mm

unic

ate>

>

Sis

tem

a P

lani

fica

cion

Rut

a(fr

om 0

1-D

omai

n D

escr

iptio

n ph

ase)

...)

Ges

tiona

r P

etic

ion

(from

Ber

thR

equ.

..

<<co

mm

unic

ate>

>

Con

sulta

r E

xist

enci

a de

B

arco

(from

Doc

kCe

nt...

Gua

rdar

Reg

istr

o de

B

arco

s(fr

om D

ockC

ent...

Rep

lani

fica

r P

etic

ione

s

(from

Doc

kPla

n...

<<co

mm

unic

ate>

>

<<co

mm

unic

ate>

>

Reg

istr

ar A

sign

acio

n de

S

itio

(from

Ber

thR

equ.

..

<<in

clud

e>>

Rec

haza

r P

etic

ion

(from

Ba.

..

Cre

ar P

etic

ion

de A

traq

ue

(from

Ba.

..

<<ex

tend

>>

<<co

mm

unic

ate>

>

<<co

mm

unic

ate>

>

Insc

ribir

Nue

vo

Bar

co

(from

Ba.

..

<<co

mm

unic

ate>

>

Mod

ific

ar P

etic

ion

(from

Ba.

..

Info

rmar

Ev

ento

s

(from

Ba.

..

<<co

mm

unic

ate>

><<

com

mun

icat

e>>

Man

ejar

Ev

entu

alid

ades

de

l Bar

co(fr

om B

erth

Req

u...

<<co

mm

unic

ate>

>

<<in

clud

e>>

<<co

mm

unic

ate>

>

Bar

co

(from

01-

Dom

ain

Des

crip

tion

phas

e)...

)C

ance

lar

Pet

icio

n

(from

Ba.

..

<<co

mm

unic

ate>

>

Figura 17 – Identificación de Agentes

37

: Barco : Barco GestionadorDeBarcos : Barco

GestionadorDeBarcos : Barco

Consultor : DockCentralConsultor : DockCentral

: Sis tema de Registro...

: Sis tema de Registro...

Registrador : DockCentralRegistrador : DockCentral

1: AgregarNuevoBarco(Barco)

2: ConsultarExistencia(Barco)

5: NoExiste

3: ExisteBarco(Barco)

4: NoExiste

7: RegistrarNuevoBarco(Barco)

8: RegistrarBarco(Barco)

9: Ok

10: Ok

11: Agregado

6: *[Si YaExiste] NoAgregado

Camino Alternativo: En caso de que ya exista

[Si No Existe]

Una vez generado este diagrama de agentes, se continuó con la fase de Identificación de Roles, donde se crearon diagramas de secuencia por cada uno de los escenarios del sistema, mostrándose los distintos roles que adquieren los agentes en estos escenarios, las distintas tareas que efectúan y los mensajes que eventualmente realicen entre ellos. Estos diagramas serán de mucha utilidad para la fase de especificación de tareas de cada uno de los agentes, que eventualmente podrán ser traducidos como comportamientos o behaviours en las etapas de implementación

A continuación se muestran los diagramas de secuencias creados por cada escenario identificado en el sistema:

Figura 18 – Caso de uso: Registrar nuevo barco

El caso de uso anterior muestra el simple escenario en que un barco nuevo desea registrarse en el

sistema para hacer uso del servicio de asignación de berth. En la Figura 19 se muestra el diagrama de caso de uso principal, en donde un barco solicita la asignación de un nuevo punto de atraque.

38

[Fin

Loop

]

: B

arco

: B

arco

Sol

icita

nte

De

Siti

o :

Bar

coS

olic

itan

teD

eS

itio

: B

arco

Con

sulto

r :

Doc

kCen

tral

Con

sulto

r :

Doc

kCen

tral

: S

iste

ma

d

e R

egis

... :

Sis

tem

a

de

Reg

is...

Neg

ocia

dor

: B

ert

hR

equ

est

Neg

ocia

dor

: B

ert

hR

equ

est

Med

iado

r :

Doc

kPla

nne

rM

edia

dor

: D

ockP

lan

ner

Con

sulto

r :

Doc

kCen

tra

lC

onsu

ltor

: D

ockC

entr

al

Can

did

ato

: B

erth

Pla

nner

Can

did

ato

: B

erth

Pla

nner

Ele

gido

: B

ert

hP

lan

ner

Ele

gido

: B

ert

hP

lan

ner

Reg

istr

ado

r :

Doc

kCen

tral

Reg

istr

ado

r :

Doc

kCen

tral

: S

iste

ma

de

Reg

istr

o...

: S

iste

ma

de

Reg

istr

o...

Info

rman

te

: B

arc

oIn

form

ante

:

Ba

rco

1: P

etic

ion

Atr

aque

()

2: V

erifi

carE

xist

enc

iaB

arco

(Pet

icio

n)

5: E

xist

e

3: E

xist

eBar

co()

4: E

xist

e

8: G

estio

narP

etic

ion(

Pe

ticio

n)

9: P

roce

sarP

etic

ion(

Pe

ticio

n)10

: Obt

ener

Siti

osA

dhoc

(Pet

icio

n)

11:

Lis

tado

De

Siti

os

12: G

ener

aPro

pues

ta(P

etic

ion

)

13: P

rop

uest

a

[For

each

Ber

th d

el li

stad

o]

[Fin

Loop

]

14: R

anke

arP

ropu

esta

s()

15:

Lis

tado

Pro

pues

tas

16:

Ele

girP

rop

uest

a(P

ropu

esta

)

19:

Co

nfirm

acio

n

Si l

a p

rop

uest

a ya

no

esta

di

spon

ible

, la

petic

ion

inic

ial d

ebe

volv

er a

pr

oces

arse

.

[Mie

ntr

as

no s

e ha

ya a

sig

nado

]

[F...

17:

Co

nfirm

arP

rop

uest

a(P

ropu

esta

)18

: Con

firm

aci

on

[For

each

can

did

ato

rec

haza

do]

Con

firm

ar

pro

pue

sta

en c

aso

de

ser

po

sitiv

a i

nvo

lucr

a u

na

"res

erva

" es

pera

ndo

un m

sg

defin

itivo

de

Gen

erar

Sec

uenc

ia

22:

Ge

nera

rSec

uenc

ia(P

ropu

esta

)

23: R

egis

trar

Se

cuen

cia

()

24: A

sig

naci

on

25:

Re

gist

rarA

sig

naci

on(

Asi

gnac

ion)

26:

Gua

rda

rAsi

gna

cion

(Asi

gna

cio

n)

27:

Ok

28:

Ok

20:

Re

chaz

oPro

pue

sta(

Pro

pues

ta)

21:

Ok

29: R

egis

trar

Asi

gnac

ion(

Asi

gna

cion

)

6: *

[Si N

oE

xist

e] R

echa

zarP

etic

ion(

)

7: *

[Si N

oE

xist

e] P

etic

ionR

ech

azad

a

[Si E

xist

e e

l Bar

co]

Cam

ino

Alte

rnat

ivo:

C

aso

si n

o e

xist

e el

ba

rco

Se

Asu

me

que

si

empr

e h

ay s

itios

di

spo

nibl

es

Ad

-Ho

c

30: I

nfo

rmar

Asi

gnac

ion

(Asi

gna

cion

)

31:

Asi

gna

cio

n

Figura 19 – Caso de uso: Solicitar asignación de sitio

39

: Barco : Barco Informante : Barco

Informante : Barco

BomberoBarco : BerthRequest

BomberoBarco : BerthRequest

Replanificado...

Replanificado...

BomberoBerth : BerthPlannerBomberoBerth : BerthPlanner

1: InformarCancelacion(Asignacion)

2: ProcesarCancelacion(Asignacion)

3: Cancelar(Asignacion)

4: RemoverAsignacion(Asignacion)

7: Ok

5: RegenerarSecuencia()

6: Registrar Secuencia()

8: Ok

9: CancelacionExitosa

10: CancelacionExitosa

: Seccion : Seccion GestionadorDeSitios : Berth

GestionadorDeSitios : Berth

Consultor : BerthPlannerConsultor :

BerthPlannerInformante : BerthPlannerInformante : BerthPlanner

Replanificador : DockPlanner

Replanificador : DockPlanner

Informante : Barco

Informante : Barco

: Barco : Barco

1: CambiarANoDisponible()

2: HayBarcosAsignados?

3: ExistenBarcos

4: *[Si no hay barcos] ModificarDisponibilidad()

5: Ok

6: *[Si Existen Barcos] InformarReplanificacion()

7: Replanificar(Peticiones)[Foreach peticion ...

8: PedirReprocesamiento(Peticion)

9: InformarReprocesamiento(Peticion)

[FinLoop]

Se le informa al Barco de la peticion que debe ser reprocesada, luego comienza una nueva peticion como ha sido explicado en el CU de solicitud.

También debe considerarse el escenario que muestra la Figura 20 en que es cancelada una asignación de sitio por parte de un barco.

Figura 20 – Caso de uso: Un barco cancela la asignación de sitio

Figura 21 – Caso de uso: Un sitio se vuelve no disponible

40

Barco.PeticionDeAtraque

<<External Agent>>

DockCentral.Listener

BerthRequest.Listener

Barco.RegistrarNuevoBarco

<<External Agent>>...>>

Barco.InformarEventualidad

<<External Agent>>...>>

BerthRequest.InformarResultado

DockPlanner.ReprocesarPeticion

Barco.RecibirReprocesamiento

<<External Agent>>

RecibirPeticion

ConsultarExistencia

InformarResultado

Listener

IniciarPeticion

InformarEvento InscribirBarco

InformarReprocesamiento

BarcoBarco T.Sp.:Interacting Agents

La Figura 21 muestra otro escenario en el que un sitio que posee asignación de barcos en su secuencia de llegada, se vuelve no disponible.

Una vez realizados los diagramas de secuencia e identificados los distintos roles de los agentes, se

pueden generar las especificaciones de tareas para cada uno de ellos. Estas son las primeras visualizaciones de lo que se podría traducir posteriormente a comportamientos o behaviours.

A continuación, en la Figura 22 se exponen las especificaciones de tarea para el agente barco y el

agente berthrequest.

Figura 22 – Especificación de tareas: Agente Barco

En estos modelos se puede visualizar las tareas internas que posee cada agente, pero también se muestran las tareas de los agentes externos asociados a él, las cuales se comunican ya sea gatillando tareas internas o sirviendo de receptores de eventos generados al interior del agente.

41

Domain Ontology Description Diagram

Nave<<concept>>

Muelle

codMuelle : StringnombreMuelle : String

<<concept>>Sitio

nroSitio : intancho : floattasaProcesamiento : float

<<concept>>

Solicitud

codigoBarco : StringfechaPeticion : Date

<<concept>>

Propuesta

codPropuesta

<<concept>>

Participante<<concept>>

Perfil<<concept>>

Negociacion<<concept>>

Asignacion<<concept>>

CancelacionPeticion

ModificacionPeticion

Secuencia<<concept>>

EventoNave<<concept>>

ModificarDisponibilidad

EliminarSitio

Eventualidades<<concept>>

EventoSitio<<concept>>

Barco.IniciarPeticion

DockPlanner.Listener

DockPlanner.InformarPropuesta

Barco.Listener

Barco.InformarEvento

Listener

RecibirPeticion

NegociarPeticion

EvaluarPropuesta

InformarResultado

InformarEvento

BerthRequestBerthRequest T.Sp.:Interacting Agents

En la Figura 23 se muestra la especificación de tareas para el agente BerthRequest, que es el agente que cumple el rol en el sistema de actuar de intermediario del barco en el proceso de asignación del sitio de atraque.

Figura 23 – Especificación de tareas: Agente BerthRequest

La Figura 24 muestra una versión simple del diagrama de descripción de la ontología, donde se intenta definir lo más claramente posible los conceptos que existen en el dominio del problema.

Figura 24 – Descripción de la ontología del dominio

42

Barco A

Ventana de tiempo total

Ventana Factible: [ET,LT – N]

ET LT

N

4.4 Algoritmo de inserción

Dentro del sistema MABAP, poder evaluar la inserción de un nuevo barco a una secuencia de un

berth y poder elegir dentro de las propuestas de cada uno de ellos cuál es la más conveniente, es el objetivo fundamental del problema y por tanto un aspecto clave en la implementación de la aplicación.

El algoritmo utilizado en la aplicación se basó en la heurística de inserción propuesta por Jaw et al.

[41] para el problema de Multiple Dial-a-ride con ventanas de tiempo. Sin embargo existen claras diferencias entre el problema de dial-a-ride y el problema BAP, por tanto fue necesario considerar estas diferencias y establecer los cambios en la aplicación de la heurística.

En primer lugar el problema de dial-a-ride considera dos eventos, uno de pick-up del cliente y otro de

delivery del cliente. En el caso de BAP existe solo un evento asociado a cada barco, que es el comienzo de la atención de éste. En el dial-a-ride existen dos ventanas de tiempo asociadas a los eventos de pickup y delivery. En el caso del BAP sólo se considerará la ventana de tiempo asociada al comienzo de “atención” de cada barco. La creación de la ventana de tiempo inicial para cada barco tendrá relación con el tiempo de procesamiento asociado a éste, tal como muestra la Figura 25. Para el barco A de tiempos de llegada y partida estimadas como ET y LT, y tiempo de procesamiento N, se tendrá como ventana de tiempo máxima [ET,LT] y su tiempo factible inicial como [ET,LT-N].

Figura 25 – Ventanas de tiempo

La heurística de inserción de Jaw además propone el uso de bloques para agrupar los eventos de

pickup y delivery, en donde se exige que cada par de eventos asociados a cada cliente se encuentren ambos dentro del mismo bloque. La utilización de bloques en esta heurística obedece a que ésta es restrictiva en cuanto al uso de tiempos de “slack” o de ocio del vehículo, por tanto cada vez que se desea agregar un tiempo de ocio, se genera un nuevo bloque en donde el paso de un bloque a otro genera un tiempo de ocio o “slack”. En el caso del BAP, la restricción de bloques no existe, y se trata el horizonte de inserción si se quiere como un sólo bloque global en donde se encuentran todos los eventos. Además los tiempos de ocio tendrán un trato menos restrictivo como se explicará a continuación.

En el transporte de pasajeros, el tiempo de ocio está asociado al tiempo en que el vehículo está

detenido o viajando “sin sentido” sin tener que ir a buscar o dejar un pasajero, por tanto es lógico que la heurística original intente eliminar estos tiempos y exigir que el traslado del vehículo siempre obedezca a estar yendo a buscar o dejar un cliente a un cierto lugar. En el caso de la “atención” de barcos, la problemática es distinta, el tiempo de “viaje” entre un lugar a otro o de un pasajero y otro, se puede traducir en BAP como el tiempo que es necesario para que un berth que ha terminado de atender un barco pueda estar disponible para la llegada de otro. El tiempo de ocio o “slack” en este caso estará determinado entre el tiempo en que el berth este listo para recibir un nuevo barco y la llegada de éste. Por tanto, a menos que el puerto posea una tasa de llegada de barcos muy alta, siempre existirán tiempos de ocio en los puntos de recaladas del puerto, por esto se ha optado por eliminar la restricción de la heurística original con tal de permitir tiempos de slack en ellos. Estos tiempos de ocio permitirán además diferenciar las propuestas de solución de cada berth e identificar una solución relativamente mejor que otra.

43

Tfact B

Tfact A Tfact B

Evento A Evento B

El nuevo intervalo factible (hacia delante) de B. No es

necesario un slack para “llegar a atender a B”

Horizonte de tiempo

Tfact A

Tfact B

Tfact A Tfact B

Evento A Evento B

El intervalo factible de A desplazado queda después del intervalo factible de B, por tanto el evento no se

puede insertar

Horizonte de tiempo

Tfact A Tfact A

A continuación se explica el detalle del algoritmo de inserción aplicado en el evento de llegada de un barco B.

Al llegar un barco B al atracadero (berth), para nosotros un nuevo evento de atraque, se revisa en la secuencia del berth lo siguiente:

• Si la secuencia esta vacía, simplemente se inserta el nuevo evento en ella. • Si la secuencia no esta vacía, se busca el evento justo anterior (evento A) donde a continuación de

él debería insertarse el nuevo evento. Esta búsqueda se realiza comparando el ETA (tiempo de llegada) de ambos.

• Una vez que se sabe donde debería insertarse, se traslada la ventana factible del evento A en un tiempo delta dado por el tiempo de procesamiento de A más el tiempo que tarde el berth en estar listo para recibir un próximo evento. En este procedimiento pueden ocurrir uno de los siguientes casos:

Figura 26 – Caso de imposibilidad de inserción

En el caso de la Figura 26, el intervalo factible del evento ya insertado A desplazado, no

logra intersectar con el intervalo factible de B, y queda pasado a éste. Por tanto el evento B no puede insertarse en la secuencia del Berth X.

Figura 27 – Caso de posibilidad de inserción

En la Figura 27 se puede observar el caso en que la intersección es distinta de vacía, por

tanto no es necesaria la inserción de un slack de tiempo para que el evento B logre ser atendido en el berth X.

44

Tfact A Tfact B

Evento A Evento B

Tproc + TgetReady

Es necesario este “slack” para que exista una

intersección y poder llegar a atender a B

Horizonte de tiempo

Tfact A Tfact A Tfact B

Figura 28 – Caso de posibilidad de inserción mediante tiempo de slack

En el caso de la Figura 28, si la intersección resulta ser vacía pero el intervalo factible de A

desplazado queda al lado izquierdo del intervalo factible de B, es posible la inclusión de un tiempo de slack que permita la intersección. Este tiempo de slack finalmente resulta en un tiempo de penalización en esa inserción.

• Luego de determinada la factibilidad (hacia delante) y de ser necesario calculado el tiempo de

slack, se verifica si el lugar a insertar el nuevo evento es el final de la secuencia o no. Si es el final de la secuencia, simplemente se inserta el nuevo evento en ella, con o sin la penalización que corresponda (tiempo de slack). Si no es el final de la secuencia, y el evento debe insertarse antes que otro, es necesario realizar una validación de factibilidad con el evento posterior C (hacia atrás). Para esto se toma el intervalo factible del evento C y se desplaza hacia atrás en el tiempo de procesamiento de B más el tiempo para que el berth esté listo (getReadyTime). Como resultado puede que se de uno de tres casos análogos a los vistos anteriormente.

Figura 29 – Caso de imposibilidad de inserción (factibilidad hacia atrás)

En la Figura 29 se puede observar que el intervalo factible de C desplazado hacia atrás queda al lado izquierdo del intervalo factible de B, imposibilitando la inserción del evento B.

45

Figura 30 – Caso de posibilidad de inserción (factibilidad hacia atrás)

Figura 31 – Caso de posibilidad de inserción con tiempo de slack (factibilidad hacia atrás)

En la Figura 30 y 31, existe la posibilidad de inserción. En el primer caso, existe una factibilidad

“hacia atrás” pues existe una intersección entre el tiempo factible de C desplazado y el tiempo factible de B. En el caso de la Figura 31 es necesario agregar un slack de tiempo para que esta intersección sea distinta de vacía.

En ambos casos anteriores, para verificar definitivamente la posibilidad de inserción, es necesario

verificar que el intervalo de tiempo resultado de la intersección realizada en primer lugar “hacia delante”, y el intervalo de tiempo resultante del último proceso de verificación de factibilidad “hacia atrás”, intersecten. En caso de que éstos se intersecten se puede realizar la inserción del evento, con cualquier penalización que acarree de los procedimientos pasados. En caso de que no intersecten, se puede sumar a la penalización que exista en el momento, un intervalo más de penalización que permita la inserción definitiva del evento. En la Figura 32 se puede observar finalmente que es necesario agregar un último tiempo de slack para que las ventanas puedan intersectar.

46

Figura 32 – Proceso de inserción – Intersección “triple” vacía

Finalmente en la Figura 33 se da el caso de la intersección triple no vacía, por tanto se puede insertar el nuevo evento B entre los eventos A y C, sin agregar un tiempo de slack adicional.

Figura 33 – Proceso de inserción – Intersección “triple” no vacía

Explicado el algoritmo de inserción que se aplicará en cada uno de los puntos de atraque de los barcos, es necesario mencionar que mediante este algoritmo cada punto de atraque generara una propuesta que será enviada al agente de planificación o Dock Planner para que sean evaluadas. La decisión sobre cual será la propuesta aceptada se basará en la minimización de tanto los tiempos de espera de cada barco como las penalizaciones asociadas a la inserción de cada uno de ellos.

47

<<class>> Agent

-requester: BerthRequesterAgent-nroBarco-processTime-ET, LT-...

<<class>> BarcoAgent

<<class>> BarcoListenerBehaviour

-peticion: PeticionAtraque

<<class>> IniciarPeticion

<<class>> CyclicBehaviour <<class>> OneShotBehaviour

Clase BarcoAgent

Capítulo 5

IMPLEMENTACIÓN DEL SISTEMA Considerando la especificación de diseño expuesta en el capítulo anterior, en este capítulo se

presentan los detalles de la implementación del sistema.

5.1 Implementación de Clases/Agentes

La implementación del sistema bajo el modelo de agentes presentado en la especificación de diseño,

ha resultado en el siguiente conjunto de clases:

5.1.1 Clase BarcoAgent Esta clase representa al actor Barco, extiende de la clase Agent y posee dos clases behaviour

(comportamiento): BarcoListenerBehaviour e IniciarPeticion. El primero de ellos es un comportamiento que se ha creado en la mayoría de los agentes, el cual se encarga de “escuchar” mensajes que provienen desde otros agentes realizando alguna solicitud. En este agente en particular el behaviour se encarga de recibir solicitudes del agente principal MainAgent ya sea para iniciar una petición o para terminar su ejecución.

Figura 34 – Clase BarcoAgent

48

<<class>> Agent

-profile: BerthProfile-berthPlanner: BerthPlannerAgent-...

<<class>> BerthAgent

<<class>> BarcoListenerBehaviour <<class>> RegisterBerthBehaviour

<<class>> CyclicBehaviour <<class>> OneShotBehaviour

Clase BerthAgent

<<class>> CreateAgentBehaviour

<<class>> Agent

-peticion: PeticionAtraque-barcoAID-...

<<class>> BerthRequesterAgent

<<class>> ListenerBehaviour<<class>> ProcesarPeticion

<<class>> CyclicBehaviour

<<class>> OneShotBehaviour

Clase BerthRequesterAgent

5.1.2 Clase BerthRequesterAgent

Esta clase es la que representa a cada barco en el proceso de negociación al solicitar un nuevo punto de atraque. Extiende de la clase Agent y posee un comportamiento cíclico ListenerBehaviour que se encarga de recibir órdenes de procesar una nueva petición y terminar su ejecución.

Figura 35 – Clase BerthRequesterAgent

5.1.3 Clase BerthAgent Esta clase representa a cada punto de atraque o berth, extiende de la clase Agent y posee tres clases

behaviour (comportamiento): BarcoListenerBehaviour, CreateAgentBehaviour y RegisterBerthBehaviour. El primero espera el mensaje que le solicite terminar su ejecución. El segundo se gatilla automáticamente y una sola vez para crear el correspondiente agente BerthPlannerAgent el cual será su negociador particular en el proceso de asignación de naves a los distintos puntos de atraque.

Figura 36 – Clase BerthAgent

49

<<class>> Agent

+evaluateInsertion()+confirmAcceptance()

-secuencia: BerthSequenceNew-berthAID-...

<<class>> BerthPlannerAgent

+ListarSecuencia()+Terminate()

<<class>> ListenerBehaviour

+prepareResponse()+prepareResultNotification()+handleRejectProposal()

-bp: BerthProposal-peticion: PeticionAtraque-evento: EventoAtraque

<<class>> NegotiationResponderBehaviour

<<class>> CyclicBehaviour

<<class>> ContractNetResponder

Clase BerthPlannerAgent

5.1.4 Clase BerthPlannerAgent Esta clase corresponde al agente planificador de cada punto de atraque o berth, lleva el registro de su

secuencia de inserción e interviene en el proceso de asignación de nuevos atraques evaluando las distintas peticiones de los barcos que van llegando. Extiende de la clase Agente, posee un ListenerBehaviour que recibe peticiones de listar la secuencia actual y de terminar su ejecución; y el NegotiationResponderBehaviour

que extiende de la clase ContractNetResponder.

Figura 37 – Clase BerthPlannerAgent

5.1.5 Clase DockCentralAgent Esta clase representa al tercer agente principal, el muelle. Extiende la clase Agent, y posee tres comportamientos: un ListenerBehaviour encargado de recibir solicitudes de acciones sobre los otros dos comportamientos, como el listado de berths que resultan ser candidatos para una petición en particular (BerthBrokerBehaviour) y llevar el registro de los berths del muelle (BerthRegisterBehaviour).

50

<<class>> Agent

-berthVector: Vector

<<class>> DockCentralAgent

+BerthBrokerBehaviour()+BerthRegisterBehaviour()+Terminate()

<<class>> ListenerBehaviour

-msg:ACLMessage

<<class>> BerthRegisterBehaviour

<<class>> CyclicBehaviour

<<class>> OneShotBehaviour

Clase DockCentralAgent

+getBerthCandidates()

-msg:ACLMessage-berthList: Vector-peticion: PeticioinAtraque

<<class>> BerthBrokerBehaviour

<<class>> Agent

<<class>> DockPlannerAgent

+GestionarPeticionBehaviour()+Terminate()

<<class>> ListenerBehaviour +IniciarNegociacionBehaviour()

-peticion: PeticionAtraque

<<class>> GestionarPeticionBehaviour

<<class>> CyclicBehaviour<<class>> OneShotBehaviour

Clase DockPlannerAgent

+handleAllResponses()+handleFailure()+handleInform()+handlePropose()+handleRefuse()

-nResponders: int

<<class>> IniciarNegociacionBehaviour

<<class>> ContractNetInitiator

Figura 38 – Clase DockCentralAgent

5.1.6 Clase DockPlannerAgent Esta clase esta dedicada a gestionar el proceso de asignación de puntos de atraque, manejando las peticiones entrantes e iniciando la negociación con los distintos berths del muelle. Posee para esto un ListenerBehaviour que espera por la llegada de nuevas solicitudes de atraque para gatillar el comportamiento GestionarPeticionBehaviour y a partir de éste, el comportamiento IniciarNegociacionBehaviour.

Figura 39 – Clase DockPlannerAgent

51

5.2 Interacción de Agentes

En cuanto a la interacción de los agentes, los modelos brindados por la metodología PASSI,

específicamente los diagramas de secuencia que identifican roles y los diagramas de tareas, redundaron en la identificación de los detalles de implementación.

Concretamente las interacciones entre agentes se ejecutan en base al uso de mensajes ACLMessage

con las performative que correspondan. Lo básico de todo agente es realizar toda clase de tareas, ya sea de interacción/comunicación como de tareas específicas propias, mediante la definición de los comportamientos o behaviours. Generalmente estos están siendo mapeados uno a uno con las distintas tareas definidas en la especificación de tareas de cada agente como se ha mostrado en el punto anterior, aunque existen casos en los que una tarea ha necesitado generar más de un behaviour.

Para establecer la comunicación en forma ordenada y controlada, se hacen uso de dos clases de

JADE que implementan todos los aspectos de ella en base a dos roles, el Iniciador y el Responder. Para el primer rol, se define la clase ContractNetInitiator que es fácilmente extensible y basta implementar los métodos de cada una de las respuestas que le puedan llegar ya sea si son primeras (Not-understood, Refuse y Agree) o las segundas (Failure e Inform). Es posible con esta clase además manejar conversaciones de cardinalidad 1: N, no así su version “Light”, la SimpleAchieveReInitiator, que solo admite conversaciones 1:1. Para el segundo rol, el que responde, existe la contraparte definida por la clase ContractNetResponder, análoga al Initiator.

Para el envío de objetos entre los agentes, por ejemplo la Petición, esta se realiza serializando el

objeto y ayudado por métodos de la clase ACLMessage, como el setContentObject() y el getContentObject(), para incorporar o rescatar el contenido del mensaje ACL, respectivamente.

5.3 Implementación del algoritmo de inserción

Para el algoritmo de inserción utilizado por cada uno de los berths, y explicado en el capítulo anterior, se decidieron ciertos detalles de implementación importantes. Para representar la secuencia de los eventos se optó por realizarlo a través de una lista enlazada, en donde cada nodo (clase ListNode) de la lista represente la inserción de un evento. Dentro de cada nodo de la lista, se cuenta con los siguientes elementos:

• EventoAtraque: clase que contiene la información principal relativa al evento de atraque de los

barcos. Dentro de esta información se cuenta con los tiempos de llegada y salida límites (ET, LT), las ventanas de tiempo factibles hacia delante (FETini, FLTini) y hacia atrás (FETend, FLTend) además del tiempo asignado para la llegada AT (arrival time), el tiempo de procesado y el número identificador del barco.

• Penalización: es la penalización relativa a la inserción de cada evento de atraque. • Un puntero al próximo nodo en la lista.

Para manejar la secuencia se decidió crear la clase BerthSequence que posee una variable header de

tipo ListNode que representa la cabeza de la lista enlazada. Además posee un campo getReadyTime que representa el tiempo que un berth se toma para estar preparado para procesar una nueva llegada de un barco. Posee diversos métodos de inserción, búsqueda de eventos y despliegue de secuencia, pero siendo los más importante aquellos que evalúan e insertan un nuevo evento en la secuencia. Además se cuenta con una clase de tipo utilitaria BerthSequenceItr que corresponde a un iterador sobre un objeto de tipo ListeNode. Esta clase sirve para apuntar y recorrer sobre eventos en la secuencia.

52

Algoritmo de Evaluacion e Inserción

public synchronized boolean evaluateAndInsert(EventoAtraque evento) { int prevEarlyTimeScrolled = 0; int prevLateTimeScrolled = 0; int postEarlyTimeScrolled = 0; int postLateTimeScrolled = 0; int delta = 0; double costo = 0; double slack = 0; double factorCantidadBarcos = 0.9; double factorSlack = 0.1; boolean insertado = false; boolean hasSlackBack = false; boolean hasSlackFwd = false; int factEarlyTimeBack = 0; int factLateTimeBack = 0; if(this.isEmpty()) { this.insert(evento,this.headerItr()); this.setCantidadBarcos(1); this.setCostoSecuencia(1 * factorCantidadBarcos); insertado = true; } else { ListNode index = getInsertionIndex(evento.getEarlyTime()); delta = index.evento.getProcessTime() + this.getReadyTime; prevEarlyTimeScrolled = index.evento.getFactEarlyTimeBack() + delta; prevLateTimeScrolled = index.evento.getFactLateTimeBack() + delta; if( prevEarlyTimeScrolled <= evento.getFactLateTimeBack()){ // Prefactibilidad hacia adelante factEarlyTimeBack = (prevEarlyTimeScrolled > evento.getFactEarlyTimeBack()) ? prevEarlyTimeScrolled : evento.getFactEarlyTimeBack(); factLateTimeBack = (prevLateTimeScrolled < evento.getFactLateTimeBack()) ? prevLateTimeScrolled : evento.getFactLateTimeBack(); if (prevLateTimeScrolled < evento.getFactEarlyTimeBack()) { // Es necesario un slack (hacia atras) slack = evento.getEarlyTime()- index.evento.getLateTime() - this.getReadyTime; } else { evento.setFactibleBack(factEarlyTimeBack, factLateTimeBack ); this.reassignArrivalTime(evento,factEarlyTimeBack); } if(index.next == null){ // Se debe insertar al final this.insert(evento,new BerthSequenceItr(index)); this.setCostoSlack(slack); this.setCantidadBarcos(this.getCantidadBarcos() + 1); // se suma uno por el evento recien ingresado costo = (this.getCantidadBarcos() * factorCantidadBarcos) + (slack * factorSlack); this.setCostoSecuencia(costo); insertado = true; } else { // Se debe insertar entremedio de dos eventos postEarlyTimeScrolled = index.next.evento.getFactEarlyTimeFwd() - evento.getProcessTime() - this.getReadyTime; postLateTimeScrolled = index.next.evento.getFactLateTimeFwd() - evento.getProcessTime() - this.getReadyTime; if( postLateTimeScrolled >= evento.getFactEarlyTimeFwd()) { // Prefactibilidad hacia adelante if(postEarlyTimeScrolled > evento.getFactLateTimeFwd()) { // Es necesario un slack hacia adelante slack += postEarlyTimeScrolled - evento.getFactLateTimeFwd() + 1; } else{ // No es necesario un slack hacia atras, pero hay que determinar el intervalo factible int factLateTimeFwd = (postLateTimeScrolled < evento.getFactLateTimeFwd()) ? postLateTimeScrolled : evento.getFactLateTimeFwd(); int factEarlyTimeFwd = (postEarlyTimeScrolled > evento.getFactEarlyTimeFwd()) ? postEarlyTimeScrolled : evento.getFactEarlyTimeFwd(); evento.setFactibleFwd(factEarlyTimeFwd,factLateTimeFwd); } this.insert(evento,new BerthSequenceItr(index),costo); this.setCostoSlack(slack); this.setCantidadBarcos(this.getCantidadBarcos() + 1); costo = (this.getCantidadBarcos() * factorCantidadBarcos) + (slack * factorSlack); this.setCostoSecuencia(costo); insertado = true; } else { System.out.println("[Barco "+evento.getNroBarco()+"] Cannot be inserted in the berth sequence"); insertado = false; } } // Fin else insercion entremedio } //Fin Prefactibilidad hacia adelante else { System.out.println("[Barco "+evento.getNroBarco()+"] Cannot be inserted in the berth sequence"); insertado = false; } } return insertado; }

A continuación se muestra la función principal encargada de la evaluación e inserción de una petición de atraque ya procesada y asignada a una secuencia de un berth.

Figura 40 – Algoritmo de Evaluación e Inserción

53

Archivo data0040101.txt

4 101 3 44 492 3 8 113 4 26 314 2 7 105 2 5 96 4 48 547 2 34 368 1 14 179 3 39 4410 5 40 47

Capítulo 6

SIMULACIÓN Y RESULTADOS En este capítulo se expone el resultado de la simulación del sistema presentando los formatos de los

archivos de entrada y salida, y el análisis de los resultados obtenidos.

6.1 Formatos de Archivos de Entrada y Salida

El archivo de entrada contiene en una presentación sencilla la información de un escenario de simulación. El nombre del archivo tiene un formato del tipo dataXXXYYYZ.txt, en donde XXX corresponde a la cantidad de berths que posee el muelle, ZZZ a la cantidad de barcos que arribarán al puerto y Z es simplemente un correlativo.

A continuación, en la Figura 41 se presenta un ejemplo de archivo de entrada de nombre data0040101.txt

Figura 41 – Ejemplo de archivo de entrada

La primera línea del archivo muestra, separados por espacios, en primer lugar la cantidad de berths y en segundo lugar la cantidad de barcos. Luego, tomando en cuenta la cantidad de barcos N, a partir de la segunda línea en adelante hasta la línea N, se muestran cuatro datos asociados a cada barco, separados por espacios: el Nº del barco, el tiempo de procesamiento, el tiempo estimado de arribo y por último el tiempo estimado de zarpe.

El archivo de salida presenta los resultados de la asignación de barcos a los distintos puntos de atraque. Cada línea representa un punto de atraque y contiene separados por un espacio: la identidad del berth, la cantidad de barcos asignados, el costo total de la secuencia y el costo de “slack” o costo de tiempo ocioso de cada berth. El nombre del archivo esta en el formato outdataXXYYZDDMMYYYYhhmmss.txt en referencia al nombre del archivo de entrada más el día y hora de ejecución del proceso. Un ejemplo de archivo de salida se muestra en la Figura 42.

54

Archivo de salida outdata04101091216224659.txt

berth1 2 1.8 0.0berth2 2 2.2 4.0berth3 3 2.9 2.0berth4 3 4.9 22.0

Figura 42 – Ejemplo de archivo de salida.

Existen dos costos básicos que intervienen en la simulación, el costo básico asociado a la cantidad de barcos en la secuencia, y el costo de ocio o “slack” dado por la suma de los tiempos en que un punto de atraque deja de atender a un barco y espera la llegada de otro, sin contar el tiempo que necesita para prepararse. Si bien ambos costos básicos se refieren a cosas distintas, para efectos de la simulación ambos se definen de tipo entero y se considera posible la suma entre ellos. La suma de ellos, agregando la utilización de factores porcentuales para la definición de distintos escenarios, entrega el costo total para una determinada secuencia.

Por lo tanto el costo total de la secuencia esta dado por la siguiente fórmula:

Ctotal secuencia = [(∑ barcos)* factorCantidadBarcos] + [(∑slacks) * factorSlack]

Donde tanto factorCantidadBarcos y factorSlack reciben valores dentro del intervalo [0,1] y ambos suman 1.

6.2 Recolección y análisis de resultados

Para la recolección de datos se seleccionó un escenario tipo considerando un muelle con 10 puntos

de atraque, y la llegada de 50 barcos en un horizonte de tiempo máximo de 60 unidades de tiempo. Cada punto de atraque demora una unidad de tiempo en estar listo para atender la llegada de un nuevo barco (getReadyTime). No se consideran restricciones de espacio por lo que cualquier punto de atraque puede atender a cualquier barco.

La generación de instancias se realizó mediante un proceso automático, generando datos de barcos

con ventanas de tiempo aleatorias de máxima duración de 5 unidades de tiempo. En la Figura 43 se muestra una representación gráfica de la llegada de los barcos en el horizonte de tiempo para un ejemplo de archivo de entrada. Cada caja representa un barco y el ancho su ventana de tiempo.

55

Figura 43 – Ejemplo de distribución gráfica de llegada de barcos de un archivo de entrada

La simulación se desarrolló bajo cinco escenarios distintos en relación a distintos valores para los

factores factorCantidadBarcos y factorSlack. Los cinco escenarios distintos se desarrollaron bajo las siguientes combinaciones factorCantidadBarcos/factorSlack: 80%/20%; 60%/40%; 50%/50%; 40%/60%; 20%/80%. Para obtener los resultados se utilizaron 4 archivos de entrada y sobre ellos se realizaron 10 ejecuciones bajo cada escenario para un total de 200 ejecuciones. Los resultados de la simulación se presentan a continuación en tres gráficos: Asignación de Barcos, Costos Totales de Secuencia y Costos de Slack.

En la Figura 44, se muestran cinco gráficos con los resultados de distintas distribuciones de barcos

sobre cada punto de atraque según distintos valores para las variables factorCantidadBarcos y factorSlack. En esta figura se puede observar comparativamente que de manera natural para cada escenario la heurística intenta mantener un equilibrio en la cantidad de barcos que se asignan a cada punto de atraque, rondando la solución simple de cinco barcos por cada berth. Como mínimo se asignan 3 barcos y como máximo 8 a cada punto. De manera esperable se observa además que bajo escenarios de restricción fuerte sobre la cantidad de barcos y restricción débil sobre los tiempos de ocio (escenarios a y b), la heurística privilegia una equilibrada distribución de los barcos en el muelle, mientras que para los escenarios de restricción fuerte sobre el tiempo de ocio y restricción débil para la cantidad de barcos (escenarios d y e), la heurística privilegia el menor tiempo de ocio de cada berth entre las llegadas de los barcos. Hay que destacar que si bien el escenario (a) es el que mejor solución brinda en términos de distribución de carga de trabajo, fue el único en el que no fue posible entregar asignación a todos los barcos entrantes, atendiendo a 49 de los 50 barcos.

56

Nº Barcos vs Berths

0

1

2

3

4

5

6

7

berth1 berth2 berth3 berth4 berth5 berth6 berth7 berth8 berth9 berth10

0,8/0,2

Nº Barcos vs Berths

0

1

2

3

4

5

6

7

8

berth1 berth2 berth3 berth4 berth5 berth6 berth7 berth8 berth9 berth10

0,6/0,4

Nº Barcos vs Berths

0

1

2

3

4

5

6

7

berth1 berth2 berth3 berth4 berth5 berth6 berth7 berth8 berth9 berth10

0,5/0,5

Nº Barcos vs Berths

0

1

2

3

4

5

6

7

berth1 berth2 berth3 berth4 berth5 berth6 berth7 berth8 berth9 berth10

0,4/0,6

Nº Barcos vs Berths

012

3456

789

berth1 berth2 berth3 berth4 berth5 berth6 berth7 berth8 berth9 berth10

0,2/0,8

(a) factorCantidadBarco: 0,8 ; factorSlack: 0,2 (b) factorCantidadBarco: 0,6 ; factorSlack: 0,4

(c) factorCantidadBarco: 0,5 ; factorSlack: 0,5

(d) factorCantidadBarco: 0,4 ; factorSlack: 0,6 (e) factorCantidadBarco: 0,2 ; factorSlack: 0,8

Figura 44 – Gráficos de distribuciones de barcos versus berths (según factoresCantidadBarco y factorSlack)

57

Costos de Secuencias Totales

0

5

10

15

20

25

30

berth1 berth2 berth3 berth4 berth5 berth6 berth7 berth8 berth9 berth10

0,2/0,8

Costos de Secuencias Totales

0

5

10

15

20

25

30

berth1 berth2 berth3 berth4 berth5 berth6 berth7 berth8 berth9 berth10

0,8/0,2

Costos de Secuencias Totales

0

5

10

15

20

25

30

berth1 berth2 berth3 berth4 berth5 berth6 berth7 berth8 berth9 berth10

0,6/0,4

Costos de Secuencias Totales

0

5

10

15

20

25

30

berth1 berth2 berth3 berth4 berth5 berth6 berth7 berth8 berth9 berth10

0,5/0,5

Costos de Secuencias Totales

0

5

10

15

20

25

30

berth1 berth2 berth3 berth4 berth5 berth6 berth7 berth8 berth9 berth10

0,4/0,6

En la Figura 45 se muestran los gráficos de costos totales calculados de las diez secuencias para los cinco escenarios. Se puede observar que partiendo por el escenario de restricción fuerte sobre la cantidad de barcos (a), el costo total se representa en principio casi como una línea recta, manteniéndolo controlado equitativamente para cada punto de atraque, hasta llegar al escenario extremo de restricción fuerte sobre los tiempos de ocio (e), el cual no muestra una distribución uniforme como en el resto de los escenarios, sin embargo logra alcanzar en dos puntos de atraque (berth1 y berth8), costos más bajos que cualquier otro escenario, aunque en la suma el costo total supera a todo el resto.

(a) factorCantidadBarco: 0,8 ; factorSlack: 0,2 (b) factorCantidadBarco: 0,6 ; factorSlack: 0,4

(c) factorCantidadBarco: 0,5 ; factorSlack: 0,5

(d) factorCantidadBarco: 0,4 ; factorSlack: 0,6 (e) factorCantidadBarco: 0,2 ; factorSlack: 0,8

Figura 45 – Gráficos de costos de secuencias totales versus berths

58

Costos de Slack

0

5

10

15

20

25

30

35

berth1 berth2 berth3 berth4 berth5 berth6 berth7 berth8 berth9 berth10

0,8/0,2

Costos de Slack

0

5

10

15

20

25

30

35

berth1 berth2 berth3 berth4 berth5 berth6 berth7 berth8 berth9 berth10

0,6/0,4

Costos de Slack

0

5

10

15

20

25

30

35

berth1 berth2 berth3 berth4 berth5 berth6 berth7 berth8 berth9 berth10

0,2/0,8

Costos de Slack

0

5

10

15

20

25

30

35

berth1 berth2 berth3 berth4 berth5 berth6 berth7 berth8 berth9 berth10

0,4/0,6

Costos de Slack

0

5

10

15

20

25

30

35

berth1 berth2 berth3 berth4 berth5 berth6 berth7 berth8 berth9 berth10

0,5/0,5

En el tercera Figura 46, se muestran comparativamente los costos de ocio de los puntos de atraque bajo cada escenario, el cual si se contrasta con el gráfico anterior de costos totales, resulta interesante de analizar que el escenario de mejor resultado es el de restricción débil a cantidad de barcos y restricción fuerte para tiempos de ocio (e), que en la suma posee un costo total de slack menor a cualquier otro escenario.

(a) factorCantidadBarco: 0,8 ; factorSlack: 0,2 (b) factorCantidadBarco: 0,6 ; factorSlack: 0,4

(c) factorCantidadBarco: 0,5 ; factorSlack: 0,5

(d) factorCantidadBarco: 0,4 ; factorSlack: 0,6 (e) factorCantidadBarco: 0,2 ; factorSlack: 0,8

Figura 46 – Gráficos de costos de slack versus berths

59

Finalmente, se puede ver que los resultados de la simulación son los esperados y el sistema bajo el uso de factores y una heurística sencilla, propone una forma simple de implementar distintos escenarios de acuerdo a los objetivos que se tengan en mente, ya sea de una equitativa distribución de la carga de trabajo entre los puntos de atraque o de minimizar los tiempos de ocio de cada uno de ellos, aumentando la eficiencia en el trabajo global del muelle.

60

Capítulo 7

CONCLUSIONES

En este trabajo se ha presentado uno de los tantos problemas que se pueden encontrar en el

funcionamiento diario de un muelle, el berth allocation problem (BAP) o problema de asignación de puntos de atraque a los barcos entrantes. Se ha revisado la complejidad del problema, su modelamiento matemático, sus variantes y su similitud con otros problemas ligados al área de investigación de operaciones, como el del problema de ruteo de vehículos o Vehicle Routing Problem. Con respecto a esto, se estudió el estado del arte en cuanto a los distintos algoritmos de solución existentes hasta el momento, que resuelven distintas variantes del BAP desde un punto de vista centralizado. Debido a la naturaleza distribuida del problema y bajo la necesidad de ofrecer una solución enfocada a un mejoramiento en la calidad de servicio que entrega el muelle a los barcos que deseen atracar en él, es que se ha propuesto como alternativa el uso de la tecnología de agentes en la construcción de un sistema multiagente que resuelva el problema de una forma innovadora en lograr tal enfoque.

En el proceso de construcción del sistema, en primer lugar se han revisado las características de los agentes, las arquitecturas sobre las cuales se construyen, interactúan y resuelven problemas. Luego, aplicando una metodología de trabajo específica para los sistemas multiagentes, se ha expuesto el resultado del desarrollo de cada uno de los pasos definidos por la metodología, en la creación de la especificación funcional y técnica del sistema.

Utilizando la especificación antes señalada, y utilizando una infraestructura técnica ad hoc se

construyó un sistema multiagente capaz de entregar una solución al problema, cumpliendo así el objetivo principal de este trabajo.

La arquitectura multiagente del sistema, en forma resumida consta de un agente Barco y un agente

Berth, más un agente Muelle que actúa de coordinador y mediador en el proceso de negociación entre los dos primeros.

Como objetivo secundario se buscó analizar la forma en que el sistema multiagente podía brindar

una mejora en la calidad de servicio del muelle, más que el simple hecho de resolver el problema de asignación. Mediante el uso de una heurística sencilla común para cada agente Berth, cada uno de ellos propone una alternativa de asignación con un costo asociado, alternativa que en un proceso de negociación el agente Muelle decidirá cual de ellas es la “mejor”. Este costo asociado consideró básicamente la cantidad de barcos que ya posee asignado el punto de atraque y la suma de los tiempos ociosos en que el punto de atraque debe esperar la llegada de cada barco en su secuencia de trabajo. Para poder cumplir con este objetivo secundario es que, para el cálculo de este costo de asignación que propone cada berth, se definieron restricciones en la forma de factores, tanto para la cantidad de barcos como para los tiempos ociosos, que permitieran analizar los resultados desde distintos escenarios.

Los resultados mostraron que cada escenario propone una solución factible para el problema con

diversos matices que proponen ventajas y desventajas de acuerdo a los objetivos que se tracen en el funcionamiento global del muelle.

De acuerdo al análisis de los resultados, se concluye que los escenarios que ponen menor énfasis en

los tiempos ociosos y mayor énfasis sobre las cantidades de barcos, proponen soluciones de distribución equitativa a cada punto de atraque, lo que puede resultar beneficioso en cuanto a equilibrar la carga de trabajo que cada punto de atraque posee, y en consecuencia disminuir costos de mantención si es que algunos puntos trabajaran más que otros. Además, bajo este escenario, se fomenta la competitividad entre equipos de trabajos asociados a cada punto de atraque, y se asegura siempre un mínimo de barcos a atender en el horizonte de tiempo. Como desventaja se puede concluir que bajo este escenario, existe mayor riesgo a la hora de enfrentar una emergencia como que un punto de atraque falle. Al poseer casi todos los puntos un número similar de

61

barcos asignados, existe un mayor riesgo de no poder reubicar los barcos en otros puntos distintos. Igualmente un hecho inesperado como el anuncio del atraque de un barco como emergencia, puede que bajo este escenario el muelle no sea capaz de asignarle un punto de atraque. Estos hechos inesperados pueden ser manejados de mejor manera en un escenario que privilegie una disminución en los tiempos de espera entre atenciones. Puesto que la solución para estos casos será de menor “densidad” en el horizonte de tiempo, es posible que un hecho como que un punto de atraque falle o que un barco solicite un atraque de emergencia no sea tan complicado de resolver, puesto que casi siempre existirá algún punto de atraque con menor carga que el resto.

Considerando la comparación de los escenarios del párrafo anterior, se puede concluir que conseguir

soluciones que brinden una mayor calidad de servicio, desde el punto de vista de la oferta por parte del muelle, es posible y dependerá de los factores a tomar en cuenta en la heurística, donde se calcula el costo de inserción que cada punto de atraque propone. Un factor a tener en cuenta en este proceso sería, por ejemplo, el tiempo de espera de atención de los barcos, el cual debe ser minimizado.

Como trabajo a futuro es posible añadir complejidad considerando nuevas variables como el

trasbordo de contenedores entre un barco y otro; el apilamiento de contenedores a la espera del embarque; el tamaño variable de los barcos, y que algunos necesiten ocupar más de una sección del muelle; la presencia de distintas maquinarias en cada punto de atraque ofreciendo distintas velocidades de procesamiento. Es posible ir considerando cada uno de estos valores para darle completitud a la solución propuesta por el sistema. Además, sería importante agregar al sistema actual la posibilidad de optimizar la solución inicial factible mediante un proceso del agente Muelle.

Finalmente, se puede concluir que el sistema bajo una arquitectura multiagente, propone una

solución al Berth Allocation Problem más que aceptable considerando la complejidad y el costo que significa resolver problemas de este tipo en forma centralizada. Si bien, el problema se acotó bastante como para construir un sistema con una heurística simplificada, éste se puede considerar como una buena base de desarrollo para futuras mejoras y proyectos en paralelo.

62

Capítulo 8

REFERENCIAS [1] United Nations Conference on Trade And Development (UNCTAD). Review Maritime Transport, Cap V pags. 73-74, Cap VII. 2005. [2] Vincent J. Botti, Universidad Politécnica de Valencia. Multi-Agent System Technology in a Port

Contenedor Terminal Automation. Ercim News, Número 56 Enero ,pags 37-39, 2004. [3] Jean Francois Cordeau, Gilberto Laporte, Pasquale Legato, Luigi Moccia. Models and tabu search

heuristics for the berth allocation problem. Abril 4, 2004. [4] Jean Francois Cordeau, Manlio Gaudioso, Gilberto Laporte, Pasquale Legato, Luigi Moccia. (2003) Solving Berth Scheduling and Yard Management Problems at the Gioia Tauro Maritime Terminal.

CITESEER.IST Scientific Literature Digital Library (http://citeseer.ist.psu.edu/). [5] RAE “Real Academia de la Lengua Española”. http://www.rae.es (Online). [6] Michael Wooldridge, “An Introduction to Multiagent Systems”. Dept. of Electronic Enginee-ring, Queen Mary & Westfield College,2002

[7] Enciclopedia Virtual Wikipedia. http://es.wikipedia.org (Online). [8] Haddadi, A; y Sundermeyer K. Belief-Desire-Intention Agent Architectures. Wiley-Interscience Publication , 1996. [9] Rao, A.S.; y Georgeff, M.P.: BDI Agents from Theory to Practice. Proceedings of the First International Conference on Multi-Agents Systems (ICMAS-95), 1995. [10] Brooks, R.A.: Intelligence without Representation, Artificial Intelligence, 47, 139-159, 1991. [11] Foundation of Intelligent Physical Agents (FIPA), “FIPA ACL Message Structure Specification”. http://www.fipa.org (Online). [12] Austin, J.A.: How to do things with words. Oxford University Press, Oxford. 1962. [13] Jacobson, I; G.Booch; y J. Rumbaugh: El Proceso Unificado de Desarrollo de Software, Addison Wesley. 2000. [14] eXtreme Programming, http://www.extremeprogramming.org/ (Online). [15] Kinny, D.; M.Georgeff; y A.Rao: A Methodology and Modelling Technique for Systems of BDI Agents. Australian Artificial Intelligence Institute. 1997. [16] Schreiber, A.; J. Wielinga; J. Akkermans; y W.V. de Velde: CommonKADS: A compre-hensive

methodology for KBS development, University of Amsterdam, Netherlands Energy Research Foundation ECN and Free University of Brussels. 1994. [17] Caire, G.;F. Leal; P. Chainho; R. Evans; F. Garijo; J.J. Gómez-Sanz; J. Pavon; P.Kerney; J.Stark; y P.Massonet: Agent Oriented Analysis using MESSAGE/UML, Springer Verlag. 2001.

63

[18] Lind, J.:MASSIVE: Software Engineering for Multiagent Systems, University of the Saarland. 2000 [19] Wooldridge, M.; N.R.Jennings; y D.Kinny: The Gaia Methodology for Agent-Oriented Analysis and

Design. Journal of Autonomous Agents and Multi-Agent Systems 3(3) 285-312. 2000 [20] DeLoach, S.A.;M. Wood; y C.H. Sparkman: Multiagent Systems Engineering. International Journal of Software Engineering and Knowledge Engineering 11(3). 2001. [21] C.Daganzo, The Crane Scheduling Problem, Transportation Research B 23B, 159-175. 1989. [22] Pinedo, M: Scheduling: Theory, Algorithms and Systems, Prentice-Hall, Englewood Cliffs, NJ. 1995. [23] Garey, M.R.; y Johnson,D.S.:Computers and Intractability: Aguide to the Theory of NP-Completeness, Freeman, San Francisco. 1979. [24] Imai, A.; Nishimura, E; y Papadimitriou, S.: The dynamic berth allocation problem for a contenedor

port, Transportation Research 35B, 401-417. 2001. [25] Imai, A.; Nagaiwa, K; y Chan, W.T.: Efficient planning of berth allocation for contenedor terminals in

Asia, Journal of Advanced Transportation 31, 75-94. 1997. [26] Papadimitriou, C.H.; y Steiglitz, K.: Combinatorial Optimization; Algorithms and Complexity, Prentice-Hall, Englewood Cliff, NJ. 1982. [27] Nishimura, E; Imai,A.;Papadimitriou, S.: Berth allocation planning in the public berth system by genetic

algorithms, European Journal of Operational Research 131, 282-292. 2001. [28] Imai, A.; Nishimura, E.; Papadimitriou, S.: Berth allocation with service priority, Transportation Research 27B, 437-457. 2003. [29] Lim, A.: The berth plnning problem, Operations Research Letters 22, 105-110. 1998. [30] Park, Y.M.; y Kim, K.H.: A scheduling method for berth and quay cranes, OR Spectrum 25, 1-23. 2003. [31] Kimm, K.H.; y Moon, K.C.: Berth scheduling by simulated annealing. Transportation Research 37B, 541-569. 2003. [32] Guan, Y.; y Cheung, R.: The Berth Allocation Problem: Models and Solution Methods. Department of Industrial Engineering and Engineering Management.2003. [33] Cubillos, F.; Guidi-Polanco, F.; Demartini, C.: MADARP: Multi-Agent Framework for Passenger

Transportation Systems. 2005. [34] National University of Singapore (NUS), The RAS Group. http://www.nus.edu.sg/ (Online) [35] Guan, Y.; Xiao, W.; Cheung, R.; Li, C.: A Multiprocessor task scheduling model for the berth allocation:

heuristic and worst-case analysis. Operations Research Letters 30, 343-350. 2002. [36] Thangiah, S.; Shmygelska, O.; Mennell, W.: An Agent architecture for Vehicle Routing Problems. 2001. [37] JADE, Java Agent Development Framework, http://jade.tilab.com/. [38] Cordeau, J.F.; Gendreau, M.; y Laporte, G:.A tabu search heuristic for periodic and multi-depot vehicle

routing problems, Networks 30, 105-119. 1997.

64

[39] Cordeau, J.F.; Laporte, G; y Mercier, A.: A unified tabu search heuristic for vehicle routing problems

with time windows, Journal of the Operational Research Society 52, 928-936. 2001. [40] Listado de Instancias y mejores soluciones para el Multi-Depot vehicle Routing Problem with Time

Windows. http://neo.lcc.uma.es/radi-aeb/WebVRP/main.html [41] Jaw, J., Odoni, A.R., Psaraftis H N, Wilson, NHM. “A heuristic algorithm for the Multi-Vehicle

Advance-Request Dial-a-Ride Problem with Time Windows”. Transportation Research B, Vol 20B, Nº 3, 1986, pp. 243 – 257. [42] Mas, Ana. “Agentes Software y Sistemas Multi-Agente: Conceptos, Arquitecturas y Aplicaciones”. 2005, Pearson Education.