117

Capítulo 4. Implementación de la Arquitectura: Plataforma de

Simulación SCOPE

4.1. Introducción

En este capítulo se presenta la implementación del modelo descrito en el Capítulo 3 en una

plataforma para desarrollo de MAS, dando lugar a la Plataforma de Simulación SCOPE. La

implementación se ha llevado a cabo mediante las librerías de Swarm para Java (Swarm

Development Group Wiki, 2003). En el apartado 1.3.2 ya se hizo una breve introducción a

ésta y otras plataformas de desarrollo de MAS.

Para su programación se ha utilizado el IDE NetBeans 6.7 (NetBeans). También ha sido

necesario el uso de Gurobi 4.01 para la optimización de los modelos de planificación

utilizados por los agentes Master Planning y Production Planning (ver apartados

3.3.2.3 y 3.3.2.4). Gurobi es un software comercial para la optimización de problemas lineales

enteros-mixtos de gran tamaño. La conexión de Gurobi con el IDE NetBeans es muy sencilla

gracias a unas bibliotecas en Java obtenidas directamente de la página oficial de Gurobi

(Gurobi Optimization). Una vez instaladas las bibliotecas se pueden programar y resolver los

modelos directamente desde el IDE.

El capítulo comienza con una breve descripción de Swarm, sus elementos principales y su

arquitectura. Posteriormente se relacionan los elementos de la arquitectura explicada en el

capítulo anterior con los elementos de la plataforma Swarm, que dan lugar a los agentes,

swarms, objetos y archivos de configuración que forman SCOPE. Finalmente se describen las

posibles aplicaciones de la plataforma SCOPE.

4.2. Swarm

Swarm es una plataforma multi-agente para la simulación de sistemas complejos

adaptativos (Minar et al., 1996). Fue diseñado como un lenguaje genérico para ser utilizado

en una amplia variedad de dominios científicos, incluyendo herramientas que resultarán útiles

en la mayoría de modelos, y excluyendo herramientas específicas para algún dominio en

concreto (Railsback et al., 2006).

118

El formalismo adoptado por Swarm para el modelado consiste en una colección de agentes

independientes interactuando vía simulación de eventos discretos mediante calendarios que

contienen las acciones ordenadas en el tiempo. Mediante esta arquitectura, Swarm no hace

suposiciones sobre el tipo de modelo que se quiere implementar. La unidad básica es el

agente, que es cualquier entidad del sistema que pueda generar eventos que afecten a sí

mismo o a otros agentes. El paso del tiempo en Swarm se modela mediante la sucesión de

dichas acciones.

Los agentes se organizan dentro de un objeto llamado swarm. Un swarm es una colección

de agentes con un calendario de eventos asociado y representa un modelo completo.

Normalmente un agente es modelado mediante una serie de reglas que responden a ciertos

estímulos. Sin embargo un swarm puede ser al mismo tiempo un agente. En este caso el

comportamiento del agente se define mediante el comportamiento emergente de los agentes

que forma el swarm. De esta forma se pueden crear modelos jerárquicos, anidando múltiples

swarms. Esta característica es muy potente, permitiendo a los usuarios construir

explícitamente modelos multi-nivel.

Swarm ha sido implementado tanto en Objective C como en Java, ambos lenguajes

orientados a objetos. Los agentes son modelados como objetos, y las acciones que realizan

mediante métodos. Los calendarios son el motor de la simulación: son estructuras de datos

donde se ordenan las acciones a realizar sobre cada objeto. Estas acciones especifican en cada

caso el método que será ejecutado en el agente correspondiente.

Swarm permite observar la evolución de cualquier objeto durante la simulación mediante

una interfaz específica. La manera habitual de hacerlo es incluyendo el swarm Modelo dentro

de un swarm Observador. En el swarm Observador existirán agentes observadores cuyo

propósito es recolectar información sobre otros agentes. Otra función de este swarm es el

control de la simulación.

En resumen, la estructura general de un modelo en Swarm se compone de dos elementos:

- un swarm Observador formado por una serie de agentes observadores con al menos

