Capítulo 6.- Modelado de los sistemas de...

Sistema de control de la producción basado en tarjetas para entornos de tipo taller: estudio del sistema COBACABANA y propuesta de mejora

Página 46

Capítulo 6.- Modelado de los sistemas de control.

En el modelado de los sistemas de control existen elementos comunes a los distintos

sistemas analizados y elementos de los modelos distintos.

Los elementos del modelo comunes son:

· La entidad trabajo.

· Variables de análisis.

· Definición de las rutas de trabajo.

· Ordenación de la ruta en el taller.

Los elementos del modelo distintos son:

· Setup de los display de tarjetas.

· Zona de Espera.

· Actualización de los display a la salida de las estaciones de trabajo.

1. Modelado de la entidad trabajo.

Los trabajos que entran al sistema se modelan como entidad, los atributos propios del

trabajo son:

InputTime: Instante de entrada del pedido o trabajo.

En el software Arena se asigna el instante actual mediante el comando TNOW, dicho

comando asigna el valor que en ese instante tiene el reloj de la simulación.

Figura 6.1. Asignación de valor al atributo InputTime.

DD: Fecha de entrega.


Página 47

La fecha de entrega se determina en función al instante de entrada y a una asignación

aleatoria de tiempo de proceso definido a partir de una variable aleatoria U(35,60),

variable utilizada en la experimentación de referencia sobre la que se realizarán las

comparaciones.

Figura 6.2. Asignación de valor al atributo DD (Due Date).

NumProcess: Número de procesos.

Este atributo determina el número total de estaciones de trabajo que contiene la ruta del

trabajo.

Como se verá posteriormente, la asignación del valor concreto de este atributo

dependerá de si la ruta del trabajo es de flujo dirigido o no dirigido (figura 3.3)

RD: Fecha de liberación.

Este atributo corresponde a una aproximación de cuál debería ser la fecha más tardía de

liberación del trabajo al taller. Para su cálculo se realiza la hipótesis de que el tiempo de

proceso del trabajo en cada máquina es , este tiempo de proceso planificado se

modela a través de la variable TsD. El número de procesos del trabajo multiplicado por

el tiempo de proceso planificado es el tiempo de proceso total planificado, este valor se

resta a la fecha de entrega y se obtiene el valor del instante máximo de liberación para

poder cumplir con la fecha de entrega.

Figura 6.3. Asignación de valor al atributo RD (Release Date).


Página 48

Este atributo (RD) se emplea como criterio de ordenación de trabajos en las colas del

pool de espera o de las estaciones de trabajo.

CurrPos: Posición actual de la ruta.

Este atributo determina en cada momento en que fase de producción, atendiendo a la

ruta de trabajo, se encuentra el trabajo.

Path: Ruta

La ruta del trabajo se define como un atributo vectorial. En este modelo, tal y como

puede observarse en la figura 6.4, el vector Path se define inicialmente con 7 valores.

Como se expondrá en el capítulo 7, los trabajos a modelar tendrán un máximo de 6

trabajos por ruta.

El primer valor del atributo vectorial Path corresponde al número de la estación de

trabajo en la que, según la ruta, el trabajo debe ser procesado en primer lugar; el

segundo valor del atributo vectorial Path corresponde al número de la estación de

trabajo en la que, según la ruta, el trabajo debe ser procesado en segundo lugar; y así

sucesivamente.

A partir de la posición del vector correspondiente al último trabajo de la ruta, el resto de

valores del vector serán igual a cero.

El vector tiene 7 valores debido a que el modelo detecta la finalización de una ruta a

partir de la aparición del valor 0 en el atributo Path, en el caso de rutas con 6 procesos

es necesario incluir un séptimo elemento al que asignarle el valor 0.

Como se verá posteriormente, la asignación del valor concreto de este atributo

dependerá de si la ruta del trabajo es de flujo dirigido o no dirigido (figura 3.3)


Página 49

Figura 6.4. Atributo vectorial Path (ruta).

A modo de ejemplo, en la figura 6.5 se muestra una ruta formada por los procesos en

serie en las estaciones de trabajo 5, 2 y 4, así como los valores que adoptarían los

