Capsula 11: Punto de Uso

Descripción del problema

En una línea de montaje de automóviles, existen diversos sistemas que se han denominado puntos de uso. La función principal de estos puntos de uso no es otra que la de ensamblar los componentes con su automóvil correspondiente, por tanto cada tipo de componente tendrá un punto de uso asociado diferente.


Así, si se consideran estos puntos de uso como una caja negra, se puede definir dos entradas y dos salidas. Por un lado, entrarán al punto de uso racks cargados de componentes y por otro los automóviles a los que se le han de ensamblar dichos componentes. En cuanto a las salidas, por un lado abandonaran el punto de uso los racks descargados de componentes y por otro el automóvil con los componentes ensamblados.

Una vez descrita el funcionamiento global de estos puntos de uso se procederá a explicar con detalle las restricciones y particularidades que se dan en estos.

Los racks no podrán abandonar el sistema hasta que todos los componentes hayan sido ensamblados al automóvil.

Solo podrá haber en el sistema un rack del cual se estén descargando componentes y otro en espera, en definitiva, la capacidad global de los puntos de uso es de dos racks.

Por otro lado únicamente podrá haber un solo automóvil en el sistema, por tanto la capacidad de estos puntos de uso será de un automóvil.

Como la producción es secuenciada, cada automóvil tendrá asociado únicamente un componente específico, además estas asociaciones han de ir en estricto orden. Así el primer automóvil que salga del mezzanine irá asociado a los primero componentes que salgan desde los puntos de uso, el segundo automóvil con los segundos componentes, y así sucesivamente. Esto se traduce en que tanto la salida del mezzanine como la producción de componentes se han de realizar en el mismo y estricto orden.

En un punto de uso se pueden dar únicamente dos situaciones, que se detallan a continuación

En la primera situación, el componente llega al punto de uso antes que su automóvil correspondiente. En este caso el componente esperará en el punto de uso hasta que llegue el automóvil correspondiente y será ensamblado a él.

En la otra situación ocurre al contrario, el automóvil llega antes que su componente asociado. En este caso el automóvil pasa por el punto de uso sin ensamblar ningún componente y se produce el denominado missing part, en español pieza perdida. Una vez producido el missing part será necesario ensamblar el componente faltante posteriormente. La gestión de los missing part no entra dentro del alcance de este proyecto por lo que no se especificarán más detalles. Por otro lado, cuando llegue al punto de uso el componente asociado al automóvil responsable de este missing part, evidentemente no será ensamblado a ningún automóvil y será enviado a otro lugar para su adecuada gestión.

Es precisamente la medida de estos missing part uno de los principales medibles del proyecto, por ello también se requerirá que estos datos sean almacenados en ficheros de texto externos.

Por último, destacar la diferencia de que en el punto de uso del componente consolas, estas no van almacenadas en racks, si no que lo hacen en balancinas.

Arquitectura del modelo

Como en capsulas anteriores, en este caso también se optará por convertir el modelo en un objeto que pueda ser integrado en otro modelo global.

En la figura anterior podemos observar la vista global del modelo. A continuación se detallará la misión de cada una de sus partes así como los flujos que los entities tienen en él.

Comenzaremos con las entradas y salidas del sub-modelo. Para una mejor comprensión se ha confeccionado la siguiente tabla.

Tipo

Elemento

Objeto

Nodo

Entrada

Rack cargado

Server1

Input

Entrada

Automóvil sin componente

CocheNode

Salida

Rack descargado

EsperaRack

Output

Salida

Automóvil con componente

Combiner1

Output

El “Server1” simula un almacén previo con capacidad 1 para así poder cumplir con la restricción de que sólo podían existir dos racks en el sistema, uno en espera y otro del cual se estén descargando componentes. Más adelante se detallarán los procesos y elementos que hacen esto posible.

En cuanto a la función que desempeña el “Separator1” es la de separar los racks de los componentes. En la realidad esto no es así, sino que los componentes se van cogiendo uno a uno conforme son requeridos en el proceso de ensamblamiento. Precisamente para solucionar este problema está “EsperaRack”, donde el rack esperará y no se marchará del modelo hasta que no se hayan consumido todos los componentes que contenía. El funcionamiento de este sistema se explicará con detalle más adelante.

En el nodo “ComponenteNode” se toma la decisión de que el componente sea enviado al “Combiner1” donde será ensamblado con su correspondiente automóvil, o si por el contrario a ocurrido un missing part se dirija hasta el “Sink1”. En la realidad este componente se dirigiría, como se ha comentado en la descripción del problema, hacia un lugar donde sería gestionado, pero a efectos prácticos de la simulación no influiría en el comportamiento general si desaparece del sistema mediante el sink.

Por último el nodo “CocheNode” funciona de forma similar al nodo “ComponenteNode”. En este nodo existe también una regla de decisión que envía los automóviles al “Combiner1” cuando se encuentran en el sistema su componente asociado, y que cuando esto no ocurre así, los automóviles son enviados directamente a la salida del combiner.