un calendario de acciones y un swarm Modelo.

- un swarm Modelo formado por los agentes del modelo y al menos un calendario de

acciones. Los agentes del modelo pueden ser a su vez otros swarms anidados.

119

Swarm se compone de un total de siete librerías de clases diseñadas para trabajar en

conjunto: defobj, collections, random, tkobj, activity, swarmobject y simtools. Las cuatro

primeras son librerías de soporte que tienen un uso potencial fuera de Swarm. Las tres últimas

son específicas para Swarm. Estas librerías están formadas por una serie de clases que el

usuario puede usar directamente en su modelo, aunque también es posible crear nuevas clases

(hijas) a partir de las ya incluidas (padres) heredando sus métodos y especializándolas según

las necesidades concretas del modelo. A continuación se describen brevemente las funciones

principales de cada librería:

- swarmobject: contiene las clases principales en las que están basadas los agentes en

Swarm. Las clases SwarmObject (para el modelado de agentes) y Swarm para el

modelado de swarms se encuentran en esta librería.

- activity: contiene el núcleo del mecanismo de simulación, las estructuras de datos para

los calendarios y el soporte para la ejecución.

- simtools: contiene las clases necesarias para construir y ejecutar las simulaciones.

Pueden operar de dos formas distintas: en modo gráfico o en modo batch para la

recolección de datos offline.

- defobj: define la infraestructura del modelado de objetos para Swarm.

- collections: implementa las clases necesarias para el seguimiento de los objetos en el

sistema: mapas, listas, vectores, etc.

- random: es una colección de generadores de números aleatorios.

- tkobjc: librería gráfica para interfaz de usuario basada en Tcl/Tk.

Se ha elegido Swarm frente a otras muy populares como JADE o Repast porque permite la

programación a bajo nivel, ampliando las posibilidades de desarrollo. Además, su jerarquía

anidada estructurando el modelo en swarms facilita el modelado de las redes de suministro.

Según Lin et al. (1998) la plataforma Swarm es muy apropiada para el modelado de redes de

suministro. En la Tabla 4.1, extraída del trabajo desarrollado por Lin et al. (2002), se

muestran las características que hacen que Swarm sea una herramienta adecuada para modelar

redes de suministro.

120

Tabla 4.1. Adecuación de Swarm para modelar redes de suministro (Lin et al., 2002)

Red de Suministro Swarm

Compuesta de entidades autónomas y semiautónomas Swarm de agentes modelados individualmente

Las entidades actúan de diferentes formas Los agentes se construyen con variables de estado

internas y funciones

Múltiples niveles de abstracción Jerarquía anidada inherente

Flujo de información entre entidades Paso de mensajes entre agentes

Flujo de materiales durante las actividades de

obtención de materias primas, fabricación, y

distribución

Simulación de eventos discretos y calendarios para

activar las acciones de los agentes

Rendimiento global obtenido a partir de los procesos

de las entidades individuales

Comportamiento colectivo obtenido a partir de la

combinación de los comportamientos individuales

La visibilidad viene determinada por el intercambio de

información

La visibilidad viene determinada por el paso de

mensajes

4.3. Implementación del modelo

El diseño conceptual del modelo descrito en el apartado 3.2 se adapta perfectamente al

concepto de swarms descrito en el apartado anterior. La posibilidad de agrupar los agentes en

swarms y poder anidarlos unos dentro de otros facilita la organización del modelo y permite

estudiar fenómenos a diferentes niveles de profundidad.

Puesto que el modelado mediante MAS se corresponde con una metodología ―de abajo

hacia arriba‖ (de mayor a menor detalle) se comienza modelando la capa de mayor detalle,

que en este caso son los agentes funcionales (capa funcional). Cada uno de los agentes

funcionales descritos en el Capítulo 3 se corresponde con un agente en Swarm, y cada una de

las funcionalidades descritas en el mismo capítulo se corresponde con uno o varios métodos

en Java. Además también se describieron una serie de objetos auxiliares, que se corresponden