distintos elementos del atributo Path para definir dicha ruta.

Figura 6.5. Ejemplo valores Path.

PoolTime: tiempo en la zona de espera.


Página 50

Este atributo determina el tiempo que transcurre desde la entrada del pedido hasta la

liberación del mismo en el taller.

Figura 6.6. Asignación de valor al atributo PoolTime.

Retraso

A partir del instante de salida del taller, se define el tiempo de retraso respecto a la fecha

de entrega comprometida (DD). En el caso de que el valor de este atributo sea negativo

se cumple con el compromiso de entrega.

JST: Tiempo de procesado en el taller.

Este atributo determina el tiempo que el trabajo ha estado siendo procesado en el taller.

Figura 6.7. Asignación de valor al atributo JST.

2. Variables de análisis.

El objetivo del modelo es realizar un análisis estadístico del comportamiento de los

sistemas de control, las variables de análisis se definen a continuación.

TiempoEnSistema

Este atributo expresa el tiempo transcurrido entre la entrada del pedido y la salida del

trabajo del taller.


Página 51

NumRetrasos

Número de trabajos finalizados fuera del plazo de entrega, son aquellos cuyo valor del

atributo Retraso es positivo.

Tardiness

Tiempo de retraso.

PorcRetrasos

Porcentaje de trabajos entregados fuera del plazo de entrega respecto al número total de

trabajos procesados.

3. Definición de rutas de trabajo.

Para la simulación de los sistemas de control se utilizan dos tipos de taller, tal y como se

definió en el apartado 2.4.

Las dos tipologías de taller utilizadas, flujo dirigido o flujo no dirigido, se muestran

gráficamente en la figura 3.3.

Ambas tipologías responden a las matrices de probabilidad de la figura 6.8.


Página 52

Figura 6.8. Matriz de probabilidad (a) flujo no dirigido (b) flujo dirigido (F. (Martin Land, 2004))

Las matrices determinan la probabilidad de transición de una estación a otra. El

elemento (r,s) de la matriz determina la probabilidad de que una vez que el trabajo sea

procesado en la estación r, la siguiente estación de trabajo de la ruta sea la s. Los

elementos (0,s) determinan la probabilidad de que la primera estación de trabajo de la

ruta sea la s. Los elementos (r,0) determinan la probabilidad de que el proceso en la

estación de trabajo r sea el último de la ruta (Martin Land, 2004).

En el caso de los talleres de flujo no dirigido, el caso de estudio determina que las rutas

con 1, 2, 3, 4, 5 o 6 estaciones son equiprobables. Del mismo modo, una vez

determinado el número de procesos, la probabilidad de que una estación forme parte de

la ruta también es equiprobable. Este hecho provoca que para el modelado de estas rutas

no sea necesario el uso de las matrices de probabilidad de la figura 6.8.

3.1. Flujo no dirigido.

En la figura 6.9 se muestra el bucle mediante el cual se ha modelado la determinación

de la ruta de trabajo.

Figura 6.9. Modelo Arena. Determinación de la ruta en tipo flujo no dirigido.

Como puede observarse una vez que el trabajo entra al sistema (bloque Create 2), se le

asignan los atributos básicos (bloque Assign 7), en este bloque de asignación se

determina el número de procesos de la ruta (NumProcess), teniendo en cuenta que los

seis valores posibles, 1 a 6, tienen una probabilidad de 1/6 (figura 6.10)


Página 53

Figura 6.10. Asignación del valor del atributo NumProcess en tipo flujo no dirigido.

En este caso se ha empleado el comando DISC(p1, v1, p2,v2,…, pn,vn) que asigna un

valor aleatorio discreto teniendo en cuenta que la probabilidad de que ese valor sea

menor o igual que vn es igual a pn.

Una vez definido el número de estaciones que componen la ruta de trabajo, en el bloque

Assign 6, se asigna un valor equiprobable de 1 a 6 a un atributo intermedio

(attr_Random), dicho valor representa el número de la estación de trabajo que debe

incluirse en la ruta. Tras esta asignación en el bloque Decide 4 se comprueba si la