Parametrización del modelo

En esta capsula existen multitud de process, states y otros elementos. La gran mayoría de ellos se han usado en capsulas anteriores aunque hay otros conceptos nuevos. Es por esta razón por la que se ha decido el orden de esta capsula y las anteriores, siguiendo el criterio de que la complejidad vaya aumentando.

Para el desarrollo de esta capsula hay que aclarar primero un aspecto del modelo global. Tanto para los entities que representan a los componentes y los automóviles implicados en este sub-modelo, incluyen un state llamado “Contador” que contiene la información referida al orden con el que se han creado, es decir con la secuencia de producción. Así el primer automóvil creado tendrá en su state “Contador” el valor 1, para el segundo 2 y así sucesivamente. Lo mismo ocurre con el state “Contador” de los componentes.

Por otro lado para que el modelo global funcione correctamente es necesario u periodo de estabilización en el cual se encuentran automóviles que ya estaban dentro del sistema una vez iniciada la simulación. Estos automóviles no tiene asociado ningún componente por lo que se le ha asignado el valor 0 a su state “Contador”.

Para comenzar la parametrización del modleo se mostrarán los States incluidos en el modelo.

El state “ContadorComponentes” será el encargado de almacenar el state “Contador” del último componente que ha entrado en el sistema. De manera análoga, “ContadorCoches” contendrá la información del state “Contador” del último automóvil entrado en el sistema. Estos dos states son utilizados para las reglas de selección de “CocheNode” y “ComponenteNode” como se verá más adelante.

“NumeroEnElSistema” contiene la información de la cantidad de componentes que se encuentran en el modelo. La función de este state está relacionada con el hecho de que el rack no puede abandonar el sistema hasta que no se hayan descargado todos los componentes. Posteriormente entraremos en detalle en su funcionamiento.

A continuación se mostrarán los process que intervienen en el modelo.

ElegirCoches

Se comenzará especificando cual es el disparador de este process, la entrada del nodo “CocheNode”.

A continuación se detallarán cada uno de los steps que componen el process.

En la imagen anterior se observan las propiedades del step assign de “ElegirCoches”. La misión de este step es la de asignar el valor del state Contador del entity que representa a los automóviles al state global ContadorCoches.

Aquí se contemplan las propiedades del step “Decide1”. Su función es la de dejar pasar libremente y sin contabilizar ningún missing part los automóviles que como se ha citado al comienzo de este apartado, son necesarios para la estabilización del modelo global. Es decir cuando se cumple la condición de que ContadorCoches es distinto de cero, se ejecuta “Decide2”, mientras que si la condición es falsa es ejecutará “SetNode2”.

Los steps setnode, envían un entity al nodo especificado. En el caso de “SetNode1” envían el entity al parentinput del “Combiner1”, mientras que “SetNode2” lo envía al output del “Combiner1”.

Por otro lado el step Decide2 decidirá a que step se ejecutará en el process. En el caso de que ContadorCoches<=ContadorComponentes se ejecutará “SetNode1”, mientras que si ContadorCoches>ContadorComponentes se ejecutará “SetNode2”.

Para clarificar las reglas de decisión del process se ha confeccionado la siguiente tabla.

Condición Descripción Step ejecutado Nodo Reprecusión Missing Part
ContadorCoches!=0 Automovil del periodo de estabilización del modelo global SetNode2 Output-Combiner1 El automóvil es enviado a la salida del modelo No
ContadorCoches<= ContadorComponentes Automovil cuyo componente asociado ha llegado a tiempo SetNode1 ParentInput-Combiner1 El componente asociado será acoplado al automóvil No
ContadorCoches> ContadorComponentes Automovil cuyo componente asociado no ha llegado a tiempo SetNode2 Output-Combiner1 El automóvil es enviado a la salida del modelo Si

ElegirComponentes

El disparador de este proceso es el siguiente.

A continuación se procederá a detallar cada una de los propiedades de los steps que componen el process.

Asigna el valor del state “Contador” del entity al state global “ContadorComponentes”.

Si ContadorCoches<ContadorComponentes entonces se ejecutará el “SetNode1”. Si ContadorCoches>=ContadorComponentes se ejecutará “SetNode2”

Envia al entity al MemberInput del “Combiner1”

Envia al entity al Input del “Sink1”.

Como este process es muy similar al anteriorno se detallará más la función de los steps, pero si que se adjunta una tabla similar a la del process anterior para el mejor entendimiento de la lógica de este process.

Condición Descripción
ContadorCoches<ContadorComponentes El componente esperará en la entrada del Combiner hasta que llegue su automóvil asociado
ContadorCoches>=ContadorComponentes El componente desaparecerá del sistema a través de un Sink, ya que su automóvil asociado ya ha abandonado el modelo contabilizando un missing part