con objetos de Java (instancias de clases Java). Estos objetos se diferencian de los agentes en

que son simples contenedores de información, y sus métodos son utilizados por los agentes

para modificar algunas de sus variables internas, mientras que los agentes disponen de

métodos para interaccionar con otros agentes, crear y destruir objetos, pasar información, etc.

En el apartado 4.3.1 se describen estos agentes con más detalle.

121

En el siguiente nivel de detalle se encuentra la capa empresarial, donde los agentes se

corresponden con las empresas de la red de suministro. Cada empresa es en este caso un

swarm formado por una cierta combinación de agentes funcionales (ver apartado 3.3) y una

serie de calendarios para activar los métodos de estos agentes. Al irse activando los métodos

de los calendarios los agentes van realizando sus funciones e interaccionando entre sí,

emergiendo así el comportamiento de la empresa. En el apartado 4.3.2 se describe este swarm

con más detalle.

En el siguiente nivel se encuentra el swarm Modelo, que representa el modelo completo de

la red de suministro. Está formado por todos los swarms empresa del modelo y su función es

la creación de dichas empresas y la activación de sus calendarios. En el apartado 4.3.3 se

describe este swarm con más detalle.

En el último nivel se encuentra el swarm Observador, que contiene al swarm Modelo. Al

ser el swarm de nivel superior se encarga de controlar la simulación y los menús de usuario,

así como de recopilar la información que los agentes van almacenando y su presentación

final. En el apartado 4.3.4 se describe este swarm con más detalle.

Además de los objetos, los agentes y los swarms, la implementación del modelo necesita

un último elemento: los archivos de configuración. Los elementos anteriores son estructuras

genéricas reutilizables, que carecen de significado y funcionalidad si no se personalizan sus

variables internas. Además es necesario indicar a los agentes con quiénes son sus proveedores

y sus clientes. Todo esto se hace mediante la edición de un conjunto de ficheros de texto,

descritos con detalle en el apartado 4.3.5.

Para mejor comprensión de la relación entre los elementos del modelo y su

implementación en Swarm, se describe gráficamente en la Figura 4.2 cómo sería la estructura

del modelo en Swarm para una red de suministro sencilla, como la de la Figura 4.1. Esta red

de suministro está formada por los siguientes participantes:

- Dos Proveedores que suministran materias primas a una Fábrica.

- Una Fábrica con capacidad de planificación de la producción, que fabrica ciertos

productos y los vende a dos Distribuidores.

- Dos Distribuidores sin capacidad de previsión de la demanda, que venden los

productos que obtienen de la Fábrica a un Cliente.

122

- Un Cliente, que compra productos a los dos Distribuidores.

Figura 4.1. Red de suministro ejemplo

Figura 4.2. Estructura de la implementación en Swarm para la red de la Figura 4.1

4.3.1. Agentes

Cada agente funcional del modelo es implementado en una clase Java diferente. Los

agentes participantes en una simulación son instancias de estas clases Java. Las instancias

tendrán unos valores de sus variables internas diferentes, lo que diferenciará a unos agentes de

123

otros. Sin embargo los métodos que utilicen serán los de la clase Java de la que han sido

instanciados.

Todas las clases Java que modelan los agentes se estructuran de la misma forma:

- Variables Internas: indican el estado de un agente y su comportamiento. Estas

variables son utilizadas por los métodos del agente, determinando cómo serán

ejecutados, y por tanto, cómo se comporta el agente en un instante determinado.

Algunas variables pueden cambiar durante la simulación (límites, políticas), mientras

que otras permanecen fijas (identificación del agente).

- Constructor: este método se ejecuta cada vez que se va a instanciar un agente a partir

de su clase correspondiente, y sirve para la inicialización de todas las variables. Puede

haber más de un constructor.

- Métodos: definen la forma de actuar de cada clase de agente. Serán los mismos para

todas las instancias de una misma clase, aunque pueden ser ejecutados de forma

distinta según las variables internas del agente. Cuando un método necesita

información externa al agente que lo ejecuta, esta información es pasada por