estación de trabajo pertenece a la ruta o no, es decir, si ese valor ya está presente en el

atributo vectorial Path.

Si la estación de trabajo ya pertenece a la ruta, se vuelve al bloque Assign 6; si no es así,

se asigna en el bloque Assign 9 el valor de attr_Random en el elemento del atributo

vectorial Path correspondiente.

Figura 6.11. Asignación de estación de trabajo a la ruta en tipo de flujo no dirigido (Assign 9).

Como puede observarse en la figura 6.11, el valor aleatorio attr_Random se asigna

como la estación de trabajo que forma parte del vector de la ruta en la posición

CurrPos.

El atributo CurrPos se usa en este bucle como puntero de las distintas posiciones de la

ruta.


Página 54

Una vez realizada la asignación anterior, en el bloque Decide 3 se comprueba si ya se ha

completado la determinación de la ruta mediante la igualdad o no de los atributos

CurrPos y NumProcess. En caso afirmativo, la entidad sale del bucle de creación de la

ruta mediante la asignación del valor 1 al atributo CurrPos en el bloque Assign 1.

En el caso de que la ruta no se hubiese completado, la entidad es enviada al bloque

Assign 8 donde se actualiza el puntero (CurrPos= CurrPos+1) y se reenvía al inicio del

bucle (Assign 6).

3.2. Flujo Dirigido.

En la figura 6.12 se muestra el modelo de creación de la ruta en el caso de talleres con

tipología de flujo dirigido.

En este caso, sí se empleará la matriz de probabilidades de la figura 6.7 b).

El atributo attr_Random se emplea como puntero de estaciones de salida, es decir, en

cada momento su valor nos indicará cual es la última estación de trabajo que se ha

asignado a la ruta.

El atributo CurrPos, al igual que en el modelo de flujo no dirigido, se usa en este

modelo como puntero de las distintas posiciones del atributo vectorial Path.


Página 55

Figura 6.12. Modelo Arena. Determinación de la ruta en tipo flujo dirigido.

Una vez entra la entidad al sistema (Create 2), se le asignan los atributos básicos al

trabajo en el bloque Assign 7. En este caso, el atributo NumProcess se determinará al

final del proceso. En este bloque también se asignan los valores iniciales a los dos

punteros que van a utilizarse: attr_Random=0 y CurrPos=1.

El bucle de creación de la ruta se inicia en el bloque Direccionar Ruta (decide), tal y

como se muestra en la figura 6.13 este bloque envía a la entidad a un nuevo bloque

decide en función al último trabajo que se le asignó a la ruta. Al igual que en la matriz

de probabilidades se asigna el valor 0 al hecho de que aún no se haya asignado ningún

trabajo a la ruta. Este proceso puede identificarse con la determinación de la fila de la

matriz de probabilidades (figura 6.7)

Figura 6.13. Determinación de fila en matriz de probabilidad.

Del bloque Direccionar Ruta la entidad es enviada a uno de los bloques decide

denominados Origen“s”, siendo s el valor de attr_Random o de la última estación de

trabajo asignada.

En este tipo de bloques se aplica la probabilidad de que una vez finalizado el proceso en

la estación de trabajo s (siendo attr_Random=s) la ruta continúe en una estación de

trabajo posterior o por el contrario haya concluido la ruta.

En la figura 6.14 puede observarse la correspondencia entre el bloque Origen1 y la

matriz de probabilidad correspondiente al tipo de flujo dirigido. Como puede observarse

en la figura 6.12, la entidad es enviada a los bloques “CC s” (siendo s el número de

estación de trabajo) según la matriz de probabilidades, donde se asigna el valor de la

estación de trabajo que se añade a la ruta (figura 6.15)


Página 56

Figura 6.14. Aplicación de la matriz de probabilidad en el bloque Origen1.

Figura 6.15. Asignación de valor al puntero attr_Random en el bloque CC 3.

Una vez se actualiza el puntero attr_Random, en el bloque Assign 9 se toma este valor

como la estación de trabajo que forma parte del vector de la ruta en la posición

CurrPoss, tal y se observa en la figura 6.16.

A continuación se actualiza el puntero (CurrPos= CurrPos+1) en el bloque Assign 8 y

