View
220
Download
0
Category
Preview:
Citation preview
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
Recommended