argumento desde la entidad que esté ejecutándolo. En función de quién activa los

métodos, éstos se clasifican en tres tipos diferentes:

Activados por calendarios: estos métodos son activados periódicamente por

algún calendario. Representan la parte más proactiva del agente pues son

ejecutados continuamente durante la simulación, definiendo su

comportamiento general.

Activados por otro agente: estos métodos son activados por otro agente para

dar una orden, para intercambiar información, o para enviar productos o

materiales. Representan la parte pasiva del agente, pues solo se activan cuando

otro agente lo necesita, siendo estos métodos la respuesta a dichas necesidades.

Activados por el propio agente: estos métodos suelen ser funcionalidades

auxiliares encapsuladas, bien por repetitividad en otros agentes (reutilización)

o bien por ser una funcionalidad bien definida y/o suficientemente compleja

como para poder separarse en otro método independiente, ayudando a

clarificar el código.

124

4.3.2. Swarm Empresa

Este es el swarm donde se agrupan los distintos agentes funcionales que forman una

empresa. Aunque su estructura básica es similar a la de un agente (Variables, Constructor y

Métodos), es en realidad mucho más compleja, pues debe ser capaz de modelar las distintas

configuraciones de la empresa (distinta composición de agentes funcionales), se deben

inicializar las variables de todos los agentes que lo forman, y se deben incluir algunos

métodos específicos de un swarm para crear los agentes y los calendarios.

- Variables: Se incluyen las variables de todos los agentes implementados, así como

todos los calendarios y los propios agentes. Cada agente dispone de al menos un

calendario asociado (algunos tienen dos calendarios). Cada calendario contendrá una

secuencia ordenada en el tiempo de acciones que llevará a cabo el agente al que está

asociado. Los calendarios ejecutan dicha secuencia de acciones y se repiten cada

cierto intervalo de tiempo (intervalo de repetición). Estos intervalos de repetición son

un factor determinante en la simulación, pues indican cada cuántos pasos de

simulación actúa cada agente, pudiendo ser diferentes para cada agente (se puede

modelar por ejemplo que un agente efectúe sus tareas diariamente mientras que otro lo

haga semanalmente).

- Constructor: Existen cuatro constructores diferentes: dos para el rol de Cliente Final

(se pueden definir de dos formas distintas, ver Anexo 2), uno para el rol de Proveedor

Final, y otro para Intermediario y Fábrica. Se encargan de inicializar únicamente las

variables correspondientes a los agentes que van a formar parte del swarm.

- Métodos: Hay dos grupos de métodos bien diferenciados en este swarm: en primer

lugar aparecen los métodos específicos de un swarm, para construir los calendarios

(buildActions) y los agentes (buildObjects), y para activar los calendarios (activateIn);

en segundo lugar aparecen el resto de métodos, que son en su mayoría métodos

activados por los calendarios encargados de activar los métodos correspondientes de

los agentes. A continuación se detallan los métodos específicos del swarm:

buildActions: Este método se encarga de generar los grupos de acciones que

llevarán a cabo los agentes y asociarlos a los calendarios. Durante la

simulación, cuando un calendario ejecuta un grupo de acciones, se buscan los

métodos que tenga asociados y son ejecutados en el orden en que han sido

125

añadidos al grupo. Todas las acciones (métodos) que deben realizar los agentes

periódicamente tienen que asociarse a algún calendario dentro de este método.

Sólo se construyen los calendarios asociados a los agentes que formarán parte

del swarm de acuerdo al rol que tendrá la empresa. El procedimiento para crear

un grupo de acciones y asociarlo a un calendario es el siguiente:

1. Se crea un objeto ActionGroup.

2. Se le añaden tantos métodos como se desee.

3. Se crea un nuevo calendario, al que se le asocia el intervalo de

repetición correspondiente.

4. Se le añade el ActionGroup y se ordena temporalmente. Un calendario

puede contener un número ilimitado de objetos ActionGroup.

buildObjects: Este método crea todos los agentes del swarm. En función del