se reenvía al inicio del bucle (Determinar Ruta).


Página 57

Figura 6.16. Asignación de estación de trabajo a la ruta en tipo de flujo no dirigido (Assign 9).

La salida “else” de los bloques Origen“s” tiene una probabilidad equivalente a la

columna 0 de la matriz y supone la finalización de la ruta.

Figura 6.17. Finalización de ruta en los bloques Origens.

Una vez finalizada la ruta, la entidad circula por los bloques Assign 203 y Assign 1,

donde se determina el número de procesos (NumProcess) y se actualiza el atributo

CurrPoss respectivamente.


Página 58

4. Ordenación la ruta en el taller.

Una vez liberado el trabajo al taller, el trabajo debe ser procesado en las estaciones de

trabajo según la ruta establecida por el atributo vectorial Path.

En la figura 6.18 se muestra el modelo realizado para asegurar el cumplimiento de la

ruta, así como para medir las variables de análisis una vez procesados los trabajos.

Figura 6.18. Flujo en taller según ruta

El primer bloque del bucle es Decide 6, tal y como puede observarse en la figura 6.18,

en este bloque se determina si la ruta ha concluido o por el contrario aún quedan

procesos pendientes en la ruta. Debe recordarse que en el vector Path el primer

elemento igual a 0 indica que el trabajo ya ha sido procesado por completo.


Página 59

Figura 6.19. Comprobación de la finalización o no de los trabajos de la ruta.

En el caso de que la ruta no haya finalizado, en el bloque Assign 11, se determina cual

es la siguiente estación de trabajo de la ruta (atributo NextProcess) y se actualiza el

puntero CurrPoss tal y como puede observarse en la figura 6.20.

En el caso del sistema de control MPK, se actualiza también el puntero NextPos

(NextPos=CurrPos+1) cuya función es facilitar la actualización de los display tras la

ejecución de los procesos en los centros de trabajo.

Figura 6.20. Actualización de ruta y puntero.

Una vez actualizado el valor de NextProcess el bloque Decide2 envía el trabajo a la

estación de trabajo correspondiente según el valor de dicho atributo.

En el caso de que el bloque Decide 6 detecte la finalización de la ruta, la entidad se

envía a la parte final del modelo en la que se calculan y graban los atributos y variables

de análisis (TiempoEnSistema, Tardiness, PorcRetrasos, etc).

5. Setup de los display de tarjetas

Tanto en COBACABANA como en MPK, el número total de tarjetas es una variable de

análisis ya que determinan indirectamente el valor de la norma de carga de trabajo. En

ambos modelos se ha incluido una variable Num_Cards cuyo valor se utiliza para

analizar el comportamiento según el número total de tarjetas.

5.1. Setup display COBACABANA.

Dado que en el tipo de análisis que se va a realizar, las distintas estaciones de trabajo

tienen el mismo porcentaje de uso, y dado que los tiempos de proceso son iguales para


Página 60

todos los trabajos y para todas las estaciones de trabajo; el número máximo de tarjetas

será el mismo para los 6 display correspondientes a las 6 estaciones de trabajo.

La variable vectorial Lp representa los display de las 6 estaciones de trabajo, de manera

que el valor que en cada momento tenga la posición s del vector representará el número

de tarjetas libres de la estación de trabajo s.

En la figura 6.21 se muestra el bucle de setup de la variable Lp, debe tenerse en cuenta

que previamente a la simulación debe introducirse el valor de Num_Cards que se

corresponde con el valor de inicio del número total de tarjetas en cada estación de

trabajo.

Figura 6.21. Setup display COBACABANA.

Dado que el setup se produce sólo en el primer instante de la simulación, el bloque

Create 3 crea una sola entidad en el instante 0.

Para el setup se emplea la variable i1 como puntero, así en el bloque Assign 188 esta

variable se reinicia al valor 1. A partir de este reinicio el bucle comienza en el bloque

Assign 189 que asigna el valor de Num_Cards al elemento de Lp que esté en la posición

que indique i1.

En el bloque Decide 18 se comprueba si el display de COBACABANA ya está