EsperaRack

Estos dos process son los encargados de habilitar o deshabilitar que el rack pueda salir del sistema. Se recuerda que el rack solo pueda salir del modelo cuando se hayan consumido todos los componentes que se encontraban en su interior.

Se comenzará con el process “AbreEsperaRack2. Los disparadores de este proceso son los siguientes.

El TimePath3 es el que conecta “CompoenteNode” con el “Sink1”.

A continuación se expondrán los diferentes steps del process.

Disminuye el state NumeroEnElSistema en una unidad. Esto es así porque el proceso se dispara cuando un componente es ensamblado en el automóvil.

Condición lógica que comprueba que NumeroEnElSistema=0. Si esto se cumple, quiere decir que ya se han ensamblado todos los componentes que estaban contenidos en un rack y por tanto se deberá dejar salir el rack del sistema. Esto lo conseguimos con el step siguiente.

Cambia la capacidad de “EsperaRack” a 1, es decir, desbloquea el rack y deja que pueda pasar a través de este server para salir del modelo.

Por otro lado, el disparador del process “CierreEsperaRack” esta contenido dentro del process “AbreSeparator” a través de un step Execute que se detallará más adelante.

El único step contenido el process “CierreEsperaRack” es un assign que cambia la capacidad de “EsperaRack” a 0, es decir, bloquea este server para que no pueda pasar el rack.

Separator

Ambos process son los encargados de que solo pueda haber un solo rack siendo descargado mientras que si existe otro se quede en cola.

El disparador de “AbreSeparator” se puede observar en la imagen siguiente.

El step assign de este process cambia la capacidad del “Server1” a 1, es decir habilita el paso de racks hasta el separator.

En cuanto el step execute es el encargado de disparar el process “CierraEsperaRack” como se ha comentado anteriormente.

EscribirComponente

Este proceso es el encargado de escribir en un archivo de texto el número de componente cuando se produce un missing part. Como este modelo se incorporará como objeto repetidas veces en el modelo global (existirá un objeto diferente para cada uno de los diferentes puntos de uso), será necesario crear un archivo de texto para cada componente, pues sino Simio nos daría un error al intentar abrir el mismo archivo desde diferentes objetos a la vez.

Para poder comprender la lógica de este proyecto se deberá hacer una referencia respecto al modelo global. En este modelo cada uno de los entitys tiene una property llamada “Tipo”. A diferencia de los states, las propiedades solo pueden ser cambiadas al inicio de la simulación, pero no durante esta. Así, se ha confeccionado una tabla con las propiedades “Tipo” asociadas a cada uno de los componentes.

Componente

Tipo

Puerta Derecha

11

Puerta Izquierda

12

Bullhorn

2

Defroster

3

Consola

4

Una vez aclarado esto, comenzaremos exponiendo el disparador del process.

Así este process se disparará cada vez que un componente llegue al “Sink1”, es decir, cada vez que se produzca un missing part.

A continuación se adjuntan las propiedades de los steps write.

Como se observa cada uno de estos steps tiene asociado un tipo distinto de File. La declaración de estos elementos se muestra a continuación

Por otro lado la columna que escribirán los steps son iguales y se muestra a continuación.

Es decir, escribirán el state Contador de cada uno de los entities que activen el proceso.

Seguidamente se adjuntan las propiedades de los steps decide.

A continuación se expone una tabla para comprender mejor la lógica del process.

Entity Condición Step asociado File
Puerta Derecha ModelEntity.Tipo==11 Write1 FilePuertaDerecha
Puerta Izquierda ModelEntity.Tipo==12 Write2 FilePuertaIzquierda
Bullhorn ModelEntity.Tipo==2 Write3 FileBullhorn
Defroster ModelEntity.Tipo==3 Write4 FileDefroster
Consola ModelEntity.Tipo==4 Write5 FileConsola

Una vez finalizada la descripción de los procesos, se hara referencia la única propiedad del modelo que puede ser cambiada externamente.

Esta propiedad hace referencia al TatkTime de la línea de Ford, es decir, al tiempo que permanece un automóvil en un punto de uso.

Esta propiedad está asociada a los siguientes objetos, siendo el “TimePath5” el que conecta “CocheNode” con la salida del “Combiner1”.

Para finalizar, destacar que todos los demás objetos del modelo que no se han adjuntado sus propiedades , TimePaths, Servers, Combiners, etc. tienen su tiempo de proceso o tiempo de viaje a 0.

Anuncios

3 pensamientos en “Capsula 11: Punto de Uso

  1. Hola, muy buen blog y muy interesante. Me gustaria saber si Simio puede trabajar con algún programa de resolución de modelos matematicos y en ese caso cual seria el más recomendable. Muchas gracias.

  2. Me encanta tu blog, me ha ayudado mucho en el curso que llevo, espero que sigas poniendo ejemplos aplicativos sobre los usos de las diferentes herramientas de simio.

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s