rol que va a desempeñar la empresa se crean solo los agentes correspondientes.

Las variables necesarias para la creación de los agentes han sido inicializadas

previamente por el constructor apropiado.

activateIn: Finalmente este método se encarga de activar los calendarios de los

agentes que componen el swarm, ejecutando el método activateIn de cada uno

de ellos. El orden en que se programa la activación de los calendarios

determina el orden en que serán ejecutadas las acciones en caso de activarse

varios en el mismo instante de tiempo. Por tanto, aquí se está definiendo el

orden en que la empresa llevará a cabo sus acciones, siendo crucial que se

ajuste lo máximo posible al modelo que se quiera simular. Aunque han sido

programados de forma realista, puede ser necesario modificar este orden para

modelar algún caso concreto que no se ajuste con el orden actual. Esto ha sido

crucial para validar la SCOPE, como se verá en el siguiente capítulo.

4.3.3. Swarm Modelo

Como ya se ha comentado, este swarm representa el modelo completo de la red de

suministro. Es el medio o el entorno en el que ―habitan‖ las empresas del modelo. Por tanto,

mediante los métodos específicos del swarm comentados en el apartado anterior se deben

126

crear todas las empresas del modelo y activar sus calendarios. La estructura del swarm es

similar a las anteriores.

- Variables: Las variables principales de este swarm son los agentes (los swarm

Empresa) que lo forman. Además hay otras tres variables importantes relacionadas

con la logística inversa, que son las siguientes:

PreverseLogistic: si se pone esta variable a true se está permitiendo a las

empresas devolver productos a sus proveedores si al revisar su inventario se

observa que se dispone de una cantidad mayor que la deseada.

MreverseLogistic: si se pone esta variable a true se está permitiendo a las

fábricas devolver materiales a sus proveedores si al revisar su inventario se

observa que se dispone de una cantidad mayor que la deseada.

reverseCustomerOrders: si se pone esta variable a true se está permitiendo a

los Clientes realizar pedidos negativos.

- Constructor: Las variables anteriores son seleccionadas manualmente, por lo que el

constructor en este caso no hace nada.

- Métodos: Sólo dispone de los métodos específicos de un swarm. Los métodos

buildActions y activateIn se limitan a activar estos mismos métodos en cada agente del

modelo. De esta forma se crean y se activan los calendarios de cada agente. El método

buildObjects lee desde el archivo de configuración general (ver apartado 4.3.5) toda la

información referente a los agentes (swarms Empresa) que debe crear, y los va

creando uno a uno. Conforme los crea activa el método buildObjects de cada swarm

Empresa para que éste a su vez cree sus propios agentes.

Igual que en el swarm Empresa el orden de activación de los calendarios determinaba el

orden de las acciones que llevan a cabo los agentes que lo forman, en el swarm Modelo el

orden de activación de los calendarios afecta de la misma forma. Ahora los agentes son las

Empresas de la red de suministro, por lo que aquí se determina el orden de actuación de las

mismas. Éste es un factor importante en el modelado pues probablemente no se consigan los

mismos resultados si el orden de actuación de las Empresas va desde los Proveedores Finales

hasta los Clientes Finales, o si va en sentido inverso, o si es totalmente aleatorio. SCOPE

viene programado por defecto para que el orden de actuación vaya desde los Clientes Finales

127

hasta los Proveedores Finales, por ajustarse a la mayoría de los casos, pero puede

reprogramarse fácilmente si fuera necesario. El método activateIn activa los calendarios de

las Empresas del modelo según su orden de creación. Por tanto es el orden de creación de los

agentes en el método buildObjects lo que determina el orden de actuación de las Empresas.

4.3.4. Swarm Observador

Este es el swarm de más alto nivel. Contiene al swarm Modelo y se encarga del control de

la simulación y de extraer información de los agentes del Modelo cuando ésta termina para

presentarla al usuario. La estructura del swarm es similar a las anteriores.

- Variables: Las variables principales de este swarm son un calendario para controlar la

ejecución de la simulación y el swarm Modelo. Además existen unas variables