completo, es decir si i1>6, en caso afirmativo finaliza el setup y en caso negativo se

actualiza el puntero (i1= i1+1) y se envía la entidad al Assign 189.

5.1. Setup display MPK.

En este caso los display se modelan mediante una variable matricial 6x6 (Matrix),

donde las filas representan las 6 estaciones de trabajo y las columnas los 6 periodos de


Página 61

control. Así, el valor de la posición (r,s) representará el número de tarjetas disponibles

de la estación de trabajo r para el periodo de control s.

Dado que en el tipo de análisis que se va a realizar, las distintas estaciones de trabajo

tienen el mismo porcentaje de uso, y dado que los tiempos de proceso son iguales para

todos los trabajos y para todas las estaciones de trabajo; el número máximo de tarjetas

será el mismo para los 6 display correspondientes a las 6 estaciones de trabajo.

En la figura 6.22 se muestra el bucle de setup de la variable Matrix, debe tenerse en

cuenta que previamente a la simulación debe introducirse el valor de Num_Cards que se

corresponde con el valor de inicio del número total de tarjetas en cada estación de

trabajo. En este caso el valor de Num_Cards es el mismo para todos los periodos de

control.

Figura 6.22. Setup display MPK.

Dado que el setup se produce sólo en el primer instante de la simulación, el bloque

Create 3 crea una sola entidad en el instante 0.

Para el setup se emplean dos variables (Fila,Columna) como punteros para los

elementos matriciales, así en el bloque Assign 188 estas variables se reinician al valor 1.

A partir de este reinicio el bucle comienza en el bloque Assign 189 que asigna el valor

de Num_Cards al elemento de Matrix que esté en la posición que indique

(Fila,Columna).

Los valores son asignados a los elementos por columnas, de este modo en el bloque

Decide 18 se comprueba si el display correspondiente al periodo de control está

completo, es decir si Fila=6, en caso afirmativo se actualiza el valor de Columna en el

bloque Assign 204 (Columna=Columna+1) y en caso negativo se actualiza el puntero

de filas (Fila=Fila+1) y se envía la entidad al Assign 189.

En el bloque Decide 38 se determina si el setup ha concluido (Columna>6) o si por el

contrario se inicia la asignación de valores a un nuevo periodo de control mediante el

envío de la entidad al inicio del bucle.


Página 62

6. Zona de Espera.

Los dos sistemas de control tienen un modelado de zona de espera similar, la única

diferencia consiste en la comprobación de que hay tarjetas suficientes que permitan la

liberación del trabajo, así como en el proceso de actualización de los display tras la

liberación del trabajo.

Se expone en primer lugar la parte del modelo que es idéntica en ambos sistemas de

control.

La figura 6.23 muestra el modelo que permite establecer los periodos de liberación. En

el bloque Create 1 se introducen entidades con la periodicidad del ciclo de liberaciones

(5 segundos en los análisis realizados). Posteriormente, en el bloque Assign 153 se

actualizan dos variables auxiliares que servirán para modelar la simulación del ciclo de

comprobación y liberación. En concreto se trata de las variables NumInPool y

ContadorCola.

Figura 6.23. Ciclos de liberación.

Una vez actualizan los valores de las variables auxiliares, se emite una señal (Signal 1)

de modo que el bloque Hold 1 libera los trabajos en espera hacia la zona donde se

comprueba el cumplimiento de los criterios de liberación al taller.

En la figura 6.24 se observa que a la variable auxiliar NumInPool se le asigna el valor

correspondiente al número de trabajos existentes en la cola del bloque Hold 1 que

representa la zona de espera entre que un trabajo es aceptado y su liberación al taller;

por otra parte la variable ContadorCola se resetea a 0.


Página 63

Figura 6.24. Asignación de valor a las variables auxiliares del ciclo de liberación.

En la figura 6.25 se muestra el modelo mediante el que se controla la zona de espera.

Cuando un trabajo es aceptado y su ruta es determinada mediante los modelos

mostrados en el apartado 3 de este mismo capítulo, la entidad queda retenida en el

bloque Hold 1.

Figura 6.25. Zona de Espera.