asociadas a la simulación que se explican a continuación:

simulationTime: número de pasos que tendrá la simulación. Si a cada paso se

le asocia un intervalo de tiempo, equivale al tiempo de simulación.

warmUpTime: los resultados de la simulación serán obtenidos ignorando lo

ocurrido antes de este tiempo.

day: número de pasos de simulación que equivalen a un día. Solo se utiliza

como referencia para mostrar algunos resultados.

updatingTime: el Observador puede necesitar chequear periódicamente ciertas

variables de los agentes del modelo para la obtención de los resultados. En ese

caso el valor de esta variable indica el periodo entre chequeos. Actualmente

sólo se utiliza para obtener información sobre los inventarios de los agentes

(ver apartado 4.3.5.6).

Al comenzar la simulación aparecerá un menú con estos parámetros de simulación

(ver Figura 4.3) y su valor por defecto será el que tengan en el código de

programación. Por tanto si se desea realizar una gran cantidad de experimentos con los

mismos valores de estos parámetros se puede modificar directamente en el código,

aunque también es posible introducir valores distintos en cada simulación a través de

dicho menú.

128

- Constructor: Aquí es donde se incluyen los parámetros en el menú comentado en el

párrafo anterior. Es posible añadir otras variables a dicho menú muy fácilmente si

fuera necesario en un futuro.

- Métodos: Se incluyen, además de los métodos específicos del swarm, dos métodos

para el control de la simulación y uno para la obtención de datos y presentación de los

resultados de la simulación:

buildActions: En primer lugar ejecuta el método buildActions del swarm

Modelo. A continuación asocia el método stopRunning (comentado

posteriormente) a un calendario especial que se ejecutará una sola vez, cuando

se alcance un número de pasos de simulación igual al valor del parámetro

simulationTime.

buildObjects: Se construyen los objetos del swarm Modelo ejecutando el

método buildObjects de dicho swarm. A continuación se construye el Panel de

Control de la simulación y el Menú de Usuario (Figura 4.3) donde se incluyen

los parámetros declarados en el Constructor.

activateIn: Se activan los calendarios del swarm Modelo ejecutando el método

activateIn de dicho swarm. Luego se activan los calendarios del propio swarm

Observador.

go: Este método es activado presionando el botón Start desde el Panel de

Control (Figura 4.3) y se encarga de comenzar la simulación.

stopRunning: Este método es activado por un calendario al terminar el tiempo

de simulación. Activa el método exportData y termina la simulación.

exportData: Este método lee la información guardada por los agentes durante

la simulación y exporta dicha información a ficheros de texto. También se

calculan algunos índices de rendimiento a partir de la información obtenida,

vitales para la mejor comprensión de los resultados de la simulación. En el

archivo de configuración de análisis (ver apartado 4.3.5) se indica de qué

empresas se quiere obtener la información y qué tipo de información. En dicho

apartado se explicará con detalle qué tipos de resultados se pueden obtener y

cómo son presentados.

129

Figura 4.3. Panel de Control y Menú de Usuario

4.3.5. Archivos de configuración

Los últimos elementos que forman la plataforma SCOPE son los archivos de

configuración, que permiten configurar SCOPE para modelar una amplia variedad de redes de

suministro. La configuración se realiza mediante la edición de archivos de texto que permiten

determinar el número de empresas participantes y todas sus características, la estructura de la

red de suministro, las características de fabricación de los productos, la configuración de los

modelos de planificación, las posibles incertidumbres y los resultados que se van a mostrar.

La descripción detallada de cada archivo de configuración se encuentra en el Anexo 2, junto

con un ejemplo en el que explica cómo se modela una red de suministro simple mediante

dichos archivos.

4.4. Aplicaciones

En este apartado se pretende dar una visión general de las posibles aplicaciones de SCOPE.

Su uso puede enfocarse según dos líneas bien diferenciadas: un enfoque de usuario, que

quiere modelar una red de suministro utilizando las características actualmente

implementadas y estudiar los efectos de diferentes políticas y parámetros, o un enfoque de