Una vez emitida la señal de inicio del ciclo de liberación, la entidad es enviada al

bloque Decide 1 donde se comprueba el número de procesos de los que se compone la

ruta (NumProcess), a partir de este valor se envía a un nuevo bloque donde se

comprobará si cumple los criterios de carga, o lo que es lo mismo, si los display de las

estaciones de trabajo que componen la ruta disponen del número de tarjetas suficientes

para permitir su liberación al taller. Este bloque de comprobación de los display es

distinto según el sistema de control de estudio.

Una vez comprobados los criterios de carga, si el trabajo cumple los criterios se produce

la liberación al taller y el bloque Assign 3 se actualiza la variable auxiliar ContadorCola

(= ContadorCola+1) y se determina el atributo PoolTime.


Página 64

En el caso de que no haya suficientes tarjetas para que el trabajo pueda ser liberado, la

entidad se envía al bloque Assign 2 donde se actualiza la variable auxiliar ContadorCola

(= ContadorCola+1).

El proceso de comprobación y liberación culmina cuando en la cola del bloque Hold 1

no quedan más entidades. En ese instante los trabajos retenidos en Hold 2 se envían a

Hold 1 para esperar al siguiente ciclo de liberación.

6.1. Comprobación y actualización de tarjetas disponibles en sistema

COBACABANA.

En la figura 6.26 se muestra el modelado del proceso de comprobación de la existencia

de tarjetas libres en los display de las estaciones de trabajo correspondientes a la ruta.

Tal y como se expuso respecto a la figura 6.25, el bloque Decide 1 distribuye las

entidades en función al número de procesos que componen la ruta. En función al valor

de NumProcess la entidad es enviada a un bloque Decide donde se comprueba la

disponibilidad de tarjetas para todos los centros de trabajo que componen la ruta.

En la imagen 6.27 se muestra el modo en el que se comprueba la disponibilidad de

tarjetas en los display de las estaciones de trabajo correspondientes a una ruta con tres

estaciones de trabajo.

Figura 6.26. Comprobación tarjetas COBACABANA.


Página 65

Figura 6.27. Comprobación de la disponibilidad de tarjetas en sistema COBACABANA.

Tras comprobar si existe disponibilidad de tarjetas, la entidad es enviada a Assign 2

(figura 6.25) en caso de que en al menos uno de los display no haya tarjetas; si se

comprueba la disponibilidad de tarjetas se procede a la liberación del trabajo a taller y a

la actualización de los display.

En la figura 6.28 se muestra un ejemplo de actualización de display para rutas con tres

estaciones de trabajo, en el caso de análisis el display se actualiza restando una tarjeta

por cada una de las estaciones de trabajo.


Página 66

Figura 6.28. Actualización de display en sistema COBACABANA tras liberación.

Una vez concluida la actualización el trabajo es enviado al taller a través del bloque

Decide 6 (figura 6.18).

6.2. Comprobación y actualización de tarjetas disponibles en sistema MPK.

Del mismo modo que en el modelado del sistema COBACABANA la comprobación de

disponibilidad de tarjetas MPK, la actualización de display y la liberación del trabajo, se

basa en una serie de bloques Decide/Assign distintos según el número de procesos que

contenga la ruta.

En la figura 6.29 se muestra el modo de comprobación de disponibilidad de tarjetas en

los display MPK. Como puede observarse, la diferencia estriba en el carácter matricial

de los display de este sistema de control.


Página 67

Figura 6.29. Comprobación de la disponibilidad de tarjetas en sistema MPK.

En la figura 6.30 se muestra la actualización de tarjetas del display MPK.

Figura 6.30. Actualización de display en sistema MPK tras liberación.


Página 68

7. Actualización de los display a la salida de las estaciones de trabajo.

Cuando los trabajos son procesados en una estación concreta, es necesario actualizar los

display de tarjetas.

En el caso del sistema de control COBACABANA, cuando un trabajo es procesado en

una estación de trabajo s, la tarjeta correspondiente a ese centro de trabajo vuelve al

display. Dicho de otro modo, una vez procesado el trabajo en la estación s, el display

correspondiente se incrementa en una tarjeta.