investigación, para probar nuevas técnicas de gestión de la red de suministro, para lo cual

puede encontrar la plataforma SCOPE muy útil como base para programar dichas técnicas y

simular sus efectos.

130

Según en el primer enfoque, el uso de SCOPE permite modelar redes de suministro de

cualquier tamaño rápidamente gracias a que su arquitectura está basada en elementos

reutilizables (agentes y objetos). Además, se pueden configurar estructuras complejas de la

red de suministro definiendo adecuadamente las relaciones entre cada empresa. Las diferentes

opciones para configurar cada empresa permiten aumentar aún más la complejidad y el

realismo de la red de suministro modelada, pudiéndose configurar distintas políticas de

gestión de la demanda o de gestión de inventarios (personalizadas para cada producto de la

empresa). El número de productos que se manejan en la red de suministro también es

ilimitado, pudiéndose definir características de fabricación individuales para cada producto y

en cada fábrica. Las fábricas se pueden modelar también con bastante complejidad,

permitiendo incluir cualquier número de recursos productivos y de diferentes técnicas de

secuenciación (incluyendo heurísticas). Para comprobar la robustez de la red de suministro se

pueden modelar algunas incertidumbres típicas de estos sistemas mediante la inclusión de

funciones aleatorias en la demanda de los clientes, los tiempos de funcionamiento de los

recursos productivos, los tiempos de transporte de los productos y la disponibilidad de

suministro de los proveedores externos. Por último, es posible comprobar los efectos de las

configuraciones elegidas mediante la observación de ciertos parámetros, que se presentan en

ficheros de texto de forma independiente para cada empresa.

Según el segundo enfoque, las características anteriores permiten a SCOPE servir de base

para la programación de nuevas funciones y su posterior experimentación. La modularidad de

la arquitectura basada en agentes permite implementarlas sin demasiada complejidad. En el

Capítulo 6 se comentan algunas líneas de mejora para SCOPE. Las características

implementadas actualmente en la plataforma SCOPE se resumen en la Tabla 4.2.

131

Tabla 4.2. Resumen de las características actuales de SCOPE

Empresas Número ilimitado

Cuatro roles: Fábrica, Intermediario, Proveedor Externo, Cliente Externo

Productos Número ilimitado de productos

Características de fabricación individuales (rutas de fabricación y materias primas

necesarias)

Políticas de control de inventario individuales para cada producto

Estructura de la

Red de Suministro

Diseño de estructuras flexibles y complejas, pudiéndose modelar estructuras de Tipo 1,

Tipo 2 y Tipo 3 (ver apartado 1.2.1)

Políticas de Control

de la Demanda

Make-to-Order (MTO): Lotes (Tiempo, Cantidad), en línea

Make-to-Stock (MTS): (r,S), (r,Svar1), (r,Svar2), (s,S), (r,Q), Planificación de la Producción

Assemble-to-Order (ATO): Modelado indirectamente mediante política MTO

Entorno de

fabricación

Número ilimitado de máquinas

Configuraciones Job-shop & Flow-shop del entorno de fabricación independientes para

cada fábrica

Programación de la

Producción Reglas de Prioridad (FCFS, SPT, LPT)

Heurísticas (Greedy) para optimizar el makespan y el flowtime

Planificación de la

Producción Plan Maestro de Producción (agregado)

Plan de Producción (detallado)

Conexión con Gurobi para resolver todos los modelos de planificación

Incertidumbres Tiempo de procesado de las máquinas

Tiempo de transporte

Demanda externa (intervalos de los pedidos y cantidad)

Suministro externo (cantidad)

Previsión de la

demanda Medias Móviles (SMA)

Medias Móviles con N periodos de antigüedad (NPMA)

Medias Móviles Ponderadas (WMA)

Alisamiento Exponencial Simple (SES)

Distribuciones

Aleatorias Uniforme

Normal

Poisson

Exponencial

Gamma

Otras

características Logística Inversa

Cálculo de Fechas de Entrega

Exportación de los resultados para su análisis posterior