En el caso del sistema MPK, debe tenerse en cuenta que los display dependen del centro

de trabajo y del periodo planificado. Cuando un trabajo es procesado en una estación s,

el display correspondiente al periodo 1 de esa estación se incrementa en una tarjeta; el

resto de display correspondientes a los centros de trabajo pertenecientes a la parte de la

ruta no procesada aún también tienen que modificarse. Así, el display correspondiente al

periodo de planificación previsto tras el proceso se verá reducido en una unidad, y el

periodo de planificación anterior se verá incrementado en una unidad.

7.1. Actualización de los display en COBACABANA.

En el caso del sistema COBACABANA la actualización del display de tarjetas es

sencilla. Cuando una entidad trabajo acaba de ser procesada en el centro de trabajo s, el

valor del atributo NextProcess es s (ver apartado 4 de este capítulo). Por lo tanto, una

vez que el trabajo sale del bloque de proceso correspondiente, es enviado al bloque

Assign 196, donde se actualiza el display correspondiente a la última estación donde ha

sido procesado el trabajo.

Figura 6.31. Actualización de display en sistema COBACABANA tras proceso.

Tal y como se muestra en la figura 6.31, la actualización consiste en aumentar en una

tarjeta el elemento de la variable vectorial Lp correspondiente a la estación de trabajo.


Página 69

7.2. Actualización de los display en MPK.

En el sistema MPK la actualización del display de tarjetas es relativamente más

compleja que en COBACABANA. Cuando una entidad trabajo acaba de ser procesada

en el centro de trabajo s, el valor del atributo NextProcess es s (ver apartado 4 de este

capítulo).

Como puede observarse en la figura 6.32, cuando un trabajo es procesado se envía al

bloque Decide 39, en el que los trabajos se canalizan en función al número de tareas

pendientes de ejecutar de la ruta (NumProcess-CurrPoss). Este número de tareas

pendientes indica también el número de periodos planificados (véase capítulo 7.4), por

lo tanto, una vez determinado el número de tareas pendientes de ejecutar se actualizan

los display en los bloques Assign correspondientes.

Figura 6.32. Bloque de actualización de display en sistema MPK tras proceso.

A modo de ejemplo, en el caso de que el número de tareas pendientes sea 3, la entidad

es enviada a los bloques Assign 210 y Assign 211. En el primero de los bloques se

modela la devolución de las tarjetas que el trabajo tenía asignadas en la fase anterior, en

el segundo bloque se extraen las tarjetas para el siguiente periodo de proceso. En ambos


Página 70

bloque se emplea el puntero NextPos cuyo valor y actualización se expone en la sección

4 de este mismo capítulo.

Como puede observarse en la figura 6.33, en la actualización de los display MPK se

devuelven en primer lugar las tarjetas que actualmente están asignadas al trabajo, salvo

la tarjeta correspondiente a la tarea que acaba de ser ejecutada. Para ello debe tenerse en

cuenta que el puntero NextPos indica la posición, en la ruta inicial, que tiene la siguiente

tarea que será ejecutada. Así, la tarea que corresponda con NextPos devolverá su tarjeta

al display correspondiente al periodo de planificación 2 (columna 2 de la matriz de

display); la tarea que corresponda con NextPos+1 devolverá su tarjeta al display

correspondiente al periodo de planificación 3 (columna 3 de la matriz de display).

Figura 6.33. Actualización de display en sistema MPK tras proceso. Devolución de Tarjetas.

La asignación de las nuevas tarjetas y la correspondiente actualización de los display

MPK puede observarse en la figura 6.34. En este caso, la tarea que corresponda con

NextPos tomará una tarjeta del display correspondiente al periodo de planificación 1

(columna 1 de la matriz de display); la tarea que corresponda con NextPos+1 tomará

una tarjeta del display correspondiente al periodo de planificación 2 (columna 2 de la

matriz de display).


Página 71

Figura 6.34. Actualización de display en sistema MPK tras proceso. Asignación de Tarjetas.

Capítulo 6.- Modelado de los sistemas de...

Documents

Transcript of Capítulo 6.- Modelado de los sistemas de...