Arte y Oficio de La Simulación - (PG 392 - 650)

392 EL ARTE DE LA SIMULACIÓN
Cuadro 8
Sección system del modelo «Zipkin»
.....................
System
GENERATE 1,On;
COMPUTE begin
for j = 1 to dim do begin
if j == 1 then IO[1] = Erlang(Rate*L[1],2*L[1]),
IN[j] = s[j] - IO[j] ,
I[j] = max(IN[j],0),
B[j] = max(-IN[j],0),
if j < dim then IO[j+1] = Erlang(L[j+1]*Rate,
2*L[j+1]) + B[j],
Debug draw do FTTab(4*j-3,IO[j]),
Debug draw do FTTab(4*j-2,IN[j]),
Debug draw do FTtab(4*j-1,I[j]),
Debug draw do if B[j] > 0 then FTtab(4*j,B[j])
end,
end;
TERMINATE 0;
endsystem;
Hacemos la simulación con los mismos datos de las secciones pre-

cedentes. Para ello, utilizamos como valores del punto crítico de pedido
20 y 50 unidades respectivamente, valor del stock promedio resultado
de las políticas Ss anteriores.
Nótese que las distribuciones que se usan en la simulación, son las
Copyright © 2004. EUNSA. All rights reserved.
distribuciones de la demanda durante el plazo de entrega teórico del

escalón anterior, es decir durante el tiempo Lj. La demanda final se usa
sólo para calcular estas expresiones. El resto de la simulación es simple-
mente la aplicación directa de las fórmulas anteriores.
A continuación incluimos los histogramas del stock en mano en los
dos escalones.
Riverola, J., & Cuadrado, B. (2004). Arte y oficio de la simulación. Retrieved from http://ebookcentral.proquest.com
Created from espochsp on 2018-04-17 16:38:07.
DISEÑANDO UN SISTEMA LOGÍSTICO 393
Figura 9
Histograma del stock en mano en retail y almacén
En estos histogramas es fácil leer la probabilidad de tener stock re-

trasado, dada por la altura de la barra en el valor 0. Para el retail es de
alrededor de un 3%, y para el almacén de un 6%. Aunque lo único que
interesa como medida de servicio es el valor para el retail, que es el que
está en contacto con el cliente.
Con este procedimiento la velocidad de simulación es alrededor de
50 veces mayor que con el modelo general.
Si el lector quiere comparar esta simulación con las simulaciones an-
teriores, hay que tener en cuenta que hay cuatro fuentes de discrepancia:
1. El uso de una política de punto crítico, en vez de una política Ss.
En este último tipo de políticas, el tamaño del lote interacciona
con el punto de pedido en formas no triviales.
2. La demanda se produce de unidad en unidad, por un proceso re-
generativo y a intervalos determinados por una distribución. En
el caso anterior, la demanda se producía de forma regular, en lo-
tes de tamaño aleatorio. Aunque la demanda total sea la misma,

el efecto sobre el sistema es muy distinto.
3. En esta sección hemos usado fórmulas para el régimen perma-
nente, mientras que en secciones anteriores muestreábamos la
trayectoria de los stocks del sistema. El efecto neto de esta apro-
ximación es parecido al que se producía en las colas, en los capí-
tulos 11 y 12. El modelo básico necesita un tiempo grande de si-
mulación para obtener estimaciones fiables, especialmente si se
opera con niveles de servicio muy cercanos al 100%. Una vez
más, tratamos con acontecimientos raros que, al producirse con
baja frecuencia, obligan a simular largo tiempo para obtener una
aproximación fiable.
4. No hay interferencias debidas a lotes, incluyendo los lotes de en-

vío. Ya hemos visto el tipo de efectos que esto puede producir, y
por tanto el tipo de anomalías que pueden introducir en un siste-
ma. El modelo de esta sección es mucho más estilizado, y no tie-
ne en cuenta estas peculiaridades del sistema real.
A pesar de todo, este enfoque funciona muy bien. Pero, desgracia-
damente, no se puede extender a un sistema cualquiera, porque no se
conocen recursiones generales como las anteriores, válidas para cual-
quier tipo de red logística. Sin embargo ver [Zipkin].
6. Un sistema logístico más complejo
Sigamos examinando el comportamiento del sistema logístico de

tres escalones presentado en la sección 3. Nos vamos a concentrar en
comparar nuestro sistema secuencial con otro sistema idéntico, excepto
porque el primer escalón estará formado por dos distribuidores, que re-
cibirán demanda de los clientes. ¿Serán ambos sistemas iguales cuando
la demanda en cada distribuidor es la mitad de la demanda total? La pri-
mera cuestión que se plantea es cómo deben cambiar las políticas de
gestión de stocks al cambiar la demanda. Supongamos que adoptamos
el enfoque simplista de tomar para Smin y Smax la mitad de sus análo-
gos en el caso básico. Esto es, intuitivamente, equivalente a dividir el
stock en partes iguales y asignarlo a las dos nuevas ubicaciones.
Cuadro 9
Fichero principal del modelo Unilogistica-np
{---Sistema logístico secuencial ----}

Constants {$constLogis.pss}
graficos = False; {--Dibuja los stocks}
ioGraficos = False; {--Dibuja las curvas de IO solicitadas}
lumpyDemand = False; {--Dibuja la demanda de forma discreta}
HistoPpend = False; {--Mantiene el histograma de Pedidos pendientes--}
HistoStock = TRue; {--Mantiene el histograma del stock en mano--}
Labels {$LabelsLogis.pss}
Variables {$varsLogis.pss}
Lispalmacen;
Lispfabrica;
LispRetail1;
LispRetail2;
Macros {$MacrosLogis.pss}
Data
Item 20000;
Reset 200;
Vars TotalTime = 1000;
initial begin
InitBloques,
{----Estructura de los bloques--------------}
Lispretail1 = defbloqueLogistico(“Retail1”),
Lispretail2 = defbloqueLogistico(“Retail2”),
Lispalmacen = defbloqueLogistico(“almacen”),
Lispfabrica = defbloqueFabrica (“Fabrica”),
{---parámetros del sistema logístico--------}

DefProductParams(Lispretail1 ,1,10,0, 15,5,Lispretail1,
TransportePaquetes),
DefProductParams(Lispretail2 ,1,10,0, 15,5,Lispretail2,
TransportePaquetes),
DefProductParams(Lispalmacen,1,20,0,100,20,LispFabrica,TransportePaquetes),
DefProductParams(Lispfabrica,1,0,0,0, 0,False,TransporteGrandeCC),
{---Curvas de IO que se desea dibujar-------}

ShowIOCurves(Lispretail1,1,True,False,False,True),
end;
{$DataLogis.pss}
System {$BloquesStandard.pss}
{-------Generación y subida de pedidos-----------------------}

DEMANDA 1/5,Erlang(1,2),1,LispRetail1;
COMPUTE if LFreeSpace < 20000 then LGC;
TERMINATE 1;
DEMANDA 1/5,Erlang(1,2),1,LispRetail2;
COMPUTE if LFreeSpace < 20000 then LGC;
TERMINATE 1;
endsystem;
Montemos una nueva red logística con esta estructura y simulemos.

El modelo se muestra en el cuadro 9. Veamos algunos resultados:
Figura 10
Tabla de Resultados
A pesar de las fluctuaciones, podemos observar que el servicio en

cada una de las ubicaciones es mejor que en el caso anterior, pero que,
en conjunto, el sistema tiene fallos en el servicio de 0,03+0,04 = 0,07,
es decir de un 7% del tiempo. La distribución en dos centros, a igualdad
de stock total medio, tiene peor servicio que la distribución desde un
único distribuidor. Que esto es siempre cierto puede probarse analítica-
mente bajo ciertas hipótesis adicionales. Pero ya que estamos simulan-
do, simulemos algo más usando nuestro mismo modelo, por ejemplo
aumentando Smin hasta 17.
Figura 11
Tabla de resultados. Smin = 17
Ahora el servicio es algo mejor que en el caso inicial. Por tanto el

servicio se igualará entre los valores de Smin 16 y 17. Esto representa
un pequeño aumento del stock con respecto al caso inicial. En realidad
el efecto real, obtenido con grandes muestras, es bastante mayor. El re-
sultado general es que para una demanda total constante, el stock total
necesario para dar el mismo servicio, aumenta en proporción a la raíz
cuadrada del número de almacenes que sirven la demanda. Es decir, si
con un único almacén (distribuidor) se puede servir un mercado, y en
vez de uno se ponen dos almacenes de la mitad de tamaño, el stock to-
tal necesario para dar el mismo servicio que antes aumentará en propor-
ción a √2, es decir aumentará en un 41%. Intuitivamente esto se puede
constatar con un ejemplo sencillo. Supongamos que un mercado se cu-

bre con dos distribuidores, que la demanda de un distribuidor es de 0, 1
y 2 unidades con la misma probabilidad, y que cada distribuidor man-
tiene un stock total de 1 unidad. Si las demandas en un periodo son
(0,0), (1,0), (0,1) o (1,1) no se producen fallos de servicio y los clientes
quedan completamente satisfechos. En los demás casos hay roturas e in-
satisfacción de alguien. El buen servicio se da, pues, en 4/9 = 0,44, un
44% de los casos. Por tanto tenemos una probabilidad de fallo de 0,56.
Si ahora se concentran las demandas y los stocks en una única ubica-
ción, las combinaciones de demanda para las que no hay fallo son las
mismas que antes, y adicionalmente (2,0) y (0,2). Es decir, un 6/9 =
0,66, 66% de casos. El servicio ha aumentado desde el 44% hasta el
66%, por la simple concentración de las demandas en un único alma-
cén, manteniendo el stock total constante. Por supuesto, todo esto de-
pende de que el servicio pueda darse de la misma forma con un distri-
buidor que con dos, cosa que debe discutirse en cada caso, en función
de lo que se entienda por servicio en una compañía.
Bibliografía
ZIPKIN, Paul, Foundations of inventory management, McGraw-Hill,

2000.
Capítulo 16
(*)MUNDOS SUAVES: SIMULACIÓN CONTINUA EN PSPS
Los sistemas que hemos simulado hasta ahora han sido sistemas dis-
cretos. En la simulación discreta el número de eventos es finito para
cualquier intervalo de tiempo. Por ejemplo, la llegada de clientes con-
secutivos a un sistema se produce en instantes de tiempo diferentes, se-
parados por un intervalo mayor que 0. Sin embargo, hay sistemas en los
que se están produciendo cambios todo el tiempo. Supongamos que te-
nemos un depósito de agua que se llena a velocidad constante y se va-
cía también a velocidad constante. El nivel de agua del depósito está
cambiando continuamente. En estos casos la simulación continua es
más apropiada, aunque la simulación discreta puede servir como una
aproximación.
En este capítulo veremos cómo mediante el bloque INTEGRATE de
la sección System podemos implementar de manera sencilla la simula-

ción de un modelo en tiempo continuo.
1. Simulación Continua. Bloque INTEGRATE
El bloque INTEGRATE del PSPS se limita a programar la ejecución

de una función en línea que figura en su único argumento. Recordamos
que una función en línea es una colección de sentencias Pspal que de-
vuelven un valor mediante la sentencia Return. La ejecución de la fun-
ción en línea se repite a pequeños intervalos elementales que se pueden
proporcionar en bloque STEP, definido en la sección Data del modelo.
La mayoría de procesos en tiempo continuo se pueden especificar

dando el estado del sistema y la velocidad de cambio en función del es-
tado y posiblemente de otras magnitudes del entorno, incluyendo el
tiempo. Por ejemplo supongamos un depósito cuyo nivel x es el estado.
El depósito se llena a velocidad llenado(x,t) y se vacía a la velocidad
vaciado(x,t). La velocidad conjunta de llenado/vaciado será:
llenado(x,t) – vaciado(x,t)
En la notación típica del cálculo, se denota la velocidad de cambio
del estado por la expresión dx/dt, es decir el incremento dx de x, en un
intervalo pequeño de tiempo dt. El cambio en el sistema se indica di-
ciendo que la velocidad de cambio del estado, dx/dt, es precisamente la
diferencia de velocidades de llenado y vaciado:
dx
–––– = llenado (x,t) – vaciado (x,t)
dt
Esta ecuación se puede escribir de otra forma más sugerente como:
dx = (llenado (x,t) – vaciado (x,t))dt
Podemos también escribir la ecuación anterior como:
x (t + dt) – x(t) = (llenado (x,t) – vaciado (x,t))dt
lo que sugiere el cálculo iterativo de x(t+dt), a partir de x(t) y de las ve-
locidades correspondientes. Este proceso se conoce como «integración
de la ecuación diferencial», y hay muchos «métodos de integración» o
formas de llevar a cabo la integración. Quizá el método más sencillo es
el método de Euler. Para un valor pequeño, pero finito, de dt digamos a,
este método calcula la solución aplicando repetidamente la fórmula:
x (t + α) = x(t) + (llenado (x,t) – vaciado (x,t))α

incrementando en cada paso el tiempo actual t por el valor de a.
El bloque INTEGRATE está pensado para realizar repetidamente
los pasos elementales de este cálculo. La función debe hacer el cálculo
de x(t+dt) a partir del estado anterior x(t), de las velocidades y del inter-
valo elemental de integración, dt, que es el valor que se facilita en el
bloque STEP. El bloque INTEGRATE llama a la función argumento
cada dt unidades de tiempo, para que haga un paso de integración.
El sistema no implanta directamente ningún método de integración.
El método debe ser programado por el propio usuario dentro de la fun-
ción en línea.
MUNDOS SUAVES: SIMULACIÓN CONTINUA EN PSPS 401
El cálculo iterativo debe usar un valor de dt, el intervalo elemental

de tiempo, igual al valor máximo compatible con la dinámica del sis-
tema que se va a integrar. Un valor de STEP demasiado grande puede
hacer oscilar el sistema de forma artificial, e introducir componentes es-
púreos en el comportamiento del mismo. Por otra parte, un valor dema-
siado pequeño provocará frecuentes recálculos, haciendo más lenta la
simulación. Por tanto el usuario debe tratar de determinar el valor de dt
como el valor más grande que mantenga las verdaderas propiedades di-
námicas del sistema que esta siendo simulado. A menudo esto se puede
lograr realizando experimentos controlados, antes de proceder a simu-
laciones masivas.
El proceso de integración se desencadena con la llegada de una tran-
sacción al bloque INTEGRATE. La transacción queda detenida en el
bloque y la función en línea se activa. A partir de ese momento se
ejecuta la función cada dt unidades de tiempo. El proceso continua
mientras la función devuelve el valor False, esto es hasta que la función
devuelva el valor True. En ese momento el proceso se detiene y la tran-
sacción detenida se libera para seguir su recorrido por los bloques del
modelo.
La utilización del bloque INTEGRATE puede dar lugar a situacio-
nes peculiares. Por ejemplo, a no ser que se programe adecuadamente,
al llegar cada transacción siempre se realiza un paso de integración.
Esto puede evitarse, rodeando el proceso de integración con un If.
Una transacción sólo se libera cuando la función argumento del blo-
que devuelve el valor True. Por otra parte toda transacción que llega a
un bloque INTEGRATE accede a él y desencadena un proceso de inte-
gración. Por tanto puede haber varias transacciones detenidas en un
mismo bloque, y varios procesos de integración procediendo en simul-
táneo sobre las mismas variables. Que esta situación no produzca resul-
tados anómalos cae bajo la responsabilidad del usuario. Por ello debe
procederse con precaución en la utilización del bloque INTEGRATE 1,
y especialmente, se deben usar los atributos de la transacción para con-
tener las variables de trabajo, cuando pueda haber dos transacciones en
el mismo bloque.
Para la programación del método de integración es de utilidad la
función Dt. Es una función sin argumentos que devuelve el intervalo de
integración dt definido en el bloque STEP.
1. Moraleja: Usar bien el bloque INTEGRATE es un arte que se adquiere con la

experiencia.
Ejemplo 1:
Este ejemplo muestra la forma de simular el vaciado y llenado de

un depósito. La ecuación que describe el proceso es la ecuación dife-
rencial
dx
–––– = llenado (x,t) – vaciado (x,t)
dt
El depósito se llena a velocidad constante y se vacía a velocidad
constante, hasta que se ha vaciado del todo. Luego se esperan 15 minu-
tos antes de volver a arrancar el proceso de vaciado.
La forma más simple de proceder es implantar, mediante el bloque
INTEGRATE, un sencillo método de integración de Euler para la ecua-
ción diferencial del depósito. Como hemos dicho, el método de Euler
usa la expresión:
x (t + dt) – x(t) = (llenado (x,t) – vaciado (x,t))dt
para realizar la integración. Para evitar las oscilaciones típicas de la in-
tegración numérica cuando se alcanza una frontera, se utiliza un truco
estándar que consiste en no usar nunca una velocidad mayor que aque-
lla que lleva a llenar, o vaciar, completamente el depósito en un dt.
Cuadro 1
Modelo «Vaciado y Llenado de un Depósito»
Variables
nivel;
VelocidadEntrada;
VelocidadSalida;
Macros
Llenado:Function(velocidad)
Begin
nivel=nivel+ velocidad*dt,
FDrawXY(1,1,cl,nivel),
Return False
End;
Vaciado:Function(velocidad)
Begin
nivel = nivel - Cond(nivel> 0,Min(velocidad*dt,nivel)),

FDrawXY(1,1,cl,nivel),
If nivel > 0 then Return False Else Return True
End;
Data
TIME 100;
Vars velocidadEntrada = 50;
Vars velocidadSalida = 200;
Initial FdrawCont(1,GSERNODOTS,1);
System
GENERATE 0,1;
INTEGRATE Llenado(VelocidadEntrada);
GENERATE 15,1;
INTEGRATE Vaciado(VelocidadSalida);
WAITFOR 15,cb-1;
Endsystem;
El modelo tiene dos bloques generadores. El primer bloque GENE-

RATE genera una única transacción que pone en marcha el proceso de
llenado del depósito. El proceso de llenado está controlado por la fun-
ción Llenado. Esta función realiza un paso de integración a partir de
la velocidad de llenado. La función se encuentra en un bloque INTE-
GRATE y, por tanto, se ejecutará cada STEP unidades de tiempo. Como
podemos observar, la función devuelve siempre el valor False, y por
tanto la transacción no saldrá nunca del bloque INTEGRATE. Esto hace
que el depósito se llene continuadamente.
El segundo bloque GENERATE también genera una única transac-
ción. Esta transacción lanza el proceso de vaciar el depósito activando,
al llegar al bloque INTEGRATE, la función Vaciado. Esta función

vacía el depósito de forma continua. Si el depósito llega a estar vacío la
función devuelve el valor True y la transacción generada sale del bloque
INTEGRATE dirigiéndose a un bloque de demora donde espera 15 uni-
dades de tiempo. Durante este tiempo la función Llenado que sigue
«en marcha» continúa llenando el depósito. De esta forma cuando la úl-
tima transacción salga del bloque de demora, el nivel del depósito habrá
subido y la función de Vaciado podrá volver a ponerse en marcha. La
figura 1 muestra la evolución del nivel en el tiempo. Una característica
típica de estos modelos es que el dibujo de las gráficas hay que hacerlo
desde dentro de las funciones del bloque INTEGRATE.
Figura 1
Nivel del depósito
Graph Number1
800
700
600
500
400
300
200
100
0
-100
0 20 40 60 80 100
X axis
2. Movimiento Browniano y difusiones
Uno de los procesos aleatorios más usado en la simulación dis-

creta es el proceso normal. En este proceso se muestrea repetidamen-
te una distribución normal a intervalos unitarios de tiempo. Por ejem-
plo, la demanda externa de un sistema se modela a menudo de esta
forma.
Si se cambia la frecuencia de muestreo del proceso la media y la va-
rianza de la distribución normal deben alterarse convenientemente. Por
consistencia, es necesario que la media de la distribución sea proporcio-

nal a la duración del intervalo unitario, y su desviación tipo proporcio-
nal a la raíz cuadrada de dicho intervalo.
En la simulación continua, es necesario disponer de un proceso aná-
logo al proceso normal, que en algún sentido sea el límite de ese proce-
so cuando el intervalo de muestreo tiende a 0. Intuitivamente queremos
que, en cada momento, el proceso sea una observación de una pobla-
ción normal, y que sus medias y varianzas mantengan entre sí las rela-
ciones de consistencia enunciadas más arriba.
El proceso de movimiento Browniano, o proceso de Wiener, W(t)
realiza este deseo. El proceso tiene las siguientes propiedades básicas:
1. Trayectorias continuas.
2. Incrementos independientes, el incremento de la trayectoria en

cualquier intervalo dado es independiente del incremento en otros
intervalos que no tengan puntos en común con aquél.
3. Sus incrementos en un intervalo cualquiera, digamos dt, están dis-
tribuidos normalmente, con media 0 y desviación tipo raíz de dt.
En símbolos:
W (t + dt) = W (t) + Normal (0, √dt)
Esta fórmula es cierta para cualquier incremento de tiempo dt. Una
forma más sugestiva de expresar la misma idea es la expresión:
dW (t) = Normal (0, √dt)
que proporciona el incremento del proceso W(t) durante un intervalo de
tiempo dt.
A partir de esta expresión para dW(t) se puede construir una rica fa-
milia de procesos aleatorios relacionados con el de Wiener, que se co-
nocen con el nombre de difusiones. Así como los incrementos del pro-
ceso de Wiener están distribuidos normalmente con media 0, en las
difusiones admitimos que el proceso tenga cualquier media. De la mis-
ma forma una difusión generaliza el proceso de Wiener, admitiendo
cualquier valor positivo para la desviación tipo. En ambos casos deben
cumplirse las condiciones de consistencia. En general una difusión D(t)
se puede describir por una expresión como la siguiente:
dD(t) = a(D,t)dt + b(D,t)dW(t)
Esta expresión, a la que se le puede dar un sentido preciso 2 se cono-
ce con el nombre de ecuación diferencial aleatoria. El término a(x,t) es
el coeficiente de dirección (drift coefficient) y el término b(x,t) se llama
coeficiente de difusión (diffusion coefficient). Ambos dependen, en ge-

neral, del valor del proceso y del instante de tiempo. Si pensamos en el
proceso como un conjunto de trayectorias, el coeficiente a(x,t) empuja
las trayectorias en una dirección determinada, porque determina la me-
2. Aunque el desarrollo es horriblemente complicado y sorprendente. Por ejemplo,

se puede probar que las trayectorias W(t) del movimiento Browniano no poseen deriva-
da en ningún punto. Por tanto la expresión dW(t) carece de significado desde el punto
de vista tradicional. No es un diferencial ya que el incremento de la trayectoria no tien-
de a 0 para casi todas las trayectorias. Por tanto la expresión diferencial, de entrada, es
una tontería. A partir de aquí debe empezar un proceso de construcción tan delicioso
como aburrido para el no interesado en disquisiciones matemáticas.
dia de los incrementos de las mismas. Por su parte, el coeficiente b(x,t)

actúa sobre la desviación tipo, y dispersa las trayectorias, generando en
cada punto una «escoba de trayectorias» de ancho variable.
Si, por ejemplo, estamos hablando de un proceso de demanda,
a(D,t) indica la velocidad media de crecimiento de la demanda en cada
instante de tiempo. De la misma forma b(D,t) determina la velocidad de
crecimiento de la dispersión de la demanda, a medida que el tiempo se
aleja del instante actual y hacia el futuro.
Cuadro 2
Modelo «Difusiones»
Variables
Proceso array 3;
Macros
axt : function(x,t) return 0;
bxt : function(x,t,k) return sqrt(k);
difusion: function(x,t)
Locals i;
begin
for i = 1 to 3 do begin
proceso[i] = Proceso[i] +
axt(x,t)*dt+Normal(0,bxt(x,t,i)*sqrt(dt)),
FDrawXY(1,i,cl,Proceso[i])
end,
return False
end;
System
GENERATE 0,1;
INTEGRATE difusion(&Proceso,cl);
TERMINATE 0;
Endsystem;
La simulación de una difusión es sencilla. Basta tratar la ecuación

definitoria como una ecuación diferencial, e integrarla con un cierto
STEP. El proceso debe incrementar el valor de la trayectoria por a(x,t)
dt y a continuación sumarle una variable normal.
El cuadro anterior muestra cómo generar este proceso. La figura 2

compara trayectorias del proceso para a(x,t) = 0 y b(x,t) = √k) con k =
1,2 y 3. (¿Quién es quien en la figura?).
Figura 2
Tres difusiones
Graph Number1
20
10
-10
-20
-30
-40
-50
-50 0 50 100 150 200 250 300
X axis
Es de destacar la irregularidad salvaje de las trayectorias, que no se

aprecia suficientemente debido a un problema de escala. De hecho, el
proceso de Wiener es fractal, en el sentido de que cualquier pequeña
porción de una trayectoria reproduce las propiedades de la trayectoria
completa, especialmente en cuanto a irregularidad.
El proceso de Wiener tiene todo tipo de propiedades curiosas. Por

ejemplo, vuelve con probabilidad 1 al origen, aunque las excursiones
son de tamaño ilimitado, porque con probabilidad 1 alcanza cualquier
valor. Sucede que el tiempo medio hasta volver al origen es infinito, por
lo que hay tiempo de sobra para hacer excursiones lejanas. Todas estas
propiedades y otras muchas pueden consultarse en la literatura [Karlin]
y no podemos proseguirlas aquí.
A pesar de estas propiedades raras, las difusiones son de gran apli-
cación, especialmente en el modelado de los precios en los mercados fi-
nancieros. La teoría de las opciones, con sus fórmulas famosas y popu-
lares de Black-Scholes para evaluar opciones, utiliza las difusiones
como modelo básico para las series de precios. Para nuestros propósi-
tos, valga que como aproximación a un proceso normal en tiempo con-

tinuo, las difusiones comparten utilidad y facilidad de generación (una
simple aplicación del bloque INTEGRATE), por lo que, en la aplica-
ción, sus propiedades esotéricas son más una anécdota que una dificul-
tad seria.
3. Simulación mixta discreta / continua
A menudo es necesario simultanear la simulación discreta con la

continua. Típicamente los procesos físicos, como la transmisión de la
energía, o el llenado y vaciado de depósitos, entre otros, se simulan me-
jor como procesos continuos. En cambio, los procesos operativos em-
presariales suelen simularse mejor por modelos discretos. Las herra-
mientas de que disponemos pueden usarse para conseguir modelos
integrados en los que conviven ambos enfoques.
Ejemplo 2:
Una factoría dispone de un horno en el que se lleva a cabo el reco-

cido de lingotes de acero. El horno tiene una capacidad máxima de 10
lingotes y está funcionando constantemente a la misma temperatura. La
llegada de los lingotes al horno sigue una distribución exponencial de
media 4 minutos. La temperatura de los lingotes se mide continuada-
mente para controlar el proceso. Los lingotes deben permanecer en el
horno hasta alcanzar la temperatura adecuada para completar el reco-
cido, que depende del lingote y se distribuye uniformemente en el inter-
valo 900 ± 100 grados. La temperatura inicial, con la que los lingotes
llegan al horno, está distribuida uniformemente en el intervalo 150 ± 50,
y el coeficiente de transmisión de calor, desde el entorno del horno has-

ta el lingote vale 0,02. Por supuesto, el horno se enfría al entrar un lin-
gote. También el lingote se enfría, por efecto del aire, si debe esperar.
Los lingotes estarán representados por transacciones, y el horno por
un procesador de capacidad 10 al que deben acceder las transacciones.
Programa del modelo:
Las transacciones que representan a los lingotes son generadas por

un bloque GENERATE. A continuación un bloque ENTER controla la
entrada al procesador que representa al horno. Las características de los
lingotes se asignan a los atributos de la transacción mediante un bloque

COMPUTE. Así el At [2] indica la temperatura inicial con la que llega
un lingote al horno, el At[3] el coeficiente de transmisión de calor y el
At[4] la temperatura que debe alcanzar el lingote en el horno.
Una vez que las transacciones se encuentran en el procesador, el
bloque INTEGRATE junto con la función Calentamiento realiza el
proceso de calentamiento de los lingotes.
La función Calentamiento modifica progresivamente la tempe-
ratura del lingote, en función de la temperatura del horno y del coefi-
ciente de transmisión de calor. También altera la temperatura del horno.
El horno tiene una temperatura inicial que disminuye con la entrada de
un lingote frío, y que aumenta mientras no entra ningún lingote. La fun-
ción, por último, comprueba si la temperatura alcanzada por el lingote
es igual o mayor que la temperatura deseada. Si aún no alcanza la tem-
peratura deseada, la función devuelve el valor False; en caso contrario
devuelve el valor True.
De forma similar, la función enfriamiento reduce la temperatu-
ra del lingote, si es que tiene que esperar un rato sin entrar en el horno.
Obsérvese la técnica para terminar la integración en el momento en que
la transacción es admitida al procesador. Se consulta constantemente el
espacio libre en el procesador, y si es distinto de 0 se detiene la integra-
ción para que la transacción siga su camino y pueda entrar.
La transacción en curso permanece en el bloque INTEGRATE has-
ta que la función Calentamiento devuelve el valor True, es decir
hasta que el lingote alcanza la temperatura deseada. Puede haber más de
una transacción en el bloque INTEGRATE y por lo tanto la función
Calentamiento puede ser ejecutada por más de una transacción. Por
este motivo hemos asignado la temperatura del lingote a un atributo de
la transacción que lo representa. Esto separa las variables y logra que el
código sea reentrante, es decir ejecutable por varias transacciones a la

vez sin interferencias mutuas. En cambio la variable TempHorno es
siempre la misma y debe poder ser modificada por todos los procesos
de integración que se encuentran en marcha.
Cuadro 3
Modelo «Cocción de Lingotes»
Constants
Horno = 1; Out = False;
Temp = 2; C = 3;
Desired = 4;
Labels
Ciclo;
Variables
TempHorno; {---Temperatura del horno---}
TempExterna; {--Temperatura del aire fuera del horno---}
Macros
{---Esta función controla el calentamiento de los lingotes. Si han alcan-
zado la temperatura deseada la función devuelve True, en caso contrario
False---}
Calentamiento: Function()
begin
At[Temp] = At[Temp] + dt * (TempHorno-At[Temp])*At[c],
TempHorno = TempHorno+ dt * (2000-TempHorno)*2/10,
FDRawXY(1,1,cl,TempHorno),
If At[Temp] <= At[Desired] Then Return False
Else Return True
end;
{--Mientras se espera se va enfriando--}

Enfriamiento:function()
begin
At[Temp] = At[Temp] + dt * (Tempexterna-At[Temp])*At[c],
FDRawXY(1,1,cl,TempHorno),
If fc[Horno] < fs[horno] then Return True

Else Return False
end;
Data
Time 10000;
Vars Fs[Horno] = 10;
Vars TempHorno = 2000;
Step 1;
Report On;
Initial FDrawCont(1,GSERNODOTS,1);
Initial FDrawCont(2,GSERUNORDER,1);
System
GENERATE Exponential(4);
INTEGRATE enfriamiento;
COMPUTE Begin
At[Temp] = Uniform(100,200),
At[C] = 1/50,
At[Desired] = Uniform(800,1000),
End;
ENTER Horno;
DRAWXY( 2,[1,cl,fc[Horno]];
{--aproximación a la caida de temperatura del horno al entrar un

lingote--}
COMPUTE TempHorno = TempHorno -(TempHorno- at[temp])/5;
Ciclo:INTEGRATE Calentamiento;
LEAVE Horno;
DRAWXY( 2,[1,cl,fc[Horno]];
TABULATE 1, Cl-At[1];
TERMINATE;
Endsystem;
Cuando el lingote alcanza la temperatura deseada, la transacción

abandona el bloque INTEGRATE y continua su recorrido, formado por
un bloque LEAVE que hace que la transacción deje el horno y un blo-
que TERMINATE que la hace desaparecer del sistema.
Simulando este modelo durante 100 minutos obtenemos outputs
como los de la figura 3. El primer gráfico muestra el número de lingo-
tes en el horno. El segundo es una gráfica de la temperatura del horno.
Figura 3
Output simulación
Graph Number2 Graph Number1
2100
10
2000
8 1900
1800
6
1700
4
1600
2
1500
0 1400
0 10 20 30 40 50 60 70 80 90 100 0 20 40 60 80 100
X axis X axis
El modelo se puede instrumentar ahora para obtener diferentes pa-

rámetros del sistema, por ejemplo: no entramos en detalles, dejando
como ejercicio al lector la instrumentación adecuada para responder a
las siguientes cuestiones: ¿Cuál es la producción horaria media del sis-
tema?, ¿Cuánto es el tiempo de estancia en el horno?
El horno es una cola G/G/n, cuyo servicio tiene una distribución de
probabilidad muy complicada. Una forma de estimar esta función de
distribución es simularla. En el modelo básico hemos incluido la instru-
mentación para obtener la distribución del tiempo de servicio, y el re-
sultado se recoge en el histograma adjunto.
Figura 4
Tiempo de estancia en el horno
El tiempo medio de estancia es 30 minutos y el coeficiente de varia-

ción es 4,89/30 = 0,163. Con estos valores, usar las técnicas del capítulo
12 para determinar la cola media a la entrada del sistema es un sencillo
ejercicio, que dejamos al lector. Así, hemos combinado la simulación
continua con la discreta y con las técnicas analíticas. ¿Alguien da más?
Ejemplo 3: Simulación de una planta alcoholera
El proceso de destilación que se lleva a cabo en una planta produc-

tora de alcohol de caña es el siguiente:
La melaza llega de forma continua a la planta, que dispone de dos

depósitos en los que se realiza el proceso de fermentación. La velocidad
de llenado de los depósitos es constante, pero debido a problemas de
tuberías no pueden llenarse los dos depósitos a la vez. Cuando los de-
pósitos están llenos, la melaza debe permanecer en ellos durante una
hora, hasta que acabe de fermentar. Después, la melaza fermentada
pasa a la torre de destilación y de ahí el alcohol destilado se almacena
en un depósito de gran capacidad. El tiempo de paso por la torre de
destilación es de 8 minutos. Cada vez que uno de los depósitos de fer-
mentación queda vacío, se limpia (se le pasa agua) y puede volver a lle-
narse, comenzando un nuevo proceso.
Esquema del modelo:
Figura 5
Esquema de la planta alcoholera
Cuba melaza
Vertido de
alcohol
hacia el
depósito
de almacén
Cuba melaza Torre de

destilación
En el modelo de la planta alcoholera, que desarrollamos a continua-

ción, casi todo el proceso se realiza de forma continua. La excepción es
la carga de los depósitos de fermentación. Ahí se supone que el tiempo
de carga es despreciable, y por tanto el rellenado del depósito corre a
cargo de una transacción que lo ocupa con el numero de litros adecua-
do, vaciando al mismo tiempo el de entrada.
En este proceso continuo hay que modelar el retraso que se produce

en la destilación. La velocidad de salida de la torre es la misma que la
de entrada hace 8 minutos. Por tanto, con velocidades variables hay que
recordar las velocidades de entrada de los últimos 8 minutos, para usar-
las en la salida, 8 minutos después. Para este propósito utilizamos un
array funcional o FArray.
Recordamos que un FArray es un tipo especial de array unidimensio-
nal cuyos subíndices pueden tomar cualquier valor real. Como vimos, un
FArray define una función construida por puntos con interpolación line-
al entre ellos. En nuestro ejemplo, definiremos un FArray al que asigna-
remos, en cada instante de tiempo, la velocidad de entrada a la torre de
destilación de la melaza fermentada, que a su vez sale de los depósitos.
La velocidad de salida de la torre en el instante cl, y por tanto la de en-
trada en el depósito final, será el valor de la función retrasada por el
tiempo de destilación x, es decir el valor del FArray en el tiempo cl - x.
Programa del modelo
El programa está estructurado en varios ficheros. El fichero Alco-

holVars.pss, contiene la definición de las constantes, etiquetas y varia-
bles del modelo. El fichero AlcoholFuns.pss contiene la sección Macro,
en la que se definen las funciones que implementan los procesos de lle-
nado y vaciado de los depósitos y de la torre de destilación. Por último,
el fichero Alcohol.pss contiene las secciones Data y System. Éste es el
programa principal, los demás ficheros están contenidos en él usando
comentarios activos.
Cuadro 5
Modelo Continuo «Planta Alcoholera».

Sección Constants y Variables
FICHERO: ALCOHOLVAR.PSS
Constants
Pintar = True; PintaIO = False;
depo1 = 1; depo2 = 2;
descarga = 3; melaza = 4;
destila = 5; contador = 1;
Labels
seguir; vaciar; final;
Variables
i;x;
total;
velocidad;
modulo;
Retraso;
Lote;
vel array 2;
velRetrasada farray;
Funciones del Modelo
Melazas ( ): función sin argumentos que devuelve siempre el valor

False. Esta función controla la llegada de la melaza al sistema. La me-
laza llega de forma continua a una velocidad de 30 litros por unidad de
tiempo y se almacena en un depósito representado por el procesador
Melaza. Si el contenido del procesador es mayor que la capacidad del
mismo, la entrada se detiene y no se añade más melaza al depósito. La
entrada se restablece automáticamente cuando el procesador deja de
estar lleno. Esta función también modifica el estado del Switch 1, que
coordina la llegada de melaza al sistema con el proceso de llenado de
los depósitos de fermentación. Si el contenido del procesador Melaza es
superior a la constante Lote, es decir, si hay suficiente melaza para lle-
nar los depósitos de la planta alcoholera, el estado de Switch se pone
en On.
VaciaMelaza (Número Depósito): función de un único argumento

que devuelve siempre el valor False. Esta función aumenta de forma
instantánea el contenido del procesador indicado en el argumento de la
función. Es decir, la función modela el proceso de llenado de los depó-

sitos de fermentación, y el proceso de vaciado del depósito de melaza.
Destilación (Número de Depósito, Retraso): función de dos argu-

mentos que devuelve el valor True si el contenido del procesador que
representa al Depósito es igual a cero. En caso contrario, devuelve el
valor False. La función modela el flujo de alcohol destilado que entra y
sale de la torre de destilación. Modifica el contenido del procesador
Descarga mediante el FArray VelRetrasada. Este array tiene en cuenta
el retraso que sufre la melaza en la torre debido a la destilación.
Cuadro 6
Modelo Continuo «Planta Alcoholera». Sección Macros
FICHERO: ALCOHOLFUNS.PSS
Macros
Dibu : function (num,yy)
Locals x;
begin
if mod(cl,modulo) eq 0 then x = FdrawXY(1,num,cl,yy),
return 0
end;
Pintadepos : function ()
Locals x;
begin
x = Dibu(1,fc[melaza]),
x = Dibu(2,fc[depo1]),
x = Dibu(3,fc[depo2]),
return True
end;
Destilacion : function(index,retraso)
Locals x;
begin
x = Cond(fc[index] <= 0, 0,
Cond(fc[index] > vel[index]*dt, vel[index], fc[index]/dt)),
velRetrasada[cl] = x,
fc[index] = fc[index] - x*dt,
if abs(fc[index]) < 1/1000 then fc[index] = 0,
x = velRetrasada[cl-retraso],
if fc[index] > 0 then begin

fc[descarga] = fc[descarga] + x*dt,
FDrawXY(2,1,cl,fc[descarga]),
return False
end else return True
end;
Melazas :function()
Locals x;
begin
fc[melaza] = fc[melaza] + Cond(fc[melaza] >= fs[melaza],0,
velocidad)*dt,
DEBUG Pintar do x = PintaDepos,

if fc[melaza] >= Lote then x = FSwitch(1,On), {Hay un lote. Señalarlo}
return False
end;
VaciaMelaza: function (index)
Locals x;
begin
DEBUG Pintar do x = PintaDepos,
fc[index] = fc[index] + Lote,
fc[melaza] = fc[melaza] - lote,
DEBUG Pintar do x = pintaDepos,
return False
end;
Cuadro 7
Modelo Simulación «Planta Alcoholera». Sección Data y System
FICHERO:ALCOHOL.PSS
@$AlcoholVars.pss@
@$AlcoholFuns.pss@
Data
Facility 5;
Switch 1;
Step 1/5;
Time 200;
Vars fs[descarga] = 300;

Vars fs[melaza] = 400;
Vars fs[destila] = 1;
Vars Velocidad = 30;
Vars Vel = \10,10\;
Vars Modulo = 5;
Vars Lote = 300;
Vars Retraso = 8;
Report On;
initial begin
for i = 1 to 3 do begin
Fdrawcont(1,GSERNODOTS,i),
Fdrawcont(1,GSERUNORDER,i),
FDrawcont(1,GTITLE,“Estado Depositos”)
end,
FDrawCont(2,GSERNODOTS,1)
end;
{----Modelo de una planta alcoholera----------------------}

System
{--- se recibe melaza de forma continua--------}
GENERATE 0,1;
INTEGRATE melazas;
{---- La melaza entra en dos depósitos instantáneamente donde fermenta en

batch durante 60 minutos. Entre el depósito y la salida hay una destila-
ción en continuo con un retraso de 8 -------}
GENERATE 0,2;
vaciar: QGATE 1,Off,Fifo,wait,Off; {---Espera a que haya un lote ---}

SWITCH 1,Off;
COMPUTE x = VaciaMelaza(TrCount);
{---y lo pone instantáneamente en el depósito}
ADVANCE 60; {--fermentación--}
ENTER destila;
INTEGRATE destilacion(TrCount,Retraso);
LEAVE destila,1,vaciar;
endsystem;
El modelo tiene dos bloques generadores de transacciones. El pri-

mer bloque GENERATE genera una única transacción que activa el
proceso de llegada de la melaza al sistema. El segundo bloque genera
dos transacciones que representan el proceso de los dos depósitos de la
planta alcoholera. Estos procesos, el de llegada de la melaza y los de
gestión de los depósitos, están coordinados mediante un semáforo (el
switch 1).
El primer GENERATE genera una única transacción en el instante
Cl = 0, y el bloque se desactiva. La transacción generada entra en un
bloque INTEGRATE que ejecutará la función Melazas cada Step uni-

dades de tiempo. La transacción quedará atrapada para siempre en el
bloque INTEGRATE, ya que la función argumento del bloque devuelve
siempre el valor False. Al igual que en el modelo del depósito de agua,
la melaza llega de forma continua al sistema.
El segundo bloque GENERATE genera dos transacciones en el ins-
tante Cl = 0. Estas dos transacciones quedan atrapadas en el bloque
QGATE a la espera de que el Switch 1, que controla el nivel de melaza
en el sistema, esté en On, es decir que haya suficiente melaza para lle-
nar un depósito. Cuando el estado del Switch cambia a On, la primera
transacción avanza al bloque siguiente. Se trata de un bloque SWITCH
que devuelve el estado del Switch número uno a Off, impidiendo de
esta manera que si hay una transacción en el bloque QGATE, ésta pue-
da continuar su camino hasta que no haya suficiente melaza. Después
del bloque SWITCH la transacción se dirige a un bloque COMPUTE en
el que se ejecuta la función VaciaMelaza que a la vez llena el depó-
sito de fermentación (representado por un procesador) y vacía el depó-
sito de la melaza, de forma instantánea. Una vez el depósito lleno, la
melaza debe fermentarse en «batch». Para ello un bloque WAITFOR
demora la transacción durante el tiempo de fermentación. Durante todo
el tiempo la función Melazas, argumento de un bloque INTEGRATE,
ha estado comprobando constantemente el contenido del procesador
Melaza, y cambiará el estado del Switch número 1 en el momento en el
que haya suficiente melaza para llenar un depósito completo. Cuando
esto suceda el cambio de estado del Switch pondrá en movimiento la se-
gunda transacción que se encuentre en el bloque QGATE.
Por último la transacción en curso se dirige a un bloque ENTER
para solicitar la entrada al procesador Destila. Si el procesador está
libre quiere decir que no hay ningún depósito vaciándose en la torre de
destilación y puede comenzar el proceso de vaciado del depósito núme-
ro TrCount. Como se han generado sólo dos transacciones, TrCount val-

drá 1 ó 2, para la transacción en curso. La transacción se dirige a un blo-
que INTEGRATE que usa la función destilación para modelar el
proceso de destilación. Cuando el contenido del procesador que repre-
senta al depósito de entrada es 0, significando que se ha acabado de pro-
cesar el deposito, la función devuelve el valor True y la transacción sale
del bloque INTEGRATE y se dirige a un bloque LEAVE mediante el
que abandona el procesador Destila. La transacción se dirige al blo-
que etiquetado con el label Vaciar, donde comienza un nuevo proce-
so de llenado y vaciado del depósito.
Resultados del modelo

En la figura 6 se muestra un fragmento de las gráficas de niveles de
los depósitos, que se obtienen en la simulación. Podemos observar tres
series. La serie verde, en línea continua, representa la evolución del de-
pósito de melaza. Las otras dos series muestran la evolución de los dos
depósitos de fermentación. La producción acumulada de la torre de des-
tilación se muestra en la figura 7.
Figura 6
Niveles de los depósitos
Estado Depósitos
450
400
350
300
250
200
150
100
50
0
-50
-50 0 50 100 150 200 250 300 350 400 450
X axis
Figura 7
Producción acumulada de la torre
Graph Number2
2400
2200
2000
1800
1600
1400
1200
1000
800
600
400
200
0
0 50 100 150 200 250 300 350 400
X axis
La producción total es de 2.360 unidades durante 400 unidades de

tiempo y por tanto la producción media del sistema es de 2360/400 =
5,9 unidades por unidad de tiempo, lejos de las 10 de velocidad punta
que puede obtener la torre. Esto se debe a las pausas en el proceso de la
torre causadas por la operación aguas arriba de la misma, en concreto
por las pausas en la fermentación. El lector debe tratar de entender lo
que está sucediendo, y a continuación tratar de determinar el número de
depósitos necesarios para que la torre funcione a plena capacidad.
4. Análisis de colas en régimen transitorio
Vamos a retomar el análisis del centro de atención al cliente que se

presentó en la sección 1 del capítulo 10, centro con una sola cola en ré-
gimen de llegadas variable. A continuación, reproducimos las tasas de
llegada según la hora del día, dadas allí. Entre los instantes indicados, la
tasa se puede obtener interpolando linealmente en la tabla.
9 10 11 12 13 14 15 16 17 18
1 2 4 5 3 2 1 4 6 7
Recordemos que las llegadas se iniciaban a las 8 horas y terminaban

a las 19, siendo en ambos momentos la tasa 0.
En la sección 4 del capítulo 12 vimos las dos ecuaciones diferencia-
les aproximadas, que se pueden usar para el cálculo de N(t) y V(t) en
régimen transitorio. Ahora ya podemos integrarlas, usando el bloque
INTEGRATE. El cuadro adjunto muestra la función que realiza la inte-
gración de estas dos ecuaciones diferenciales.
Cuadro 8
Colas en régimen transitorio. Sección Macros
{--Integración de las fórmulas aproximadas suponiendo la distribución

binomial negativa para las probabilidades de hallar el sistema en un
estado dado--}
DynamicMMn :function(x0,x1,landa, nu, n)
Locals i, p, aux, xk, Prob, cumProb, Tasa, tasaMedia, mediaCorregida,
Binomial, Poisson,j,mu,f0, f1,v0,v1,media,varianza;
begin
media = ^x0,
varianza = ^x1,
{--preparación de las distribuciones-----------------}
mu = nu * n,
If (varianza <1/10000) Then p = media*10000
Else p = media / varianza,
Binomial = (p > 1001/1000),
Poisson = (Abs(1 - p) < 1/1000),
If Not Poisson Then aux = media * p / (1 - p),
If Poisson Then xk = 0
else If Binomial Then xk = Int(aux + 1/2)
else xk = aux,
If Poisson Then Prob = Exp(-media)
else If xk == 0 Then Prob = 1
else Prob = power(p,xk),
f0 = 0,
f1 = 0,
cumProb = 1,
j = 0,
{--loop de cálculo de las velocidades de servicio---}
for j = 0 To n do begin
if (Not Binomial) Or (j <= -aux) Then begin
if j <= n then Tasa = j * nu else Tasa = n * nu,
f0 = f0 + Tasa * Prob,
f1 = f1 + j * (mu - Tasa) * Prob,
cumProb = cumProb - Prob,
if Poisson then Prob = Prob * media / (j + 1)
else Prob = Prob * (1 - p) * (xk + j) / (j + 1),
end Else j = n+1
end,
if Binomial then mediaCorregida = xk * (p - 1) / p
else mediaCorregida = media,

tasaMedia = (mu * cumProb) + f0,
v0 = - tasamedia,
v1 = (2 * media + 1) * tasaMedia + 2 * (f1 - mu * mediaCorregida),
{--Ahora la integración--}
^x0 = ^x0 + (landa + v0) * dt,
^x1 = ^x1 + (landa + v1) * dt,
FDrawXY(1,1,cl,media),
FDrawXY(1,2,cl,sqrt(varianza)),
return False
End;
DynamicMMn lleva a cabo la integración de las dos ecuaciones.

Los argumentos de la función son dos direcciones x0 y x1 de dos varia-
bles globales, que contienen la media N y la varianza V iniciales, y que
durante el cálculo contendrán, en cada instante, estos mismos paráme-
tros de la distribución del número en el sistema. Landa es la tasa de lle-
gada en el momento de llamar a la función. Los otros dos argumentos
definen el sistema en cada momento. Se trata de la tasa de servicio de
cada servidor (inversa del tiempo de servicio, en unidades por unidad de
tiempo) y el número de servidores. La primera parte de la función, has-
ta el bucle for, decide cuál es el tipo de distribución a usar para aproxi-
mar la distribución del número en el sistema, a partir de los parámetros
suministrados. El bucle for calcula las probabilidades individuales y las
utiliza para calcular los sumatorios que figuran en los segundos miem-
bros de las ecuaciones diferenciales. Finalmente, el resto de la función
pone juntas estas cantidades y realiza un paso de integración por el mé-
todo de Euler.
El próximo cuadro muestra el programa de la sección principal del

modelo:
Cuadro 9
Colas en régimen transitorio
Variables
tasareal farray;
x0;x1;
Macros
Resto : function(x,m)
return x-int(x/m)*m;
TasarealReal :function(tiempo)
return tasareal[Resto(tiempo,10)];
{$EcDiffColaMMn.pss}
Data
Vars tasareal=\1,2,4,5,3,2,1,4,6,7\;
initial begin
tasareal[0] = 0,
end;
RESET 100;
STEP 1/4;
INITIAL begin
Fdrawcont(2,GSERNODOTS,1,2,3),
Fdrawcont(1,GSTEPLEFT,1)
end;
TIME 1000;
System
GENERATE 0,1;
INTEGRATE DynamicMMn(&x0,&x1,TasaRealReal(cl),4,1);
TERMINATE 0;
endsystem;
Tasareal es la tasa horaria, el dato que se presentó en el capítulo

11. Para más detalles consultar la sección correspondiente de aquel capí-
tulo. La figura 8 muestra la evolución de la media y la desviación tipo (la
raíz cuadrada de la varianza) en función del tiempo y para el ejemplo.
Figura 8
Media y varianza de la distribución del número en el sistema
Graph Number1
8
7
6
5
4
3
2
1
0
-1
0 20 40 60 80 100
X axis
La línea continua es la media y la de trazos la varianza. Con estos

datos se pueden calcular en forma aproximada las probabilidades Pi, uti-
lizando la distribución Binomial Negativa (cuando N > V), la distribu-
ción Binomial (cuando N<V) o la distribución de Poisson cuando N=V.
Bibliografía
KARLIN, Samuel, A second course in stochastic processes, Academic

Press, 1981.
Capítulo 17
(*)SIMULACIÓN ESTRATÉGICA:
DINÁMICA DE SISTEMAS1
En este capítulo presentamos los principios de modelado de la Di-

námica de Sistemas. Se trata de un enfoque especial a la simulación de
sistemas continua, que ha tenido mucho éxito, especialmente entre los
iniciados. Este tipo de simulación se puede programar en PSPS de for-
ma relativamente fácil, usando el bloque INTEGRATE, con lo que la
Dinámica de Sistemas queda al alcance de cualquier lector de este libro,
sin necesidad de acceder a programas más complicados. Pero la Diná-
mica de Sistemas, además de una técnica de simulación es una visión
del mundo, y para algunos, hasta una religión. Empezaremos introdu-
ciendo las ideas básicas de la metodología, para presentar a continua-
ción una serie de ejemplos, que muestran cómo se puede implantar un
modelo de Dinámica de Sistemas en PSPS.
1. Fundamentos
Un modelo de Dinámica de Sistemas es, como toda simulación, pero

con más motivo, una ayuda al pensamiento que confronta a éste con la
1. Este capítulo es esencialmente idéntico al publicado sobre este mismo tema en

el libro de J. Riverola y B. Muñoz-Seca, Riqueza y Conservación: La gestión de espa-
cios Naturales Protegidos, Consejería de Medio Ambiente de la Junta de Andalucía,
1996.
lógica interna de sistemas complicados. Ante un sistema complejo con

multitud de interacciones, el pensamiento no asistido tiene problemas
para comprender todas las implicaciones de aquéllas. La Dinámica de
Sistemas es entonces una forma de contemplar interacciones, o de iden-
tificar formas de comportamiento, y no tanto una forma de predecir va-
lores de variables observables
La Dinámica de Sistemas toma una visión agregada del mundo 2.
Los modelos de Dinámica de Sistemas son muy relevantes cuando se
trata con muchas variables, cuya interacción es necesario entender para
diseñar cambios estructurales en el sistema para prevenir ciertos com-
portamientos no deseados. Son poco adecuados cuando el objetivo es el
control detallado del sistema, es decir, la especificación de los valores
de un cierto número de parámetros que pueden llevar al sistema al esta-
do deseado. En algún sentido la Dinámica de Sistemas es complemen-
taria al enfoque PSPS, orientado a los detalles de procesadores y tran-
sacciones.
La Dinámica de Sistemas se originó en Forrester hace unos 50 años,
y tiene sus bases metodológicas en el análisis de señales del campo de
la Ingeniería eléctrica. Forrester era un profesor de MIT 3, cuyas contri-
buciones a la Ingeniería eléctrica fueron notables. Sus patentes en el
campo de los dispositivos de memoria de ordenadores (núcleos de ferri-
ta) fueron muy celebradas en los inicios de la moderna informática. En
un momento dado, Forrester concibió la idea de que, a ciertos niveles,
el mundo es representable por sistemas de ecuaciones diferenciales no
lineales, y la puso en práctica por medio de dos desarrollos. En primer
lugar, un programa de ordenador, de manejo muy simple, que permitía
la formulación y cálculo rápido de sistemas 4. En segundo lugar, prepa-
ró una gran cantidad de ejemplos y material pedagógico que mostraban
la forma (a veces bastante retorcida) en la que un buen número de situa-
ciones reales se podían analizar con este tipo de modelos. En buena par-
te, el origen de la popularidad de la Dinámica de Sistemas se debe al es-

fuerzo de Forrester y su grupo para facilitar su uso. Hay pocas personas
que, expuestas brevemente a la Dinámica de Sistemas, no caigan presos
2. Que algunos pueden calificar inmediatamente como demasiado simple y hasta

inválida. En buena parte estos calificativos han sido debidos a la actitud mesiánica de
los autores iniciales de la Dinámica de Sistemas, que pretendieron la validez objetiva
universal de sus construcciones. Como representaciones de una realidad los modelos de
Dinámica de Sistemas son relativamente limitados y sencillos, y han sido por ello jus-
tamente criticados. Pero como ayudas al análisis son una herramienta vital.
3. Ahora ya jubilado.
4. El primer programa se llamaba Dynamo y fue un precursor de los modernos
I-think y Stella.
SIMULACIÓN ESTRATÉGICA: DINÁMICA DE SISTEMAS 429
en sus redes y se conviertan en profetas de la buena nueva. Queda aler-

tado el lector, para no caer en las redes de esta (veterana) seductora.
Para ayudarle, en lo que sigue inyectaremos un cierto grado de escepti-
cismo en su exposición.
2. Los principios de la Dinámica de Sistemas
Hay cuatro principios y dos reglas de conveniencia en el modelado

según la Dinámica de Sistemas.
Principios:
1) El mundo está compuesto de entes que evolucionan en trayecto-

rias continuas y derivables. La evolución de cualquier sistema se reali-
za en incrementos infinitesimales. Los cambios dramáticos no existen,
o a lo sumo se implantan como una secuencia rápida de pequeños cam-
bios. El lector puede objetar que esta hipótesis es poco restrictiva, ya
que una función continua y derivable puede ser bastante salvaje. Esto es
cierto, pero note también que esto elimina todo tipo de comportamien-
tos discretos, como la mayoría de los que se dan en PSPS. En este tipo
de modelos no podemos, por ejemplo, «descubrir petróleo» ni «cons-
truir un hotel». En el primer caso, la discontinuidad es temporal, no ha-
bía petróleo en el tiempo t menos algo, y lo hay en t. En el segundo
caso, la discontinuidad es más sutil. Se trata de la discontinuidad origi-
nada por una población discreta. Puede haber un hotel, o dos, o tres,
pero no 1,2 hoteles. Y en el mundo de la Dinámica de Sistemas ¡el nú-
mero de hoteles debe ser una función continua!
Esta condición no es grave cuando el número de hoteles es muy
grande, o cuando se dan condiciones de mezcla, en las que 1,5 hoteles

puede interpretarse como un promedio. En el primer caso, 1.000,5 ho-
teles es prácticamente lo mismo que 1.000 o que 1.001. En el segundo
caso, podemos pensar que se trata de hoteles equivalentes, es decir 1,5
hoteles es el equivalente de, digamos un hotel de 200 camas y otro de
100. La observación crucial es que, para que un modelo de Dinámica
de Sistemas sea relevante, el efecto de las discontinuidades en el fenó-
meno debe ser pequeño. En general esto sucede cuando el fenómeno
es agregado, porque normalmente se producen las dos situaciones an-
teriores, hay un gran número de elementos y/o una mezcla considera-
ble de ellos que permite sensatamente hablar de su promedio equiva-
lente.
2) El mundo puede describirse en términos de un sistema de flujos

y niveles 5. En Dinámica de Sistemas, el mundo se conceptualiza en tér-
minos de flujos, niveles y señales de control. Un nivel es una variable de
estado, y se puede imaginar como el nivel de un depósito en el que se
almacena la variable correspondiente. Un nivel es un integrador de flu-
jos. Un flujo es una velocidad asociada a una cierta magnitud, es decir
representa la velocidad de cambio temporal de una cierta magnitud.
Todo nivel tiene un flujo de entrada y/o de salida. La existencia de flu-
jos hace que los niveles aumenten o disminuyan con el paso del tiempo.
Por tanto, la base de un modelo de Dinámica de Sistemas es un conjun-
to de depósitos (niveles) y de flujos alimentando y detrayendo material
de ellos. Los flujos de entrada y de salida de un nivel están controlados
por señales. El lector debe imaginar la existencia de válvulas en la en-
trada y salida de un nivel, válvulas controladas por señales, que son el
resultado de aplicar reglas de decisión al valor de los niveles.
3) El comportamiento del sistema es describible por una serie de
mecanismos de feed-back. En Dinámica de Sistemas se supone que el
comportamiento global viene originado por la aplicación de reglas de de-
cisión internas al propio sistema. En otras palabras, el comportamiento
se genera por mecanismos de realimentación o feed-back. Estos meca-
nismos parten de la observación de las variables de estado, los niveles, y
transforman sus valores, por medio de funciones y procedimientos, en
señales de control, cuyos valores fijan la posición de los reguladores de
entrada y salida de los flujos hacia y desde los niveles.
Algunas variables pueden ser exógenas, fijadas externamente por
algún agente. Pero en Dinámica de Sistemas, la inmensa mayoría son
endógenas, resultado del comportamiento del propio sistema. El mundo
que trata de describir la Dinámica de Sistemas es un mundo autónomo,
en el que el sistema contiene todo el comportamiento necesario para su
evolución. El analista no es un controlador, sino un contemplador. Una
vez definida la estructura del sistema, se esfuerza en comprender por

qué suceden las cosas, y cómo puede cambiarse la estructura del siste-
ma para que evolucionando, aislado y sometido sólo a sus propias fuer-
zas, tenga el comportamiento deseado. Esta observación es clave para
entender los motivos 6 por los que algunos autores se han entusiasmado
con la Dinámica de Sistemas. Se trata de una de las pocas herramientas
para el análisis estructural de un sistema, en contraposición a su análi-
sis paramétrico.
5. En términos técnicos, esta hipótesis se puede reformular diciendo que la evolu-

ción del sistema es describible por medio de un sistema de ecuaciones diferenciales.
6. Siendo algo cínicos...
Un análisis paramétrico de un sistema hace hincapié en los contro-

les del mismo. El analista se pregunta cuáles deben ser los valores de
los parámetros de control y trata de calcularlos. La implicación es que
una vez calculados, el decisor procederá a implantar los controladores
oportunos para que esos valores se realicen. En el enfoque implícito en
la Dinámica de Sistemas, el analista trata de determinar cuál es la es-
tructura de los circuitos de realimentación, que conseguirá el comporta-
miento cualitativo deseado. Frecuentemente la estructura de realimen-
tación tiene características que la identifican con la estructura de las
relaciones sociales entre los agentes que forman el mundo virtual.
4) En un modelo deben introducirse todas las variables que se cre-
an relevantes, sin importar su nivel de abstracción o la dificultad de su
medición. El modelo sólo pretende ayudar a ofrecer explicaciones, y
una explicación cualitativa es a veces suficiente premio a una tarea de
modelado. Esto anima al modelador a incluir variables como «Satisfac-
ción de los empleados», «Fe en los líderes», «Bienestar del cliente» y
otras, cuya medición es difícil y cuyo impacto cuantitativo en otras va-
riables es aún más difícil de estimar. Un modelo sobre digamos «Satis-
facción del empleado» puede desarrollarse observando que la «Satisfac-
ción» es un nivel, que aumenta a medida que se tienen «experiencias
positivas» y disminuye cuando las experiencias «son negativas». Las
experiencias positivas pueden incluir variables como el «salario», el
«trato personal», la «interacción con el cliente» y otras, y otro tanto
para las negativas. Cualquier intento de medir y evaluar de forma preci-
sa las relaciones entre estas cantidades tropieza con todo tipo de dificul-
tades, como la de su propia definición operativa. Probablemente el
avance de la ciencia hará posible esta labor, pero quizá dentro de 200
años. Pero el decisor no puede esperar, tiene prisa por resolver su pro-
blema. El modelado sigue adelante sin importar la precisión con la que
se representa cada variable. La idea de fondo es que las propiedades es-
tructurales de un sistema, a menudo, no dependen de la forma detallada

en que se representan las variables, sino sólo del signo de su interac-
ción.
Esta característica de la Dinámica de Sistemas provoca a veces la
polémica. Un modelo del mundo puede contener sólo seis niveles: gra-
do de industrialización, nivel de polución, población, y otros. Y el mo-
delo puede predecir la extinción, casi con independencia de la forma
concreta de modelar cada variable, mientras sea correcto el signo de sus
influencias. Por ejemplo, con que sea cierto que a mayor industrializa-
ción mayor polución, y no lo recíproco, es suficiente. Por supuesto, esto
puede producir la imagen de «esos locos armados de ordenadores», un
montón de osados ignorantes que se lanzan sobre cualquier tema, arma-
dos de la espada sistémica. Es un riesgo que se corre, pero que añade

atractivo al campo.
No hay que sobrevalorar los efectos negativos de este principio.
Bien administrado, abre la puerta al modelado cualitativo de sistemas, a
la simulación cualitativa. Este tipo de simulación es de gran importan-
cia, pero aún está poco desarrollada por la vía más científica [Kuipers].
Juicio y sentido común son pues dos cualidades importantes de un buen
Dinámico de Sistemas.
Reglas de conveniencia
1) Las relaciones entre variables deben ser fundamentalmente de

tipo multiplicativo. Ésta es una regla técnica, pero que no carece de im-
portancia aunque no se identifica a menudo explícitamente en los trata-
dos sobre el tema.
Sucede que la naturaleza agregada del modelado hace delicada la
elección de unidades de medida. Mantener la consistencia de las unida-
des exige un cierto grado de atención a las dimensiones de las magnitu-
des involucradas. Hay que estar atento, y evitar sumar «manzanas» con
«peras» en alguna de las ecuaciones del modelo. Pero este problema se
presenta con la suma, no con la multiplicación. En una multiplicación,
las unidades del resultado son el resultado de multiplicar las unidades
de cada factor. Por ello no hay problemas de consistencia, basta con lle-
var la cuenta de las unidades, teniendo presentes las cancelaciones. En
las relaciones multiplicativas los cambios de escala en alguna variable
son también muy simples, ya que sólo afectan a la variable resultado.
En otro tipo de funciones, un cambio de escala en una variable puede
obligar a redefinir otras variables para preservar la consistencia.
Por estas razones de conveniencia, la Dinámica de Sistemas usa, en
la medida de lo posible, relaciones multiplicativas. El modelista no está

limitado a ellas, pero su tarea se simplifica notablemente si se adhiere a
este principio.
2) Regla de Ocam. Los conceptos abstractos se deben convertir en
valores concretos por medio de las transformaciones (variables proxy)
más sencillas que preserven el signo de la interacción. Esto es una re-
gla para la aplicación práctica del cuarto principio. Al elegir la forma
concreta de representar numéricamente un concepto, hay que concen-
trarse en mantener el sentido de su impacto, aumento o disminución,
pero siempre de la forma más sencilla posible. Esto quiere decir que si
el comportamiento del sistema es el mismo, si se usa por ejemplo, x o
x 2, la elección de qué función usar debe hacerse, dentro de las posibili-
dades, para simplificar al máximo la interpretación de los resultados. El

grado con el que esta regla impregna la Dinámica de Sistemas queda en
evidencia al constatar que como herramienta de análisis preliminar del
problema previo a su modelado, se recomiendan los «diagramas causa-
les». Un diagrama causal es simplemente un gráfico en el que figuran
todas las variables del problema, y que contiene flechas para unir varia-
bles que están causalmente relacionadas, con una indicación del sentido
de la relación. Y sólo se distinguen dos sentidos en toda relación: «po-
sitiva» o «+», cuando el aumento en la causa produce un aumento en el
efecto, y «negativa» o «–», cuando un aumento en la causa produce una
disminución del efecto.
3. Metodología de modelado
Por naturaleza, la Dinámica de Sistemas se utiliza para describir

modelos muy complicados, cuyas relaciones internas son difícilmente
escrutables para un analista no asistido por esta herramienta. Por ello, y
a diferencia de PSPS, hay que enfatizar la complejidad derivada del ta-
maño, más que de la delicadez de interacciones especificas. Esto hace
conveniente tener algún tipo de metodología de modelado capaz de ata-
car problemas de grandes dimensiones. Nuestro enfoque para ello es un
enfoque Top-Down, de refinamiento recursivo que aboga por el refina-
miento progresivo de un modelo inicial sencillo.
La secuencia de ejemplos que presentaremos en las próximas sec-
ciones tiene como objetivo fundamental ilustrar este enfoque. Las ca-
racterísticas principales de este procedimiento de modelado son las si-
guientes:
1) Modelado parsimonioso. Se empieza modelando una situación
muy simple que sólo involucre los recursos básicos que se quieren estu-
diar, y se refina de forma consecutiva en fases posteriores.

2) En cada fase se definen unas fronteras del sistema con el mundo
exterior, que se parametrizan y se mantienen constantes a lo largo del
análisis. Estos parámetros «de frontera» constituyen en cada momento
las variables exógenas o inputs de control del modelo.
3) Cada fase requiere la explotación del modelo para tratar de en-
tender el comportamiento del mismo y el efecto de la variación en los
parámetros exógenos. Antes de pasar a la etapa 4, el analista debe tener
una idea clara de la sensibilidad del sistema a variaciones controladas
de esos parámetros.
4) Cierre del mundo. Ahora el analista debe preguntarse cuáles de
los parámetros exógenos de la fase anterior pueden calcularse, a su vez,
a partir de características internas del sistema. Una vez resuelta la inte-

rrogación, se introducen los necesarios circuitos de feed-back para que
esto suceda. Los circuitos de realimentación pueden a su vez parametri-
zarse, definiendo así nuevas variables exógenas «de orden superior».
5) Iteración. Este proceso de refinamiento prosigue hasta que o no
es práctico seguir añadiendo complicaciones; o la complicación del mo-
delo es excesiva; o la introducción de nuevos circuitos de realimenta-
ción no enriquece el comportamiento del modelo de forma apreciable;
o, finalmente, el modelo escapa a la capacidad de interpretación del
analista.
4. Ejemplos
Veamos ahora algunos ejemplos que ponen de manifiesto las carac-

terísticas anteriores. Uno de los auxiliares más útiles para facilitar la
construcción de modelos de Dinámica de Sistemas es el formato gráfi-
co asociado al paquete de programas «I-think». Es fácil de comprender
y muy claro, por lo que lo usaremos para describir las abstracciones de
la Dinámica de Sistemas, antes de proceder a trasladarlas a PSPS.
Algunos tipos básicos de crecimiento de una población
Comenzaremos nuestra galería de ejemplos, presentando dos mode-

los básicos de crecimiento de una población aislada, que tiene capaci-
dad propia de reproducción. Los dos modelos corresponden respectiva-
mente a los casos de una población reproduciéndose sin limitaciones, y
una población reproduciéndose en un entorno limitado.
Ejemplo 1: Población sin limitaciones de entorno
En este modelo, y para fijar ideas, pensemos en una población de

seres con reproducción asexuada, evolucionando en ausencia de depre-
dadores. Llamémosles «amellenas». Al no haber limitaciones de recur-
sos, suponemos que pueden encontrar fácilmente toda la comida que
necesiten. Los conceptos básicos que intervienen en modelado de la
evolución del sistema son: la población de amellenas, los nacimientos o
apariciones de nuevos individuos a partir de los existentes, y la muerte
de individuos, que con ello se eliminan de la población. Es fácil recono-
cer en el primer concepto un nivel, un stock o depósito de individuos.
Un test sencillo para distinguir flujos de niveles es pensar qué su-

cedería si el sistema se parara. Aquellas cosas que permanecen cuando
el sistema se para son los niveles. Las que desaparecen son los flujos.
Tracemos un diagrama causal para ilustrar el tipo de análisis premo-
delado 7. La figura 1 muestra tal diagrama.
Figura 1
Diagrama causal
+ +
Población de
Nacimientos Muertes
amellenas
+ -
Los signos en las flechas indican el tipo de relación, + para una re-
lación positiva, y - para el caso contrario. Incidentalmente, puede verse
en la figura un ciclo completo de arcos cuyas flechas todas tiene el sig-
no +. Esto señala la presencia de un ciclo de refuerzo, o de feedback po-
sitivo, que anuncia la posibilidad de un incremento ilimitado de la po-
blación.
La hipótesis típica en el crecimiento sin limitaciones es suponer que
la velocidad de los nacimientos (en individuos/unidad de tiempo) es
proporcional al tamaño de la población. Nos adherimos, y suponemos
que todo individuo tiene, en cada momento, una cierta probabilidad de
dar origen a un nuevo ser por lo que si la población está compuesta de
X individuos, el total de nacimientos tiene la forma λX, para una cons-
tante λ que llamaremos tasa de nacimiento 8. Supondremos que la muer-
7. A pesar de las recomendaciones de Forrester y sus colegas, uno de los autores

(siempre el mismo) sostiene (¡aquí también!) que lo mejor es ponerse directamente a
modelar, ya que el aprendizaje sobre el sistema se desarrolla mucho mejor a medida que
uno comprueba los comportamientos del sistema. También opina que el diagrama cau-
sal es una herramienta de comunicación, para usar en clase o compartir pensamientos
con otros. Finalmente, cuando se lía irremisiblemente, cosa que sucede con cierta fre-
cuencia, el mismo autor confiesa que «no le queda más remedio que dibujar el diagra-
ma causal». Claro que el mismo autor dice que «la única forma de entender de verdad
lo que sucede en un modelo complejo es escribir las ecuaciones diferenciales y hacer las
matemáticas».
8. Esta hipótesis es la hipótesis malthusiana clásica, que lleva a crecimientos de
tipo exponencial.
te se produce con la misma lógica, por lo que la velocidad total de desa-

parición de individuos es µX, siendo µ la tasa de muerte. Estas dos hi-
pótesis, de apariencia inocente, tienen implicaciones importantes, en las
que no vamos a entrar aquí. Basta decir que implican que la muerte no
se puede deber a un proceso de envejecimiento, una situación parecida
a lo que ocurría con la distribución exponencial en capítulos anteriores.
El lector probablemente se ha encontrado antes con estas ecuacio-
nes clásicas. De hecho fueron formuladas como ecuaciones diferencia-
les mucho antes de que Forrester creara su metodología. Desde Vito
Volterra 9 han sido corrientes en cualquier obra sobre teoría de poblacio-
nes. Pero también debe notar cuidadosamente que las hemos elegido
porque se adaptan perfectamente a la filosofía de la Dinámica de Siste-
mas.
Figura 2
Un modelo simple de Dinámica de Sistemas
Población
Nacimientos Muertes
Tasa de muerte
Tasa de nacimiento
El diagrama del modelo, en la figura 2, tiene un único nivel (represen-

tado por el rectángulo): el número de individuos de la población existen-
tes en cada instante de tiempo. Esta población aumenta por los nacimien-
tos y disminuye por las muertes. Los flujos de nacimientos fluyen desde
la nube de la izquierda, y por la flecha de doble raya, hacia el nivel Pobla-
ción. Lo mismo sucede para las muertes, pero ahora desde el nivel hacia
la nube de la derecha (¡el exterior!). Los flujos están controlados por vál-
vulas accionadas por señales. La posición de la válvula de la izquierda
9. Vito VOLTERRA, Essays sur la lutte pour la Vie. Hay traducción española e in-
glesa en Dover.
viene dada por la variable auxiliar Nacimientos, y la de la derecha por la

variable auxiliar Muertes. Todas las variables auxiliares se representan
por círculos. Los arcos (flechas) indican que la variable origen del arco
interviene en el cálculo de la variable destino de aquél.
En nuestro modelo el valor del nivel se convierte en una señal, que
se convierte en la variable auxiliar Nacimientos por combinación con el
valor de otra variable auxiliar Tasa de Nacimiento, esta última determi-
nada exógenamente (no hay arcos que entren en ella). En concreto: Na-
cimientos = Población * Tasa Nacimiento. El sistema representa, en
forma gráfica, la ecuación diferencial:
d
––– Población = (Tasa Nacimiento – Tasa de Muerte) * Población
dt
o en una notación más próxima a la notación inicial, y más matemática,

dx
–––– = (λ – µ) X
dt
La Dinámica de Sistemas procede ahora a calcular con este modelo.
Para que el modelo pueda calcularse, se deben dar valores iniciales a la
población y a las variables exógenas, los parámetros Tasa Nacimiento y
Tasa de Muerte. El cuadro siguiente muestra un programa PSPS para
modelar esta población.
Cuadro 1
Modelo «Población sin limitaciones de entorno»
Variables
población;
TasaNacimiento;
TasaMuerte;
Nacimientos;
Muertes;
Macros
TasaNeta: function()
begin
Nacimientos = TasaNacimiento*Poblacion,
Muertes = TasaMuerte*Poblacion,
return Nacimientos - Muertes
end;
PoblacionIlimitada: function()
begin
población = TasaNeta*dt + población,
FDrawXY(1,1,cl,Poblacion),
return False
end;
Data
Vars TasaNacimiento = 1/10;
Vars TasaMuerte = 5/100;
Vars población = 100;
TIME 50;
System
GENERATE 0,1;
INTEGRATE PoblacionIlimitada;
Terminate 0;
endsystem;
La estructura de programa que adoptaremos en este capítulo se

basa en la utilización de dos tipos de funciones. Por un lado una fun-
ción, en este caso PoblacionIlimitada, se usará en un bloque INTEGRA-
TE para la integración de las ecuaciones de los niveles, usando siempre
el método de Euler. Esta función llamará a otras funciones, que deben
suministrarle los datos necesarios para que pueda operar. En nuestro
caso llama a TasaNeta. Todas las variables no auxiliares serán variables
globales, declaradas en la sección Variables.
El resultado de la integración, el análisis del modelo, se puede obte-

ner de muchas formas, pero en la mayoría de los casos la gráfica es la
más interesante. Por ejemplo, para nuestro caso, con población inicial =
100, y tasas de nacimiento y muerte iguales a 0,1 y 0,05 respectivamen-
te, la gráfica de la población es:
Figura 3
Gráfica de crecimiento de una población
Crecimiento ilimitado
1400
1200
1000
800
600
400
200
0
0 5 10 15 20 25 30 35 40 45 50
Tiempo
mostrando el esperado crecimiento exponencial. El lector puede entre-

tenerse haciendo experimentos con los valores de los parámetros, para
descubrir patrones de comportamiento interesantes. Comprobará, si no
lo ha descubierto ya, que hay tres casos posibles. Cualquier valor de los
parámetros tal que tasa nacimiento > tasa de muerte, tiene el mismo
comportamiento cualitativo: explosión más o menos retardada de la po-
blación. Por el contrario si tasa nacimiento < tasa de muerte la pobla-
ción desparece. Finalmente cuando tasa nacimiento = tasa de muerte la

población permanece constante e igual a su valor inicial. La existencia
de estas regiones puede verificarse fácilmente por un pequeño análisis
matemático (ver el cuadro adjunto).
Cuadro 2
Análisis matemático
En primer lugar podemos determinar los puntos singulares de la

ecuación diferencial. Los puntos singulares son aquellos puntos a los
que se dirigen algunas de las trayectorias del sistema, es decir, aunque
el sistema empiece desde puntos diferentes, poblaciones diferentes,
eventualmente llega a alguno de ellos. Cuando el tiempo tiende a infini-
to, el sistema puede quedar atrapado en uno de estos puntos. Para hallar
los puntos singulares se analizan las situaciones en las que la ecuación
diferencial presenta velocidad nula, es decir, para las que el segundo
miembro se anula. En este caso los puntos son:
0 = (λ – µ) X
Según los valores de los parámetros hay dos posibilidades:

1) λ = µ. Todos los puntos iniciales son estados singulares. En este
caso, parta de donde parta, el sistema se mantiene en ese estado.
2) λ ≠ µ. X= 0 es el único punto singular. Si el sistema llega a X=0
queda atrapado en este estado. Quedar atrapado ahí implica la desapari-
ción de la población.
Ahora la teoría realiza el cálculo de las «cuencas de atracción» de
cada punto singular. Cuando λ > µ ninguna trayectoria desde un punto
inicial distinto de 0 lleva a X=0. Si λ < µ todas las trayectorias llevan a
X=0. Este punto se convierte en un atractor, «atrae» a todas las trayec-
torias.
Un análisis más minucioso de la situación nos llevaría demasiado
lejos, ya que cuando una trayectoria no es atraída hacia un atractor la
casuística de posibilidades es elevada, y especialmente en sistemas no
lineales, el comportamiento es muy complicado. Puede haber compor-
tamientos explosivos, oscilantes o con características más o menos di-
vertidas. Este campo, que siempre fue considerado el dominio de los pa-
tólogos, profesionales interesados en enfermedades de los sistemas de
ecuaciones diferenciales, es hoy un campo de gran actividad 10. En cual-
quier caso, un sencillo análisis de los ceros del segundo miembro a ve-
ces revela mucho más que varias horas de simulación en ordenador. La
ventaja(?!) de la simulación es poner al alcance del analista poco ducho
en álgebra (o perezoso) el análisis directo de las ecuaciones. Y para ser
justos, a menudo el análisis preciso es demasiado complicado para ser
viable. Y como en la simulación quien piensa es el ordenador...
10. Las catástrofes..., el caos... ¿le suena al lector?
Como puede verse, el comportamiento cualitativo del sistema es el

mismo para una amplia gama de posibilidades. Si sólo estamos intere-
sados en saber cuánto puede sobrevivir la población, no necesitamos el
valor preciso de las tasas, sólo el conocimiento de su relación. Por su-
puesto, si nos interesa el tiempo hasta la desaparición, entonces sí se re-
quieren valores precisos de los parámetros. Pero, a menudo, para prede-
cir el comportamiento cualitativo del sistema no hacen falta los valores
numéricos precisos, basta con una aproximación a los mismos.
Ejemplo 2: Población con limitaciones de crecimiento.

Proceso de infección
El caso más sencillo es este tipo, el de una población de amellenas

viviendo en una caja de Petri 11, alimentándose del apetitoso «agar-
agar». Para poder reproducirse, una amellena requiere encontrar un es-
pacio vacío en su hábitat y ocuparlo. El modelo es parecido al del caso
anterior, pero ahora la tasa de nacimiento ya no es constante, sino que
puede considerarse proporcional al espacio libre, espacio sin ocupar y
disponible para la reproducción. En nuestro caso, y de acuerdo con la
segunda regla de conveniencia, vamos a medir el espacio sin ocupar en
amellenas. En cada instante el espacio vacío es igual al número adicio-
nal de amellenas que aún pueden ponerse en la caja de Petri. Si el nú-
mero máximo de amellenas que pueden habitar una caja es máximo re-
curso, entonces el diagrama del sistema es el siguiente:
Figura 4
Representación I-think de las ecuaciones del crecimiento logístico
Población
Nacimientos Muertes
Máximo recurso Tasa de muerte

Tasa de nacimiento
11. Una caja de Petri es una especie de hotel para amellenas...
correspondiendo al sistema de ecuaciones diferenciales:
d
–––– Población = Tasa Nacimiento * Población * (Máximo Recurso – Población)
dt – Tasa Muerte * Población
Para el valor tasa nacimiento = 0,005, la evolución de la población,

partiendo de un estado inicial con población igual a 1, se muestra en la
figura adjunta. Esta forma de crecimiento se conoce en la literatura
como crecimiento logístico, y a la función de la figura se la conoce como
«curva logística». En su forma general, la curva logística tiene una ex-
presión analítica compacta y bien conocida.
Figura 5
Curva logística
Recursos finitos
40
35
30
25
20
15
10
5
0
0 5 10 15 20 25 30 35 40 45 50
Tiempo
El cuadro que aparece a continuación muestra el modelo PSPS uti-

lizado. Sólo damos las secciones Variables y Macros, porque el resto es
idéntico al del caso anterior.
Cuadro 3
Modelo «Población con limitaciones de crecimiento»
Variables
población;
TasaNacimiento;
TasaMuerte;
Nacimientos;
Muertes;
MaximoRecurso;
Macros
begin
Nacimientos = TasaNacimiento*Poblacion*(MaximoRecurso-población),
Muertes = TasaMuerte*Poblacion,
return Nacimientos - Muertes
end;
begin
población = TasaNeta*dt + población,
FDrawXY(1,1,cl,Poblacion),
return False
end;
Este modelo puede plantearse también cambiando los papeles del in-
put y del output. En este caso se trataría de un sistema con decrecimien-
to logístico. El comportamiento es parecido y el lector puede encontrar
ilustrativa su formulación y análisis. Nosotros no distinguiremos entre
ambas variedades y nos referiremos a las dos como al «modelo de creci-

miento logístico».
Una disgresión sobre comportamientos oscilatorios
Una de las mayores diversiones de los expertos en Dinámica de Sis-

temas es encontrar e interpretar comportamientos oscilatorios. Nuestros
ejemplos tienen normalmente comportamientos asintóticos estables,
pero dentro de la parafernalia de singularidades de los sistemas de ecua-
ciones diferenciales ocupan un lugar importante los fenómenos oscila-
torios. En un fenómeno oscilatorio, el sistema no tiende hacia unos va-
lores asintóticos, sino que se queda oscilando, como un péndulo, por en-
tre una serie de estados, que reaparecen recurrentemente.
En los modelos de Dinámica de Sistemas, el comportamiento osci-
latorio aparece típicamente cuando hay retrasos en la aplicación de me-
canismos correctores. Por ejemplo, cuando el sistema evoluciona bajo
un conjunto de fuerzas impulsoras, y las fuerzas correctoras que deben
estabilizarlo tienen un retraso con respecto a las primeras, puede espe-
rarse inmediatamente un comportamiento oscilante. La palabra clave
aquí es retraso. Si no existieran retrasos, desfases entre los mecanismos
correctores y los mecanismos impulsores del sistema, sería más difícil
la presencia de comportamientos oscilatorios. Por supuesto estas razo-
nes son de tipo intuitivo, fruto de la experiencia en el desarrollo de mo-
delos y no corresponden a un análisis matemático exacto. Pero en un
porcentaje elevado de casos el lector puede identificar la causa de com-
portamientos oscilantes buscando los retrasos que se producen en el sis-
tema.
Un retraso, por supuesto, se puede presentar de forma explícita. Los
retrasos explícitos son reales como la vida misma. Siempre hay retrasos
en la propagación de señales. Pero la introducción de retrasos en un mo-
delo a menudo enmascara las propiedades dinámicas del sistema al su-
perponerle, en formas complicadas, efectos oscilatorios. Por esto el
constructor de modelos debe evitar la incorporación de retrasos en las
primeras etapas de modelado. Sólo tras haber entendido el comporta-
miento del sistema sin los retrasos, puede introducirlos con cierta con-
fianza de que el sistema «no se le desmadrará».
Pero no debe olvidarse que todo proceso de acumulación, de inte-
gración, tiene implícitos retrasos en la respuesta. En efecto, cualquier
proceso de suavizado, que calcula un estado en función de un input y
del estado anterior del sistema, supone la existencia de algún tipo de re-
traso.
Vamos a ilustrar las consideraciones anteriores en un ejemplo sen-
cillo, que debe alertar al lector de lo resbaladizo del terreno que se pisa
cuando se usan alegremente retrasos en las propagaciones de señal. Vea-
mos el caso sencillo, del «regulador proporcional».
Ejemplo 3: Ajuste de precios
Supongamos que un campesino chino lleva a la ciudad cada maña-

na las verduras que el día anterior ha recogido de su huerto. Su produc-
ción diaria es constante e igual a 20 Kg. de verduras. El campesino se
instala en la calle, frente a un mercado y vende las verduras a un pre-

cio que fija a su arbitrio. Por supuesto, si el precio es demasiado alto
no vende mucho, y si es pequeño le quitan las lechugas de las manos.
Para simplificar supongamos que el número de compradores potencia-
les del día es de la forma K/precio, con K un valor determinado que,
para fijar ideas, tomaremos igual a 20. K se mantiene estable en el
tiempo, ya que el barrio en el que vende es siempre el mismo y los gus-
tos de sus moradores cambian muy lentamente. El mecanismo de co-
rrección de precios que utiliza nuestro hombre es el siguiente. Cada día
observa si le han faltado o sobrado verduras. Si le han sobrado baja el
precio ligeramente. Recíprocamente si le han faltado sube el precio li-
geramente. Digamos que el cambio de precio es de la forma:
alfa *(Verduras Demandadas – Verduras suministradas),
con alfa un coeficiente, que por el momento fijamos en 0,1.
En estas condiciones el modelo es:
Figura 6
Diagrama del modelo
Alfa
Precio
Cambio
Verduras suministradas Verduras demandadas
Retraso
La implantación de este modelo utiliza una fracción de la diferencia

entre el valor de referencia y la demanda para manejar un nivel. Nótese
que hay sólo una corriente que llega al nivel (hay una sola nube), pero
que en la raya doble hay dos flechas. Esto indica que se trata de una vía
de doble sentido. En términos técnicos, el flujo tiene signo. Es también
interesante observar que el suavizado de una cierta cantidad requiere un
nivel. Al usar el «valor anterior» para añadirle algo, estamos suponiendo
la disponibilidad de este valor anterior en el momento del cálculo. Si el
sistema se parara, siempre nos quedaría el valor anterior. Por tanto, debe
haber un nivel, puesto que los flujos desaparecen al parar el sistema.
El cuadro muestra el fragmento de programa relevante.
Cuadro 4
Modelo «Ajuste de precios»
Variables
Precio;
HortalizasDemandadas;
HortalizasSuministradas;
Alfa;
Cambio;
Macros
begin
HortalizasDemandadas = 20/precio,
HortalizasSuministradas = 20,
cambio = alfa*(HortalizasDemandadas-HortalizasSuministradas),
return cambio
end;
begin
Precio = TasaNeta*dt + Precio,
FDrawXY(1,1,cl,Precio),
return False
end;
Data
Vars precio = 3;
Vars alfa = 1/10;
TIME 10;
He aquí una simulación (con Retraso = 0)
Figura 7
Ajuste de precio con retraso = 0
Ajuste
3,0
2,5
2,0
1,5
1,0
0,5
0,0
0 2 4 6 8 10
Tiempo
¡Todo va bien! Se observa una bonita trayectoria en la que el cam-

pesino ajusta su precio para que la oferta y la demanda sean iguales.
Nuestro texto de economía elemental así nos lo había advertido y tene-
mos el placer de observarlo.
Pero ahora supongamos que hay un retraso en la reacción del publi-
co a los precios de nuestro hombre. En primer lugar supongamos que

son los precios de ayer los que influyen en el número de personas que
van a comprar hoy. Esta hipótesis es más razonable que la de reacción
instantánea. Supongamos que el retraso 12 es de 0,5. ¿Puede el lector
adelantar qué sucederá con el precio? Veámoslo.
12. No damos la implantación de este modelo con retrasos, pero el lector puede
reconstruirlo fácilmente, usando la técnica del Farray presentada en el capítulo prece-
dente.
Figura 8
Ajuste de precio con retraso = 0,5
Precios retrasados
2,0
1,8
1,6
1,4
1,2
1,0
0,8
0,6
0,4
0,2
0,0
0 2 4 6 8 10
Tiempo
¡Sí señor! Estamos en presencia de un comportamiento oscilante,

aunque se amortigua hasta convertirse en asintótico. Como en el caso
anterior, el precio se estabiliza pero ahora toma más tiempo y el campe-
sino se puede ganar una fama, merecida, de frívolo. Mucho más diver-
tido es lo que sucede con valores crecientes del retraso. ¡¡Para un retra-
so de 0,84 el sistema oscila perpetuamente sin tender nunca al precio
adecuado!! La frivolidad del campesino ahora es eterna. Por supuesto
para valores superiores a 0,85 el sistema explota de forma oscilante, no
sólo oscila sino que cada vez lo hace a una mayor amplitud, entra en re-
sonancia y se destruye a sí mismo. Todo por efecto de un pequeño retra-
so que hace que la acción correctiva se aplique a destiempo, justo cuan-
do su efecto es más nocivo.
Figura 9
Ajuste de precio con retraso = 0,84
Graph Number1
2,6
2,4
2,2
2,0
1,8
1,6
1,4
1,2
1,0
0,8
0,6
0,4
0,2
0,0
-2 0 2 4 6 8 10 12 14 16 18 20 22 24 26 28 30 32 34 36 38 40 42
X axis
El lector puede divertirse planteando el mismo ejemplo, pero te-

niendo en cuenta la reputación del campesino. Cuesta tiempo ganarse
fama de «barato» o «caro», pero una vez ganada cuesta tiempo desha-
cerse de ella. Este es otro tipo de retraso. Se produce debido a la histé-
resis en la reputación del campesino. Su modelado requiere introducir
otro nivel, la reputación de nuestro hombre, que se altera con sus accio-
nes cotidianas. Esta alteración es un suavizado, y por tanto engendra un
retraso que llevará eventualmente a comportamientos oscilatorios.

No queremos insistir más en este tipo de comportamientos, porque,
como hemos dicho, en nuestro enfoque éste es un efecto residual, que
enmascara la verdadera naturaleza dinámica de la situación. Siempre se
pueden provocar oscilaciones (en cualquier modelo) introduciendo re-
trasos en la forma adecuada.
Ejemplo 4: Turismo rural
Vamos a construir ahora un modelo sencillo del uso de un recurso

regenerable. Supondremos, para fijar ideas, que se trata de un parque
natural que se abre al turismo rural. Suponemos, por el momento, que la

demanda potencial de turismo en el parque viene dada de forma exóge-
na. Es decir, existe una función que nos permite deducir el número de
personas que estarían dispuestas a acudir al parque en su estado actual.
Pero la aparición de visitantes ejercerá impacto sobre el medio, produ-
ciendo una cierta degeneración del mismo. De las muchas posibilida-
des, elegimos suponer que la degradación del medio será función del
número de visitantes en el parque. Es decir, si en un día hay 100 perso-
nas en el parque, la degradación diaria (la velocidad de degradación) es
función de este valor. Para medir el estado de conservación del parque
elegimos un índice de atractividad que varía entre 0 y 1. El estado ini-
cial del parque tiene Atractividad = 1, y la presión de los visitantes
degrada esta atractividad. Pero al mismo tiempo, el medio se regenera
espontáneamente con una tasa dada. Supondremos pues que la atracti-
vidad del parque evoluciona como un sistema de crecimiento logístico,
con la salvedad de que la tasa de muerte es función del número de visi-
tantes en el parque.
Figura 10
Diagrama modelo del parque
Atractividad
Deterioro Regeneración
Visitantes
CoefRegeneración
Capacidad
CoefDeterioro
Visitantes
Demanda real Salidas
Atractividad Estancia
Demanda
potencial
ExpCongestión
El número de visitantes en el parque se obtiene de las llegadas al

mismo, la remanda real y del tiempo de estancia (que suponemos cons-
tante) en el recinto. Las salidas de visitantes son simplemente las entra-
das decaladas en el tiempo, por un retraso igual al tiempo de estancia.
La figura 10 muestra el esquema completo del modelo. Nótese la pre-
sencia de elementos punteados con los mismos nombres que otros ele-
mentos normales del diagrama. Se trata de elementos «fantasma» que
son alias de elementos reales (o normales) y que se utilizan para evitar
llenar la gráfica de flechas. De esta forma el nodo demanda real, en el
segundo nivel, se alimenta desde una copia de atractividad, y no hace
falta dibujar una flecha cruzando la figura desde el elemento atractivi-
dad hasta el nodo en cuestión.
El cuadro siguiente muestra un modelo para la situación descrita. El
lector debe observar que la lógica inherente es muy simple. Excesivamen-
te simple, ya que no explicará la variedad de fenómenos que se observan
en la realidad. Complicaremos el modelo para incorporar estos aspectos,
pero en un proceso de búsqueda de un conjunto «mínimo» de variables
explicativas, se debe empezar siempre por los casos más sencillos.
Cuadro 5
Modelo «Turismo rural»
Variables
Atractividad;
Regeneracion;
CoefRegeneracion;
Deterioro;
CoefDeterioro;
Visitantes;
Capacidad;
DemandaPotencial;
ExpCongestion;
Salidas;
Estancia;
DemandaReal farray;
Macros
begin
DemandaPotencial = 60 *(1-exp(-cl)),
DemandaReal[cl] = DemandaPotencial*power(Atractividad, expCongestion),

Salidas = DemandaReal[cl-Estancia],
Regeneracion = CoefRegeneracion*(1-Atractividad)*Atractividad,
Deterioro = Visitantes/Capacidad*CoefDeterioro*Atractividad,
return True
end;
Turismo: function()
Begin
TasaNeta,
Visitantes = visitantes + (DemandaReal[cl]-Salidas) * dt,
Atractividad = Atractividad + (Regeneracion-Deterioro)*dt,
FDRawXY(1,2,cl,Atractividad),
FDrawXY(1,1,cl,visitantes),
return False
end;
Data
Vars capacidad = 5;
Vars coefDeterioro = 1;
Vars coefRegeneracion = 1/2;
Vars Estancia = 1/10;
Vars ExpCongestion = 1;
Vars Atractividad = 1;
TIME 10;
Initial FdrawCont(1,GSERNODOTS,1,2);
Initial FdrawCont(1,GSERSOLID,1,2);
System
GENERATE 0,1;
INTEGRATE Turismo;
Terminate 0;
endsystem;
La figura 11 muestra los visitantes (curva superior) y la atractividad

del parque (curva inferior) que se obtienen con los valores de la tabla.
Figura 11
Visitantes y Atractividad
Turismo rural
3,0
2,5
2,0
1,5
1,0
0,5
0,0
-0,5
0 2 4 6 8 10
Tiempo
La demanda potencial es un input externo, que se supone creciente

hasta alcanzar un valor asintótico. La expresión analítica de esta deman-
da potencial que usamos en el modelo es 60 (1 - exp(-t)). Pero la de-
manda real se obtiene modulando la demanda potencial por la atractivi-
dad. Cuando la atractividad decrece, un menor número de ciudadanos
del mercado potencial se sienten interesados en acceder al parque. En
ausencia de otras acciones, y con el sistema regenerándose de forma es-
pontánea, la atractividad siempre decrece desde 1, el valor inicial, ten-
diendo a un valor tanto más elevado cuanto más elevada sea la capaci-
dad de regeneración. Por supuesto si se limita la demanda potencial, por

ejemplo si se establecen limitaciones para que el valor asintótico de ésta
sea 30 en vez de 60, el decrecimiento es menor, la atractividad del par-
que se estabiliza en 0,45 en vez de en 0,29.
En este caso se pueden calcular los atractores por una formula sen-
cilla. Por medio de un análisis asintótico, esta vez algo más dificultoso,
se puede probar que hay dos puntos singulares. Uno de ellos es la extin-
ción del sistema, atractividad = 0. Para escribir el segundo, definamos
el parámetro ρ como:
DemandaPotencial * Estancia Coef.Deterioro
ρ = –––––––––––––––––––––––––– * ––––––––––––––––––
Capacidad Coef.Regeneración
Entonces el segundo punto singular viene dado por la expresión:

1
Atractividad = –––––––
1+ρ
La variable ρ adquiere una interpretación sencilla cuando observa-
mos que la primera fracción en la definición anterior es simplemente el
valor de la ocupación de capacidad, y la segunda es el inverso de la rela-
ción entre el coeficiente de regeneración y el coeficiente de deterioro, o
tanto por uno del deterioro que se regenera espontáneamente. Por tanto:
% Ocupación
ρ = ––––––––––––––––––
% Regeneración
Con nuestros valores iniciales ρ = 2,4, y por tanto el valor asintóti-
co es atractividad = 0,29. Si dejamos esta expresión en función del va-
lor de la demanda potencial asintótica, digamos D, la atractividad viene
dada por:
1
Atractividad = ––––––––––––
1 + 0,04 D
Vemos por tanto, que a mayor demanda asintótica menor nivel de
atractividad, y mayor nivel de degradación se obtendrá en el parque. No
hacía falta tanto modelo para llegar a esta conclusión. La intuición la
preveía. Por tanto, basándonos en la intuición, probablemente nuestra
tentación inmediata sería controlar la atractividad, estableciendo cotas
al número de visitantes.
El modelo ayuda a entender mejor la situación, lo que sucede. La
expresión asintótica para la atractividad ρ pone al mismo nivel los cin-
co parámetros del sistema. Se puede mantener ρ constante sin limitar
la demanda, actuando sobre los cuatro coeficientes restantes. ¡El pará-
metro básico del parque es ρ! El planificador puede actuar esencial-
mente sobre la ocupación o sobre la capacidad de regeneración. Para lo

primero, puede limitar las estancias, aumentar la capacidad o reducir la
demanda potencial. Para lo segundo puede aumentar el coeficiente de
regeneración o disminuir el de deterioro. Todos los aumentos se pue-
den compensar por cambios proporcionales en otra variable, sin alterar
la atractividad. Basta monitorear el valor de ρ para tener una prognosis
razonable de lo que puede suceder en el parque a largo plazo.
Ejemplo 4: Segundo modelo

El modelo anterior es muy esquemático. Ilustrativo, pero aún dema-
siado elemental. Hemos podido hacer un análisis asintótico preciso, y
por tanto nuestra amiga, la Dinámica de Sistemas aún no está jugando

un papel esencial. Sigamos adelante. El proceso de refinamiento típico
de un modelo de Dinámica de Sistemas consiste en sustituir parámetros
exógenos por ciclos de feed-back que los calculan en función de carac-
terísticas del sistema.
Figura 12
Diagrama inicial del parque
Atractividad
Deterioro Regeneración
Visitantes
CoefRegeneración
Capacidad media
CoefDeterioro
Visitantes
Demanda real Salidas
Atractividad Estancia
Demanda
potencial
ExpCongestión
En nuestro caso, tenemos como parámetros exógenos los cinco pa-

rámetros que intervienen en el cálculo de ρ. Para determinar cómo ex-
pandir el modelo inicial, es conveniente considerar los agentes de la si-
tuación y su control sobre la misma. Hay que introducir la actividad

económica en el modelo, y considerar la forma en que las decisiones de
los agentes implicados alteran el equilibrio del sistema. En esta segun-
da aproximación, vamos a suponer que los agentes operadores de los
servicios del parque tienen control sobre dos variables básicas: la capa-
cidad de los servicios que ofrecen y el precio que cobran por ellos.
El nuevo modelo que se presenta en la figura 12, es casi idéntico al
modelo anterior. Pero el lector se dará cuenta de que hay un sutil, y real-
mente astuto, cambio. Unos de los nodos que alimentan las entradas de
visitantes está ahora punteado, ¡es un fantasma! Efectivamente esto se
debe a que en otra parte del diagrama este nodo es el resultado de un
cálculo. Para no esconder nuestras cartas he aquí el esquema completo
de las modificaciones que hay que añadir al diagrama anterior.
Figura 13
Modificaciones al diagrama inicial del parque
Demanda potencial
Coste
Precio Elasticidad
Precio
Demanda
Ingresos
CoefAjuste Ajuste
Precios
Visitantes
Precio
Capacidad Visitantes
operadores
En la figura hay tres piezas de diferente naturaleza. La de la parte

superior derecha es la reacción del mercado al precio que determina la
demanda potencial, un elemento exógeno en el caso anterior. La de la
izquierda, centrada alrededor del nivel Precio, representa el mecanismo
de fijación de precios que predicamos de los agentes operadores del
parque. El lector reconocerá en él la estructura básica del ejemplo del
campesino chino. Finalmente, el pequeño diagrama de la parte inferior
derecha es un inocente cálculo contable, para obtener el ingreso por uni-
dad de tiempo, a partir de los visitantes y de los precios. Describiremos

ahora uno por uno los cambios introducidos.
1) Demanda potencial. Como la demanda potencial es ahora fun-
ción de las decisiones de precios de los agentes, se hace necesario intro-
ducir una función de demanda. La estimación de una función de deman-
da es un tema tratado hasta la saciedad en la literatura económica, pero
muy lejos de tener una solución satisfactoria. El lector puede hacer la
hipótesis que prefiera. Pero en ausencia de una mejor posibilidad, he-
mos elegido un método sencillo basado en curvas de demanda de elas-
ticidad constante.
El lector recordará que la elasticidad de la demanda es el porcentaje
de cambio en la demanda dividido por el porcentaje de cambio en el
precio que lo produce. Una curva de demanda tiene elasticidad 1 en un
punto, cuando se genera un cambio en la demanda de 1 punto porcen-
tual, por cada punto porcentual de cambio del precio. Por supuesto para
ser precisa esta noción requiere de cierto aparato (¿aparatito?) matemá-
tico. Remitiendo al lector a los tratados de economía elemental [Sa-
muelson], puede comprobar que una curva de demanda de elasticidad
constante a, viene dada por la expresión Demanda = K/Precioα con K
un valor α fijar en cada caso. Esta es la expresión que se usa para las
curvas de demanda, en la parte superior derecha de la figura. En las for-
mulas a se llama elasticidad y K se llama demanda 13.
2) Ajuste de precios. Necesitamos ahora un mecanismo que expli-
que de forma dinámica cómo los agentes operadores ajustan el precio a
condiciones cambiantes del sistema. De nuevo aquí podemos sacar a
colación todos los libros de economía de la biblioteca. Pero ninguno de
ellos nos dará la solución. Los mecanismos de ajuste de precios son aún
más ignotos que los de formación de demanda, si cabe. Otra vez, en au-
sencia de la forma verdadera, utilizamos una forma sencilla, y consagra-
da en los tratados de economía, que ya se expuso al tratar de nuestro

campesino chino. Los economistas grandilocuentes la llaman «tatone-
ment» 14. Esencialmente consiste en suponer que el agente es algo mio-
pe y ajusta el precio por movimientos locales. En concreto, el agente
observa la ocupación de su capacidad, y si está subocupado baja ligera-
mente el precio para tratar de captar más clientes. Si está a plena capa-
cidad, sube ligeramente el precio. Aquí «ligeramente» significa que se
aplica un suavizado, moviendo el precio una fracción del incremento
adecuado para llevar el sistema a plena capacidad.
13. Para que todo el mundo lo recuerde, incluyendo los autores...

14. En francés viste más.
3) Cálculo de los ingresos totales. Queda como ejercicio para el lector 15.
Resultados para este caso se dan en las dos gráficas de la figura 14.
Figura 14 a
Turismo rural 2
3,5
3,0
2,5
2,0
1,5
1,0
0,5
0,0
-0,5
0 2 4 6 8 10 12 14 16 18 20
Tiempo
Figura 14 b
Precio y margen
Turismo rural 2
2,5
2,0
1,5
1,0
0,5
0,0
0 2 4 6 8 10 12 14 16 18 20
Tiempo
15. Desafiamos al lector a que intente realizar este complicadísimo ejercicio. Si no

lo logra recibiremos gustosos sus quejas, siempre que se identifique oportunamente.
En la primera mostramos la atractividad y el número de visitantes.

En la segunda el precio y el margen por unidad de tiempo. Como puede
verse, en condiciones idénticas a las de las simulaciones anteriores, la
miopía de los agentes les hace disminuir el precio para aumentar la ocu-
pación. Por tanto el número de visitantes aumenta y la degradación del
medio también. Esto redunda en un menor número de visitantes que
conduce a su vez a reducciones de precios, con lo que el sistema avan-
za inexorablemente hacia precios bajos, masificación y beneficio cero.
En estas circunstancias se consume el recurso natural por unos agentes
que, usando la terminología anglosajona, son «free-riders», agentes que
consumen el patrimonio y se alejan.
Una posible salida de esta situación es reducir la capacidad de ser-
vicio. Esta medida conducirá a la creación de una zona de élite, un cen-
tro de servicios caros sólo al alcance de unos pocos. En esta situación,
por ejemplo con capacidad de servicio 1, el sistema cambia radicalmen-
te de comportamiento como puede verse en la figura 15, en la que apa-
recen las mismas variables que anteriormente. Los precios suben hasta
que la demanda se iguala con la oferta. El sistema se regenera y alcan-
za un nivel de calidad razonable. La evolución no es muy rápida, ya que
el nivel de calidad se degrada inicialmente como resultado de la inva-
sión de consumidores, que se produce al principio de la operación. El
proceso de ajuste de precios reacciona lentamente y, cuando lo hace,
hay que confiar en la velocidad de regeneración natural para restaurar el
medio. En estas circunstancias no se consigue ni crecimiento económi-
co ni preservación, sino tan solo enriquecimiento oportunista.
Figura 15 a
Turismo rural 2
3,0
2,5
2,0
1,5
1,0
0,5
0,0
0 2 4 6 8 10 12 14 16 18 20
Tiempo
Figura 15 b
Precio y margen
Turismo rural 2
3,0
2,5
2,0
1,5
1,0
0,5
0,0
0 2 4 6 8 10 12 14 16 18 20
Tiempo
Ejemplo 5: Un último modelo: inversión en regeneración
Por supuesto, el modelo anterior olvida algo muy importante. Espe-

cialmente en Europa, muchas zonas naturales sufren las consecuencias
de la interacción deliberada del hombre con la naturaleza. Una parte im-
portante de las rentas de explotación del parque se han invertido, en el
pasado, en la regeneración del mismo. Nuestro último modelo pretende
introducir la idea de inversión en regeneración. De nuevo el lector debe
observar la metodología: ¡sustituir un nudo exógeno por una relación
con las variables internas del modelo!
Para ello basta modificar ligeramente el modelo, en lo que hace re-
ferencia al coeficiente de regeneración. Una parte, alfa, de los ingresos

generados se desviará a la regeneración. La ecuación correspondiente
será:
CoefRegeneracion = Ingresos * Alfa
¡Esto es todo! La unidades encajan y los órdenes de magnitud tam-
bién. Con estas modificaciones, podemos de nuevo calcular el modelo
a partir de los datos iniciales. Suponemos Alfa = 0,5. El resto de datos
son los mismos del modelo anterior.
En el cuadro siguiente presentamos el modelo completo:
Cuadro 6
Modelo «Turismo rural con inversión en regeneración»
Variables
Atractividad; Regeneracion; CoefRegeneracion;
Deterioro; CoefDeterioro; Visitantes;
Capacidad; CapacidadOperadores; Demanda;
DemandaConst; DemandaPotencial; ExpCongestion;
Salidas; Estancia; Precio;
Elasticidad; Ingresos; Coste;
Ajuste; CoefAjustePrecios; Alfa;
DemandaReal farray;
Macros
Locals aux;
begin
CoefRegeneracion = alfa*Ingresos,
Demanda = DemandaConst*(1-exp(-cl)),
DemandaPotencial = Demanda/power(precio,elasticidad),
DemandaReal[cl]= DemandaPotencial*power(Atractividad, expCongestion),
Salidas = DemandaReal[cl-Estancia],
Regeneracion = CoefRegeneracion*(1-Atractividad)*Atractividad,
Deterioro = Visitantes/Capacidad*CoefDeterioro*Atractividad,
Ajuste = Cond(Precio > Coste,
CoefAjustePrecios*(Visitantes–CapacidadOperadores)*precio, 0),
Ingresos = Precio*Visitantes,
return True
end;
Turismo: function()
Begin
TasaNeta,
Visitantes = visitantes + (DemandaReal[cl]-Salidas) * dt,
Atractividad = Atractividad + (Regeneracion-Deterioro)*dt,
Precio = Precio + Ajuste*dt,
FDRawXY(1,2,cl,Atractividad),
FDrawXY(1,1,cl,visitantes),
FdrawXY(2,1,cl,precio),
FDRawXY(2,2,cl,(precio-coste)*visitantes),
return False
end;
Data
Vars capacidad = 5;
Vars coefDeterioro = 1;
Vars CoefAjustePrecios = 1/10;
Vars Estancia = 1/10;
Vars ExpCongestion = 1;
Vars Atractividad = 1;
Vars Elasticidad = 1;
Vars DemandaConst = 60;
Vars coste = 1/10;
Vars precio = 1;
Vars alfa = 1/2;
Vars CapacidadOperadores = 3;
TIME 20;
Initial FdrawCont(all,GSERNODOTS,1,2,3);
Initial FdrawCont(all,GSERSOLID,1,2,3);
Initial FDrawCont(all,GXTITLE,“Tiempo”);
Initial FDrawCont(all,GTITLE,“Turismo Rural 2”);
Initial FDrawCont(1,GYTITLE,“Visitantes,Atractividad”);
Initial FDrawCont(2,GYTITLE,“Precio,Margen”);
INITIAL Fdrawcont(all,GSIZE,0,0,20,5) ;
System
GENERATE 0,1;
INTEGRATE Turismo;
Terminate 0;
endsystem;
Ahora el comportamiento cualitativo es distinto al del modelo ante-

rior. Ahora 0 (o el precio de coste) no es el atractor dominante para el
precio, y por tanto los ingresos crecen con el número de visitantes. Y
cuantos más ingresos más cantidad dedicada a la conservación, lo que
produce un círculo virtuoso de mejora.
Figura 16 a
Turismo rural 2
5
0
0 2 4 6 8 10 12 14 16 18 20
Tiempo
Figura 16 b
Precio y margen
Turismo rural 2
5
3
0
0 2 4 6 8 10 12 14 16 18 20
Tiempo
5. A modo de conclusión
Esperamos que el lector haya podido constatar la capacidad de se-

ducción de nuestra tentadora amiga la Dinámica de Sistemas. A ella se
le aplican, incluso con mayor razón, los mismos caveats que hemos ido
exponiendo a lo largo del libro. No está de más resumirlos como adver-
tencia de los peligros que corren los adoradores de nuestra sirena:
1) En buena parte la visión global del sistema modelado se obtiene
por una cuidadosa combinación de razonamientos lógico-matemáticos
y un uso adecuado de la simulación. La simulación produce atisbos de
propiedades, pero su constatación requiere a menudo de argumentos
más delicados.
2) El sistema de modelado que hemos mostrado hace hincapié en el
comportamiento cualitativo. Hay un peligro serio de confundir el com-
portamiento cualitativo con el cuantitativo, y tomar al pie de la letra los
resultados numéricos del modelo. No es cierto que con un 50% de la
renta dedicada a regeneración se alcancen resultados satisfactorios. Sí
es cierto que hay un valor del porcentaje de renta dedicado a la regene-
ración, que invierte el comportamiento cualitativo del sistema.
3) Para usar la Dinámica de Sistemas para establecer planes cuan-
titativos, debería contrastarse cuidadosamente la validez empírica del
modelo. Para ello habría que validar todas las relaciones del mismo. Y
la mayoría de las veces esta es una tarea excesiva.
4) Hemos ilustrado el nivel de agregación al que trabaja la Diná-
mica de Sistemas. De hecho, no hemos considerado más que un solo
recurso. No hemos considerado nociones como la dispersión de carac-
terísticas en una población, ni fenómenos de envejecimiento, etc. Intro-
ducir varios recursos crea complicaciones notables. Desde el punto de
vista técnico, esto lleva el análisis al terreno de las ecuaciones en deri-
vadas parciales, y en este mundo quedan muy mermadas las posibilida-

des de la simulación, o de la exploración por medio de la fuerza bruta
de cálculo.
Bibliografía
KUIPERS, Benjamin, Qualitative Reasoning. Modeling and simulation

with incomplete knowledge, The MIT Press, 1994.
SAMUELSON, Paul, Foundations of Economic Analysis, Harvard Univer-
sity Press, 1983.
Capítulo 18
(*)SIMULACIÓN Y PROCESO DE LISTAS
En este capítulo vamos a estudiar cómo las técnicas de proceso de

listas se pueden combinar con las herramientas básicas de simulación
para dar lugar a aplicaciones de mayor potencia, capaces de acometer
problemas complejos manteniendo cierta simplicidad. Para ello vamos
a describir brevemente la extensión de manejo de listas tipo Lisp, que
incorpora el PSPS/Pspal. Esto permite concretar las ideas generales y
operativizarlas dentro de un sistema de simulación concreto. Sin embar-
go, los temas centrales son independientes del contexto de simulación,
y el lector aprenderá aquí conceptos de gran riqueza aplicables a otras
situaciones, más allá del propio PSPS.
La extensión de proceso de listas provee casi un centenar de funcio-
nes, que abarcan desde el manejo más elemental, hasta el uso de bases
de datos, tipo dBase, y extensiones de manejo de conocimientos. Estas

últimas serán objeto de estudio en el próximo capítulo.
La extensión LISP de proceso de listas es esencialmente un sistema
independiente del propio PSPS, que maneja su propia zona de memoria,
sus formatos de datos y su propia aritmética. Las listas se almacenan en
esa zona de memoria, que llamaremos la memoria LISP. Por tanto, una
lista aparecerá en una variable Pspal como un número, su dirección de
memoria LISP. Igual que sucedía con las strings, lo que se haga con este
número es responsabilidad del usuario.
Todos los nombres de funciones Pspal para el manejo de listas co-
mienzan con la letra L. Por ejemplo LCar, LCdr, LAppend son funcio-
nes Pspal de manejo de listas.
Figura 1
Extensión LISP y Pspal
Memoria PSPS Memoria LISP
Funciones L
Direcciones
1. Átomos
Toda lista está compuesta por átomos, que pueden ser de dos tipos.
Los átomos numéricos representan un número. Recíprocamente, un nú-
mero, decimal o no, por ejemplo 1234, puede ser un átomo numérico.
Un símbolo es un átomo no numérico. Un símbolo se representa por su
nombre, una secuencia de caracteres alfanuméricos que empiezan por
una letra. No se distinguen las mayúsculas de las minúsculas. De hecho
el sistema trata todos los caracteres alfabéticos como letras mayúsculas.
Por ejemplo, ABC es un símbolo (que también puede escribirse como
abc).
Un átomo es una unidad indivisible que se maneja e interpreta por
las primitivas del lenguaje.

Una variable Pspal que tiene asignado un átomo es también un nú-
mero, una dirección que apunta a la estructura que representa al átomo
dentro de la memoria LISP. Un átomo numérico y un número de Pspal
son dos tipos diferentes de datos. «Viven» en dos zonas diferentes de
memoria. Pero además se manejan de forma diferente y no se pueden
mezclar entre sí. Pero se pueden convertir unos en otros por medio de
funciones de conversión.
• LDefNAtom(double): convierte el número Pspal argumento de la
función en un átomo numérico
• LNumVal(numeric-atom): convierte el átomo numérico, argu-
mento de la función, en un número manejable en PSPS.
SIMULACIÓN Y PROCESO DE LISTAS 467
• LAtomp(arg): un predicado que testa si arg es un átomo. Devuel-

ve True si arg es un átomo y False en caso contrario.
• LNumberp(arg): predicado que testa si arg es un átomo numéri-
co. Devuelve True si arg es un átomo numérico y False en caso
contrario.
• LNullp(arg): predicado que testa si arg es el átomo nulo, NIL.
Devuelve True si arg es igual a Nil y False en caso contrario.
2. Listas: estructura y manejo básico
Una lista es una estructura de datos residente en la memoria LISP,

que consta de dos partes: el Car de la lista y el Cdr de la misma. El Car
de la lista es su primer elemento y puede ser una lista o un átomo. El
Cdr es siempre una lista, la lista de todos los demás elementos de la lis-
ta original.
Hay varias formas de representar listas. La más sencilla es en forma
de una secuencia de átomos, separados por espacios en blanco y todo
ello entre paréntesis. Así la secuencia (A B) es una lista, cuyo Car es
el átomo A y cuyo Cdr es la lista (B). En una lista como (A B C D
E), el Car de la lista es el átomo A, y su Cdr la lista (B C D E). En
esta representación, las dos partes de la lista se separan por el primer se-
parador (un blanco o un paréntesis). Por ejemplo (A(B C)) es una lis-
ta cuyo Car es el átomo A y cuyo Cdr es la lista ((B C)), es decir una
lista cuyo Car es (B C) y cuyo Cdr es ( ), la lista vacía equivalente
a NIL.
Una forma más intuitiva de representar listas es en forma de cajas.
Cada caja tiene dos partes, una que apunta al Car de la lista y la segun-
da que apunta al Cdr de la misma. Por ejemplo la figura 2:
Figura 2
Lista ( A )
A Nil
representa la lista ( A ) cuyo Car es A y cuyo Cdr es Nil o (). Esta

representación se suele simplificar, en la forma.
Figura 3
Lista ( A )
Esta manera de representar listas es muy próxima a la forma en que

se almacenan en la memoria LISP. Para cada lista se asigna una doble
celda (llamada un Cons) cuya primera parte apunta al Car de la lista y la
segunda contiene la dirección del Cdr de la lista, o un Nil (representado
por la dirección 0). Los átomos se implantan por medio de estructuras
algo más complicadas, de las que no daremos detalles. En esta notación
la lista:
(A (B C) (D E) F)
se representa como:
Figura 4
Representación de una lista en la memoria Lisp
A F
D E
B C
Las listas se pueden construir estéticamente, utilizando la función

LQ(string), con argumento una string Pspal que contiene la versión con
paréntesis de la lista, y que devuelve la dirección de la lista construida,
como un número Pspal. La string se convierte en una lista, si esto es po-
sible, es decir si la string conforma con la estructura de la primera repre-

sentación. Por ejemplo LQ(“(A (B C) (D E) F)”) construye la
lista anterior. Recíprocamente, una lista se puede convertir en una string
utilizando la función LShow(lista). Aquí lista es una variable Pspal que
contiene la dirección de una lista.
También pueden construirse listas de forma dinámica, usando otras
funciones. Una de ellas es LList(arg) que convierte arg en una lista que
tiene a arg como su Car y Nil como su Cdr. La función más importante
de este tipo es LCons(arg1,arg2). LCons reserva un Cons (un bloque de
dos celdas) y pone la primera celda a apuntar a arg1 y la segunda a
apuntar a arg2, devolviendo la dirección del bloque Cons, que efectiva-
mente es la dirección de la lista resultado. Nótese que en esta construc-
ción no se alteran ni se copian los argumentos. El fragmento de código
adjunto construye dinámicamente la lista del ejemplo anterior:
LCons( LQ(“A”),
LCons( LCons(LQ(“B”), LList(LQ(“C”))),
LCons( LCons(LQ(“D”), LList(LQ(“E”))),
LList(LQ(“F”)))));
Nótese que la construcción comienza por el Car de la lista y luego

procede de forma recursiva.
Más comprensible es, posiblemente, el siguiente fragmento de códi-
go, que hace exactamente lo mismo que el anterior.
AtomoA = Lq(“A”),
AtomoB = Lq(“B”),
AtomoC = Lq(“C”),
AtomoD = Lq(“D”),
AtomoE = Lq(“E”),
AtomoF = Lq(“F”),
aux = LCons(AtomoD,Llist(AtomoE)), {--(D E)--}
aux = LCons(aux,Llist(AtomoF)), {--((D E) F)--}
aux2 = LCons(AtomoB,Llist(atomoC)),{--(B C)--}
aux = LCons(aux2,aux),{--((B C) (D E) F)--}
aux = LCons(AtomoA,aux) {--(A (B C) (D E) F)--}
Utilización de las listas: acceso a sus elementos
Pspal provee un rico entorno de funciones para acceder a los ele-

mentos de una lista. Las ilustraciones que siguen las aplicaremos a la
lista siguiente:
x = LQ (“(A (B C) (D E) F)”).
Las funciones más relevantes son:

• LCar(arg) devuelve el Car de la lista argumento.
Ejemplo: LCar(x) = A
• LCdr(arg) devuelve el Cdr de la lista argumento.

Ejemplo: LCdr(x) =((B C) (D E) F)
• LCadr(arg) devuelve el Car del Cdr de la lista argumento.

Ejemplo: LCadr(arg) = (B C)
• LCaar(arg) devuelve el Car del Car del argumento.

Ejemplo: LCaar(Lcdr(x)) = B
• LNth(arg, i) devuelve el i-ésimo componente de primer nivel de

la lista arg.
Ejemplos: LNth(x,2) = (B C) ,
LNth(x,3) = (D E) ,
y LNth(x,4) = F
• LLast(arg) devuelve el último Cdr de la lista arg.
Ejemplo: Llast(x) = (F)
Finalmente, y aunque estrictamente no se trate de una función de

acceso a listas, la función LPrint(arg) se limita a devolver el argumen-
to, pero tiene un efecto indirecto importante, ya que imprime en la ven-
tana del Listener la lista cuya dirección Pspal esta contenida en arg.
Un tipo de listas que aparece constantemente en las aplicaciones son
las listas de asociación. Una lista de asociación, o abreviadamente una
alista, es una lista de pares del tipo:
((codigo1 valores...)
(codigo2 valores...)....)
Estas listas pueden pensarse como listas de récords. Cada record

contiene un código identificador y una serie de campos, o valores, aso-
ciados con el código. Veamos algunas de las funciones útiles para ma-
nejar este tipo de listas, que aplicaremos a la lista x = LQ(“((A
1)(B 2)(C 3)(D 4)(A 5))”):
• LAssoc(codigo, alista). La operación típica en listas de este tipo
es obtener el record asociado a un determinado código. Esta fun-
ción realiza esta labor. Busca en la alista el record con código
dado y devuelve todo el record. Si hay varios récords cuyo códi-
go coincida con el argumento, la función devuelve el primero.
Ejemplo: LAssoc( LQ(“c”),x) = (C 3)
• LDelAssoc(código, alista). Elimina de la alista el record con el

código dado en el primer argumento de la función. Si hay varios
récords cuyo código coincida con el argumento, la función elimi-
na el primero.
Ejemplo: LDelAssoc(LQ(“D”),x) = ((A 1)(B 2)(C
3)(E 5)))
• LAllAssoc(código, alista). Devuelve una alista con todos los ré-

cords de la alista que tienen el código dado en el primer argumen-
to de la función.
Ejemplo: LAllAssoc(LQ(“A”),x) = ((A 1)(A 5))
• LInsert(lista,lista2,posición). Inserta la lista2 en la lista del pri-

mer argumento, en la posición dada por el argumento posición.
Ésta es una función general pero que se aplica a las alistas, para lo
que lista2 debe ser un record completo.
Ejemplo: Linsert(x,LQ(“(Z 1000)”),2)=
((A 1)(Z 1000)(B 2)(C 3)(D 4)(E 5)))
3. Predicados
Cierto tipo de funciones de proceso de listas no devuelven una lista

sino un valor booleano True o False. Estas funciones se conocen en el
gremio con el nombre de predicados, y se utiliza para testar condicio-
nes dentro de la lógica del programa. Sus nombres terminan siempre
con la letra «p». Algunos de los más útiles son:
• LNullp(arg1): devuelve True si el argumento es Nil, y False en
caso contrario.
• LAtomp(arg1): devuelve True si el argumento es un átomo y Fal-

se en caso contrario
• LListp(arg1): devuelve True si el argumento es una lista y False
si no lo es. (p.ej. si es un átomo).
• LNumberp(arg1): devuelve True si el argumento es un átomo nu-
mérico y False en caso contrario.
La comparación entre listas es más delicada. ¿Cuándo son dos listas
iguales? Caben por lo menos tres posibilidades en la igualdad entre ob-
jetos:
1. Identidad. Los dos objetos son efectivamente el mismo objeto.
Esto sucede cuando se están comparando dos variables que con-
tienen la misma dirección, es decir dos punteros a la misma lista.
2. Si ambos objetos son átomos no idénticos en el sentido anterior,
pero que tienen el mismo valor.
3. Si la estructura de ambos objetos es idéntica y sus átomos corres-
pondientes tienen el mismo valor.
Por tanto hay tres funciones para comparar objetos 1:
• == La comparación estándar de Pspal. Devuelve True si la igual-
dad es de tipo 1.
• LEqv(arg1,arg2): devuelve True si la igualdad es de tipo 1 ó 2.
• LEqual(arg1,arg2): devuelve True si la igualdad es de tipo 1, 2 ó 3.
El cuadro siguiente presenta ejemplos de los resultados obtenidos
con estas funciones. Lo mejor es evitar en lo posible el uso de == por-
que es el que conduce a resultados menos intuitivos.
Cuadro 1
Comparación de objetos en lisp
INITIAL begin
{--Unos cuantos datos--}
x = LQ(“a”),
xx = x,
y = LQ(“a”),
z = LQ(“(a (b c) e)”),
1. La falta de la letra «p» al final del identificador de los predicados de compara-

ción se debe a razones históricas.
zz = z,
w = LQ(“(a (b c) e)”),
n1 = LDefNAtom(10),
n2 = LDefNAtom(10),
n3 = LQ(“(10 (1 2) 10)”)
{--Ahora una serie de comparaciones--}
writeTF(x == y), {False}
writeTF(x == xx), {True}
writeTF(z == w), {False}
writeTF(z == zz), {True}
writeTF(n1 == n2), {False}
writeTF(Lnth(n3,1) == Lnth(n3,3)), {False}
writeTF(LEqv(x,y)), {True}
writeTF(LEqv((x,xx)), {True}
writeTF(LEqv(z,w)), {False}
writeTF(LEqv(z,zz)), {True}
writeTF(LEqv(n1, n2)), {True}
writeTF(LEqv(Lnth(n3,1),Lnth(n3,3))), {True}
writeTF(LEqual(x,y)), {True}
writeTF(LEqual((x,xx)), {True}
writeTF(LEqual(z,w)), {True}
writeTF(LEqual(z,zz)), {True}
writeTF(LEqual(n1, n2)), {True}
writeTF(LEqual(Lnth(n3,1),Lnth(n3,3))), {True}
end;
System
TERMINATE 0;
endSystem
4. Aplicación
Vamos a utilizar ya algunas de las funciones presentadas en un pe-

queño programa PSPS. La estructura dinámica de las listas, su creación
sobre la marcha, se presta a asociarlas con transacciones, de forma que
cada transacción lleve en uno de sus atributos una lista con información
relevante. La potencia de esta construcción es elevada. Por supuesto, se
trata fundamentalmente de facilidad de uso, no de nuevas capacidades,
ya que obviamente todo lo que puede conseguirse con listas se puede
también lograr con arrays. Pero el uso de arrays para lograr la creación
dinámica de objetos implica la asignación de elementos del array a la
transacción en secuencias elaboradas, que acaban siendo incontrolables.
Ejemplo 1:
Una fábrica consta de cinco centros de proceso, imaginativamente

denotados por A, B, C, D y E. La empresa produce diez productos, cada
uno de los cuales tiene una ruta específica a través de los distintos de-
partamentos. En esta ruta se aplican al producto diferentes operacio-
nes, que conjuntamente realizan su producción. La fábrica dispone de
un fichero maestro de productos, en el que se indican las operaciones
que cada producto debe sufrir y su tiempo de operación.
Dada una secuencia de llegadas a producción, se desea calcular la
carga media en el tiempo que genera sobre las estaciones de trabajo del
sistema. Los pedidos se producen a una tasa de un pedido cada 12 mi-
nutos. La probabilidad de que el pedido sea de un determinado produc-
to, entre 1 y 10, es la misma e igual a 1/10.
Para fijar ideas supongamos la lista de productos y operaciones de
la figura 5.
A observar que la lista es una alista. En el primer nivel se encuentran
las listas de operaciones, una para cada producto. Cada lista tiene la for-
ma (Nombre_del_Producto Operacion1 Operacion2 ...), y cada operación
es una lista con la estructura (Nombre_del_centro Tiempo_proceso) 2.
Figura 5
Lista de productos y operaciones
(( P1 (A 10)(B 5)(E 2))

( P2 (E 4)(C 15))
( P3 (C 12)(B 8)(A 9)(C 6))
( P4 (D 8)(B 5)(D 12))
( P5 (A 11)(D 13)(E 14))

( P6 (E 5)(A 8))
( P7 (B 16)(A 14)(D 10)(B 1))
( P8 (E 2)(A 8)(C 11)(E 12)(B 5))
( P9 ((A 11)(C 14)))
( P10(E 12)(C 5)(D 15)) )
2. Nótese la proliferación de paréntesis que aparecen en la representación stándar

de la lista. ¡es fácil olvidarse de alguno! Por ello en el editor de PSPS hay una opción
para comprobar los paréntesis de una expresión. El botón busca a partir de la posi-
ción del cursor y hacia atrás, el paréntesis que equilibra la expresión. Lo mismo hace el
menú Edit/Check().
El siguiente programa PSPS implementa un modelo de simulación

para este caso.
Cuadro 2
Modelo «Fábrica»
Constants
Ruta = 3;
Estacion = 4;
Labels
Ciclo; Final;
Variables
LispRutas;
LispMaquinas;
Macros
Maquina:function(x) return LNumval(Lcadr(Lassoc(LCar(x),
Lispmaquinas)));
Tiempo :function(x) return LNumval(Lcadr(x));
Pasos :function(i) return LCdr(Lnth(LispRutas,i));
Data
Initial LispRutas = LQ(“( ( P1 (A 10)(B 5)(D 2))
( P2 (D 4)(C 15))
( P3 (C 12)(B 8)(A 9)(C 6))
( P4 (D 8)(B 5)(D 12))
( P5 (A 11)(D 13)(E 14))
( P6 (E 5)(A 8))
( P7 (B 16)(A 14)(D 10)(B 1))
( P8 (E 2)(A 8)(C 11)(E 12)(B 5))
( P9 (A 11)(C 14))
( P10(E 12)(C 5)(D 15)) ) ”);
Initial LispMaquinas = LQ(“((A 1)(B 2)(C 3)(D 4)(E 5))”);
System
GENERATE 12,On;
ASSIGN at[Ruta] = Pasos(Random(1,11));
ASSIGN at[Estacion] = Lcar(at[Ruta]);

ciclo: TRANSFER Cond(Lnullp(at[Ruta]),final,cb+1);
QUEUE Maquina(at[Estacion]);
WAITFOR Tiempo(at[Estacion]);
LEAVE Maquina(at[Estacion]);
ASSIGN at[Ruta] = Lcdr(at[Ruta]),ciclo;
final: TERMINATE 1;
EndSystem
Nótese que la lista LispRutas está diseñada de tal forma que el

LCdr de cualquiera de sus récords produce una lista con las operaciones
del producto correspondiente. El estilo de programación es típico de Lisp;
Trata de esconder el uso de las primitivas LISP tras funciones de acceso a
los datos creadas por el usuario, de forma que si se altera la estructura de
los datos, se pueda mantener la funcionalidad simplemente reescribiendo
las funciones de acceso. Aquí hay tres funciones de acceso:
Pasos(i): obtiene la lista de operaciones del producto i. Opera to-

mando el Cdr del record i-ésimo de la lista LispRutas.
Maquina(x): si se le suministra una lista de la forma (Proceso Tiem-
po) obtiene el número del procesador PSPS asociado a la máquina que
realiza el proceso. Primero toma el Car del par suministrado, es decir el
nombre del proceso. A continuación consulta, usando la función Lassoc,
la lista LispMaquinas, una alista de pares de la forma (Proceso Proce-
sador) y obtiene el número del procesador tomando el segundo elemen-
to, LCadr, del par hallado. El resultado es un átomo numérico que debe
transformarse en un número PSPS por medio de la función LNumVal.
Tiempo(x): parecida a la anterior, partiendo de un par de la forma
(Proceso Tiempo) obtiene el valor del tiempo de estancia en el procesa-
dor.
El bucle de transacciones, en la sección System, es típico de la for-

ma en que se recorre una lista iterativamente. El esqueleto del bucle se
muestra a continuación. Recorre la lista unaLista elemento por ele-
mento, hasta agotarla.
{---Recorrer la lista unaLista--}

x = unaLista,
While not Lnullp(x) do begin
aux = Lcar(x),
....aquí trabajar con aux....
x = Lcdr(x)
end
Esta estructura aparece tan a menudo, que el lector hará bien en re-
cordarla y entenderla.
5. Cirugía de listas
La mayoría de funciones de manejo de listas no alteran sus argu-

mentos. Cuando se construye una nueva lista, se suele proceder por co-
pia, con asignación de memoria adicional. De esta forma las funciones
de manejo de listas son limpias, porque no producen efectos indirectos.
Al salir de la función los argumentos quedan tal como estaban. En la
medida de lo posible, conviene que las funciones de manejo de listas
cumplan esta condición.
Sin embargo, por razones de eficiencia o de espacio, es a veces ne-
cesario construir listas alterando de varias formas las listas existentes.
De hecho, ya hemos definido una función que usa esta técnica, la fun-
ción LdelAssoc, que elimina físicamente una parte de uno de sus argu-
mentos. En la práctica se conoce este enfoque como cirugía de listas.
En PSPS disponemos de un número de funciones para «hacer ciru-
gía».
• LConc(arg1,arg2): concatena la lista arg2 con la lista arg1, cam-
biando la celda del último Cdr de arg1 para que apunte al Car de
arg2. La lista arg1 queda pues modificada 3.
• LSetCar(arg1,arg2): coloca la lista arg2 como Car de la lista arg1.
Esto se logra haciendo que la celda Car de arg1 apunte a arg2.
Por tanto la lista arg1 queda modificada.
• LSetCdr(arg1,arg2): coloca la lista arg2 como Cdr de la lista
arg1. La lista arg1 queda modificada.
• LSetNth(arg1,n,arg2): coloca la lista arg2 en la posición n-ésima
de la lista arg1. La lista arg1 queda modificada.
• LGrow (arg1,arg2): añade un Cons al final de la lista arg1, cuyo
Car apunta a arg2.
• LSetNVal(arg1,número): esta función cambia el valor de un áto-

mo numérico. El átomo es arg1 y el nuevo valor se indica en el
argumento número. El átomo anterior desaparece del sistema.
Esta función puede usarse para evitar el crecimiento del número
de átomos numéricos, ya que en vez de generar nuevos átomos,
reutiliza los existentes. Pero la función tiene peligros ocultos que
obligan a proceder con cuidado. Al crear una lista, los átomos nu-
méricos con el mismo valor no se duplican, sino que se usan los
3. En todas partes donde aparezca. Si, por ejemplo otra lista tiene un Cons apun-
tando a la lista arg1, esta segunda lista quedará modificada como resultado de la modi-
ficación de arg1. ¡Lío asegurado!
existentes. Por ello puede existir una única copia de un átomo nu-
mérico, aunque se use en múltiples lugares. El uso de esta función
altera esa única copia, con el resultado de que todas las aparicio-
nes del átomo numérico quedan modificadas.
Al usar cirugía de listas siempre hay la posibilidad de que se pro-
duzcan fenómenos curiosos e impensados. Uno de los más normales es
crear listas circulares, que no se pueden escribir, y cuyo recorrido por
un programa provocaría bucles infinitos. Moraleja: deben evitarse estas
funciones siempre que sea posible, reservándolas para casos en los que
la copia de listas es muy onerosa. Situaciones típicas donde esto acon-
tece se encuentran al manejar bases de datos, representadas por listas de
algunos cientos de elementos.
6. Asignación de memoria
Al construir una lista con la función LCons, o con otras parecidas,

se asigna memoria dinámicamente, que se debe recuperar cuando ya no
se necesita. La recuperación de memoria LISP es semiautomática. La
función LGC, que debe ser llamada por el usuario, hace «recolección
de basura», es decir elimina de la memoria todas las listas que no se ne-
cesitan.
LGC debe identificar de alguna forma las variables que contienen
direcciones de listas a preservar. Hay que notar que lo que se preserva
son las listas a las que apuntan esas variables, no las variables en sí, que
en PSPS son siempre estáticas.
La identificación de listas a preservar se realiza de varias formas:
a) Forma implícita. Todas las variables globales Pspal con un nom-
bre de la forma Lispxxxx donde xxxx es una secuencia váli-

da de caracteres, se supone que siempre contienen listas que hay
que preservar.
b) Forma explícita. Si el usuario llama a la función LStatic(arg)
con argumento una variable Pspal, declara que la variable con-
tiene la dirección de una lista que hay que preservar. Como lo
que se preserva son contenidos, si el valor de la variable cambia,
apuntando a otra lista, y no se vuelve a llamar a la función LSta-
tic, la nueva lista no se preservará. Sin embargo, la lista anterior
seguirá preservada. Las variables locales a una función no pue-
den preservarse de forma implícita, y deben reservarse siempre
usando la función LStatic ( ).
c) Forma automática. PSPS preserva automáticamente todas las

listas que figuran en los atributos de alguna de las transacciones
vivas, por lo que el usuario no debe preocuparse de ellas.
Cuando un programa no crea listas sobre la marcha, es decir no hace
consing, no es necesario hacer recogida de basura. En el ejemplo ante-
rior no se necesita hacer LGC. Sólo se usan listas en modalidad de con-
sulta y por tanto no hay necesidad de destruir nada, porque no se crea
nada. Aunque hay que ser consciente de que algunas de las funciones
Lisp hacen consing internamente. En cualquier caso, si la memoria se
agota el sistema avisa y se detiene la simulación, lo que indica la nece-
sidad de insertar instrucciones LGC en el programa.
7. Uso de bases de datos dBase
La extensión LISP proporciona funciones para acceder a las tablas

de bases de datos tipo dBaseIV. Este acceso se logra por medio de las si-
guientes funciones:
• LOpenRdb(Filename): Filename es una string que indica el nom-
bre de una tabla dbf de la base de datos. La función prepara la ta-
bla para su lectura posterior. La función devuelve un átomo, que
debe asignarse a una variable PSPS y que se usa como referencia
a la tabla en todas las demás funciones.
• LGetStruct(fich): la función devuelve una lista que contiene la
estructura de campos de los récords de la tabla identificada por la
variable fich (resultado de la utilización de la función LOPenRdb).
• LGetRecord(fich): obtiene el siguiente record del fichero identifi-
cado por fich, en forma de una lista de los valores de sus campos.
Adicionalmente, el record queda como record en curso. Cuando
se intenta leer más allá del último record devuelve la lista vacía
Nil.
• LGetFieldByName(fich,nombre): obtiene el valor del campo nom-
bre del record en curso del fichero fich.
• LEofDb(fich): si el fichero está agotado, es decir, si el último
LGetRecord ha intentado leer más allá del fin de fichero, devuel-
ve True. Si no, devuelve False.
• LCloseDb(fich): cierra el fichero y elimina la asociación entre la
variable especificada y la tabla de la base de datos.
Cuadro 3
Modelo «Lectura base de datos»
Variables
Lispfichero;
Lisprecord;
Lispestructura;
Lispframes;
Data
initial begin
{--Abrir el fichero con la tabla--}
Lispfichero = LOpenRDB(
“C:\Archivos de Programa\Borland\Delphi5\camisas\stocks.dbf”),
{--Conseguir su estructura--}
Lispestructura = LPprint(LGetStruct(Lispfichero)),
{--Leer hasta el final de fichero--}
while not LEofDb(Lispfichero) do begin
Lisprecord = LGetRecord(Lispfichero),
{--antes de testar por eof leer más allá del eof, dando nil--}
if Lisprecord # nil then Lispframes = LCons(Lisprecord,
Lispframes)
end,
LGC {--y se recoge toda la memoria que contiene basura--}
end;
System
generate 1,1;
terminate 1;
endsystem;
El cuadro muestra un programa que lee de una base de datos de

stocks. Hay que hacer algunas observaciones:
a) Hemos usado variables cuyos nombres empiezan por Lisp para
facilitar la recogida de basura, si se desea usarla.
b) Al leer en un bucle While, hay que testar el record por Nil, para
anticipar una posible lectura más allá del último record, que se
producirá antes de detectar el fin de fichero en el bucle.
8. Debugging en las listas
Una variable Pspal contiene siempre un número. Por tanto, en el de-

bugging normal PSPS muestra como valor de las variables el valor nu-
mérico de la dirección a la que ésta apunta, y no la lista correspondien-
te. En operaciones de debugging lo que se suele necesitar es la lista, no
su dirección. Para obtenerla, y prácticamente en cualquier lugar donde
pueda aparecer una dirección Lisp, el botón derecho del ratón hace apa-
recer un menú emergente que contiene la opción «Show List at Ad-
dress». Esta opción muestra, en una ventana aparte, la lista completa de
forma inteligible.
Por otra parte, el listener incluye un menú completo dedicado al de-
bugging en LISP, y un menú emergente que contiene las opciones más
frecuentes.
9. El lenguaje LISP
Hasta ahora hemos presentado las funciones Pspal para el manejo

de listas tipo Lisp. Pero hay más. PSPS proporciona un intérprete de
una versión reducida de LISP 4, un lenguaje general orientado al proce-
so de listas. Una de las propiedades más básicas de LISP es que todo
programa en ese lenguaje es también una lista, es decir se representa y
almacena exactamente igual que una lista cualquiera. El intérprete LISP
puede recorrer una lista arbitraria e interpretarla como un programa. El
LISP de PSPS admite la creación de programas por la especificación de
la lista correspondiente, ya sea usando LQ, o haciendo consing. Dada
una lista sintácticamente correcta en LISP, el intérprete, una versión del
cual es llamable por medio de las funciones LEval, LApply u otras,
puede interpretar la lista realizando los cálculos indicados.
No es nuestra intención lograr que el lector aprenda a programar en

LISP. Esto puede lograrse consultando la literatura especializada. Que-
remos tan sólo dar una idea de lo que está escondido en el LISP de
PSPS, y de sus capacidades y limitaciones.
Un programa en LISP es una lista formada por sublistas, que repre-
sentan o llamadas a funciones o formas especiales.
En LISP casi todo son funciones. Toda función LISP tiene un nom-
bre, unos argumentos y devuelve un valor. Se llama a la función, dando
4. La principal omisión en el LISP de PSPS con respecto al COMMON LISP es la

de las clausuras. Ver [Norvig]. Por supuesto hay otras muchas más omisiones, incluyen-
do los arrays, input-output sofisticado... Pero PSPS no pretende ser COMMON LISP...
una lista cuyo Car es el nombre de la función, y cuyo Cdr es la lista de

argumentos de la misma. Muchas funciones de LISP tienen un número
variable de argumentos, lo que indicaremos por puntos suspensivos en
su descripción.
Como en las versiones estándar, el LISP de PSPS evalúa primero
los argumentos de la función, y tras esta evaluación, evalúa la función
aplicándola a los argumentos. Por tanto, al realizar la llamada a una fun-
ción, todos los argumentos de una función serán siempre evaluados.
Esto no sucede así para algunas de las formas especiales, que describi-
remos más adelante. En estas formas hay argumentos que están protegi-
dos de la evaluación.
En general, LISP contiene las mismas funciones que la extensión
Lisp de Pspal. Sus nombres son idénticos, excepto por la L inicial, que
se suprime en LISP, y su formato de llamada es el formato LISP, ya des-
crito, y no el formato Pspal.
Por ejemplo son funciones LISP:
• (QUOTE lista). En LISP, la definición de una lista se puede reali-
zar mediante la función QUOTE, análoga a la función LQ en Ps-
pal, que se puede abreviar a ’lista. La interpretación de esta
sentencia hace que se lea la lista y se devuelva ésta como resulta-
do.
• (LIST lista1 lista2 ... ) devuelve la lista creada a partir de sus ar-
gumentos.
• (CAR lista) devuelve el Car de la lista argumento de la función.
• (CDR lista) devuelve el Cdr de la lista argumento de la función.
LISP define dos valores booleanos, verdadero y falso representados
por el átomo T y el valor Nil. Una función que devuelve uno de estos
valores se llama un predicado.

Probemos a entrar algunas funciones e interpretarlas directamente
en LISP. La mejor forma es utilizar directamente el listener, que provee
acceso directo al intérprete de LISP embebido en PSPS. La forma de
ejecutar una expresión LISP es empezar ya sea seleccionándola, o posi-
cionándose detrás del último paréntesis de la expresión. En el primer
caso, en el menú emergente del listener (botón derecho) hay una opción
«Evaluate Selection», que evalúa lo seleccionado. En el segundo caso la
opción es «Evaluate previous expresión» y tiene el mismo efecto que la
expresión anterior. También hay una opción para evaluar todas las ex-
presiones de la ventana del listener, útil cuando se trata de evaluar, de
una vez, un conjunto complicado de expresiones. El lector puede probar
los ejemplos del cuadro, que deben dar los resultados indicados en el
cuadro 5, resultados.
Cuadro 4
Ejemplo de funciones Lisp
Ejemplos
(defvar x) {--define la variable global x--}
(defvar y) {-- idem para y--}
(setq x '(a b c d e f))
(setq y '(1 2 3 4 5 6))
(car x)
(cdr x)
(nth x 3)
(cons (nth x 3)(cadr y))
(list x)
(cons (nth x 3) (list(cadr y)))
Cuadro 5
Resultados
Resultados
[ 3]:(A B C D E F)
[ 4]:(1 2 3 4 5 6)
[ 5]:A
[ 6]:(B C D E F)
[ 7]:C
[ 8]:(C.2)
[ 9]:((A B C D E F))
[ 10]:(C 2)
Las opciones «Select expression <-» y «Select expression ->» del

menú emergente son útiles para no perder la cuenta de los paréntesis.
A diferencia de las funciones, en las formas básicas que describire-
mos en la próximas secciones hay argumentos que no se evalúan. Por lo
demás, el intérprete sigue la regla clásica de evaluar primero todos los
argumentos y a continuación aplicarles la función.
Variables LISP
LISP permite definir variables, que no deben confundirse con las va-
riables Pspal. Las variables LISP identifican listas o átomos, y residen en
la memoria LISP. Sólo son manejables dentro del lenguaje LISP, aunque
como veremos más adelante, se pueden crear puentes desde Pspal para
acceder a sus valores. Las variables LISP también se guardan en una lis-
ta. El sistema mantiene alistas, en las que cada récord tiene la forma:
(<nombre de la variable> <valor>)

con <valor> una lista o un átomo. Una alista de variables se suele lla-
mar un contexto de ejecución, o simplemente un contexto. El intérprete
mantiene un contexto en el que ubica las variables a medida que se van
definiendo, implícita o explícitamente. Cuando el nombre de una varia-
ble aparece en el código, se busca su valor en el contexto por medio de
la función ASSOC (análoga a la Lassoc en Pspal). Por tanto se devuel-
ve la primera coincidencia, lo que implica que nuevas variables oscure-
cen a variables definidas con anterioridad. Todas las variables definidas
en las funciones LISP son dinámicas 5. Al salir de una función se elimi-
nan del contexto y se pierden sus valores.
Se pueden definir variables globales, que mantienen sus valores du-
rante toda la vida del intérprete. Para ello basta evaluar, a primer nivel
del intérprete, la forma:
(DEFVAR <nombre>)
Esta forma crea una variable con el nombre dado, y la ubica en una
alista especial de variables globales, variables que están definidas en
cualquier contexto de ejecución, aunque son oscurecidas por variables
locales del mismo nombre.

Algunas funciones Pspal permiten pasar contextos como argumen-
tos. En concreto, Leval, que llama al intérprete para evaluar una expre-
sión LISP dada por una string, permite especificar como último argu-
mento el contexto en el que se deben interpretar las variables libres (sin
valor asignado explícitamente) de la expresión.
5. Otra diferencia importante con respecto a COMMON LISP.
Formas básicas
Como hemos dicho, las formas básicas de programación en LISP

tienen también forma de lista, con un operador o palabra clave como
Car de la misma y una serie de argumentos a continuación. Todas ellas
devuelven un valor, como si fueran funciones. Por supuesto el valor es,
en general, una lista, que puede combinarse con otras en la forma desea-
da, utilizando las primitivas del lenguaje. A continuación describimos
brevemente algunas de las formas básicas más usadas 6, indicando en
cursiva los argumentos que no se evalúan:
• (SETQ <variable> <forma>): es la sentencia de asignación.
Asigna a la variable indicada el valor de la expresión que figura
como segundo argumento. Equivale al operador = de Pspal.
• (LAMBDA <lista de variables> <forma>): se usa para definir
funciones. La lista de variables indica los parámetros de la fun-
ción, que se utilizan en la forma que aparece como segundo argu-
mento. Este tipo de definición es local y produce funciones anóni-
mas, que se pueden utilizar como argumentos en otras funciones,
y que no viven más allá de su utilización inmediata. Devuelve la
función. Si se quiere que la función sea identificable por su nom-
bre, el resultado se puede asignar a una variable mediante SETQ,
y ésta puede usarse para acceder a la función. Suele ser más prac-
tico usar la variante Defun tal como se indica a continuación.
• (DEFUN <nombre-de-la-función> <lista de variables> <for-
mas>): crea una función global con nombre, referenciable desde
cualquier lugar del programa. Formas es una colección de formas
que se pueda interpretar como un programa.
• (LET ((var1 valor1)(var2 valor2)...) <formas>): parecido al blo-
que Begin/end, pero permite definir variables locales a las formas,
inicializadas a los valores que se especifican. Una vez se ha sali-

do del Let, las variables definidas mueren y no están accesibles.
• (IF <condición> <forma-then> <forma-else>): clásico condicio-
nal de dos vías. Condición debe devolver T o Nil. Obsérvese que
no aparecen las partículas Then o Else por ninguna parte, y que la
bifurcación a elegir se determina por la posición en la sentencia.
• (WHILE <condición> <forma1><forma2>...): bucle de repeti-
ción. Mientras la condición sea T se siguen evaluando las formas.
Cuando es Nil se devuelve el valor de la ultima forma evaluada.
6. Para más detalles consultar los manuales en el CD.
Veamos algunos ejemplos sencillos de estas formas básicas. En ne-

grita se presentan los resultados de la evaluación. En negro todo lo es-
crito por el usuario.
Ejemplo A. La función «Aparea» crea una alista de pares, a partir
de dos listas x e y. Los pares están formados por elementos correspon-
dientes de ambas listas.
(Defun Aparea(x y)
(If (Not (nullp x))
(Cons (Cons (Car x)(List (Car y)))
(Aparea (cdr x)(cdr y)))))
(Aparea '(a b c d e f) '(1 2 3 4 5 6))

[1:] ((A 1) (B 2) (C 3) (D 4) (E 5) (F 6))
La escritura de programas LISP es típicamente muy recursiva, como

en el ejemplo. De hecho, ésta es la forma natural de plantear muchos al-
goritmos, y en particular los de proceso de listas. La idea básica es que
el resultado global se puede obtener aplicando un cierto proceso a los
Car de las listas, y haciendo consing del resultado con el de procesar de
la forma original sus Cdr 7.
Ejemplo B. La misma función (casi) escrita en forma iterativa.
(Defun Aparea (x y)
(let ((aux1 x)
(aux2 y)
(lista nil))
(while (not (nullp aux1))
(setq lista (cons (cons(car aux1)(list (car aux2)))
lista))
(setq aux1 (cdr aux1))
(setq aux2 (cdr aux2)))
lista))
(Aparea '(a b c d e f) '(1 2 3 4 5 6))
[ 6]:((F 6) (E 5) (D 4) (C 3) (B 2) (A 1))
7. De hecho, la estructura de LISP está cuidadosamente pensada por sus autores

para que éste sea el caso. El hecho de que el Cdr de una lista siempre sea una lista, hace
que se pueda procesar de la misma forma que la lista original. Todo ello hay que agra-
decérselo a John Mac Carthy, el padre de LISP. LISP es ya veterano, pues tiene unos 50
años. Pero un veterano en buena forma...
Nótese que el programa es simplemente una aplicación del proceso

de recorrido de una lista descrito en una sección anterior. Pero con este
proceso, ¡la lista de los resultados se obtiene invertida! No es fácil ver
cómo se puede obtener de la forma adecuada. ¿Puede hacerlo el lector 8?
Entre los «LISPeros», esta forma de programar se considera «de mal
gusto», porque realiza asignaciones a variables que causan efectos late-
rales, a veces difíciles de controlar.
Ejemplo C. Dada una lista de funciones, aplicarla a los elementos
correspondientes de una lista de datos.
Este ejemplo empieza a mostrar la potencia real que aporta LISP al
sistema PSPS. Una función f, ya sea dada por una expresión lambda, o
definida con Defun, se puede aplicar a unos argumentos utilizando la
expresión:
(APPLY f (lista-de-argumentos))
Veamos un ejemplo 9:
(Defun Aplicar (f y)
(if (Not (Nullp f))
(Cons (Apply (Car f)(List (Car y))) (Aplicar (Cdr
f)(Cdr y)))))
(Let ((x (List (Lambda(x)(Car x)) (Lambda(x)(Cadr x))))

(y '((a b)(a c b d))))
(Print x)
(Aplicar x y))
[ 15]:(A C)
Ejemplo D. Ejecutar una lista. En este programa mostramos cómo

cualquier lista interpretable se puede ejecutar con la función APPLY.
Esto permite construir programas sobre la marcha 10, generando la lista
e interpretándola a continuación.
(let ((x '(lambda(x)(cadr x))))

(apply x '((10 100 1000 2000))))
[ 17]:100
8. Sugerencia: piense en usar funciones de cirugía de listas... (¡Ufff!).

9. A diferencia de las versiones LISP estándar, APPLY necesita que todos los ar-
gumentos de la función, si hay varios, estén combinados en una lista única.
10. Hace 30 años esto causaba gran excitación, porque aparte del lenguaje de má-
quina, LISP era el único lenguaje que permitía esta operación. Ahora se reconoce la
poca utilidad de esta característica.
Nótese que la variable x contiene una lista, ya que su valor esta dado
por una función QUOTE y por tanto no es evaluado. APPLY interpreta
correctamente esta lista.
Interface de Lisp con PsPal
La verdadera potencia de la combinación PSPS y LISP aparece

cuando se combinan ambos. Desde dentro de Pspal es posible ejecutar
programas escritos en LISP, como si se hiciera desde el listener, pasan-
do resultados entre ambos entornos. Para ello hay que construir listas
que sean ejecutables en LISP, y usar las funciones Pspal de evaluación
que desatan toda la potencia del intérprete LISP 11.
• LEval(lista,variables-definidas) llama al intérprete LISP para
evaluar la lista que figura en el primer argumento, tomando como
lista de variables predefinidas las que se le indican en el segundo
argumento. Devuelve el resultado de evaluar la lista suministrada,
en el contexto indicado.
• LEvalf(string) o más abreviadamente LE(string), es idéntica a la
anterior, pero antes de evaluar transforma la string en una lista,
usando para ello la función LQ. Adicionalmente utiliza, por de-
fecto, un contexto vacío.
• LApply(función, lista-de-datos, lista-de-variables-predefinidas).
Aplica la función (¡no una lista!) a los argumentos, combinados
en la lista única lista-de-datos, usando para la evaluación el con-
texto lista-de-variables-predefinidas.
Con estas funciones se logra una interface entre Pspal y LISP. He
aquí la forma de explotarla en un pequeño programa de demostra-
ción.
11. Nótese que todas las funciones de esta seccion son funciones Pspal de proceso
de listas, no funciones del lenguaje LISP.
Cuadro 6
Interface de Lisp con Pspal
Variables
funcion; varian; programa; y;
Data
REPORT -1;
vars funcion =
Leval(LQ(“(defun aparea(x y)
(if (not (nullp x))
(cons (cons (car x)(list (car y)))
(aparea (cdr x)(cdr y))))) ”));
vars varian = LQ(“((x (a b c d e f)))”);

vars programa = Lq(“(Let ((a x)(b '(1 2 3 4 5 6)))
(print (aparea a b)))”);
vars y = LQ(“(1 2 3 4 5 6)”);
System
GENERATE 0,1;
COMPUTE LEval(programa,varian);
TERMINATE 0;
endsystem;
En cursiva se destacan las partes del programa escritas en LISP.

Como puede verse, una string que contiene la definición LISP de la fun-
ción Aparea del ejemplo A se convierte en una lista por medio de la
función LQ. Esta lista, que va a definir la función, pero que aún no es la
definición de la función, debe evaluarse para dar como resultado la fun-

ción Aparea. Esta evaluación se lleva a cabo por la función LEval 12 en
un contexto nulo, ya que no hay variables adicionales que se deban con-
siderar.
A continuación creamos una lista global de variables, que se usará
como contexto de evaluación. Como hemos dicho, las lista de variables
son alistas de pares (nombre-variable valor). En este contexto defini-
mos una única variable LISP, de nombre X y cuyo valor es la lista (A B
C D E F).
12. Este doble proceso se puede realizar en una sola operación, usando la función
LE, que combina las operaciones de creación de la lista y su evaluación.
A continuación construimos un programa a evaluar. El programa

tiene una variable libre, la variable X, cuyo valor se obtendrá del con-
texto definido más arriba. El programa es una sentencia Let, que define
dos variables internas, a y b, las asocia con valores y evalúa la función
Aparea para esos valores. Finalmente la sección Data se completa con
la definición de la variable Pspal a la que se asigna la lista (1 2 3 4
5 6).
En el bloque COMPUTE se produce la evaluación del programa en
el contexto definido usando LEval.
Accediendo a Pspal desde LISP
La sección anterior ha presentado cómo se puede acceder desde

PSPS a cualquier tipo de construcciones en LISP. Pero la interacción
entre Pspal y LISP llega mucho más lejos. En concreto todas las funcio-
nes Pspal están disponibles desde LISP. Para ello deben utilizarse tres
funciones pasarela, las funciones PspsList, PspsNum, y PspsBool, de
las que damos detalles en esta sección.
Estas tres funciones LISP permiten ejecutar, desde dentro de LISP,
cualquier función Pspal y devolver los resultados en formato LISP,
como si de una función LISP se tratara. Ya que el resultado de una fun-
ción Pspal no es más que un número sin interpretación, se necesitan tres
funciones. Una para trasladar a LISP un resultado numérico, otra para
enviar a LISP una lista y una última función para enviar un valor boole-
ano. PspsNum devuelve átomos numéricos, PspsList devuelve punteros
a listas (es decir listas LISP) y PspsBool devuelve T o Nil (los valores
booleanos correspondientes a los True o False de Pspal).
El formato de estas tres funciones es idéntico:
(PspsNum <nombre-de-la-función-Pspal> <arg1> <arg2> <arg3> ...)

(PspsList <nombre-de-la-función-Pspal> <arg1> <arg2> <arg3> ...)
(PspsBool <nombre-de-la-función-Pspal> <arg1> <arg2> <arg3> ...)
Todas tienen un número indefinido de argumentos. Los argumentos

son expresiones LISP, que se evaluarán antes de aplicarles la función
Pspal. El resultado de la evaluación se interpreta de las siguiente mane-
ra según sea:
• Un número LISP (un átomo numérico). El valor numérico del
átomo se usará en la llamada a la función Pspal.
• Una lista LISP. Se pasa a la función Pspal la dirección de la lista.
• Un átomo. El átomo se toma como nombre de una variable Pspal,

cuyo contenido se usará como argumento. Por este medio se pue-
den pasar valores Pspal cualesquiera, incluyendo listas. Nótese
que esta característica impide el uso de otros átomos como argu-
mentos, ya que siempre se interpretan como nombres de varia-
bles.
El argumento «nombre de la función Pspal» es una expresión que
debe resultar en un átomo no numérico, el nombre la función Pspal a
utilizar. Suele ser una expresión quoted, en la forma 'Nombre.
El resultado de la aplicación de una de estas funciones se transfor-
mará en una átomo numérico por PspsNum, en una lista por PspsList o
en un valor booleano lisp (T o Nil) por PspsBool. La tabla muestra al-
guna de las cosas que se pueden hacer con estas funciones, que tienen
una extraordinaria flexibilidad.
Cuadro 7
Accediendo a Pspal desde LISP
Variables
x; fun1; fun2; fun3; fun4;
Macros {--Funciones Pspal--}
{--Cuadrado de un número--}
sqr :function(x) return x*x;
{--Invierte un par, dado como una lista --}
revpar : function(x) return Lcons(Lcadr(x),Llist(lcar(x)));
Data {--Funciones Lisp--}
initial fun1 = LE(“(defun alfa1()(pspsNum 'sqr 'x))”);
initial fun2 = LE(“(defun alfa2()(pspsList 'revpar 'x))”);
initial fun3 = LE(“(defun alfa3(xx)(pspslist 'revpar xx))”);
initial fun4 = LE(“(defun alfa4(xx)(pspsNum 'sqr xx))”);

System
GENERATE 0,1;
COMPUTE begin {--Prueba de las funciones--}
x = 3,
LPrint(LApply(fun1,nil,nil)),
x = LQ(“(A B)”),
LPrint(LApply(fun2,nil,nil)),
LPrint(LApply(fun3,Llist(LQ(“x”)),nil)),
LPrint(LApply(fun4,Llist(LDefNAtom(4)),nil)),
end;
Terminate 0;
endsystem;
El cuadro define dos funciones Pspal. Una de ellas toma el cuadra-

do de un número. La otra invierte un par, dado como una lista. Luego
definimos cuatro funciones LISP que usan dos de las funciones pasare-
la Pspal, además de datos en formatos varios. Finalmente aplicamos las
funciones LISP a los argumentos. En el proceso se llamarán las funcio-
nes Pspal, adaptando las estructuras de datos para obtener el resultado
deseado.
El lector debe estudiar estos ejemplos para obtener una buena com-
prensión del funcionamiento de estas funciones.
Las funciones PspsNum, PspsList y PspsBool permiten realizar cál-
culos pesados desde LISP, sin caer en la explosión de átomos numéri-
cos. Esto se logra utilizando Pspal para el calculo numérico, cosa que
hace muy bien, mientras que se retiene el manejo de listas en LISP, cosa
en la que LISP destaca.
Veamos algunos ejemplos de la utilización de estas funciones en la
simulación.
Ejemplo 2. Una empresa reparte pan dentro de un perímetro apro-

ximadamente rectangular, con lados 3 y 2 kilómetros respectivamente.
Cada mañana se carga un camión, que sale a repartir a las seis. El ca-
mión va equipado con comunicaciones, de manera que a medida que se
reciben en la central los pedidos de las panaderías, se transmiten al ca-
mión, que organiza su recorrido para poder servirlos. El criterio que si-
gue el camionero es, aproximadamente, organizar los pedidos pendien-
tes de servir de acuerdo con su distancia al punto en que se halla. Tras
realizar una entrega, y habiendo ordenado la lista, el camión se dirige
a servir el primer pedido de la misma. La decisión de qué cliente servir
a continuación se toma tras cada entrega y no se reconsidera durante
el trayecto. Se desea saber cuánto tiempo se demorará el servicio de los
pedidos, de acuerdo con la carga recibida y en función de las diferentes

maneras posibles de calcular la distancia.
Vamos a representar los pedidos recibidos, y que están pendientes
de servir en un instante dado, por una alista. Cada record estará com-
puesto por el código del cliente, sus dos coordenadas (x, y) en el área de
reparto, y por la hora a la que se ha recibido el pedido. Adicionalmente
prevemos otro campo, que se llenará con la distancia calculada desde la
ubicación del cliente hasta el camión.
Esta lista crecerá en un nuevo record cada vez que se reciba un pe-
dido. Al servir un pedido, el record correspondiente se eliminará de la
lista. Para mantener la lista en el orden deseado de entrega, adoptamos
un procedimiento sencillo pero poco eficiente. Tras cada entrega, la lis-
ta de entregas pendientes se reordenará completamente por orden de

proximidad al camión. Tras la reordenación, tomaremos como próximo
destino del camión el primer record de la lista. No haremos más cálcu-
los hasta que no se produzca la próxima entrega.
Este modelo se puede programar completamente en Pspal, usando
listas, ya que no necesitamos la manipulación dinámica de funciones,
que es la única característica de LISP fuera del alcance de Pspal. Pero
no lo haremos así para ver cómo la intercomunicación potencia ambos
mundos. Las funciones básicas estarán escritas en LISP. Pero para evi-
tar manipulaciones numéricas en LISP, usaremos Pspal en la evaluación
de las distancias.
Cuadro 8
Modelo «Reparto de pan». Secciones Constants y Variables
Constants CamionVars.pss
cod = 1;
coordenadas = 2;
HoraPedido = 3;
distancia = 4;
{--Atributos--}
UnPedido = 4;
{--switches--}
camión = 1;
Labels
Otro;
Variables
LispPedidos; {--La estructura maestra de datos --}
Posx; Posy;
LispPedir;
LispServir;
Velocidad;
El primer cuadro muestra las constantes y variables usadas en el

modelo. Posx y Posy almacenan las coordenadas del camión tras cada
entrega. Suponemos que el camión se traslada a velocidad constante,
dada por la variable Velocidad, de manera que el tiempo de traslado será
la distancia dividida por esta velocidad.
Cuadro 9
Modelo «Reparto de pan». Funciones Lisp
CamionLispFuns.pss
LispPedir = LEvalf(“ (defun LlegadaPedidos(lista)
(let ((n (pspsNum 'codigo)))
(let ((aux
(list n
(list (pspsNum 'xcliente)
(pspsNum 'ycliente))
(pspsNum 'Horacliente)
n)))
(cons aux lista)))) ”),
LispServir = LEvalf(“ (defun ServicioPedidos(rec lista)
(delAssoc (car rec) lista)) ”)
El manejo de la base de datos la haremos en LISP. El segundo cua-

dro muestra las funciones Lisp que se encargan de poner al día la base
de datos, a la llegada de un pedido y cuando este ya ha sido servido. La
función ServicioPedidos, almacenada en la variable Pspal Lisp-
Servir, no tiene secreto ya que se limita a eliminar el record de la
alista usando la función DelAssoc. La función llegadapedidos, en
la variable LispPedir, hace un uso importante de la función psps-
Num, para manejar las funciones Pspal de la tabla.
código: función que devuelve el valor de TrCount, que usamos

como código del cliente.
xCliente: función que devuelve un átomo numérico, resultado

de muestrear con una distribución uniforme la coordenada x del
rectángulo de operación.
ycliente hace una operación parecida, pero con la coordena-
da y.
HoraCliente función que devuelve un átomo numérico que
contiene la hora de llegada del pedido, es decir el valor de Cl en
el momento de la llamada.
El primer argumento de pspsNum es siempre el nombre de la fun-

ción. Para evitar que se evalúe, hay que aplicarle la función quote. Los
demás argumentos a pspsNum se suministran de la forma adecuada.
El siguiente cuadro presenta la sección System del modelo. Hay dos
procesos diferentes, que se coordinan por medio de semáforos. Un pro-
ceso es el de recepción de pedidos. El segundo proceso es el trabajo del
camión. Se utiliza un semáforo (switch) para asegurar que el camión se
queda parado cuando no hay pedidos. La transacción que representa al
camión se genera en el segundo bloque GENERATE, y antes de atacar
el bloque GATE mira si quedan pedidos. En caso de que no los haya,
debe poner el switch en Off para impedir el paso por el GATE. La lle-
gada de un pedido activa el switch, y la transacción que representa el
camión puede pasar por el bloque GATE y proseguir con la entrega del
pedido. El resto del modelo es sencillo y el lector (a estas alturas) lo en-
tenderá probablemente con facilidad.
Cuadro 10
Modelo «Reparto de pan». Secciones Data y System
{$camionvars.pss} Camion.pss
Macros
{$Camionfuns.pss}
Data
REPORT -1;
VARS velocidad = 2;
INITIAL begin {$CamionLispFuns.pss} end;
INITIAL Fdrawcont(1,GSERUNORDER,1);
System
{--Llegada de pedidos--}
GENERATE 1,On;
COMPUTE LispPedidos = LApply(LispPedir,Llist(lispPedidos),nil);
SWITCH camion,On;
TERMINATE 1;
{--entregas. Generación del camión y uso de éste--}

GENERATE 0,1;
COMPUTE begin
posx = 0,
posy = 0
end;
{--Ciclo de las entregas--}

Otro:COMPUTE if(Lnullp(LispPedidos) then FSwitch(1,Off);
GATE camión; {--No avanza si no hay pedidos--}
COMPUTE begin {--Calcular las distancias, ordenar y elegir el prime-
ro--}
CalculoDistancia,
at[UnPedido] = Primero(lispPedidos)
end;
WAITFOR Dist(at[UnPedido])/velocidad; {--Transporte--}
COMPUTE begin {--Reubicar el camión y eliminar el pedido--}
posx = Lax(at[UnPedido]),
posy = Lay(at[UnPedido]),
FdrawXY(1,1,posx,posy),
LispPedidos = LApply(LispServir,Llist(at[UnPedido],lispPedidos),nil),
end;
TABULATE 1,cl- Lah(at[UnPedido]), Otro;
endsystem
Finalmente, y para completar el modelo, proporcionamos las fun-

ciones Pspal necesarias.
Cuadro 11
Modelo «Reparto de pan». Funciones
CamionFuns.pss
codigo : function() return TrCount;
xcliente: function() return random(0,300)/100;

ycliente: function() return random(0,200)/100;
HoraCliente: function() return cl;
primero : function(x) return Lcar(x);
Dist: function(rec) return LNumVal(Lnth(rec,distancia));
Lax : function(rec) return LNumVal(Lcar(Lcadr(rec)));
Lay : function(rec) return LNumVal(Lcadr(Lcadr(rec)));
LAh: function(rec) return LNumVal(Lnth(rec,horaPedido));
SetDistancia: function(rec,valor)
return LsetNVal(Lnth(rec,distancia),valor);
sqr : function(x) return x*x;

CalculoDistancia: function()
locals aux,primer,d;
begin
aux = LispPedidos,
while not (Lnullp(aux)) do begin
primer = Lcar(aux),
d = sqrt(sqr(lax(primer)-posx)+sqr(lay(primer)-posy)),
SetDistancia(primer,d),
aux = Lcdr(aux)
end,
return LSort(LispPedidos,distancia)
end;
De la simulación del modelo anterior se obtiene el histograma del

tiempo hasta la entrega que muestra la figura 6.
Figura 6
Histograma del tiempo de entrega
La distribución recuerda a una Erlang de grado mayor que uno. La

media es de 0,771, lo que significa que el recorrido medio del camión
es de 1,54 Km. Es posible obtener una distribución teórica para el caso
en que el camión vaya siempre a un punto del área de reparto extraído
al azar. En este caso, la teoría predice un valor de la distancia media de
alrededor de 1,47. El elevado grado de concordancia parece indicar que,
en este caso, la regla de elegir el cliente más cercano a la posición ac-
tual tiene poco efecto. Si se profundiza en el fenómeno, obteniendo da-
tos del número de pedidos pendientes, se ve que en las condiciones de
carga simuladas, la mayor parte del tiempo la lista de pedidos contiene
un solo pedido. Esto explica la falta de efecto de la regla de decisión.
Quedan para el lector cuestiones como las siguientes: ¿Es éste el
caso en otras condiciones de carga? ¿Podemos pensar en otras reglas de
prioridad que den mejores resultados? Y otras muchas...
Bibliografía
NORVIG, Peter y RUSSEL, Stuart J., Artificial Intelligence: A modern

Approach, Prentice Hall, 2002.
Capítulo 19
(*)APLICACIONES DE LA INTELIGENCIA
ARTIFICIAL EN LA SIMULACIÓN
En los dos próximos capítulos vamos a introducir algunas técnicas

de programación que tienen su origen en el campo de la Inteligencia Ar-
tificial 1. Su inclusión dentro de PSPS tiene carácter experimental, e ini-
cialmente fue motivada por el deseo de investigar cuánta potencia aña-
dían estas herramientas. A pesar de que en nuestros experimentos no
han tenido un especial impacto sobre la simulación, constituyen un área
de interés en sí misma, por lo que el lector hará bien en habituarse a las
ideas que aquí se presentan. Esto le permitirá ampliar su dominio de las
técnicas, y entender mejor lo que sucede en otras aplicaciones de Inteli-
gencia Artificial. De la misma forma, su difusión entre los simuladores
puede abrir nuevas vías de experimentación.
No vamos a entrar a fondo en la implantación de las técnicas. Tam-

poco comentaremos todos los paquetes incluidos en PSPS. Nos concen-
traremos en los más relevantes, presentado la técnica por medio de ejem-
plos. Para más detalles, el lector puede consultar la literatura [Norvig], y
el libro de Kreutzer 2 en el que están inspirados los paquetes de PSPS.
1. La técnicas que presentamos son una adaptación al PSPS de los paquetes desa-
rrollados por Kreutzer en su libro Programming For Artificial Intelligence. Allí están
presentadas en Scheme, una variedad de Lisp. Nosotros las hemos traducido y adapta-
do al contexto del PSPS.
2. Adicionalmente encontrará documentación sobre estos paquetes en la página
web del autor del libro referenciado: http://www.cosc.canterbury.ac.nz/~wolfgang/
1. Cómo encontrar una aguja en un pajar: técnicas de búsqueda
Ejemplo 1: En la simulación de un sistema logístico, hay un núme-

ro finito de puntos, o poblaciones, que pueden ser origen o destino de
mercancía. Periódicamente se reciben peticiones de transporte, que im-
plican recoger la mercancía en un punto dado (x y) y transportarla a
otro punto y. Las poblaciones están conectadas por una red de cami-
nos, que supondremos completa, es decir desde cada población se pue-
de llegar a cualquier otra, probablemente pasando por poblaciones in-
termedias. Hay un cierto número de camionetas que se usan para el
transporte, y que en un momento determinado están posicionadas en
ciertas poblaciones. En cada momento una camioneta tiene en curso
una sola orden de entrega. Si al hacer la entrega no ha recibido una
nueva orden de transporte, la camioneta se queda en el lugar de desti-
no, hasta que se le asigne trabajo. Cuando se recibe una orden de
transporte, se ubica la camioneta que puede dar la respuesta dentro de
un tiempo fijado (si existe) y se le asigna el trabajo. La estrategia ac-
tual consiste en determinar para cada camioneta si hay un camino des-
de su posición actual hasta el origen del pedido, y si se puede recorrer
en menos del tiempo requerido (función de la calidad deseada del ser-
vicio), asignando a continuación el pedido a la camioneta más cercana.
La empresa quiere evaluar esta estrategia.
Este caso es superficialmente similar al ejemplo 2 del capítulo ante-
rior, pero ahora, y ésta es una diferencia fundamental, la distancia no se
puede calcular por una fórmula en función de las posiciones, sino que
debe medirse por la suma de las distancias de la trayectoria óptima en-
tre el punto de ubicación del camión y el origen del pedido. En princi-
pio el problema se podría resolver calculando, de una vez por todas, las
distancias entre todas las poblaciones, usando un algoritmo especializa-
do en el cálculo de caminos más cortos en un grafo. Esto requiere pro-
ducir una interface entre el sistema de simulación y una rutina para ese
algoritmo. Veamos cómo puede resolverse el problema sin necesidad de
programar rutinas especiales, utilizando el paquete de búsqueda (Paque-
te Search) de PSPS.
Como en el capítulo anterior, los pedidos se guardarán en una lista,
que aumentará de tamaño a medida que se vayan recibiendo aquéllos.
Las camionetas estarán representadas por transacciones, cuyo proceso
vital representa el proceso de transporte. La red de carreteras se repre-
sentará por una lista LISP, que para cada población indica las poblacio-
nes conectadas directamente con ella y la distancia del tramo directo co-
rrespondiente. El mapa de la red es el de la figura 1.
APLICACIONES DE LA INTELIGENCIA ARTIFICIAL EN LA SIMULACIÓN 501
Figura 1
Red de carreteras
1 C 4
B 2.
4
K
2 D
2 1
2 L
1 1.
A F
H 3
5
5
5
3
G J
La alista que aparece en el cuadro 1 representa el mapa de la red

como una lista.
Cuadro 1
Alista de la red de carreteras
LispRed =LQ(“
( (A (B 2)(G 5))
(B (C 1)(F 2)(A 2))
(C (B 1)(D 24/10)(K 4))
(D (C 24/10)(F 1)(H 15/10)(K 4))

(F (B 2)(D 1)(J 3))
(G (A 5)(H 3))
(H (D 15/10)(G 3)(L 2))
(J (F 5)(K 3))
(K (C 4)(D 4)(L 1)(J 3))
(L (H 2)(K 1)) )”)
Problemas de búsqueda
Toda búsqueda, en este caso la búsqueda de un camino entre dos

puntos, puede conceptualizarse como la exploración de un espacio de
estados. Un estado resume la situación del problema en cada momento,

de manera que para el futuro del problema no importa cómo se ha llega-
do a este estado, sino tan sólo haber llegado a él. En nuestro caso, por el
momento el lector puede pensar que los estados son las poblaciones de
la red. En general el estado puede estar representado por estructuras de
datos complicadas, que resumen toda la información relevante para el
cálculo posterior.
Figura 2
Árbol parcial de exploración
B
K
L
H
D G
C
F
J K
El proceso de solución del problema empieza en un estado, digamos

el estado F, y explora progresivamente las alternativas disponibles para
llegar a K, el estado deseado. En un instante determinado, el proceso
completo puede representarse por un árbol como el de la figura 2. Cada
nudo es un estado del problema que ya han sido explorado, o por lo me-
nos visitado. La tarea del resolvedor del problema es dirigir la explora-
ción, hasta estar seguro que se ha llegado a K en la mejor forma posible,
en nuestro caso habiendo usado un camino de longitud menor que la ne-

cesaria para dar buen servicio.
Dos problemas distintos tienen familias de árboles distintas. Gene-
rar miembros de una familia de árboles, resolver un problema, requiere
el conocimiento de las reglas adecuadas para el cultivo de los árboles de
la familia. Por ello, el paquete de búsqueda permite definir entidades
llamadas problemas de búsqueda.
Un problema de búsqueda tiene los siguientes componentes (las re-
glas de cultivo de un árbol):
1. Un predicado, que es cierto para todos los estados (las hojas) que
constituyen una solución, un resultado aceptable del proceso, y
sólo para ellos.
2. Una función de calidad del estado. Una función numérica que se
puede evaluar en cualquier estado y que se usa para proporcionar
una indicación de la plausibilidad con que el estado puede con-
ducir a la solución deseada.
3. Una función de sucesores (o de creación de ramas), que para
cada uno de los estados posibles, proporciona los estados suce-
sores, estados a los que se puede ir desde el estado en cuestión, y
que por tanto puede usar la búsqueda para continuar explorando.
4. Un predicado de igualdad, que determina cuándo dos estados
son iguales. Esta función de igualdad se usa para no volver a ex-
plorar un estado ya explorado. Por tanto, sirve para detectar si el
proceso está volviendo a visitar un estado ya visitado anterior-
mente.
5. Un estado inicial (raíz) en el que empieza la búsqueda.
6. Una función para escribir el estado, que debe imprimir éste de
forma entendible por el usuario.
7. Varios indicadores, que determinan propiedades de la búsqueda.

En concreto, en la implementación PSPS hay dos indicadores:
TraceFlag, que indica si hay que escribir información de trazado
cada vez que la búsqueda elige un camino o hace backtrack, y
AnnounceFlag, que determina la cantidad de output que se pro-
duce al terminar la búsqueda.
Desde el punto de vista calculístico, el problema de búsqueda se de-
fine en tiempo de ejecución por medio de las funciones Pspal del cua-
dro 2:
Cuadro 2
Definición de un problema de búsqueda
• KMakeSearchProblem(aState,GoalFN,EvalFN,SomeActions,ac-
tionFN): define el estado inicial, la función solución, la función de
evaluación y la función de sucesores. Esta última da los estados que
siguen a cada estado.
• KSetSameState(Problema_de_Busqueda,RepeatedFN): define la fun-
ción de igualdad de estados.
• KSetPrintState(Problema_de_Busqueda,PrintFN): define la función
de impresión del estado.
• KSetTraceFlag(Problema_de_Busqueda): activa el indicador de im-
presión de trazado, TraceFlag, durante la búsqueda.
• KSetAnnounceFlag(Problema_de_Busqueda): activa el indicador de
impresión de resultados, AnnounceFlag, al terminar la búsqueda.
Todas las funciones necesarias para la especificación completa del

problema (componentes 1, 2, 3, 4 y 6 de la lista anterior), se proporcio-
nan en tiempo de ejecución, pasándolas como argumentos de las funcio-
nes Pspal de definición. Esto obliga a usar Lisp para programar las fun-
ciones del problema, ya que en Pspal no se pueden pasar funciones
como argumentos. Por supuesto se pueden programar todas las funcio-
nes del problema en Pspal, y hacer uso de las funciones pasarela del ca-
pítulo anterior.
No basta con especificar el problema para tener una idea clara de
cómo explorar el árbol de soluciones. Hay aún un montón de alternati-
vas que concretar antes de poder lanzarse a la exploración. En concreto,
hay que decidir cómo se organizará el trabajo en la búsqueda. Por ejem-

plo: ¿Cómo se elige el próximo nudo a explorar? ¿A qué profundidad se
explora un subárbol, antes de abandonarlo y empezar desde otra parte?
¿Cuándo se considera que un estado es poco prometedor?
La concreción última de estas cuestiones se proporciona por medio
de la especificación de un método de búsqueda. Los métodos de bús-
queda no dependen del problema concreto a resolver. Son un escalón
superior, y se aplican a todos los tipos de problemas que se puedan de-
finir de la forma enunciada.
En nuestro caso, el paquete proporciona varios métodos de búsque-
da que se muestran en el cuadro 3, y de entre los cuales el usuario debe
elegir el más adecuado a sus necesidades.
Cuadro 3
Métodos de búsqueda disponibles
• KdfSearch(Problema_de_Busqueda,limite): búsqueda en profundidad

(Depth First). En cada estado se elige un próximo estado, y éste se ex-
pande inmediatamente, procediendo de la misma forma hasta que se al-
canza el estado solución o hasta que no se puede seguir, ya sea por haber
agotado las opciones o por haber superado el límite de profundidad dado
por el segundo argumento de la función. En este ultimo caso se vuelve
atrás (backtracking), para elegir otro estado en la última expansión que
tiene alternativas, y se procede de la misma forma. Este tipo de búsque-
da no realiza ningún tipo de ordenación automática de las diferentes al-
ternativas y las toma simplemente en el orden de aparición en el cálculo.
Por tanto su efectividad depende de que el usuario ordene de forma inte-
ligente las opciones de forma que el procedimiento encuentre antes las
más efectivas, y deje para más adelante las demás. Si no se introduce una
limitación a la profundidad, el procedimiento puede continuar para siem-
pre, explorando sucesivas capas del espacio de estados sin encontrar la
solución, aun en el caso de que ésta estuviera accesible en la primera
capa explorada, pero como segunda opción.
• KhillSearch(Problema_de_Busqueda,limite): Un método que hace uso
de una función de evaluación, función que debe suministrar el usuario,
para evaluar los diferentes estados. La función se toma como una estima-
ción de la distancia desde el estado en curso hasta la solución. Se sigue
una trayectoria de estados casi de la misma manera que en la búsqueda
en profundidad, pero restringida a que sucesivos estados produzcan va-
lores crecientes de la función de evaluación. Si en un momento determi-
nado la función de evaluación deja de crecer (disminuye) la trayectoria
en curso se abandona y se retrocede hasta la primera alternativa posible.
Nada garantiza la rapidez de este procedimiento, que depende en gran
manera de lo bien que la función de evaluación aproxime la verdadera
distancia a la solución. Puede suceder que la búsqueda pase de largo una
solución sin darse cuenta. Sin embargo en muchos casos, y para proble-
mas bien estructurados, esta búsqueda puede ser muy eficiente.
• KgradSearch(Problema_de_Busqueda,limite). Esta búsqueda es una va-
riación de la anterior. Realiza una mayor cantidad de cálculos por itera-
ción, a cambio de la posibilidad de llegar más rápidamente a la solución.
Requiere una función de evaluación que guíe el proceso. En cada itera-
ción se enumera la lista de las posibles continuaciones de un estado, y las
continuaciones se ordenan de acuerdo con los valores de la función de
evaluación. Esta ordenación es la base para una búsqueda en profundi-
dad, que expande primero los «mejores» estados. Como todos los méto-
dos que usan funciones de evaluación, la bondad de la búsqueda depen-
de en gran manera de la función suministrada.
Uno de los métodos más usados, aunque no necesariamente el me-

jor, es el método de búsqueda en profundidad (Depth First). Se basa en
la idea intuitiva de que hay que continuar explorando un camino, mien-
tras no se demuestre que está equivocado. El método procede en verti-
cal, tratando de alcanzar una solución lo más rápidamente posible, cada
vez expandiendo el último nudo explorado, y siempre hacia el primero
de sus hijos.
Otros métodos se basan en otras ideas, siempre de amplia generali-
dad y poca especificidad. En general, cuanto menos conocimiento del
problema se tiene, más general debe ser el método, y por tanto más ex-
ploratorio y menos eficiente.
Aplicación al ejemplo
Para no aburrir al lector, nos limitaremos a mostrar cómo el paque-

te de búsqueda (el paquete Search) se aplica a las camionetas, para la
comprobación de las condiciones enunciadas. Por tanto, vamos a calcu-
lar si una camioneta ubicada en una población dada está a una distancia
del origen de la carga menor que la exigida. Usaremos la búsqueda
KgradSearch, porque podemos crear una función de evaluación bastan-
te potente, basándonos en la longitud del camino desde el origen hasta
el estado en curso.
Para poder continuar la exploración desde un estado, debemos tener
a mano la longitud del camino parcial hasta éste. Por tanto, esta infor-
mación deberá formar parte del estado. Por tanto, ahora definiremos un
estado como un par de valores, de la forma:
(Población-actual distancia-mas-corta-desde-el-origen-hasta-aquí)
Por ejemplo el par (C 7) indica que desde el nudo inicial (un dato de
partida) hemos llegado al estado C, por un camino que tiene una longi-
tud de 7 unidades. Con este estado, las funciones necesarias para la de-
finición del problema de búsqueda se dan en el cuadro siguiente:
Cuadro 4
Funciones de un problema de búsqueda
Macros
nuevoEstado: function (x,w)
return LCons(Lcar(w),
Llist(
LDefNAtom(LNumVal(Lcadr(x)) + LNumVal(LCadr(w)))));
nuevosEstados: function(x,w)
begin
if not LNullp(w) then
return
Lcons(nuevoEstado(x,Lcar(w)),nuevosEstados(x,Lcdr(w)))
else return nil
end;
Expansion: function(x)
Locals aux;
begin
aux = Lcdr(Lassoc(Lcar(x),LispRed)),
return nuevosEstados(x,aux)
end;
Destino: function(x)
return (LNumVal(Lcadr(x)) <= 5) and Leqv(Lcar(x),LQ(“K”));
Valor : function(x)
if LnumVal(Lcadr(x)) > 5 then return 0
else return LnumVal(Lcadr(x));
Mismo :function(x,y) return LEqv(Lcar(x),Lcar(y));
{--El estado son pares (Nudo valor)--}
Data
Initial begin
LispPueblos = LQ(“(A B C D F G H J K L)”),
LispRed = LQ(“((A (B 2)(G 5))
(B (C 1)(F 2)(A 2))
(C (B 1)(D 2.4)(K 4))
(D (C 2.4)(F 1)(H 1.5)(K 4))
(F (B 2)(D 1)(J 3))
(G (A 5)(H 3))
(H (D 1.5)(G 3)(L 2))

(J (F 5)(K 3))
(K (C 4)(D 4)(L 1)(J 3))
(L (H 2)(K 1)) )”),
LispFexpansion = LQ(“(lambda(x) (pspsList 'expansion x)) ”),
LispFdestino = LQ(“(lambda(x) (pspsBool 'destino x)) ”),
LispFvalor = LQ(“(lambda(x) (pspsNum 'Valor x)) ”),
LispFmismo = LQ(“(lambda(x y)(pspsBool 'mismo x y)) ”)
end;
Hemos decidido escribir las funciones totalmente en Pspal, para

aprovechar mejor la experiencia que tenemos en este lenguaje. Pero
como el pase de funciones a la función de búsqueda sólo puede hacer-
se en LISP, usamos las funciones pasarela para crear funciones LISP,
que a su vez usan las Pspal definidas. Analicemos brevemente las fun-
ciones del cuadro 4, dejando para el final la función más complicada,
LispExpansion.
LispDestino: es el predicado que permite evaluar si se ha llegado a

una solución del problema. Debe ser una función de una sola variable,
un estado. En nuestro caso la función testa el Car del estado comparán-
dolo con la población destino. En el ejemplo hemos tomado como desti-
no la población K.
LispValor: función que evalúa un estado. Esta función debe crecer

a medida que nos acercamos a la solución, idealmente decreciendo
sólo cuando deba abandonarse la trayectoria en curso. Una función que
cumple estas condiciones es la distancia recorrida, si esta es menor que
el límite de servicio, o 0 si esta distancia es mayor que dicho límite. Ya
que la distancia es el segundo ítem del par que representa un estado, la

función debe retornar el Cadr del estado o cero, en función de que se
cumpla, o no, la condición sobre proximidad al destino.
LispMismo: debe evitarse volver a visitar un estado que tiene la mis-

ma población que el estado en curso. Para ello, la función compara las
poblaciones de los dos estados, devolviendo True si son iguales.
LispExpansion: construye la lista de estados sucesores de un es-

tado dado, x, a partir del estado actual y de la estructura maestra de
datos LispRed. Para ello, y dada la representación de la red adoptada
(ver cuadro 1), la función debe empezar por encontrar, en LispRed, el
conjunto de poblaciones sucesoras de la población en curso. Esto se
logra por medio de la función LAssoc ya que LispRed es una alista.
Para todos los elementos del Cdr del resultado, se construye una lista
de estados, con el nombre de la población y la distancia recorrida. Esta
última es la distancia hasta el estado actual (Cadr del estado actual),
sumada a la longitud de cada tramo, longitud que figura en el par que
describe el tramo. La función NuevoEstado crea un nuevo estado y la
función NuevosEstados construye de forma recursiva la lista de nuevos
estados.
Cuadro 5
Definición de un problema de búsqueda: sección System
System
GENERATE 0,10;
ASSIGN at[4] = LPrint(Lnth(LispPueblos,TrCount));
COMPUTE begin
Lsilence;
LispSearc = KMakeSearchProblem(LList(at[4],LdefNAtom(0)),
LispFdestino,
LispFvalor,nil,
LispFexpansion),
KSetsameState(LispSearc,LispFMismo),
LPrint(KGradSearch(LispSearc,1)),
LGC
end;
TERMINATE 1;
Endsystem;
El cuadro anterior presenta el uso de estas funciones. Para la distan-

cia límite d = 5 y para todas las posibles ubicaciones de la red, se calcu-

la si se puede satisfacer el criterio deseado. El bloque GENERATE ge-
nera 10 transacciones, una para cada una de las posibles poblaciones.
En el bloque ASSIGN se asigna al atributo 4 la población, extraído de
la lista de poblaciones. En el bloque COMPUTE se hace el trabajo duro.
La función LSilence instruye al sistema para que no escriba los resulta-
dos de la recolección de basura. Esta es necesaria, porque el volumen de
consing de las funciones de búsqueda es elevado. A continuación, en la
sentencia Initial de la sección Data se define el problema de búsqueda
(función KmakeSearchProblem), proporcionando el estado inicial y las
funciones necesarias. Si se da una función que genere los estados, el
cuarto argumento de KmakeSearch debe ser Nil. La función de igualdad
se declara de forma independiente, fuera de la definición, por medio de

la función KSetSameState. Finalmente se realiza la búsqueda y se recu-
pera la memoria usada. Recuérdese que todas las variables que empie-
zan por «Lisp» contendrán listas protegidas contra el LGC.
El resultado de estas manipulaciones está en el cuadro 6 adjunto.
Cuadro 6
Resultados de la simulación
A
NIL
B
(3 0 ((OK 5 (K 5)) (OK 1 (C 1)) (OK 0 (B 0))))
C
(2 0 ((OK 4 (K 4)) (OK 0 (C 0))))
D
(4 0 ((OK 4,50 (K 4,50)) (OK 3,50 (L 3,50)) (OK 1,50 (H 1,50)) (OK 0 (D 0))))
F
(3 0 ((OK 5 (K 5)) (OK 1 (D 1)) (OK 0 (F 0))))
G
NIL
H
(3 0 ((OK 3 (K 3)) (OK 2 (L 2)) (OK 0 (H 0))))
J
(2 0 ((OK 3 (K 3)) (OK 0 (J 0))))
K
(1 0 ((OK 0 (K 0))))
L
(2 0 ((OK 1 (K 1)) (OK 0 (L 0))))
Los valores Nil indican situaciones en las que es imposible cumplir

la condición establecida. Las demás situaciones son posibles, y en el
output se muestra la trayectoria (invertida) de estados que logra el obje-
tivo, amén de informaciones adicionales que el lector puede reconocer
fácilmente. Para más detalles, el lector debe consultar la obra de Kreut-
zer ya referenciada.
Búsquedas y satisfacción de restricciones
El problema planteado en la sección anterior es un caso particular de

una clase de problemas que se conocen como problemas de cumplimien-
to de las restricciones (Constraint Satisfaction). En este tipo de proble-
mas se define un cierto número de restricciones que debe cumplir una
solución, y se apela a los procedimientos de búsqueda para hallarla.
Aunque de apariencia inocua, la especialización de las formas de
búsqueda, para adaptarlas al problema y así hacerlas más eficientes, es
una poderosa herramienta en las aplicaciones. El paquete de búsqueda
que incorpora PSPS no es una implantación profesional, pero el lector
puede hacerse una idea de la potencia y dificultades de la herramienta,
practicando en problemas sencillos.
Para animarle planteamos una nueva situación, relacionada también
con transportes.
Ejemplo 2: Supongamos que el camión sólo puede salir una vez
que están preparados todos los pedidos de la ruta. Por tanto, antes de
que el camión salga hay que decidir qué pedidos forman la carga del
camión. Concéntrese el lector en establecer las restricciones que tiene
que cumplir la carga, y a continuación halle una solución posible, usan-
do la búsqueda.
¿Se atreve el lector? ¡Seguro que sí!
2. Objetos y redes semánticas para pescar objetos
La nouvelle vague de la programación lleva ya años empeñada en

hacer de los objetos el centro de su actividad. Pero Pspal no tiene obje-
tos. De acuerdo con esto Pspal no está en la cresta de la ola. ¡Ah! Pero un
nuevo paquete viene a remediar la situación, proporcionando a Pspal es-

tructuras con propiedades parecidas, aunque no idénticas, a los objetos.
Como en la sección anterior empecemos con una importante situación.
Ejemplo 3: una empresa produce una variedad de productos. Cada
uno de ellos consta de varios componentes, éstos a su vez de otros com-
ponentes, y así sucesivamente hasta llegar a las materias primas. Que-
remos simular el centro de producción de una empresa de este tipo. La
simulación de la producción debe tener en cuenta esta interdependen-
cia entre los ítems que forman parte de los productos. Los productos
acabados tienen demanda independiente, generada por el mercado.
Pero sus componentes tienen demanda dependiente, demanda inducida
por el plan de producción de los productos finales. Esta demanda se

puede calcular a partir del plan de producción de los productos finales,
por un proceso de explosión, o descomposición en componentes. La de-
manda de componentes en el tiempo viene determinada por el momen-
to en que se necesitan para ensamblar el producto final. Esta forma
de programar la producción es típico de industrias que usan muchos
componentes, como la industria del automóvil. Típicamente, podemos
esperar la existencia de cientos, quizás miles, de ítems entremezclados,
determinando unos la demanda de los otros. A no ser que nos organice-
mos cuidadosamente, ningún sistema de simulación será capaz de ayu-
darnos a entender lo que sucede.
Como ejemplo concreto, vamos a tomar una fábrica de camisas. En
el CD adjunto se encuentra una base de datos en Access que contiene
los datos de la empresa. La empresa fabrica camisas de tamaño media-
no, grande y pequeño, con tres tipos de cuellos diferentes: normal, con
botones y sport. En la base de datos se encuentran, entre otras informa-
ciones, los componentes necesarios y las rutas que hay que seguir para
producir cada ítem.
Veamos cómo podemos organizar tal simulación.
Una forma es reconocer que hay una serie de objetos cuyas propie-
dades hay que mantener. La clase más obvia de objetos son los diferen-
tes productos. Y cada producto tiene una serie de atributos: su nombre,
el stock en mano, las operaciones a realizar para producirlo, y otras.
También observamos inmediatamente la presencia de otros objetos re-
levantes, como los centros de proceso —lugares donde se realizan las
diferentes operaciones sobre los productos—, las operaciones, y un lar-
go etcétera.
Desde el punto de vista de la implantación, ahora necesitamos me-
canismos para construir y explotar una estructura compleja de objetos.
Y ahora debe aparecer en escena el paquete Frames, para ayudar a orga-
nizar este zoológico, y convertirlo en una estructura manejable.
Frames3
Las frames fueron introducidas por Marvin Minsky, para represen-

tar estructuras de conocimientos en aplicaciones de Inteligencia Artifi-
3. No hay una traducción estándar de los conceptos relacionados con frames, por
lo que hemos preferido dejar los nombres en inglés en vez de intentar una traducción
que probablemente no iría más allá de este libro. De manera que además de aprender de
frames, el lector aprenderá algo de inglés, técnico, pero inglés al fin y al cabo. ¡De nada!
cial. Una frame es una estructura de información que contiene una serie
de slots que a su vez contienen los atributos de la estructura. Cada slot
tiene una serie de facets o subslots. Y las facets pueden ser de varios ti-
pos, cada facet con algún contenido, y todas ellas colaborando a definir
un valor para el slot. Se trata, pues, de una estructura de dos niveles: fra-
mes y slots, en la que las facets son instrumentales para proporcionar un
valor al slot.
La idea original es que una frame representa un concepto, del que
pueden no conocerse todos los detalles, pero del que se conoce su es-
tructura de slots. Toda frame almacena información en sus slots y por
tanto debe accederse a éstos para recuperar las propiedades que la ca-
racterizan.
Figura 3
Esquema de una frame
FRAME
SLOT
FACET
Una frame puede representar un objeto, pero también puede repre-

sentar una clase de objetos. En el lenguaje de objetos, diríamos que una
frame puede representar tanto un ejemplar como una clase de objetos.
Adicionalmente, una frame puede tener relaciones variopintas con otras
frames. Cada relación vendrá representada por un slot, que apuntará a la
(las) frame(s) relacionadas con ella. El slot representa el tipo de rela-
ción, usándose diferentes slots para diferentes relaciones. Un tipo de re-
lación común entre frames es la relación AKO (A Kind Of, o en caste-
llano «un ejemplar de») en la que una frame se declara miembro de una
clase (si representa un ejemplar) o un subconjunto de otra clase (si re-
presenta una clase). La inversa de AKO es la relación HAS-INSTANCE
(«tiene como caso particular»). Otra relación habitual es la relación
IS-PART («es un componente de») por la que una frame (un objeto) se
declara un componente (o parte) de otro objeto (o frame). En este caso
la inversa es HAS-PART («tiene como parte»).
La relación AKO es de gran importancia en las frames, y su slot tie-
ne una estructura diferente de los demás slots, ya que carece de facets 4.
Cuando se accede a una frame para obtener el valor almacenado en
alguno de sus slots, puede suceder que la respuesta no se halle en la pro-
pia frame. Aunque el atributo en cuestión sea propio de la frame, esto
puede suceder porque la frame sea un caso particular de otra clase más
general, y el atributo sea de la clase, y no de la frame. Por ejemplo, si ac-
cedemos a una frame que representa a un individuo concreto, digamos
«Carlos», y queremos obtener su atributo «número de manos», es proba-
ble que éste no se halle almacenado en la frame. El atributo probable-
mente se hallará en alguna de las frames con las que «Carlos» está liga-
da por una relación AKO. Quizá en una frame que representa el concepto
«hombre». Por tanto cuando un valor no se encuentra en la frame direc-
tamente referenciada, el mecanismo de recuperación de información
para las frames debe tener en cuenta la necesidad de ascender en el árbol
de las relaciones AKO. De esta forma, una frame hereda los atributos de
otras frames, de las que es un caso particular. Esta mecanismo es pareci-
do al de la herencia en la programación orientada a objetos.
Típicamente, un slot normal adquiere valor por la presencia de una
facet del tipo VALUE, que contiene el valor del slot, y que puede ser
una estructura de información complicada. También es posible que el
valor del slot por el que estamos interesados nunca haya sido especifi-
cado por una facet de tipo VALUE. En este caso, la frame puede conte-
ner, en este slot, una facet de tipo DEFAULT, un valor que se toma por
defecto si no se ha especificado nunca un valor individual.
Finalmente, el proceso de obtención de datos de una frame puede ser
suficientemente complejo, por ejemplo exigiendo combinaciones de

slots, para que se requiera la ejecución de un fragmento de código. En es-
tos casos se pueden especificar «demonios», o procedimientos que se eje-
cutan en la sombra, sin que el usuario lo sepa, quizá recorriendo toda una
cadena de frames relacionadas por AKO. Estos «demonios» proporcionan
la potencia necesaria para responder a la interrogación. Típicamente
se trata de procedimientos almacenados en facets de tipo IF-NEEDED,
IF-ADDED y IF-REMOVED, que actúan si no hay una facet del tipo VA-
LUE o DEFAULT disponible, o cuando se añade o si se quita algo de un
slot.
4. Véase la estructura de una frame en la siguiente sección.
Ya hemos dicho que AKO proporciona la capacidad de heredar slots

entre frames, capacidad que hace a las frames reminiscentes de los
sistemas de programación orientados a objetos. Pero es importante des-
tacar que en las frames no hay tal cosa como clases. Por tanto no se he-
reda estructura entre clases, sino valores entre objetos. Ésta es una dife-
rencia sutil, pero de gran importancia porque los sistemas de objetos
implementan el primer tipo de herencia, y normalmente no implemen-
tan el segundo.
Un conjunto de frames relacionados entre sí, se llama una red se-
mántica, y constituye un bloque básico de conocimiento estructurado.
Antes de ver cómo sería una red semántica para nuestro problema,
conviene comentar brevemente la forma en que el paquete suministra-
do con PSPS las implanta.
Cómo se implantan las frames en PSPS
En PSPS un conjunto de frames se representa por una alista 5. Cada

record de la alista representa una frame individual. El Car del record es
el nombre de la frame. Y el Cadr del record es una alista de los slots que
la forman. Consistentemente, cada slot es un record con el nombre del
slot como Car. Y a su vez, el Cadr de los slots es una alista de las facets.
Cada facet tiene el tipo de facet como Car y en su Cadr 6 la información
relevante. El cuadro siguiente muestra un ejemplo de red semántica 7
simple compuesta por dos frames.
5. ¡Cómo, si no!
6. Obsérvese la ligera asimetría. En las facets la información no es el Cadr sino el Cdr.
7. Utilizando la forma normal de Backus-Naur para describir una frame, se puede
concretar mejor su estructura. Hela aquí.
Frame ::= (<nombre> (<slot1> ... <slot n>))
AKO-Slot ::= (AKO list-of-linked-frames)
Slot ::= AKO-Slot | Slot-normal
Slot-normal::= (<nombre> (<facet1>...<facet n>))
Facet ::= (tipo <información>)
Tipo ::= VALUE | DEFAULT | IF-NEEDED | IF-ADDED | IF-REMOVED
Cuadro 7
Red semántica simple
((reloj
((AKO (maquina joya))
(peso ((VALUE 60)))
(material ((VALUE acero)))))
(cartera
((AKO (contenedor))
(peso ((VALUE 120)))
(material ((VALUE cuero))))))
En principio, se puede acceder a cualquier facet por una expresión

LISP como la siguiente 8, que devuelve la facet VALUE del slot PESO
de la frame RELOJ de la red semántica X definida en el cuadro 7:
(Assoc 'value (cadr (assoc 'peso (cadr (assoc 'reloj X)))))
Creación de redes semánticas 9
Preparar y manejar una red semántica dando su lista es complejo, y

conduce irremediablemente a errores difíciles de ubicar. El paquete fra-
mes de PSPS se centra en proporcionar herramientas para implantar las
funciones básicas de las frames, en forma cómoda de usar.
En nuestro ejemplo, la base de datos de la fábrica de camisas con-
tiene especificaciones para 54 ítems. Ya que nuestro objetivo es simular
el centro de producción, crearemos una estructura maestra que conten-
drá todos los datos necesarios para ello. Las frames de una estructura
semántica no tienen porqué tener la misma estructura de slots. En este

caso crearemos varios tipos de frames diferentes, enlazados entre sí para
facilitar su manejo.
El primer tipo de frame que vamos a crear es el que representa a un
ítem de la base de datos de materiales. Cada ítem que se maneja en la
8. Pero, todos tranquilos, que no se tiene que hacer así...

9. En lo que sigue es importante distinguir cuándo un argumento es un nombre y
cuándo es un objeto. Si el nombre de la variable contiene la palabra “Nombre” (unNom-
breDeFrame, por ejemplo) se trata de un átomo (o una variable que se evalúa a un áto-
mo) que da el nombre del objeto. Si por el contrario, no se hace así (por ejemplo unaFra-
me, unSlot, etc) entonces es el propio objeto el que debe figurar como argumento.
producción tendrá sus características documentadas en una frame con la

estructura ejemplificada en el cuadro:
Cuadro 8
Estructura de la frame para el ítem IT31
(SLOT DESCRIPCIO (VALUE CUELLO_NORMAL,_TALLA_MEDIA))

(SLOT NÚMERO (VALUE 31))
(SLOT RUTA (VALUE ((P013 1) (P012 1))))
(SLOT CONSUMOS (VALUE ((P013 IT11 1) (P012 IT10 2))))
(SLOT PADRE (VALUE (IT44)))
(SLOT LOTE (VALUE 10))
Los slots de la frame contienen:

1. La descripción del ítem. Un átomo (¡muy largo!), cuyo único
uso es identificar el ítem ante el usuario, de una forma inteligi-
ble.
2. El número del producto, un correlativo interno utilizado para
identificar numéricamente al producto.
3. La ruta de producción. Una lista de pares que representan las
operaciones que hay que realizar sobre el ítem para obtener una
unidad del mismo, y usando los materiales que se especificarán
en el slot consumos. Cada par se refiere a una sola operación y es
de la forma:
(<puesto en el que se realiza la operación ><tiempo que se tarda >)
4. Las necesidades de componentes. Una lista de ternas que da los

componentes necesarios para el proceso, en la forma:

(<puesto de trabajo> <código de componente><cantidad necesaria>)
5. Padre. La lista de los ítems en los que el ítem participa como

componente.
6. Lote. El tamaño del lote de producción, o de compra, asignado al
ítem.
Esta estructura se deberá ahora crear leyendo de la base de datos. El
paquete provee una serie de funciones para la creación de frames. Las
más importantes se listan en el cuadro 9.
Cuadro 9
Funciones Pspal para la creación de frames
• KFrame(Nombre_de_Frame, slot1,...,slotn): una función de un núme-

ro variable de argumentos. Los argumentos deben ser slots. El resul-
tado es una frame con el nombre dado y los slots suministrados como
argumentos.
• KFrameL(Nombre_de_Frame, Lista_de_slots): es básicamente igual
que la anterior, pero sólo con dos argumentos, el segundo de los cua-
les es una lista de slots.
• KSlot(Nombre_de_Slot, Facet1,...,Facetn): es idéntica a KFrame
pero para crear slots.
• KSlotL(Nombre_de_Slot, Lista_de_Facets): idéntica a KFrameL para
los slots.
• KAKO(Lista_de_Frames): crea una lista AKO que contiene la lista
de frames dada como argumento.
• KValue, KIfNeeded, KIfAdded, KIfRemoved, KDefault(valor): todas
con un único argumento, crean una facet del tipo indicado, con el con-
tenido dado por su argumento, ya sea un valor o una función.
• KMakeFN(Lista_de_Frames): crea una red semántica completa.
• KMergeFN(Red1, Red2): mezcla la red2 en la red1. El resultado com-
bina en red1 las frames slots y values de ambas redes. Si un elemento
está en ambas redes, se mezclan los subelementos, y si no está, se
añade al resultado. Esta función es muy útil para especificar una red
usando técnicas diferentes, por ejemplo leyendo una parte de la base
de datos y entrando otra por datos. En nuestro ejemplo, una parte de
la red semántica se lee de la base de datos, por medio de las funciones
del cuadro 9. Pero otra parte se entra por datos.
Estas funciones se usan para programar las funciones del usuario,

que son las que en definitiva crean la estructura maestra de la red se-
mántica, y de las que aparece una muestra en el cuadro 10.
Cuadro 10
Selección de funciones. Ficheros FuncionesLisp.pss y
FuncionesLecturaBd.pss
{--Convertir una lista en una frame usando la estructura de un fichero--}
CreateEmptyFrame:function(anFN,nom)
return KAddFrame(anFN,KFrameL(nom,nil));
{----Leer y crear la estructura maestra de productos---}
LeerEstructuraMaestra: function (filename)

Locals aux,fich,fcodigo,xx,k;
begin
fich = LOpenrDB(MakeStr(“%s%s”,directorio,filename)),
while not Leofdb(fich) do begin
aux = LGetRecord(fich),
if aux # nil then begin
LispDataBase = CreateEmptyFrame(LispDatabase,Lcar(aux)),
end,
end,
aux = LClosedb(fich),
LGC,
return LispDataBase
end;
LeerProductos:function(filename)
Locals aux,fich,nom,desc,k;
begin
k = 0,
fich = LOpenrDB(MakeStr(“%s%s”,directorio,filename)),
while not Leofdb(fich) do begin
aux = LGetRecord(fich),
if aux # nil then begin

k = k + 1,
nom = LGetFieldByName(fich,Lispcodigo),
desc = LGetFieldByName(fich,LispDesc) ,
LispDataBase = KAddAVAlue(LispDataBase,nom,LispDesc,desc),
LispDataBase =
KAddAValue(LispDataBase,nom,LispNumero,LdefNAtom(k))
end,
end,
aux = LClosedb(fich),
LGC,
return k
end;
Todas las funciones Pspal de creación de frames tienen funciones

equivalentes en LISP, que son mucho más adecuadas para crear frames
por datos. Por ejemplo, he aquí un fragmento de una subred semántica
creada por datos, que añade estructura a la existente en la base de datos
del ejemplo.
Cuadro 11
Fragmento de la red semántica creada por datos.
Fichero AdicionesDb.pss
LE(“(MakeFN
(FRAME 'Fabricado
(SLOT 'proveedor (DEFAULT 'Fabricado!))
(SLOT 'PlazoEntrega (DEFAULT 1)))
(FRAME 'MateriaPrima
(SLOT 'Proveedor (DEFAULT 'NotieneFijo))
(SLOT 'PLazoEntrega (DEFAULT 3)))
(FRAME 'camisa (AKO 'Fabricado)
(SLOT 'Componentes (DEFAULT '
'(Mangas Bolsillo Delanteros Punyos Espalda Cuello)))
(SLOT 'Talla (DEFAULT 'media))
(SLOT 'Mangas (DEFAULT '(derecha Izquierda)))
(SLOT 'Bolsillo(DEFAULT 'normal))
(SLOT 'Delanteros (DEFAULT '(derecha Izquierda)))
(SLOT 'Punyos (DEFAULT '(derecha Izquierda)))
(SLOT 'Espalda (DEFAULT 'normal))
(SLOT 'Cuello (DEFAULT 'normal)))
(FRAME 'camisaMedia (AKO 'camisa))

(FRAME 'camisaGrande (AKO 'camisa)
(SLOT 'Talla (VALUE 'Grande)))
(FRAME 'camisaPequenya (AKO 'camisa)
(SLOT 'Talla (VALUE 'Pequenya))))...”)),
Las funciones de Lisp: FRAME, SLOT, VALUE, DEFAULT, AKO,

IF-NEEDED, IF-ADDED e IF-REMOVED tienen un número de argu-
mentos variable, y hacen lo que sus nombres anuncian. Por supuesto, una
estructura definida por datos parte de una string, que debe evaluarse para
convertirla en una frame. La forma más ortodoxa de hacerlo es usar la
función LQ para entrar la string con la definición, y evaluarla a continua-

ción con la función LEval. Ambas operaciones se combinan en una sola,
usando la función LE(string_a_evaluar) como en el cuadro anterior.
En nuestro ejemplo, la red semántica del cuadro 11 se mezcla con la
obtenida de la base de datos, por medio de la función KMergeFNs,
creando así la estructura completa.
Las frames también se pueden crear sobre la marcha, por programa.
Las funciones del cuadro 12 permiten la creación dinámica de redes se-
mánticas, por medio de la adición de componentes.
Cuadro 12
Funciones de creación dinámica
• KAddFrame(unaRed, unaFrame): añade la frame dada en el segundo

argumento a la red indicada en el primer argumento.
• KAddSlot(unaRed, Nombre_de_Frame,unSlot): añade el slot dado en
el segundo argumento a la frame indicada en el primer argumento.
• KAddFacet(unaRed, Nombre_de_Frame, nombre_de_Slot,unaFa-
cet): aquí hay una ligera asimetría, ya que la función añade la facet
dada en el tercer argumento, al slot segundo argumento de la frame
indicada en el primer argumento. Esta función permite añadir facets
generales, no solamente facets de tipo VALUE, a cualquier frame.
• KsetAValue(unaRed, unNombre_de_frame, unNombre_de_slot, valor).
Esta función puede realizar todo el proceso de creación de frames. La
función realiza varias operaciones. En primer lugar, si alguno de los
elementos, frame, slot o facet de tipo VALUE no existen en la red dada
por la variable, los crea. En segundo lugar, asigna el valor a la facet
VALUE del slot, de la frame y en la red semántica que se le indican.
El acceso a la red semántica
En la sección anterior hemos explicado la forma de construir redes

semánticas. En esta sección vamos a ver cómo se puede acceder a una
red semántica, tanto para leer como para cambiar datos.
La principal función que se usa para acceder a una red es la función
KgetAValue, colega de KaddAValue, con estructura:
KGetAValue(unaRed, nombre_de_Frame, nombre_de_slot)
La función se encarga de obtener el valor en la facet Value del slot

nombrado, frame nombrada y red especificada en el argumento nom-
bre_red. Con esta función puede accederse a cualquier valor de una red
semántica. La lógica completa de acceso a valores que utiliza KGetA-
Value, se resume en el cuadro adjunto.
Cuadro 13
Lógica de acceso a valores
• Las función KGetAValue busca en la frame indicada el valor

del slot deseado.
• Si no lo encuentra, sigue la cadena de frames AKO, buscan-
do una frame ascendiente de la dada que tenga un valor en el
slot. Si lo encuentra lo devuelve.
• Si no, busca otra vez, desde el principio, un slot con el nom-
bre dado y con un valor DEFAULT.
• Si no encuentra nada, procede a ejecutar las funciones
IF-NEEDED que encuentra en el slot y en la cadena AKO,
hasta que alguna de ellas devuelve un resultado distinto de
Nil. La función devuelve entonces este resultado.
• Si con todo este proceso no encuentra el valor que busca, de-
vuelve el átomo «NOT-KNOWN»
Un ejemplo del uso de esta función se produce en el acceso a la red

semántica de la fábrica de camisas, por los bloques de la simulación.
Las dos funciones del usuario en el cuadro 14 muestran el mecanismo

de acceso. LispRuta y LispConsumos son variables que contienen
el nombre de los slots a los que se quiere acceder, en el ejemplo 'RUTA
y 'CONSUMOS, respectivamente. La función devuelve la lista comple-
ta de valores que se encuentran en la facet VALUE. Esta lista debe in-
vertirse, con Lreverse, para obtener el resultado en la forma deseada.
Como siempre, el estilo LISP trata de esconder el uso de las funciones
del sistema dentro de funciones de acceso intermedias creadas por el
usuario, en nuestro caso de las funciones datosRuta y datosCon-
sumos.
Cuadro 14
Dos funciones de acceso a la red semántica. Fichero Accesos.pss
{--obtiene la ruta de un producto. En la BD está al revés--}

datosRuta:function(producto)
Locals aux;
begin
aux = KGetAValue(LispDataBase,producto,Lispruta),
if aux # nil then return LReverse(aux)
else return nil
end;
{--Obtiene la lista de consumos de materiales de un producto--}

datosConsumos:function(producto)
Locals aux;
begin
aux = KGetAValue(LispDataBase,producto,LispConsumos),
if aux # nil then return LReverse (aux)
else return nil
end;
El uso de KGetAValue, con su lógica elaborada, va mucho más allá

del ejemplo. Como el lector recordará, tras haber leído de la base de da-
tos la red semántica básica, en el cuadro 11 añadíamos una serie de re-
laciones entre frames por medio de cadenas AKO.
Por ejemplo, hemos declarado que «camisa» es un AKO «fabrica-
do», y en el slot «fabricado» hemos especificado un plazo de entrega
DEFAULT de una unidad de tiempo. De esta forma si se pregunta, con
KgetAValue, por el plazo de entrega de IT02, que es un AKO «Camisa-

Grande», la función recorrerá la cadena AKO hacia arriba hasta llegar a
la frame «Fabricado», que le dará el valor por default del plazo de en-
trega de cualquier fabricado. Esto sucede siempre que no se haya en-
contrado en una frame de nivel inferior un valor para este plazo, es de-
cir cuando ni IT02, ni CamisaGrande, ni Camisa tienen un VALUE o un
DEFAULT para este slot.
Además de KGetAValue, hay otras funciones de acceso que permi-
ten obtener elementos completos de la red semántica. Ver el cuadro 15.
Cuadro 15
Funciones de acceso y cirugía
Funciones de acceso
• Las funciones más generales son: KGetFrame(unaRed,unNombreDe-

Frame), KGetSlot(unaFrame, unNombreDeSlot), KGetFacet(unSlot,
unTipoDeFacet) que obtienen su segundo argumento buscando den-
tro del primero.
• KGetValue(unSlot) y KGetNumValue(unSlot) son casos especiales de
KGetFacet para acceder a facets de tipo VALUE y VALUE de tipo
numérico, respectivamente.
Estas funciones no llevan a cabo la lógica general de acceso descri-
ta para KGetAValue, y se limitan a realizar la operación obvia de primer
nivel, sin recorrer las cadenas AKO, ni tener en cuenta las demás alter-
nativas. Adicionalmente, KGetNumValue devuelve un número PSPS, no
un átomo numérico LISP.
Funciones de cirugía
• KSetSlot(unaFrame,unSlot): en la frame dada, reemplaza el slot con
el mismo nombre que el del segundo argumento, por este segundo ar-
gumento.
• KSetFacet(unSlot,unaFacet): similar a KsetSlot pero con slots y fa-
cets.
• KSetValue(unSlot,unValor): reemplaza el contenido de la facet VA-
LUE del slot por el valor dado.
• KSetNumValue(unSlot,unNumero): como la función anterior pero
ahora el valor que se especifica debe ser un número PSPS, que la pro-
pia función convierte en un átomo LISP.
La simulación
Una vez comprendidos los mecanismos de acceso a la red semánti-

ca, comentemos ahora brevemente la estructura de la simulación para la
fábrica de camisas 10. Hemos estructurado la simulación de forma que
permita testar una propuesta de plan de producción, obtenido probable-
mente de una aplicación tipo MRP. Las aplicaciones MRP, que explo-
sionan la demanda final en sus componentes, determinando su deman-
10. Que se puede encontrar completa en el CD adjunto, en la carpeta Ejemplo 3 de

este capítulo.
da inducida, suelen obtener como resultado final un plan de producción,

teóricamente factible de acuerdo con las capacidades de producción de-
claradas. Pero el sistema no suele tener en cuenta la congestión produ-
cida en la fábrica por la naturaleza aleatoria de algunas cantidades. El
uso posterior de la simulación debe poner de manifiesto las esperas que
se producen y si, como resultado, el plazo de entrega de la factoría está
dentro del admisible para la calidad deseada del servicio.
Para testar el plan de producción, nuestro modelo no genera eventos
internamente sino que los obtiene del plan proporcionado por el usua-
rio. En concreto, suponemos que se proporciona una base de datos de
órdenes de producción (en la implantación que presentamos, esta base
de datos es otra red semántica). De esta estructura se irán extrayendo
acontecimientos (lanzamientos de ordenes) por medio de la función
TproximaOrden. Para cada orden de fabricación se genera una tran-
sacción, cuyos atributos reflejan las propiedades de la orden.
El núcleo del modelo es el bloque MGET, que obtiene simultánea-
mente los componentes necesarios para producir la totalidad de la or-
den. Por un tecnicismo 11 el bloque debe obtener los datos sobre compo-
nentes de los atributos de la transacción. Esto obliga a un (feo) proceso
de carga de estos atributos, para dejarlos en la forma necesaria para el
uso de MGET. De esto se encarga la función cargaNecesidades-
EnTransaccion. Los stocks se manejan como contenidos de proce-
sadores. La entrada de una orden en el stock es un ENTER por el tama-
ño de la misma. De la misma manera, una salida es un LEAVE del
procesador que representa el stock. Las máquinas están representadas
por procesadores, con números correlativos a los usados para los stocks.
En este caso, ya que hay 54 ítems, las maquinas empiezan en el proce-
sador 55. El resto de la simulación es muy parecida a los ejemplos sen-
cillos presentados en el capítulo 5. El cuadro 16 muestra la sección Sys-
tem de la simulación.
Cuadro 16
Modelo «Fábrica de camisas». Sección System
System
GENERATE TProximaOrden,numOrdenes;
ASSIGN begin {--Carga listas en los atributos de la transacción--}
at[atNombre] = NombreProductoDeLaOrden,
11. Porque lo diseñamos así... ¡qué le vamos a hacer, pasa en las mejores familias!
at[atProducto] = NumeroDeProducto(at[atNombre]),
at[atRuta] = datosRuta(at[atNombre]),
at[atConsumo] = datosConsumos(at[atNombre]),
at[atLote] = LoteDelProducto(at[atNombre]),
at[atDemanda] = DemandaDeLaOrden,
end;
ciclo:
ASSIGN begin {--direcciona uno a uno los elementos de la ruta--}
at[atOpera] = Lcar(at[atRuta]),
at[atRuta] = Lcdr(at[atRuta]),
cargaNecesidadesEnTransaccion(GetConsumosPuesto(atOpera,atConsumo))
end;
{--El proceso central al modelo lo realiza este bloque MGET que obtiene
del stock los materiales necesarios para procesar una transacción--}
MGET [1:at[atItemNeces]:&at[atItemNeces+1]],
[1:at[atItemNeces]:&at[atCanNeces+1]];
{-- Y ahora realiza la operación de ensamblado--}
QUEUE FacDelPuesto(Lcar(at[atOpera]));
COMPUTE at[atGantt] = cl;
ADVANCE TiempoProceso(at[atOpera]);
LEAVE FacDelPuesto(Lcar(at[atOpera]));
COMPUTE Bar(1,NumeroDePuesto(Lcar(at[atOpera])),at[atGantt],
cl,colorNum(at[atProducto]));
{--Seguir la ruta de proceso hasta completarlo--}
TRANSFER Cond(at[atRuta]# nil,ciclo,cb+1);
{--y se entran en el almacén--}
ENTER at[atProducto],at[atDemanda];
TERMINATE 1;
endsystem;
Aquí también hemos indicado en cursiva aquellos bloques de la si-

mulación que no son críticos para la misma, y que sólo la instrumentan.
En este caso se trata de código para realizar un diagrama de Gantt de la
producción real, que se puede comparar por el obtenido con el MRP y
así constatar las diferencias que introduce la consideración explicita de
la realidad productiva.
La simulación que hemos preparado para la fábrica de camisas se li-
mita a usar las frames como deposito de datos y no aprovecha toda su
potencia. Por ejemplo, no explotamos las capacidades que proporcionan
las cadenas de AKOS.
Ésta es una característica típica de las aplicaciones de las redes se-

mánticas. La funcionalidad de orden superior suele ir apareciendo a me-
dida que se usa el sistema y se descubren nuevas formas de explotación.
Es muy difícil especificar inicialmente la totalidad de las relaciones que
deben integrar la red. El conjunto suele ir creciendo por adiciones suce-
sivas. Una red semántica más completa para nuestro ejemplo sería pro-
bablemente un objeto complicado. Tal como está en la simulación que
acompaña al texto, la red contiene del orden de un centenar de frames,
suficientemente complicado para no poderla listar aquí. La única forma
de dominar el uso de este tipo de bichos es el estudio detallado de los
programas, y de la base de datos que los acompaña.
Un tema de gran interés práctico, que debería potenciarse por el uso
avanzado de las frames, es la «explicación» de la simulación. En una si-
mulación complicada, como ésta, la red semántica debería ser capaz de
contestar preguntas sobre «por qué» suceden ciertas cosas. Por ejemplo,
y quizás lo más obvio, el slot PlazoEntrega en la frame Fabrica-
dos podría dotarse de una función IF-NEEDED, que recorriera la ruta
de fabricación de un producto dado, sumando sus tiempos de espera
ante las máquinas. Con este dato en la mano, se puede estimar el plazo
de entrega, añadiéndole una estimación del tiempo de rotura 12 (de espe-
ra a la obtención de materiales). Esto permitiría explicar por qué las en-
tregas llegan tarde.
Quede como proyecto (complicado) para el lector convertir esta si-
mulación en una «simulación que se explique».
Bibliografía
KREUTZER, W. y MCKENZIE, B., Programming for Artificial Intelligen-

ce: Methods, Tools and Applications, Addison Wesley, 1991.
NORVIG, Peter y RUSSEL, Stuart J., Artificial Intelligence: A modern Ap-

proach, Prentice Hall, 2002.
ZIPKIN, Paul, Foundations of inventory management, McGraw-Hill,
2000.
12. Que puede hacerse usando algun procedimiento sencillo [Zipkin].
Capítulo 20
(*)SIMULACIONES CON CIERTA HABILIDAD
DEDUCTIVA (¿EXPERTAS?)
El último paquete que vamos a presentar merece capítulo aparte.

Tiene que ver con lo que se conoce en la jerga como sistemas expertos.
Los sistemas expertos tienen ya una larga historia, que se remonta a los
años 60 con el desarrollo del sistema Mycin, especializado en la identi-
ficación de enfermedades y posteriormente en la recomendación de su
tratamiento, por un grupo de investigadores de la Universidad de Stan-
ford con Edward Feigenbaum al frente.
Desde entonces, los sistemas expertos han sido una de las áreas de
trabajo más importantes, en los intentos de desarrollar sistemas que
complementen, o sustituyan, las actividades mentales superiores de las
personas. En la literatura seudo-científica se citan a menudo los éxitos

de este campo, pero la verdad es que los éxitos han sido pocos y espar-
cidos. Algunos fans dicen que esto es sólo apariencia. Segun ellos, mu-
chos sistemas de esta índole son propietarios, es decir, están desarrolla-
dos por empresas privadas que quieren mantener su uso en estricta
confidencialidad. En los muchos años que llevamos en la profesión, he-
mos encontrado muy pocos sistemas realistas de este tipo, y menos aún,
que estén realmente en uso. Ciertamente se han hecho muchos intentos
por parte de técnicos bien intencionados, pero con dudosos resultados.
Pero la idea sigue vigente y es muy atractiva. Tiene un nombre pe-
riodístico, imita la forma de actuar de las personas y es entendible has-
ta para los menos iniciados. Cada día hay probablemente cientos de per-
sonas que inician el desarrollo de un sistema experto, en la esperanza de

que, éste sí, sea verdaderamente útil.
1. Sistemas expertos
Un sistema experto se basa en la idea de representar el conocimien-

to en el ordenador por medio de reglas, o producciones 1. Una regla es
simplemente una sentencia compuesta de dos partes. La parte IF, o de
las condiciones, enumera una serie de sentencias que representan las
premisas de la situación. La parte THEN de la sentencia, o parte de las
conclusiones o consecuencias, enumera las sentencias que se siguen de
la validez de las condiciones. La regla puede ser descriptiva, algo que
sucederá así porque es una ley de la naturaleza, o normativa, algo que
debe suceder así porque alguien ha decidido que ese es el caso.
Veamos en el cuadro adjunto algunos ejemplos de ambos tipos de
reglas:
Cuadro 1
Tipos de reglas
REGLAS DESCRIPTIVAS
IF A es padre de B y B es padre de C THEN A es abuelo de C
IF compro X y pago al contado THEN disminuye la caja en X y aumenta
el activo en X
IF f es diferenciable y x es un óptimo THEN la derivada de f en x es cero
REGLAS NORMATIVAS
IF Cliente de pedido A es más importante que cliente pedido B THEN ser-
vir primero A
IF más de 3.000 km. desde el cambio de aceite THEN cambiar el aceite

IF aceite sucio THEN cambiar el aceite
IF coche no arranca THEN comprobar chispa y comprobar gasolina
Supongamos que podemos describir todas las reglas que deberían

aplicarse a una situación de acción determinada. Supongamos que pro-
ponemos un método para testar cuáles de las premisas se cumplen. Y si-
1. Producciones (productions) es el nombre específico que se da a las reglas de re-

escritura usadas en el análisis sintáctico del lenguaje, desde su inicio a manos de Noam
Chomsky.
SIMULACIONES CON CIERTA HABILIDAD DEDUCTIVA (¿EXPERTAS?) 531
gamos suponiendo que podemos escribir un programa que, utilizando

las ideas anteriores sobre la búsqueda, encadene reglas, unas detrás de
otras hasta alcanzar algún tipo de conclusión. Tomar decisiones lógicas
en este caso, sería simplemente enumerar las premisas válidas en una
determinada situación y poner en marcha el programa, que deduciría
conclusiones de las premisas. Estas conclusiones, a su vez, serían nue-
vas premisas, y así en cascada hasta encontrar un resultado satisfacto-
rio. De hecho, todo se basaría en la transitividad, una meta regla básica
que dice: Si A implica B y B implica C THEN A implica C.
La situación se puede caracterizar como el intento de alcanzar un
objetivo, parcialmente especificado, razonando a partir de unas premi-
sas. Y hay dos formas básicas de llevar a cabo el proceso. La primera
parte de las premisas y trata de obtener todas las conclusiones posibles,
testando en cada iteración si el resultado deseado se halla entre las con-
clusiones producidas. Este proceso se llama de encadenamiento directo
(Forward Chaining). Por otra parte, podemos partir del resultado desea-
do y tratar de deducir qué premisas deben ser válidas para que el re-
sultado se siga de ellas. Éste es el método de encadenamiento retrógra-
do (Backward Chaining).
Normalmente un sistema experto implementa los siguientes ele-
mentos:
1. Una base de datos de reglas, con todas las reglas aplicables.
2. Una base de datos de situación, que contiene todas las sentencias
(condiciones) que son ciertas en cada momento de la deducción.
3. Un mecanismo de encadenado, directo o retrogrado, de las re-
glas. A veces este mecanismo es conocido con el bonito nombre
de mecanismo de inferencia.
4. Criterios para la aplicación de la inferencia, o heurísticas apro-
piadas para la aplicación de las reglas, que ayuden a obtener el

resultado en el menor tiempo posible.
5. Un mecanismo para detectar cuándo se ha alcanzado una condi-
ción satisfactoria que resuelve la situación.
Cualquier procedimiento de búsqueda puede funcionar como meca-
nismo de inferencia. Cualquier proceso de prueba y error, en el que las
reglas disponibles se aplican en algún orden, hasta que no hay posibili-
dad de obtener nuevas conclusiones, o se ha alcanzado la solución, pue-
de funcionar. La única dificultad es que se trata de un procedimiento
con tiempo de ejecucion exponencial, con lo que el tiempo de proceso
de un problema real puede ser repugnantemente grande. Aunque en la
práctica se utilizan mecanismos de inferencia más sofisticados, todos
tienen un componente de prueba y error. Esto significa que, a pesar de

la sofisticación del proceso y del intento de retrasar la exponencialidad,
eventualmente ésta se producirá, por lo que tarde o temprano (como to-
dos los sistemas de búsqueda) el tiempo de deducción será demasiado
grande para que el sistema sea realmente útil.
Un casus belli aparece frecuentemente en forma de una inocente
cuestión: ¿Por qué emplear un sistema de reglas, con su ineficiente me-
canismo de inferencia general, si las condiciones pueden incorporarse a
un programa tradicional, que probablemente será mucho más eficiente?
Al fin y al cabo, el sistema de inferencia debe ser capaz de tratar cual-
quier combinación de reglas y por tanto sacrifica la adaptación al pro-
blema por la generalidad.
Una primera respuesta que dan los expertos (y bastante obvia) es la
flexibilidad. Es más fácil cambiar una regla que un programa. Aunque
esto no es del todo cierto, por lo menos es aceptable. Hay una segunda
razón, más convincente pero menos evidente, que es muy difícil de in-
tuir a partir de ejemplos sencillos, de libro. Cuando el número de reglas
es muy elevado 2, la cantidad de implicaciones entre ellas es tan grande
que es imposible anticiparlas todas en la construcción de un programa.
Cuando esto sucede es probablemente mejor confiar en un sistema de
deducción. Pero esto sólo tiene sentido para grandes problemas, lo que
impide presentarlos en un libro como éste, por lo que el lector debe de-
cidir si hace, o no, un acto de fe en nuestras afirmaciones.
Para ayudarle y darle una visión de la utilidad de estas herramien-
tas, procederemos, como siempre, presentado el esqueleto de una apli-
cación real.
2. Reparaciones y agentes
Ejemplo 1: Vamos a diseñar una simulación para estudiar el fun-

cionamiento de un sistema de detección y corrección de averías. Mu-
chas instalaciones de tecnología avanzada, desde centrales nucleares a
refinerías, poseen este tipo de sistemas, que facilitan la acción en situa-
ciones de emergencia 3. Supongamos que un agente tiene que reparar un
2. Una empresa de Texas, CYC, está tratando desde hace más de 15 años de codi-
ficar en forma de reglas todo el conocimiento necesario para actuar con sentido común,
digamos a nivel de un niño de 5 años. Hasta hace poco tiempo, la base de reglas conte-
nía alrededor de un millón de reglas, y seguía creciendo.
3. Se dice de una central nuclear española que tiene un sistema de detección y tra-
tamiento de escapes radioactivos que propone un plan de trabajo a todo el personal, eva-
determinado sistema, digamos de transmisión de datos, que no funcio-

na. Para simplificar 4, suponemos que el sistema esta formado por com-
ponentes con dos estados posibles (y solo dos): funcionando (TRUE) y
fallado (FALSE). La única acción correctiva que el agente puede tomar
es la sustitución de un componente por otro, tantos componentes como
sea necesario. Se sabe con seguridad que el nuevo componente está en
estado TRUE. El agente puede conocer la topología del sistema y el nú-
mero y tipo de los componentes, junto con (probablemente) algunas
propiedades estadísticas de los mismos, como quizás la tasa de fallo.
Pero el estado de cada uno de ellos es desconocido a no ser que se haga
un test del mismo. Suponemos que los tests que el agente puede aplicar
son perfectos, es decir, que indican sin posibilidad de error el verdade-
ro estado del ítem al que se aplican. El agente debe tratar de identificar
el problema y devolver el sistema a su estado de funcionamiento.
La base: Pattern Matching
La capacidad de un motor de inferencia para llevar a cabo su traba-

jo depende de su habilidad para reconocer formas en las sentencias de
sus bases de datos. Tanto las reglas como las condiciones pueden enca-
jar sólo parcialmente y alguien debe reconocer si este encaje parcial es
suficiente para proceder con la deducción (con la aplicación de la re-
gla). Veamos un ejemplo trivial. Supongamos que nuestra base de reglas
contiene la regla:
IF (X es hombre) THEN (X es mortal)
aquí X es una variable que se interpreta como un valor cualquiera. Esta
regla es, de hecho, un esquema de reglas, puesto que especifica una in-
finitud de reglas, una para cada uno de los posibles valores de X.
Ahora supongamos que en la base de condiciones tenemos la condi-

ción:
(Sócrates es hombre)
Obviamente, podemos aplicar la regla y deducir que Sócrates es
mortal, pero para un motor de inferencia el proceso no es trivial. En pri-
lúa el riesgo de catástrofe, avisa a protección civil, y hasta manda automáticamente la

carta de despido al director de la central en cuestión.
4. Muchas de las condiciones que siguen son sólo para simplificar la exposición,
ya que se pueden tratar con facilidad casos mucho más generales y prácticos.
mer lugar, el motor debe comparar las condiciones con el antecedente

de la regla (la parte IF). De esta comparación debe obtener, como con-
clusion, que las dos sentencias encajan si se asigna a la variable X el va-
lor «Sócrates». Por tanto el motor debe llegar a la asociación (X Sócra-
tes). A continuación debe observar el consecuente (la parte THEN) y
sustituir la variable X por su valor. Ahora ya puede afirmar la conclu-
sión (Sócrates es mortal).
Esta tarea de encajar las estructuras de dos sentencias, para indagar
si una sustitución adecuada las hace iguales, se conoce en el gremio
como un proceso de unificación. Para poder llegar a una conclusión,
cuando la regla involucra variables, el motor debe unificar la condición
con el antecedente y realizar las sustituciones pertinentes en el conse-
cuente.
En el paquete Rules, esta unificación se delega en funciones que, a
su vez, forman parte del paquete Pattern-Matching, que no estudiare-
mos con detalle. Pero para poder escribir reglas es necesario conocer su
sintaxis básica, y por ello vamos a estudiar brevemente las ideas básicas
de la unificación.
Una sentencia que puede contener variables y reglas de unificación
se conoce como una estructura, o pattern. Inicia su vida como una
string, que debe ser convertida en una lista LISP, y que por tanto debe
cumplir las condiciones sintácticas de toda representación escrita de una
lista. Una pattern está compuesta de los tipos de elementos que figuran
en el cuadro 2.
Cuadro 2
Elementos de una pattern
1. Identificador. El primer elemento de la lista debe ser el átomo PAT-

TERN. Esto indica que la lista debe ser evaluada como tal.
2. Constantes: ya sean átomos o listas.
3. Símbolos de encaje. Estos símbolos son ? y ?+. ? encaja con cual-
quier ítem que se halle en una posición correspondiente a la suya. El
símbolo ?+ encaja con cualquier número de ítems consecutivos, a
partir del primer símbolo en la posición correspondiente.
4. Encaje con variables. Un encaje con variables se indica por un par,
de la forma '(símbolo-de-encaje X) donde X es un nombre de varia-
ble LISP cualquiera. El símbolo de encaje especifica lo que se asig-
na a la variable, después de realizar el encaje como en 3. Por tanto

son posibles los pares '(? X) y '(?+ X)
5. Test de encaje. Cualquier encaje con variables puede incluir un nú-
mero indefinido de predicados, en forma de funciones lambda de un
solo argumento. El argumento que se les proporcionará en su mo-
mento es la alista de asociaciones (variable valor). El encaje se pro-
ducirá si ninguno de los predicados devuelve el valor Nil.
6. Sustituciones. Un par como '(<-? X) indica que el par completo debe
ser sustituido por el valor de la variable X. Por supuesto, la variable
debe tener asignado un valor como resultado del proceso de un enca-
je con variables. De la misma forma que en el caso 5, las sustitucio-
nes pueden contener un número de predicados que validan la sustitu-
ción, y que se llamarán por el sistema pasándoles como argumento la
lista de asociaciones.
Veamos algunos ejemplos, utilizando la función del paquete pat-

terns KMatch(aPattern,unaTira,lista_de_asociacion_inicial) que, para
abreviar, hemos combinado con la función Lprint, creando la función
Pspal, PrM. ¿Puede el lector descubrir el resultado de los encajes del
cuadro 3 5?
Cuadro 3
Ejemplos de encajes
Macros
PrM:function(x,y,z) return Lprint(KMatch(x,y,z));
System
GENERATE 0,1;
Compute begin
{--Unas funciones para el test del match--}
LE(“(defun isxnumberp(x) (numberp(cadr(car x))))”),
LE(“(defun isxpositivep(x) (>= (cadr(car x)) 0))”),
5. Para el lector que no quiera hacerlo (suponemos que todos los lectores pueden ha-
cerlo) aquí están los resultados por orden: T, NIL, T, T, ((X 123)), ((X 123)
(Y EUROS)), ((X (123 EUROS))), ((X 123)), ((X (123 124))),((X
123)), NIL, ((X 3) (Y 123)), ((X 123)), ((X PESETAS)), ((X EU-
ROS))
{--Ejemplos de diferentes casos--}

PrM(LE(“(PATTERN 'Valor 123 'euros)”),
LQ(“(Valor 123 euros)”),nil),
PrM(LE(“(PATTERN 'Valor 123 'euros)”),
PrM(LE(“(PATTERN 'Valor '? 'euros)”),
PrM(LE(“(PATTERN 'Valor '?+)”),
PrM(LE(“(PATTERN 'Valor '(? x) 'euros)”),
PrM(LE(“(PATTERN 'Valor '(? x) '(? y))”),
PrM(LE(“(PATTERN 'Valor '(?+ x))”),
PrM(LE(“(PATTERN 'Valor '(? x) '(<-? x))”),
LQ(“(Valor 123 123)”),nil),
PrM(LE(“(PATTERN 'Valor '(?+ x) '(<-? x))”),
LQ(“(Valor 123 124 123 124)”),nil),
PrM(LE(“(PATTERN 'Valor '(? x isxnumberp isxpositivep))”),
LQ(“(Valor 123)”),nil),
PrM(LE(“(PATTERN 'Valor '(? x isxnumberp isxpositivep))”),
LQ(“(Valor -123)”),nil),
PrM(LE(“(PATTERN 'Valor (PATTERN 1 '(? x)) '(? y))”),
LQ(“(Valor (1 3) 123)”),nil),
PrM(LE(“(PATTERN 'Valor '(<-? x))”),
LQ(“(Valor 123)»),LQ(«((x 123))”)),
PrM(LE(“(PATTERN '(? x) '? '(<-? x))”),
LQ(“(Pesetas 1234 pesetas)”),nil),
PrM(LE(“(PATTERN '(? x) '? '(<-? x))”),
LQ(“(Euros 12 euros)”),nil)
end;
Terminate 0
Endsystem;
Obsérvese lo siguiente:
1. La PATTERN debe ser evaluada por la función LEval, en alguna
de sus formas. Aquí se usa la funcion abreviada LE(string).
2. La observación anterior obliga a poner la comilla (QUOTE) en
todos los elementos de la PATTERN.
3. La lista a encajar no necesita comillas internas, porque no se in-

terpreta, y la función LQ es equivalente a una comilla que abar-
ca toda la lista.
4. KMatch devuelve T, Nil o (si hay variables) la lista de asociacio-
nes resultante del encaje.
Reglas: su creación y representación
Una vez expuesto el mecanismo de la unificación, veamos la repre-

sentación de las reglas de inferencia. El sistema experto de PSPS es un
sistema deductivo muy simple, que contiene todos los mecanismos enu-
merados en secciones anteriores, y que se basa en encadenamiento di-
recto (Forward Chaining). Su mecanismo de inferencia toma las reglas
en el orden en que aparecen en la base de datos, y trata de aplicarlas re-
petidamente hasta alcanzar alguna conclusión (o no poder deducir nada
nuevo o incluso eternizarse en el empeño).
El sistema tiene dos bases de datos sobre las que descansa toda su
operación. La primera es una base de datos de reglas, en la jerga del pa-
quete conocida como PM (iniciales de Production Memory). La segun-
da es una base de condiciones, o de sentencias, conocida como la base
de datos WM (iniciales de Work Memory) 6. El encadenamiento directo
realiza sucesivas pasadas por la base PM aplicando sus reglas a WM y
añadiendo las conclusiones obtenidas a esta última, hasta que no logra
aplicar ninguna regla o hay una que le hace parar.
El paquete provee funciones para construir PM, la base de datos de
reglas, y WM, la base de datos de condiciones. Estas funciones se usan
como palabras clave que puntúan las diferentes secciones de la especi-
ficación de datos. Pero, a diferencia, por ejemplo, del paquete frames
con sus muchas funciones de acceso, el manejo de un sistema deducti-

vo es muy sencillo. Una sola función, la función ForwardChaining hace
todo el trabajo. A cambio, los datos deben ser preparados con gran cui-
dado. Errores sintácticos imperceptibles pueden dan lugar a errores de
proceso que luego cuesta mucho localizar.
6. Las dos bases de datos PM y WM están organizadas de forma que sus conteni-
dos son accesibles por medio del paquete KBs (Knowledge Bases). Este paquete, que
no describiremos con detalle, contiene funciones para acceder a los elementos de una
base de datos por unificación, es decir, identificando los objetos buscados por un proce-
so de unificación. Para más detalles, ver el manual de PSPS o el libro de Kreutzer ya in-
dicado.
Por ello es importante testar las reglas una a una, antes de integrar-
las en la base completa para lo que se dispone de la función auxiliar
KFireRule, cuya estructura detallada es:
KFireRule(unaRegla,unasCondiciones, unaListaDeAsociacion)
Sintácticamente, una regla tiene dos secciones: la sección CONDI-

TIONS (el nombre formal de la parte IF) y la sección CONCLUSIONS
(lo mismo para la parte THEN). En la parte CONDITIONS se enume-
ran los antecedentes y en la parte CONCLUSIONS los consecuentes.
En ambas partes pueden aparecer patterns, que se unificarán en la for-
ma oportuna ya sea con las expresiones de la base de datos WM, o pro-
duciendo sentencias como resultado de la aplicación de la regla. Tam-
bién pueden aparecer comandos que modifiquen la base de datos de
condiciones. Incluso, y en el caso más general, dentro de una sección
puede ordenarse la ejecución de cualquier función LISP. La base de da-
tos de condiciones (una simple lista en esta implementación) contiene,
en todo momento, todas las sentencias que se han logrado deducir.
Es posible especificar una regla directamente por su lista, pero esto
es engorroso y es fácil introducir errores. Como ilustración de su estruc-
tura, aquí tiene el lector la lista que representa la regla: IF X es hombre
THEN X es mortal.
(MORTAL (((? X) ES HOMBRE)) ((ASSERT ((<-? X) ES MORTAL)))
La lista es un triplo de elementos: en primer lugar el nombre de la

regla. En este caso hemos llamado a la regla «Mortal». Luego siguen
dos listas, la de antecedentes y la de consecuentes. Cada una de ellas
está compuesta de listas que representan cada antecedente y cada con-
secuente.
De las diferentes formas de crear una regla, la más sencilla es escri-

bir una expresión Lisp, y evaluarla a continuación (probablemente con
la función LE). El cuadro 4 presenta la estructura más general de una re-
gla.
Cuadro 4
Estructura de una regla
1. Toda regla se especifica como una lista con cuatro elementos. El pri-
mer elemento es el átomo RULE, que identifica a lo que sigue como
una regla.
2. El segundo elemento es el nombre de la regla.
3. El tercer elemento es una lista de antecedentes de la forma
(CONDITIONS lista_ de_antecedentes).
4. Cada elemento de la lista de antecedentes puede ser:
4.1. Una PATTERN, de la forma estudiada anteriormente.
4.2. Una PATTERN negada, es decir una pattern precedida del sig-
no de negación -|.
5. El cuarto elemento es una lista de consecuentes, con una estructura
de la forma: (CONCLUSIONS lista_de_consecuentes).
6. Cada elemento de la lista de consecuentes puede ser:
6.1. Un comando ASSERT. Este comando seguido de una PATTERN
pone en la base de datos WM el resultado de sustituir en la pat-
tern las variables de la lista de asociaciones obtenida del proce-
so de la parte CONDITIONS. Si el comando va seguido de una
lista (EXECUTE función parámetros) se ejecutará la función
LISP con los parámetros indicados y el resultado se adicionará
a WM.
6.2. Un comando RETRACT. De la misma forma, elimina de la lis-
ta WM la sentencia correspondiente. RETRACT puede venir
seguido por una lista EXECUTE como en el caso anterior, que
se trata de forma idéntica, pero esta vez eliminado el resultado.
6.3. Un comando EXECUTE, con la misma forma que en las
CONDITIONS.
7. Un comando RETURN, de la forma (RETURN función parámetros)

que detiene el proceso de las reglas, devolviendo el valor de la fun-
ción indicada, como resultado del ForwardChainer.
El proceso detallado de ejecución del ForwardChainer se muestra

en el cuadro.
Cuadro 5
Ejecución del FowardChainer
A. Para cada regla en PM:

(1) Match la primera CONDITION de la regla con todos los hechos
que se hallan en WM, usando una lista de asociaciones inicialmente
nula. El resultado es una lista intermedia, llamada la lista RL, de pa-
res (condición, lista de asociaciones), un par para cada match com-
pletado con éxito con esta PATTERN.
(2) Para cada CONDITION adicional de la regla:
(a) If RL está vacía, esta regla no se puede aplicar porque no en-
caja, por tanto ir a A para probar la próxima regla.
(b) Crear una nueva lista, RLNEW, y ponerla en Nil.
(c) Para cada elemento de la lista RL:
(i) Match la condición con todos los hechos contenidos en
WM usando como lista de asociaciones inicial la lista de
asociaciones contenida en el elemento de RL en curso.
(ii) Añadir (Append) la lista de asociaciones obtenida por los
encajes anteriores a la lista RLNEW.
(d) Sustituir RL por RLNEW (asignar RL = RLNEW).
(3) Para cada CONCLUSION en la regla:
(a) Si la conclusión es ASSERT o RETRACT, entonces para
cada elemento de RL:
(i) Sustituir todos los elementos (<-? x) en la conclusión
utilizando las correspondencias de la lista de asociacio-
nes contenida en el elemento de RL en proceso.
(ii) Si la conclusión incluye un EXECUTE, ejecutar la fun-
ción con los parámetros sustituidos. El resultado de la
ejecución es el hecho resultante.
(ii) Añadir o quitar el hecho de la WM.

(b) Si la conclusión es un EXECUTE entonces para cada ele-
mento en RL:
(i) Sustituir todos los elementos (<-? x) en los parámetros,
nes contenida en el elemento de RL en proceso.
(ii) Hacer apply de la función a los parámetros así sustitui-
dos.
(c) Si la conclusión es un RETURN entonces:

Solo para el primer elemento de la lista RL
(i) Sustituir todos los elementos (<-? x) en los parámetros,
nes contenida en ese primer elemento de RL.
(ii) Hacer apply de la función a los parámetros así sustitui-
dos.
B. Si cualquiera de las reglas utilizadas causa un ASSERT o un RE-
TRACT en WM, volver a A.
C. Devolver el valor de WM en curso.
El proceso de las negaciones requiere un poco de precisión. El pa-

quete implanta la hipótesis del «mundo cerrado». La hipótesis supone
que todo lo que no se halla en WM es falso, o lo que es lo mismo, todo
lo que no se afirma, se niega. Por tanto, bajo esta hipótesis, una ne-
gación de una pattern tiene éxito si la pattern no se unifica con ningún
elemento de WM. Por ejemplo, si tratamos de unificar (pattern 'es
'de 'día) con WM y no hay un hecho allí que lo permita, la conclusión de
-|(PATTERN 'es 'de 'día) será cierta, aunque eventualmente el sistema
pueda llegar a deducir que es de día, pero en el momento de testar la ne-
gación el sistema no haya llegado aún a esta conclusión.
Evidentemente, la no existencia en WM de una sentencia no es lo
mismo que la existencia en WM de la negación de una sentencia. Por
tanto la hipótesis enunciada en muchos casos es de dudosa validez. Sin
embargo ha sido, y sigue siendo, ampliamente utilizada en los sistemas
expertos para ampliar su percepción del mundo. Sin una hipótesis como
esta, la única forma de negar hechos sería incluir todas las negaciones
posibles en WM. Por supuesto esto es inconcebible desde el punto de

vista práctico, porque al no conocer a priori qué sentencias van a tener
que procesarse, el sistema debería contener todo el conocimiento nega-
tivo del mundo. Por tanto se acepta la hipótesis como un mal menor,
una forma de trabajar. Deben tratarse las negaciones con gran cuidado,
porque a menudo sus implicaciones son curiosas e interesantes.
Un primer ejemplo del uso de reglas se encuentra en el cuadro 6 que
consigue la gesta de probar 7 que Sócrates es mortal...
7. Por si no nos habíamos dado cuenta...
Cuadro 6
Modelo «Definición de reglas»
Variables
reglas;cosas;
Data
initial begin
reglas = LE(“(MakePM
(RULE 'mortal
(CONDITIONS (PATTERN '(? X) 'es 'hombre))
(CONCLUSIONS (ASSERT
(PATTERN '(<-? X) 'es 'mortal)))))”),
cosas = LE(“(MakeWM '(Sócrates es hombre))”)
end;
System
GENERATE 0,1;
COMPUTE begin
LPrint(reglas),
LPrint(cosas),
cosas = KForwardChainer(reglas,cosas,False),
LPrint(cosas)
end;
TERMINATE 0;
endsystem;
Las funciones LISP MakeWM(lista_de_hechos) y MakePM (lis-

ta_de_reglas) construyen respectivamente la lista WM de hechos y la
lista PM de reglas. La función KForwardChainer(PM,WM, Trazar) lle-
va a cabo el proceso de inferencia sobre los datos indicados, devolvien-
do una versión puesta al día de WM con todos los hechos derivados en

el proceso. Trazar es una variable booleana, que si es True, provoca la
impresión en el listener de una traza del proceso de deducción.
Las reglas para el caso de las reparaciones
La simulación del sistema de reparaciones, por supuesto, va a utilizar

el paquete rules. La idea es que cuando deba tratarse una transacción,
una avería generada, el modelo utilice el ForwardChainer para simular el
proceso de decisión del agente. Esto es típico en estas aplicaciones. La
capacidad lógica del sistema de inferencia es especialmente útil para el
modelado de procesos de decisión o de manejo de conocimientos. La si-

mulación que incluye procesos cognitivos es pues un área fértil para la
aplicación de los sistemas deductivos. Este tipo de simulacion cuenta ya
con cierta tradición en en el campo de la Inteligencia Artificial, pero en
la práctica empresarial se encuentra poco explorada.
Las siguientes reglas implementan un proceso de solución de pro-
blemas orientado a objetivos, o Goal oriented. Estos procesos empiezan
con un objetivo general en WM, que las reglas van concretando en su-
bobjetivos operativos. Si no hay una regla que alcance directamente el
objetivo final, otras reglas introducen subobjetivos que se consideran
interesantes para alcanzarlo. Estos subobjetivos se van eliminando de
WM a medida que se van alcanzando. El cuadro muestra las reglas uti-
lizadas, en las que se emplean las funciones Pspal del cuadro 8.
Cuadro 7
Fichero RulesAgentTest.pss
{FICHERO rulesAgenteTest.pss}
{--Este agente sigue un plan inmutable. Determina el próximo elemento a
testar, eligiendo un componente al azar de acuerdo con la distribución
(LosNudos, Reglas). A continuación si el elemento está fallado, lo reem-
plaza. Si no, simplemente toma nota de que está bien. En caso de que el
sistema siga sin funcionar, se testa el componente siguiente módulo, el
número de componentes en la red--}
LispReparaPM = LE(“(MakePM
(RULE '0.-Inicial
(CONDITIONS)
(CONCLUSIONS (ASSERT (EXECUTE (lambda()(list 'Funciona
(pspsList 'reliability)))))))
(RULE '1-GoalRepair {--Prepara el goal--}
(CONDITIONS '(Funciona False))

(CONCLUSIONS (RETRACT '(Funciona False))
(ASSERT '(goal reparar))))
(RULE '2-NoVa {--si no funciona hay que testar alguno --}
(CONDITIONS '(GOAL reparar))
(CONCLUSIONS (ASSERT '(GOAL TestarUno))))
(RULE '3.-CualTestar {--Selecciona un ítem para ser testado--}
(CONDITIONS '(GOAL TestarUno)
(PATTERN 'ESTADO '(? x)))
(CONCLUSIONS (RETRACT '(GOAL TestarUno))
(ASSERT (EXECUTE
(lambda()(list 'Testar
(pspsList 'PrimeroFallado '(<-? x))))))))
(RULE '4.-Test {--Testea un elemento, el que se le dice--}

(CONDITIONS (PATTERN 'Testar '(? n)))
(CONCLUSIONS (RETRACT (PATTERN 'Testar '(<-? n)))
(ASSERT (EXECUTE
(lambda()(list 'Modulo '(<-? n)
(pspsList 'Test '(<-? n))))))))
(RULE '5.-GuardaTrue {--Si el ítem funciona almacena la info en estado--}
(CONDITIONS (PATTERN 'modulo '(? n) 'True)
(PATTERN 'Estado '(? x)))
(CONCLUSIONS (RETRACT (PATTERN 'modulo '(<-? n) 'True))
(ASSERT '(GOAL TestarUno))
(ASSERT (EXECUTE
(lambda()(list 'Estado
(pspsList 'setStateT '(<-? x) '(<-? n))))))))
(RULE '6-Reparacion {--Reparar el ítem y tomar nota en el estado--}
(CONDITIONS (PATTERN 'Modulo '(? x) 'False)
(PATTERN 'ESTADO '(? y)))
(CONCLUSIONS (ASSERT '(GOAL probar))
(RETRACT (PATTERN 'Modulo '(<-? x) 'False))
(ASSERT (EXECUTE
(lambda()(list 'Estado
(pspsList 'RepararEste '(<-? y) '(<-? x))))))))
(RULE '7-ProbarSiFunciona {--Prueba si funciona o no y toma nota--}
(CONDITIONS '(Goal Probar))
(CONCLUSIONS (RETRACT '(Funciona False))
(RETRACT '(Goal probar))
(ASSERT
(EXECUTE (lambda()(list 'Funciona
(pspsList 'reliability)))))))
(RULE '8.-Final {--Termina al alcanzar el goal--}
(CONDITIONS '(Funciona True))
(CONCLUSIONS (RETURN (lambda(w)
(Print (List 'Problema 'Resuelto

(car (RetrieveByPAttern (car w)
(PATTERN 'estado '(? x)) nil nil)) t)))))))”)
Se manejan tres objetivos, o goals: Reparar, TestarUno y Probar.

Reparar es el objetivo inicial. TestarUno es un objetivo que se
plantea una vez se ha constatado que el sistema no funciona (o sigue sin
funcionar). Probar es un goal que se plantea para averiguar si el siste-
ma está funcionando.
Para aplicar estas ideas generales, consideremos el sistema concre-
to representado en la figura 1. Esta red contiene cuatro componentes, o
módulos. El estado real del sistema es el vector de estados de los com-

ponentes, pero es desconocido para el reparador. Este estado real de la
red es un vector de cuatro componentes que se maneja como una lista,
que se halla en la variable LispEstadoReal. El vector contiene va-
lores True o False en cada componente, indicando el estado real de fun-
cionamiento del mismo.
El estado de opinión del decisor sobre un componente puede tener
tres valores: funcionando (True), fallado (False) o desconocido (U). Por
tanto el estado de opinion, lo que el agente sabe sobre el sistema, es
tambien un vector de cuatro componentes, cada uno de ellos con estos
tres valores posibles. El estado de opinión se halla siempre almacenado
en WM, en una proposición de la forma '(Estado (e1 e2 e3 e4))
donde e1, .., e4 son los estados de opinión en curso de cada uno de los
cuatro componentes. El estado de opinión se modifica a medida que el
proceso de detección avanza. Antes de realizar ningún test, el estado
inicial de opinion es '(U U U U).
Figura 1
Esquema de la red
x3
x1 x4
x2
Las ocho reglas de deducción tienen las siguientes funciones:

Regla 0. Inicial. No requiere condiciones. Toma nota de que el sis-
tema global se halla en el estado resultado de calcular su función de fia-
bilidad 8, Reliability. Como nuestro sistema de ejemplo es el de la figu-
8. La función de fiablidad es una función booleana que produce el estado de fun-

cionamiento del sistema a partir del estado de funcionamiento de cada uno de sus com-
ponentes.
ra 3, la función de fiabilidad es: x1 and (x2 or x3) and x4.

La estructura interna de la funcion Reliability, no está accesible al siste-
ma. Éste sólo puede aplicarla, para ver si el sistema funciona o no.
Regla 1. GoalRepair. Si el estado del sistema es False, es decir, si
no funciona, esta regla pone en la WM el goal 'Reparar, y deja para las
demás reglas el averiguar como hacerlo.
Regla 2. NoVa. Si la regla encuentra en la WM el goal 'Reparar,
deja en la WM el goal intermedio 'TestarUno, lo que significa que hay
que probar alguno de los componentes del sistema.
Regla 3. CualTestar. Si el goal 'TestarUno está entre los hechos de
WM, se selecciona un componente para hacer el test. Esta selección la
realiza la función Pspal, PrimeroFallado. El resultado es dejar en
WM el goal '(Testar x) donde x es un número de componente.
Regla 4. Test. Si encuentra el goal '(Testar x) realiza el test sobre el
componente x. En la implantación, simplemente se consulta el verdade-
ro estado del componente. Como consecuencia, se pone en WM el he-
cho '(componente x True) o '(componente x False) según el estado del
componente.
Regla 5. GuardaTrue. Cuando halla el hecho '(componente x True)
acompañado de (Estado False), esta regla se encarga de poner al día el
estado de opinión sobre los componentes del sistema, y por lo tanto
hace que el decisor «aprenda». Como el estado del sistema es False,
debe restaurar el Goal 'TestarUno para seguir avanzando.
Regla 6. Reparación. Ahora se repara. Tras encontrar un compo-
nente fallado, se recupera el estado en WM y se pone el estado del com-
ponente correspondiente a True. También se establece el Goal 'Probar,
para que alguien averigüe si ya hemos terminado y el sistema está ope-

rando correctamente.
Regla 7. ProbarSiFunciona. Se encarga de implantar el Goal 'Pro-
bar, para lo cual sustituye el hecho ('funciona x) por el resultado de cal-
cular la función de fiabilidad de la red.
Regla 8. Final. Si ha llegado al final, es decir, si el sistema funcio-
na, termina, devolviendo el estado interno, que se encuentra en WM,
utilizando la función RetrieveByPattern para recuperarlo.
Como puede observarse, todas las funciones EXECUTE han sido
programadas en Pspal, utilizando el mecanismo pspsList para llevarlas
hasta LISP.
Cuadro 8
Fichero MacrosAgentTest.pss
{FICHERO MacrosAgenteTest.pss}
{--Direccionando los módulos del sistema--}
GetModulo: function(estado,n) return Lnth(estado,n) == LispT;
setModulo: function(estado,n,valor) return Lsetnth(estado,n,valor);
{--La función de funcionamiento del sistema--}

Reliability:function()
Locals aux;
begin
if getModulo(LispEstadoReal,1) and getModulo(LispEstadoReal,4)
and (getModulo(LispEstadoReal,2) or
getModulo(LispEstadoReal,3))
then aux= LispT else aux= LispF,
Debug esc do writestr(format(“Reliability sale con %s”,
Lshow(aux))),
Debug esc do Lprint(LispEstadoReal),
return aux
end;
{--Repara el elemento n, poniendo el estado a True--}

RepararEste:function(lista,n)
Locals aux,i,n;
begin
debug esc do write(“reparando ”,n),
setModulo(lista,n,lispt),
setModulo(LispEstadoReal,n,lispt),
return lista,
end;
{--Repara el elemento n, poniendo el estado a True--}

SetStateT:function(lista,n)
Locals aux,i,n;
begin
setModulo(lista,n,lispt),
return lista,
end;
{--Cuenta el número de tests realizados--}

CuentaReparaciones:function(lista)
Locals i,k,aux;
begin
aux = lista, k = 0,
for i= 1 to red do begin
if LEqv(Lcar(aux),LispT) then k = inc(k),
aux = Lcdr(aux)
end,
return k
end;
{--Hace el test sobre el elemento n-ésimo. El test es perfecto--}

Test:function(n) return Cond(getModulo(LispEstadoReal,n),LispT,LispF);
{--La rutina central que busca el próximo a testar --}

PrimeroFallado:function(lista)
Locals aux,i,n,k;
begin
aux = lista, n = int(sample(dist)),
for i = 1 to red do begin
k = mod(n + i-2, red) + 1,
if not GetModulo(lista,k) then begin
debug esc do write(“Muestra” ,n,“A reparar” ,k),
return LDefNAtom(k)
end
end,
return LDefNAtom(0)
end;
{--genera un estado real del sistema--}

generador:function()
Locals i;
begin
for i = 1 to red do
setModulo(LispEstadoReal,i,Cond(exponential(2) <= 1,LispT,LispF)),
return LispEstadoReal
end;
El programa principal genera transacciones y se encarga de evaluar

la política de test implantada. En la versión que se presenta, el primer

elemento a testar se obtiene muestreando una distribución de probabili-
dad sesgada hacia los componentes 1 y 4. Para muestrear elementos adi-
cionales, se toman en sentido creciente de su número, a partir del mues-
treado en primer lugar. Una variable estadística, numreps, cuenta el
número de reparaciones efectuadas.
Cuadro 9
Programa principal «Reparación de componentes»
{Programa Principal}
Constants
red = 4;
esc = False;
samples = 100;
Labels
acabado;
Variables
LispT; LispF;
LispEstadoReal;
LispReparaWM;
LispReparaPM;
LispEstadoInterno;
LosNudos array red;
Probabil array red;
dist;
numreps stat;
i;
Macros
{$MacrosAgenteTest.pss}
Data
Vars LispT = LQ(“TRUE”);
Vars LispF = LQ(“FALSE”);
Vars LosNudos = \1,2,3,4\;
Vars Probabil = \1,0,0,1\;
REPORT On;
initial
begin
{$rulesAgenteTest.pss}
dist = FDistribution(red,&LosNudos,&Probabil),
LispEstadoReal = Llist(lispF,LispF,LispF,LispF),
end;
System
GENERATE 1,Samples;
ASSIGN Generador,Cond(Reliability == LispT,acabado,cb+1);
COMPUTE begin
LispReparaWM = LE(“ (MakeWM '(estado (U U U U)) )”),
LispReparaWM = KForwardChainer(LispReparaPM,LispreparaWM,False),
if trCount <= Samples then begin
LispestadoInterno = Lcadr(Lnth(lispReparaWM,3)),
numreps = CuentaReparaciones(LispEstadoInterno),
end,
end;
acabado:TERMINATE 1;
endsystem;
El lector debería caer en la tentación de:

1. Evaluar otras estrategias de selección de módulos o componen-
tes. Por ejemplo, la más sencilla es muestrear entre los que aún
no se han testado. Pero caben estrategias más elaboradas.
2. Extender la situación a tests no perfectos. Un test puede tener
errores de tipo I y de tipo II. Un error de tipo I es informar de que
el componente está fallado cuando de hecho está correcto. Y un
error de tipo II es informar de que está correcto cuando está fa-
llado. ¿Cómo pueden especificarse las probabilidades de la dis-
tribución del test en este caso? Estamos en presencia de un test
estadístico general, y aquí el lector puede sacar partido a todo lo
que sabe de estadística 9.
3. Usar un procedimiento de reparación más complicado.
Al hacer estas pruebas, el lector empezará a apreciar las ventajas de
los sistemas de reglas sobre otras formas de programación.
En el fondo, y una vez disipada la niebla posiblemente generada por
un nombre atractivo, las técnicas de sistemas expertos son fundamental-
mente otra manera de implantar, en forma mecanizada, procesos de de-
cisión de cierta complejidad. Y no son inteligencia de ningún tipo, ni si-
quiera artificial.
3. Otros paquetes
En los dos últimos capítulos hemos presentado tres de los paquetes

más útiles que incorpora Psps, como hemos dicho repetidas veces, to-
dos adaptados de Kreutzer. Pero hay otros paquetes que también se in-
cluyen y que no hemos citado. Uno de ellos, el paquete KBs, implanta
bases de datos de hechos recuperables por medio de técnicas de Pattern
9. Y si no, puede consultar, por ejemplo, S. LIPPMAN, Introducción a la Estadísti-

ca, Boixareu Editores, 1983.
Matching. El lector interesado puede experimentar fácilmente con estas

funciones que se documentan en el CD.
Debemos concluir este capítulo resaltando, de nuevo, que estos pa-
quetes no son herramientas a toda prueba, sino implantaciones experi-
mentales para explorar su aplicación en la simulación.
No hemos entrado en la posibilidad de la generación automática de
programas de simulación, a partir de una descripción del problema en
lenguaje natural. Estas ideas no se implementan bien en PSPS, porque
el lenguaje no permite fácilmente construir programas al vuelo y ejecu-
tarlos más adelante. Para adentrarse en este terreno, es interesante tra-
bajar con sistemas más cercanos al propio LISP como los de Kreutzer,
o nuestro Simmer 10.
10. Simmer está programado en Common Lisp. No hay documentación sobre el

sistema, aparte de las propias fuentes en Lisp, que están bien documentadas y que se
pueden hallar en www.ai-repository.edu.
PARTE III
EL OFICIO DE LA SIMULACIÓN
Capítulo 21
CASOS PRÁCTICOS
Estamos llegando al final del libro y por ello en este capítulo quere-
mos presentar al lector una serie de casos reales en los que la construc-
ción de un modelo de simulación ayuda a comprender mejor la situa-
ción, descubriendo la causa de los problemas en unos casos o ayudando
a la toma de decisiones en otros.
En este capítulo el lector deberá hacer uso de todas las herramientas
descritas en el libro, y de su propia habilidad lógica. Todos los casos in-
cluyen mensajes que sólo pueden apreciarse si se trata de reconstruir la
situación de forma activa. Si el lector quiere sacar el máximo partido de
estos casos, debe trabajarlos de la siguiente forma:
1. Leer el caso y asegurarse de que entiende el problema planteado.
2. Intentar desarrollar un primer modelo de simulación. Identificar

las dificultades principales y los aspectos críticos del modelado.
3. Hojear el modelo presentado en el texto, leyendo con espíritu
muy crítico su descripción. No se trata de aprender cómo se mo-
dela el caso, sino de determinar qué es lo que está mal modelado
en nuestro enfoque, y cómo debe ser revisado.
4. Ahora se debe desarrollar un modelo completo y utilizarlo para
el análisis del caso.
5. Finalmente hay que compararlo con nuestro enfoque, para con-
cluir que los autores son unos inútiles, y que el buen modelo es
el del lector.
556 EL OFICIO DE LA SIMULACIÓN
Si la conclusión es la apuntada, ¡albricias! El lector ha sacado el

máximo partido del libro. Si no lo es, y sobre todo si el lector queda bo-
quiabierto por la sabiduría de los autores al haber construido un mode-
lo tan bueno, ¡cuidado! Quizá haya que volver atrás, porque se ha
aprendido muy poco del arte de la simulación.
Para dar algunas pistas sobre el tipo de situaciones que el lector en-
contrará en lo que sigue, he aquí unos breves apuntes sobre los casos.
Caruso Pizza, en el que un novedoso negocio de entrega de pizzas
a domicilio se pregunta cuál puede ser la razón del aumento inesperado
en la cantidad de desperdicios.
Donner Company, compañía dedicada a la fabricación de circuitos
impresos. Donner se pregunta si su plazo de entrega es razonable, y a
qué se debe la congestión de la factoría.
Herrerías Uranio: fabrica bajo pedido piezas de materiales como
titanio o uranio. La fábrica presenta problemas en su taller mecánico y
se propone la supresión de la programación y su sustitución por el uso
de reglas de secuenciado.
Shouldice Hospital, hospital especializado en la operación de her-
nias en el que se quiere estudiar la capacidad del mismo y ver si los ser-
vicios tienen capacidad suficiente para atender a más clientes.
Tejidos Especiales Dentel, empresa dedicada a la fabricación de te-
jidos especiales que se enfrenta a un problema de falta de cumplimien-
to de los plazos de entrega.
Bibliografía
MUÑOZ-SECA, Beatriz y RIVEROLA, Josep, Del buen pensar y mejor ha-

cer. Mejora permanente y gestión del conocimiento, McGraw-Hill,
2003.
DE TREVILLE, S., Disruption, Learning and System Improvement in JIT
Manufacturing, Thesis GSB, Harvard University, 1987.
CASO 1
CARUSO PIZZA1
Caruso Pizza es una empresa mixta de restaurantes y reparto de piz-

zas a domicilio. Caruso se especializa en pizzas de muy alta calidad, es-
pecialmente pizzas gruesas. Este tipo de pizzas, al tener una masa de
mayor grosor, son más propensas a acumular humedad, que si no se li-
bera adecuadamente moja la pizza y la convierte en una masa blanda de
mal aspecto y peor ingestión. Por ello, Caruso ha estado siempre muy
preocupado por encontrar una tecnología capaz de situar la pizza en
casa del cliente en las condiciones ideales para ser degustada a satisfac-
ción.
El cliente doméstico de Caruso, el que pide pizza para que se la lle-
ven a casa, es típicamente una madre de familia que tiene necesidad ur-
gente de alimentar a hijos hambrientos. Por ello, cuando el cliente lla-
ma a Caruso pidiendo una pizza, espera que la entrega se produzca en
unos 30 minutos. Si se tarda más, es probable que ya no quiera la pizza.
Por otro lado, 30 minutos es tiempo suficiente para que la pizza se en-
fríe, si no se toman precauciones especiales. Y todo el mundo sabe que
una pizza fría es prácticamente incomible. En el pasado, esto hacía ne-
cesario que la producción de pizzas se hiciera siempre bajo pedido. Esto
llevaba a poner el máximo empeño en diseñar un proceso con un plazo
de producción inferior a los 10 minutos. La mayoría de los otros prove-
edores de pizza a domicilio tenían sistemas logísticos capaces de entre-
gar pizzas en menos de 20 minutos, normalmente apelando al transpor-
1. HART, C.W.L., Caruso’s Pizza: reparto Expres (A), Caso P-672, División de In-
vestigacion del IESE, Barcelona, 1988.
te en motocicletas ligeras cuya velocidad media en medios urbanos era

más elevada que la de otros tipos de transporte.
En una convención de fabricantes, Caruso atendió a la presentación
de una empresa que decía haber puesto a punto una tecnología capaz de
mantener pizzas en stock, sin que se degradaran en calidad o tempera-
tura. Se trataba de unos hornos de gas, que mantenían la pizza en atmós-
fera controlada y garantizaban una calidad como de recién salida del
horno, por un tiempo de almacenamiento de alrededor de dos horas.
Adicionalmente, la tecnología se había implantado en unidades móvi-
les, camionetas de reparto. Con estas camionetas, una empresa podía
producir pizzas y mantenerlas en stock durante dos horas, al mismo
tiempo que realizaba el reparto con la propia camioneta. En un horno
cabían unas 40 pizzas. La velocidad media de las camionetas en tráfico
urbano no superaba los 20 Km/hora, por lo que (al añadirle los tiempos
de parada) una camioneta podía cubrir un área de 2 x 2 Km. centrada al-
rededor del punto de fabricación.
Caruso compró cuatro camionetas y empezó el reparto de pizzas
usando esta tecnología. Las camionetas cargaban sus hornos en el cen-
tro de producción, con hasta 5 variedades de pizza. A continuación sa-
lían hacia las zonas de reparto. Cuando un cliente llamaba al centro de
toma de pedidos, el encargado se ponía en contacto con las camionetas,
para determinar cuál era la más cercana al domicilio del cliente que te-
nía pizza del tipo deseado. A continuación daba la orden a la camioneta
de entregar el pedido. Si ninguna camioneta tenía pizza del tipo adecua-
do, el operador trataba de convencer al cliente de que cambiara su pedi-
do. Esto, que se lograba sólo en un 30% de los casos, permitía servir el
pedido con una pizza ya existente en una camioneta. Si el cliente no
cambiaba el tipo de pizza, la camioneta debía volver al centro de pro-
ducción para recoger pizza del tipo deseado. Esta circunstancia se apro-
vechaba para recargar los hornos con todos los tipos de pizza. Si en al-
gún momento una camioneta tenía pizzas que llevaban dos horas en la
misma, la camioneta se dirigía al centro de producción para cargar piz-
zas nuevas.
Tras unos meses de operar con el nuevo sistema, Caruso empezó a
notar un aumento notable en el volumen de desperdicios. Al mismo
tiempo, no parecía que los clientes estuvieran muy contentos con el ser-
vicio de la empresa. A Caruso le preocupaban varios aspectos:
• ¿Cuál era el origen del aumento de los desperdicios?
• ¿Cuántos tipos de pizza podía distribuir con los camiones?
• ¿Cuánto le costaba mover las pizzas por toda la ciudad, con res-
pecto a la técnica tradicional de la motocicleta?
CASO 1. CARUSO PIZZA 559
• ¿Qué área podía cubrirse de una forma razonable?

• ¿Valía la pena usar el sistema de las camionetas?
1. La simulación: desarrollo de un modelo
Este caso, como muchos casos reales, requiere un modelo de simu-

lación algo complicado. Y el desarrollo de un modelo de esta índole
produce abundantes dolores de cabeza en el modelador, especialmente
si no sigue un método sistemático. En esta sección vamos a aprovechar
la ocasión que nos brinda Carusso, para introducir algo de metodología
para el desarrollo de modelos complejos. Adelantemos que se trata de
una metodología rudimentaria, inspirada en la observación de muchos
modeladores realizando su trabajo. No espere el lector grandes inven-
tos, porque aquí sólo hallará los frutos de la observación de personas,
batallando con las complejidades de un modelo 2.
Desarrollar un modelo de simulación es resolver un problema.
Cualquier metodología general para la solución de problemas puede
usarse para guiar al modelador. Subyacente en lo que sigue, está la me-
todología de solución de problemas que se describe en [Muñoz-Seca &
Riverola]. El punto más importante es que el desarrollo de un modelo es
un proceso de búsqueda, con todos los componentes que se presentaron
en el capítulo 19. El tipo de operadores que se pueden aplicar en cada
estado depende del conocimiento del modelador. Un modelador exper-
to probablemente será capaz de aplicar mejores operadores, lo que re-
dundará en un menor nivel de backtracking. Pero para un problema su-
ficientemente complicado, el backtracking se producirá eventualmente,
con independencia del grado de conocimiento del agente. La metodolo-
gía trata de que el backtracking se produzca suavemente, para que no
sea traumático en el tiempo y los recursos del desarrollador.
Típicamente un modelador parte de una idea inicial sobre cómo en-

focar el problema, basada totalmente en su conocimiento. Se trata de
validarla rápidamente, produciendo una versión que funcione. La ver-
sión será más o menos buena, pero esto no importa mucho a estas altu-
ras. Sólo se trata de demostrar que el enfoque es adecuado, que prome-
te. Por ello, no hay que perder mucho tiempo en su implantación.
Porque si descubrimos que por aquí no vamos a ninguna parte, habrá
que hacer backtracking y deshacer lo hecho, perdiendo dinero y tiempo.
2. Aquí debemos agradecer a los cientos de alumnos que han desfilado por nues-
tros cursos la contribución que han hecho a la metodología, sin saberlo y sin desearlo...
Si hay que deshacer el camino y empezar de nuevo, conviene haber in-

vertido poco y saberlo lo antes posible.
A veces este enfoque se conoce como un modelo en «espiral». El di-
seño es iterativo, repitiendo una vez tras otra las mismas fases, y refi-
nando progresivamente el modelo, hasta asegurar que la lógica básica
de la situación está recogida de forma satisfactoria. Si esto no es así,
volvemos atrás. En este proceso, no dudamos en hacer hipótesis simpli-
ficadoras, si ello permite avanzar rápidamente, relegando para más ade-
lante el refinamiento de éstas.
Figura 1
Desarrollo en espiral
Diseñar Implantar
Evaluar Testar
En la práctica esto se logra produciendo progresivamente versio-

nes que sólo difieren en unos pocos aspectos de la lógica. Cuando una
versión funciona, se copia y se guarda. Es un refugio sólido. En caso
de que nos hagamos un lío en la próxima vuelta a la espiral, podemos
deshacer el entuerto volviendo a esta versión que funcionó razonable-
mente.
La figura 1 muestra el fundamento de la metodología. En un desa-
rrollo en espiral se pasa repetidas veces por las cuatro fases DITE (Di-
señar, Implantar, Testar, Evaluar). Operativamente, el siguiente proceso
funciona muy bien.
1. Empezar por considerar la versión más sencilla de la situación
que no destruye los problemas existentes. En nuestro caso po-
demos empezar considerando la existencia de una única camio-

neta con un único tipo de pizza. Este caso es esencialmente el
último ejemplo del capítulo 18.
2. Aislar la parte más delicada de la situación y preguntarse
cómo podemos simularla. Por ejemplo, ¿cómo implantaremos
el mecanismo de despacho del camión a partir de la llegada de
pedidos? A menudo es conveniente adquirir conocimiento. Para
ello, si no se está bien familiarizado con PSPS se pueden hacer
unas pocas pruebas que clarifiquen la situación, operando sobre
ejemplos muy simples.
3. Abrir una sola ventana PSPS y preparar toda la simulación en
una única ventana. Más adelante, iremos separando el modelo
en varios ficheros, a medida que el uso de una sola ventana haga
difícil la consulta y manejo de otras secciones. Esto es típico
para las secciones Constants y Variables, por un lado, y Data
por otro. Estas secciones eventualmente terminarán en ficheros
independientes, ya que de esta forma se pueden consultar más
fácilmente.
4. Empezar trabajando la sección System. Cada vez que necesita-
mos una cantidad, definiremos una función que la obtiene y
guardaremos su definición, para implantarla más adelante. Por
el momento olvidamos todo lo que tiene que ver con la recogi-
da de resultados. Se añadirá más adelante, cuando el modelo
esté probado en sus aspectos lógicos fundamentales. Esto se
aplica tanto a los gráficos como a las tablas, histogramas, inter-
faces con el usuario y otros. Los primeros resultados de una si-
mulación se pueden manejar fácilmente con las opciones están-
dar de PSPS.
5. Identificar los procesos fundamentales y las transacciones que
los recorren. Los procesos se pueden clasificar de acuerdo con

los flujos que manejan. De entrada se pueden distinguir cinco
tipos diferentes de flujos: de pedidos, de materiales, de dinero,
de información y de personas. En el caso de Caruso Pizza ma-
nejamos materiales, pedidos y camionetas. Por tanto existirán
los procesos de:
• Manejo de los materiales (la pizza)
• Manejo de los pedidos
• Manejo de las camionetas
6. ¿Quiénes son los procesadores y cómo van a representarse?
Los procesadores suelen ser facilities, pero caben alternativas,
como variables estadísticas, switches, etc. En caso necesario,

indicar someramente el tipo y estructura de información que
hay que asociar con cada procesador y cómo se va a hacer, por
lo menos a nivel de estructura de datos. Si la estructura de in-
formación es complicada se deben usar listas. Si aún no está
claro, seguir adelante, porque en algún momento se aclarará.
7. ¿Cuál es el recorrido de las transacciones? Probablemente
aquí vale la pena describir por escrito, en lenguaje natural y de
forma breve, el proceso que cada transacción va a seguir, inclu-
yendo la posible existencia de simulaciones continuas, que exi-
gen la presencia de bloques INTEGRATE.
8. ¿Cómo se coordinarán las transacciones entre sí? Ahora entra-
mos en el núcleo de la sección System. En general hay a lo sumo
uno o dos bloques críticos, cuya elección configura el resto del
sistema. Lo más normal es que esta criticidad tenga que ver con la
coordinación, pero hay otras situaciones como uso de la impacien-
cia, procesos especiales de generación de transacciones y otros.
Nos limitamos a comentar la coordinación, de largo lo más impor-
tante. La coordinación se ha analizado con detalle en el capítulo
13, al hablar de la coordinación de procesos. En este momento hay
que decidir si la coordinación se va a hacer de la forma básica EN-
TER/LEAVE (o SWITCH/GATE), o si se va a apelar a mecanis-
mos más sofisticados. En concreto hay que identificar si se van a
usar bloques de coordinación y cuáles. Los bloques de coordina-
ción son JOIN, GETGROUP, GRAB, GROUP/UNGROUP,
MENTER, MGET, SELJOIN, SYNCHRO. Los demás bloques
son accidentales. En una simulación moderadamente compleja,
hay a lo sumo dos o tres de estos bloques de coordinación.
9. Ahora podemos empezar a listar los demás bloques de la sec-
ción System. Aquí es interesante manejar la ayuda a programa-

ción, en el botón de la barra de herramientas. Haciendo clic
en cualquier ítem de la ventana de ayuda, la línea se copia en la
posición del cursor.
10. Ahora programamos las funciones necesarias para soportar la
sección System determinadas anteriormente. La estructura de
datos decidida más arriba servirá para esta programación. En
este estadío, la funcionalidad debe ser lo más simple posible,
aunque su comportamiento no se corresponda con los detalles
del proceso. Sólo se trata de montar un esqueleto que funcione,
y que aísle las diferentes funcionalidades. Cada funcionalidad
se ira refinando progresivamente a continuación.
11. Al mismo tiempo se deben ir definiendo con precisión las varia-

bles globales, que hay que inicializar en la sección Data.
12. Una vez completado un primer prototipo, hay que probarlo.
Aquí hay que detenerse, hasta que se esté seguro de que lo que
hace el modelo es lo que se supone que debe hacer. Recuerde el
lector que si prepara un modelo para un problema en el que es-
tén involucrados otros decisores, estos sólo se fiarán del mode-
lo en la medida en que entiendan sus resultados de forma intui-
tiva. Se trata de un problema de confianza en el modelo, y la
confianza se pierde rápidamente si se descubren comporta-
mientos anómalos o inesperados, especialmente si son atribui-
bles a errores en el modelado. La prueba tiene varias subfases:
12.1. Comprobación del recorrido de las transacciones. Aquí
es de gran ayuda el DDT 3. En casos de mayor compleji-
dad, la traza de transacciones, en un intervalo del tiempo,
ayuda a resolverlo. En PSPS, la mayor parte de errores
provienen de la falsa interpretación del funcionamiento
de algún bloque, por lo que es conveniente asegurar pri-
mero los bloques complejos, como los de coordinación.
12.2. Comprobación de que las acumulaciones se producen en
la forma y medida previstas. Uno de los errores más
frecuentes en la primera prueba del modelo es tener de-
masiadas transacciones en el sistema. Esto se produce
porque el sistema no evacúa transacciones, que se están
quedando atascadas en algún punto. Cuando esto sucede
hay que comprobar:
12.2.1. La capacidad de los procesadores. Procesadores
con poca capacidad retienen las transacciones.
12.2.2. La situación de los switches. Los bloques GATE
o QGATE pueden no dejar pasar las transaccio-

nes.
12.2.3. Las esperas por coordinación. Bloques como
JOIN o SYNCRO hacen esperar una transacción
hasta que llega un colega. ¿Y si este colega no
llega?
12.2.4. Bucles en la realimentación. Cuando se generan
continuadamente transacciones, y algunas se rea-
3. Opción disponible en el menú Interaction de la barra de menús de la ventana

principal del PSPS o mediante el botón de la ventana de control de la simulación.
limentan, la condición de salida de un bucle pue-

de que no se cumpla nunca, y la transacción sea
siempre devuelta al origen.
12.3. Comprobación de la lógica de las funciones. En esta
fase, y para análisis detallados, se puede usa el debug-
ger, al que se accede desde una pause convenientemente
colocada. Si se está desarrollando un modelo con listas,
y se producen errores, el uso del listener es lo más útil.
Al producirse un error hay que consultar el stack de lla-
madas, que nos indica las funciones que se han llamado
e identifica la que produce el problema y los argumentos
que se le han pasado. Para aquellos que estén dispuestos
a tratar con el código máquina de la máquina virtual Ps-
pal (por otra parte muy sencillo), el menú Display/Stack,
de la ventana ListenerBase, y sus derivados, permiten
identificar con gran precisión lo que estaba sucediendo
en el punto de parada. El uso de trazas más avanzadas
puede ayudar, pero producen gran cantidad de output,
que puede no caber en el listener 4. Las listas son consul-
tables desde cualquier posición, mediante la opción
Show expression usando el botón derecho del ratón. El
viejo método de insertar sentencias write es aún uno de
los mejores procedimientos de depuración. La función
WriteStr, combinada con la función Format, permite es-
cribir mensajes de error tan complicados como se quie-
ra. Para las listas, la función Show(), que convierte una
lista en su representación como string, permite incorpo-
rar la lista a un formato.
12.4. Adición de gráficos para comprobar el funcionamiento
temporal. Los gráficos permiten ver de una ojeada si el
comportamiento en el tiempo de las variables del sistema

es correcto. En esta subfase unas sencillas llamadas a
FdrawXY, o el uso del bloque DRAWXY proporcionan
buena información.
13. Ahora podemos seguir añadiendo gráficos y outputs para hacer
del prototipo un sistema usable. Usar gráficos es una manera de
informar del estado del sistema en todo momento. Definir una
4. En la versión incluida esto lo hace cada vez que tiene 400 líneas en el buffer, eli-
minando las primeras 200 y reteniendo las segundas, y así poder seguir con el output
deseado.
función en la sección ONDEBUG suele ser una buena forma de

obtener resultados detallados, incluso desde el debugger.
14. Volver a empezar. Ahora hay que concentrarse especialmente
en escribir mejores versiones de las funciones básicas, que he-
mos sólo bosquejado en una primera pasada.
15. Dejar para el final:
15.1. La interacción detallada con el usuario. Las tablas, dia-
gramas de Gantt, histogramas y otras lindezas que no son
una herramienta de comprobación deben esperar a que
todo esté listo.
15.2. El formateado y la inclusión de comentarios explicativos.
Aunque la inclusión de cometarios es una buena forma de
mantener claro lo que se está haciendo, al llegar al final
hay que recordar que:
— Los programas se pudren dentro de los ordenadores,
de manera que si se vuelve a ejecutar el programa den-
tro de tres meses, probablemente no funcionará.
— El desarrollador tiene memoria limitada.
— En algún momento, dentro de un tiempo y cuando na-
die se acuerde del programa, alguien pedirá que se rea-
licen unas «pequeñas modificaciones».
15.3. El pulido, como por ejemplo eliminación de variables no
usadas, fragmentos de código complicados o anormales,
etc.
En la práctica, todas estas recomendaciones son casi inútiles. Los

desarrolladores dicen seguirlas, pero hacen oídos de mercader a las vo-
ces que recomiendan prudencia. Todo depende del conocimiento y ex-
periencia del modelador.

Los propios autores no las siguen. Como ya somos expertos en
PSPS, nos lanzamos inmediatamente a escribir código 5. La mayoría de
simuladores experimentados se lanzan a escribir inmediatamente el mo-
delo... y también los no experimentados. Tarde o temprano ambos tie-
nen que parar, reflexionar y deshacer parte del camino. Pero los experi-
mentados suelen hacerlo en mejores condiciones para reemprender el
trabajo. Los no experimentados suelen parar con un lío entre las manos
que no hay manera de desentrañar.
5. De hecho, esto es casi lo que recomendaríamos que hiciera el lector, con mayor
atrevimiento a medida que fuera adquiriendo más experiencia en simulación.
Una forma de prevenir los líos es estar permanentemente alarmado

y alerta, para detectar situaciones que constituyen un problema (una
trampa) potencial. Este estado «de alarma constante», es lo que suelen
lograr las metodologías. La metodología debe intranquilizar a todos, si-
muladores expertos y noveles. Pero cuando deja de intranquilizar, pue-
de olvidarse.
2. Un modelo para Caruso
Haciendo caso a nuestra metodología y para contestar las preguntas

planteadas, Caruso preparó una simulación usando PSPS 6, que presen-
taremos en esta sección. Empezaremos por la sección System de una
primera versión simplificada, indicando las funciones necesarias para la
implantación.
Cuadro 1
Modelo «Caruso». Sección System
System
{--Inicio y lectura de datos--}
GENERATE 0,1;
COMPUTE Leedatos;
TERMINATE 0;
{--Generar demanda y buscar camión--}

GENERATE Erlang(tDemanda,1),On;
{--Determinar el punto de demanda y la disponibilidad de tipo de pizza

fresca en el camión. Si no hay camión con pizza adecuada ir a reponer--}

COMPUTE CargaAtributosDemandayCamion, IraCasoSegunDisponibilidad;
{--si no se puede hallar un camión disponible en maxespera dejarlo--}

ENTER at[camion],1,Fifo,maxEspera,OutOfStock;
ADVANCE Erlang(at[distancia],2);
entrega: COMPUTE zz = RealizaEntrega(at[camion],at[tipo]);
6. El lector se preguntará cómo pudo Caruso usar PSPS si aún no había salido este
libro. La respuesta es que Caruso era amigo nuestro y le dejamos usar una versión pre-
liminar del sistema. Después de todo el actual PSPS es el PSPS-IV.
DEBUG step do stop;

TABULATE 1,cl-at[hora];
LEAVE at[camion],1;
COMPUTE zz = CalculaEstadisticas;
TERMINATE 1;
{--cada camión se representa por una facility. Las demandas son tran-
sacciones--}
reponer: ENTER at[camion],1,Fifo,maxespera,outofstock;
{--ir a casa, cargar y volver--}
ADVANCE Erlang(at[distancia],2);
DEBUG Mapa do COMPUTE Fdrawcont(6,GCLRALL);
COMPUTE camiones[at[camion],horasalida] =
cargapizzas(at[camion]), entrega;
{--pérdidas por impaciencia--}

outofstock: TERMINATE 1;
perdido: TERMINATE 1;
{--Informar de resultados en una tabla--}

DEBUG Tablas do GENERATE Tiempo,1;
DEBUG Tablas do COMPUTE zz = resultados;
DEBUG Tablas do TERMINATE 0;
Endsystem;
El modelo genera pedidos con una distribución entre pedidos expo-

nencial, de parámetro tDemanda (un dato). A continuación, la función
CargaAtributosDemanda carga en los atributos de la transacción
las características del pedido, las coordenadas (x, y) del punto en que se
origina la demanda, la hora a la que se produce y el tipo de pizza pedi-

do. La función FindCamion trata de encontrar un camión que cumpla
con los requisitos establecidos en el caso. Si lo encuentra, devuelve su
número, que se guarda en un atributo de la transacción, para usarlo lue-
go. Si no lo logra, puede ser por dos razones. Primero, puede haber un
camión que incluso yendo al deposito a cargar, llegue a tiempo de ser-
vir al cliente en el tiempo deseado. Si lo hay, se devuelve el número del
camión en negativo, para indicar que tiene que ir primero a casa a re-
postar pizzas. O puede ser que no haya camión a una distancia factible,
en cuyo caso se da por perdido el pedido.
Si hay que ir al centro, el camión se pone en movimiento (el bloque
ENTER bloquea el camión elegido), espera el tiempo de tránsito, y una
vez pasado éste, recarga el camión mediante la función Cargapizzas. Si

en el proceso de recarga de un tipo de pizza se encuentra que la edad de
alguno de los tipos en el camión supera un tiempo dado, antigüe-
dad, también se sustituye este tipo de pizza eliminando todas las unida-
des del mismo. El camión sale para dirigirse a la ubicación del pedido,
presumiblemente la casa del cliente. La impaciencia en el ENTER hace
que si el camión se ha hallado, pero no queda disponible en un tiempo
maxespera, el proceso se abandone y el pedido se pierda.
Cuando se ha encontrado un camión con la pizza adecuada, el pedi-
do bloquea al camión mediante un bloque ENTER. De esta forma el ca-
mión puede dirigirse a casa del cliente (bloque WAITFOR) y entregar el
pedido. Los tiempos de tránsito se muestrean de una distribución Er-
lang(x,2) para que tengan algo menos de variabilidad que en el caso ex-
ponencial.
Una vez completada la lógica fundamental podemos pasar a escribir
las funciones que implantan el detalle. El lector observará que la im-
plantación que hemos hecho no reproduce totalmente la realidad. Esto
es parte del espíritu de la metodología: llegar a un primer modelo lo
más rápidamente posible. Ahora deberá empezar el proceso de refina-
miento, que dejamos al lector como ejercicio. Aún con sus limitaciones,
el modelo tiene un poder explicativo importante, que explotaremos en
la sección siguiente.
Aquí tiene el lector las funciones que implementan los detalles.
Cuadro 2
Modelo «Caruso». Sección Macros
Macros
{--usamos la distancia l1(manhattan distance)--}

distance :function(x0,y0,x1,y1) return abs(x0-x1)+abs(y0-y1);
{--halla un camion disponible, que tiene pizza del tipo deseado y más cer-
ca de la demanda. Incluye la posibilidad de ir a repostar para los que no
tienen la pizza adecuada. Si ninguno la tiene manda a repostar al más cer-
cano. Devuelve el número de camión (positivo) si hay un camión que tiene
la pizza, y el mismo número pero negativo si hay que ir a repostar --}
findcamion : function (tipopizza,timedist)

Locals xx,i,hay,k,zz,acasa;
begin
xx = 9999999,
k = 0,
acasa = False,
for i = 1 to numfurgo do
if fc[i] == 0 then begin
punto = &camiones[i,1],
stockpizza = &camiones[i,stocks],
tiempoPizza = &camiones[i,tiempos],
hay = (stockPizza[tipopizza] > 0) and
((cl-tiempoPizza [tipopizza]) <= duracion),
if hay then zz = distance(at[posx],at[posy],
punto[posx],punto[posy])/velocidad
else zz = (distance(at[posx],at[posy],0,0)+
distance(0,0,punto[posx],punto[posy]))/velocidad +
tcarga,
if (zz < xx) then begin
xx = zz,
k = i,
acasa = (not hay)
end
end,
^(timedist)= xx,
if acasa then k = -k,
return k
end;
CargaAtributosDemandayCamion: function()
begin
at[hora] = at[1],
at[tipo] = Random(1,numpizzas+1),
at[posx] = Uniform(-xmax,xmax),
at[posy] = Uniform(-ymax,ymax),
at[camion] = findcamion(at[tipo],&at[distancia]),
return True
end;
IraCasoSegunDisponibilidad:function()
begin
if at[camion]>0 then return cb+1
else if at[camion] == 0 then return perdido
else begin
at[camion] = - at[camion], return reponer

end
end;
cargapizzas :function(num)
Locals j,zz;
begin
{--preparación de las variables--}
stockpizza = &camiones[num,stocks],
tiempoPizza = &camiones[num,tiempos],
{--mirar todos los tipos de pizza. Si su antigüedad es superior a
antigüedad reponerlos. Lo mismo si su nivel ha bajado por debajo
de smin --}
for j = 1 to numpizzas do begin
if (cl-tiempoPizza[j]) > antiguedad then begin
desperdicio = desperdicio + stockpizza[j],
stockpizza[j] = 0
end,
if stockpizza[j] <= smin[j] then begin
totalCargado = totalCargado + smax[j]-stockpizza[j],
stockpizza[j] = smax[j]
end,
tiempopizza[j] = cl
end,
numcargas = numcargas + 1,
DEBUG mapa do zz = FDrawXY(6,num,0,0),

DEBUG dibuja do if (totalCargado > 0) then
zz = Fdrawxy(1,1,cl,desperdicio/totalCargado),
DEBUG dibuja do zz = FdrawXY(2,1,cl,cl/numcargas),
return cl
end;
realizaEntrega:function(cami,tip)
Locals z;
begin
punto = &camiones[cami,1],
stockpizza = &camiones[cami,stocks],
punto[posx] = at[posx],
punto[posy] = at[posy],
DEBUG mapa do z = FDrawXY(6,cami,punto[posx],punto[posy]),
distTotal = at[distancia],
stockpizza[tip] = stockPizza[tip]-1,
entregas = entregas + 1,
return True
end;
CalculaEstadisticas:function ()
Locals zz;
begin
DEBUG dibuja do zz = FdrawXY(5,1,cl,
statvar(&distTotal,SAVERAGE)*velocidad),
if (cl-at[hora]) > tservicio then begin
numretrasos = 1,
retraso = cl-at[hora]-tservicio,
DEBUG dibuja do zz = FdrawXY(3,1,cl, statvar(&retraso,SAVERAGE)),
DEBUG dibuja do zz = FdrawXY(4,1,cl,
statvar(&numretrasos,SAVERAGE))
end else numretrasos = 0,
Return True
end;
A estas alturas el lector debe ser capaz de entender perfectamente

estas funciones, por lo que omitimos cualquier comentario adicional.
Resultados
Veamos los resultados de este modelo y qué nos dicen con respecto
a los problemas de Caruso. Iniciamos el análisis básico considerando un

solo tipo de pizza, y un stock de 10 pizzas en el horno del camión.
Figura 2
TIEMPO entre RECARGAS PORCENT AJE de DESPERDICIOS
40 0,12
35 0,10
30
0,08
25
20 0,06
15 0,04
10
0,02
5
0 0,00
-5 -0,02
0 1000 2000 3000 4000 5000 0 1000 2000 3000 4000 5000
X axis X axis
PORCENTAJE de ENTREGAS RETRASADAS DISTANCIA MEDIA RECORRIDA

0,055 50
0,050
45
0,045
0,040 40
0,035
35
0,030
0,025 30
0,020
25
0,015
0,015 20
0 1000 2000 3000 4000 5000 0 1000 2000 3000 4000 5000
X axis X axis
En esta simulación la demanda es de 1 pedido cada 3 minutos. Su-

ponemos que cada pedido es por 1 sola pizza.
Figura 3
Tabla de procesadores
El porcentaje de pedidos retrasados es de un 6%. Si suponemos que

son aceptados por el cliente, esto no perjudica la productividad, la ren-
tabilidad del negocio. Pero sí lo hace, y gravemente, con la competitivi-
dad, la percepción que tiene el cliente del servicio de la empresa.
La demanda total de pizza por hora es en promedio 60/3 = 20 uni-
dades y por tanto de 20/4 = 5 pizzas por camión. Si se cargan en prome-
dio 10 pizzas, y una pizza dura en promedio dos horas, habrá que ven-
der 5 pizzas por hora en promedio para no tener que tirar pizzas. Y este
valor coincide exactamente con la demanda. Por tanto el sistema está
perfectamente equilibrado en cuanto a capacidad de producción. Si se
opera perfectamente, no debería haber desperdicio alguno. Pero esto su-
pone que toda la demanda se atiende, es decir, que no se pierden pedi-
dos por problemas de plazo de entrega.
Contar los pedidos que se pierden no es fácil sin la simulación. Por
tanto acudamos a los resultados. Según la cuenta de los bloques TER-
MINATE, durante los 5.000 minutos de tiempo de simulación se han
entregado 1.116 pizzas. Se han cargado 1.370 (según la variable To-
talCargado) Por tanto se han tenido que tirar 1.370-1.272= 98 piz-
zas, o un desperdicio de 98/1.370 = 7%.
Pero veamos qué sucede si se cargan dos tipos de pizza. Suponga-
mos que la demanda se reparte igualmente entre ambos tipos. Divida-
mos también la carga en dos partes iguales, 5 pizzas de cada tipo.
Figura 4
PORCENTAJE de ENTREGAS RETRASADAS PORCENT AJE de DESPERDICIOS
0,055 0,16
0,050 0,14
0,12
0,045
0,10
0,040
0,08
0,035 0,06
0,030 0,04
0,02
0,025
0,00
0,020 -0,02
0 1000 2000 3000 4000 5000 0 1000 2000 3000 4000 5000
X axis X axis
Aunque el tiempo entre visitas al centro de producción parece ser

aproximadamente el mismo, el porcentaje de desperdicio ha crecido, y
ahora es del 15%. Y si añadimos un nuevo tipo de pizza, con un total de

3 tipos, el porcentaje de desperdicios se eleva a un 23%. Este fenómeno
se origina en la división de la demanda, lo que, al obligar a repartir el
stock de seguridad, hace que no se alcancen los mismos niveles de pro-
tección que consigue el stock total con la demanda consolidada. Al cre-
cer el número de productos, crece el número de roturas de stock, y por
tanto crecería el número de veces que el camión debería ir a repostar. Sin
embargo, como el porcentaje de roturas que encuentran al camión a más
de una distancia, depende poco del número de tipos de pizza, ahora se re-
chazarán más pedidos, por no poder servirse en el tiempo deseado.
La operación del sistema será de parecida eficiencia, o incluso me-
jor. Con tres productos, los camiones tienen un tiempo entre recargas de
unos 35 minutos, dando un intervalo entre visitas al centro de un camión

de 140 minutos. El porcentaje de entregas retrasadas disminuye desde el
4,2% al 3%. La dirección podría pensar que todo va mejor. Y esto es así,
en apariencia, porque el filtro del tiempo de servicio hace desaparecer
más pedidos en origen, y por tanto el sistema está menos cargado. La
venta disminuye pero la dirección puede concluir que esto es achacable
al mercado, especialmente si no queda constancia de los pedidos que no
se pueden atender por un mal tiempo de respuesta. También disminuye
la ocupación del camión desde el 56% con 1 tipo, al 54% con 3 tipos.
¿Qué se puede hacer? ¿Aumentar la velocidad de los camiones?
¿Arreglará esto algo? ¿Y cómo se puede hacer? El lector puede explo-
rar el sistema analizando posibilidades.
Aunque los refinamientos le darán una mejor perspectiva, verá que
el diagnóstico general ya está perfectamente establecido. El sistema está
mal planteado. Obliga a tener stocks de seguridad perecederos en un al-
macén móvil, la camioneta. El fenómeno de la división de demanda, al
que nos hemos referido más arriba, se agrava por estas dos circunstan-
cias. Caruso cayó en la trampa tecnológica, usando una tecnología poco
adaptada a su proceso productivo y de servicio. Posiblemente debe re-
plantearse el problema desde el principio: ¿Cómo atender a los clientes
en flexibilidad (la pizza que quieran) y en rapidez? Producir a medida,
Just In Time, parece ser la única alternativa viable.
El potencial de desastre de la situación de Caruso es grande, pero
difícil de ver sin un análisis del tipo que hemos hecho. Esta es otra ven-
taja de la simulación en la empresa: ayudar en el diagnóstico de los
motivos, en casos complicados. En Caruso, la dirección sólo se ha alar-
mado por el aumento de los desperdicios y la disminución de los bene-
ficios, sin entender el problema. Con la simulación hemos logrado en-
tenderlo. Lo de menos son los números concretos, y hasta la precisión
del modelo.
En estas condiciones, ¿vale la pena refinar el modelo? Creemos que

no. Que la diferencia serán unos puntos en los porcentajes, pero proba-
blemente no un mejor entendimiento de la naturaleza del problema. Y
refinarlo toma tiempo de diseño, de programación y de análisis. En
nuestra experiencia el balance se inclina siempre hacia modelos senci-
llos y rápidos de preparar y entender 7.
7. Una vez vimos un modelo de una factoría tan detallado, que simulaba a veloci-
dad menor que el sistema real. Se tardaba una hora en simular media hora de proceso de
la factoría. Costaba tanto entenderlo que se terminó abandonando, ante la imposibilidad
de saber lo que hacía. Sus propios creadores renunciaron a comprenderlo...
CASO 2
DONNER COMPANY1
Donner Company se dedica a la fabricación de circuitos impresos,

de acuerdo con las especificaciones exigidas por los fabricantes de apa-
ratos electrónicos.
Cada circuito consiste en una delgada plancha de material aislante,
en cuya superficie aparecen unas finas tiras de metal (conductores). La
plancha aislante sirve como medio estructural para la colocación de los
componentes eléctricos, y los frágiles conductores que los conectan en
una red eléctrica.
El proceso de fabricación de un circuito impreso tiene tres etapas.
Durante la primera etapa, se estudian los planos, y se preparan cintas de
ordenador y las materias primas. En el paso siguiente, transferencia de
imágenes, se transfiere el plano de los conductores a una base de dieléc-
trico (aislante). En la tercera etapa, se corta y da forma a la base, hasta
conseguir los circuitos impresos. La secuencia de las operaciones más
corriente se muestra en la tabla 1.
Fase de preparación
En esta fase se realiza un negativo del patrón original de los circui-
tos en un pedido de un cliente, sobre unos paneles. En cada panel caben
varios circuitos. Dependiendo del tamaño de los paneles, la imagen del
circuito se suele copiar un número de veces para aumentar el número de
circuitos por panel.
El material de los paneles consiste en láminas de plástico epoxi, re-
vestidas por las dos caras con una delgada capa de cobre. Se compra en
1. Donner Company, Caso P-776, División de Investigación del IESE, Barcelona,

1991.
grandes láminas que deben ser inspeccionadas y cortadas al tamaño

adecuado. El número normal de circuitos por panel es de 8.
Por último en los paneles se taladran los orificios que sirven para la
sujeción en la siguiente fase de fabricación.
Fase de transferencia de imagen
En primer lugar se perforan aproximadamente 500 orificios por pa-

nel, de forma manual en una de las siete taladradoras de Donner, o au-
tomáticamente con una máquina de control numérico (OCN) de gran
velocidad. Si se hacen manualmente, el operario sujeta los paneles a la
mesa de taladrado, utilizando como referencia los orificios realizados
en la fase de preparación anterior y perfora los agujeros valiéndose de
un taladro de mano. En cambio, la máquina OCN selecciona automáti-
camente las herramientas y perfora los orificios en las posiciones co-
rrectas. La perforación y la selección de las herramientas se realizan por
medio de coordenadas (x, y), especialmente programadas y almacena-
das en un disquete.
Después, los paneles se someten a un baño de cobre. Este proceso
se llama metalización.
Tras la metalización, los paneles se lavan, cepillan y cubren con una
película fotosensible. El negativo de los planos del cliente se sitúa sobre
las láminas recubiertas, y se expone el conjunto a la luz ultravioleta. A
continuación se tratan con una máquina que elimina la película aislante
que ha quedado expuesta a la luz ultravioleta.
Después los conductores de cobre, ahora descubiertos, son galvani-
zados. Por último se elimina, por medios químicos, todo el cobre que no
ha sido galvanizado.
Fase de fabricación
Se incorpora una máscara de soldadura, que deja una película pro-

tectora epóxi sobre los conductores. Los orificios galvanizados no se
cubren por la máscara de la soldadura. Se incorporan los componentes
electrónicos a los circuitos, y cada panel se introduce en baño de solda-
dura caliente, con lo que el cobre desnudo de los orificios queda cubier-
to con soldadura.
El siguiente paso consiste en cortar los circuitos impresos del panel y
reducirlos a la forma y tamaño deseados. Esto se hace con la OCN o bien,
para lotes más pequeños, con una prensa estampadora de 20 toneladas.
CASO 2. DONNER COMPANY 577
Por último se inspeccionan visualmente los circuitos, se prueban

electrónicamente, se empaquetan y se envían al cliente.
Aunque este proceso es el más normal, a menudo se modifica según
las especificaciones de los clientes. Además, los circuitos especiales re-
quieren la realización de pasos adicionales.
La empresa ha establecido la política de entregar los pedidos llega-
dos durante un mes, dentro del mismo mes. Esta política, en opinión de
la dirección, es un arma competitiva importante en un mercado tan difí-
cil como el de la fabricación de circuitos impresos.
Tabla 1
Tiempos de producción estándar del proceso
Operación Preparación Realización
PREPARACIÓN
Generación de planos 29 0,000
Inspección 20 0,500a
Agujereado para herramientas 10 0,500a
TRANSFERENCIA DE IMAGEN
Perforado
Manual 15 0,080b
ONCe 240c 0,004b
Metalización 10 0,750a
Película de secado fotorresistente
1. Preparación panel 5 0,200a
2. Lámina Epoxi 20 0,200a
3. Revelado 20 0,200a
Galvanizado 25 8,500a
Tiras PSFR 5 0,200a
Ataque químico 10 0,200a
FABRICACIÓN
Máscara de soldadura 45 1,500a
Baño de soldadura 30 0,500a
Perfilado
Estampadora 50 1,000d
ONC 150c 0,500d
Inspección, test, empaquetado 45 1,500d
a) Por panel; un panel típico tiene 8 circuitos impresos.

b) Por orificio; un circuito típico tiene 500 orificios.
c) Este tiempo de preparación corresponde casi totalmente al tiempo de preparación de control del
ordenador.
d) Por circuito.
e) La política de la distribución en planta de las instalaciones obliga a que sólo se pueden realizar
en este equipo pedidos superiores a 100 circuitos impresos.
El modelo
Con PSPS simularemos el proceso de fabricación de los circuitos

impresos de Donner. Para ello manejaremos la secuencia de operacio-
nes y los tiempos de proceso descritos en la tabla anterior.
La empresa nos ha proporcionado una lista de pedidos en un deter-
minado mes. Estos pedidos se usarán para obtener una distribución de
probabilidad del tamaño del pedido. Para ello se ajusta una distribución
de probabilidad al histograma de los tamaños de pedido de la muestra
suministrada. Ésta es una técnica general, para ajustar distribuciones de
probabilidad. En nuestro caso el mejor ajuste se logra con una distribu-
ción logarítmico normal con media 92 y coeficiente de variación 2,1.
Adicionalmente asumiremos que, como ha sucedido en meses anterio-
res, el número total de pedidos llegados por mes es de 60.
1. Curvas de input-output
En este modelo vamos a manejar stocks. Este tema se ha tratado en

profundidad en los capítulos 14 y 15, y podríamos usar las técnicas de-
sarrolladas allí. Pero, aprovechando la ocasión que nos brinda Donner,
vamos a introducir maneras de proceder, que ponen de manifiesto pro-
piedades adicionales del stock, y no únicamente el volumen del mismo.
Para ello, vamos a usar un concepto muy importante por derecho propio
en las Operaciones, y por ende en la simulación, que ya anunciamos en
el capítulo 15, las curvas de input-output.
Dado un procesador cualquiera, a lo largo del tiempo entran y salen
transacciones (o ítems) del mismo. Para todo procesador sometido a
operaciones de entrada y salida, se pueden calcular y dibujar las curvas
de entradas acumuladas y de salidas acumuladas, que llamaremos res-
pectivamente la curva de input (entrada acumulada) y de output (salida

acumulada). En la figura siguiente mostramos un ejemplo:
Figura 1
Curvas de input/output
125
Curva de input
100
75
Curva de output
50
25
0 1 2 3 4 5 6 7
Ambas curvas son crecientes. El lector debe convencerse de que su

diferencia, la distancia vertical entre ambas curvas, es el stock. Por tan-
to, el stock puede leerse directamente de las curvas de input-output, sin
necesidad de realizar construcciones adicionales. Pero aún hay más. De
las curvas, también puede leerse directamente el tiempo que un determi-
nado ítem permanece dentro del procesador, siempre que supongamos
que las entradas y salidas son Fifo. En este caso, el tiempo de estancia
de un ítem es la distancia horizontal entre las dos curvas, medida para el
número de ítem en cuestión. Para comprender por qué, el lector puede
imaginar que a la llegada de un ítem lo estampillamos con un número
correlativo (ordenada de la curva de input). La salida se producirá cuan-
do llegue el turno de ese número, es decir cuando la ordenada de la cur-
va de output coincida con el valor estampillado. Y la diferencia entre es-
tos dos momentos es el tiempo de estancia.
La próxima figura resume estas dos importantes propiedades.
Figura 2
Propiedades de las curvas de input/output
125
Curva de input
100
75
Curva de output
50
Ítem número
Tiempo de estancia
25
stock
0 Instante de llegada
0 1 2 3 4 5 6 7
El stock medio es fácil de calcular dividiendo el área entre ambas cur-

vas (área sobreada) por el tiempo. De la misma forma puede calcularse el
tiempo medio. Nótese que, por definición, si el stock debe mantenerse fi-
nito (¡y debe!), ambas curvas sólo se pueden separar durante un tiempo,
luego tienen que volver a juntarse. De hecho, la pendiente media de ambas
curvas debe ser idéntica, en promedio y a largo plazo. Pero la pendiente

media de una curva es simplemente la velocidad media correspondiente.
La figura muestra también la profunda relación que hay entre tiem-
pos y stocks, y que ya hemos estudiado en los capítulos 14 y 15. Pero
ahora es perfectamente general, no únicamente patrimonio de un fenó-
meno de servicio. Si hay stocks en un lugar es porque los ítems pasan
un tiempo allí. Si algo pasa un tiempo en un depósito, allí se formará un
stock. Por tanto stocks y tiempos son dos caras de la misma moneda.
Tanto da analizar stocks como tiempos.
Esta dualidad queda reflejada por medio de una sencilla relación en-
tre el stock promedio y el tiempo de estancia medio. En efecto, se cum-
ple que:
Stock Medio = Área /Tiempo

Espera Media = Área/total entrado
Despejando Área en la segunda expresión y sustituyendo en la pri-
mera se obtiene:
Velocidad media Tiempo medio

Stock promedio
= de entrada/salida * de estancia
a largo plazo
a largo plazo a largo plazo
O en símbolos, llamando λ al valor de la velocidad media de entra-

da a largo plazo (que debe ser igual a la de salida, por lo que hemos co-
mentado anteriormente), N al stock medio y W al tiempo de estancia
medio:
N=λW
Esta es, de nuevo, la Ley de Little, que hemos utilizado profusamen-

te en el capítulo 11. Pero ahora, como puede verse, el razonamiento ba-
sado en las curvas de input-output muestra que la Ley de Little es per-
fectamente general, y usable para el análisis a largo plazo de cualquier
procesador, de cualquier stock, no sólo de una cola.
Si la disciplina de servicio no es Fifo, en concreto si se producen
adelantamientos, la estancia no se puede leer por la distancia horizontal.
Sin embargo el stock medio se calcula de forma idéntica a partir del
área entre las dos curvas, y como consecuencia el tiempo medio de es-
tancia es igualmente calculable como la distancia media horizontal. La
ley de Little es igualmente válida.
Una propiedad muy importante que se deduce inmediatamente de

las curvas de input/output, está relacionada con las disciplinas de espe-
ra. Supongamos que dos disciplinas de espera son tales que el área com-
prendida entre sus curvas de input/output es exactamente la misma. Este
tipo de disciplinas son aquellas que cambian prioridades, sin cambiar la
cantidad total de trabajo a realizar por el sistema. Como el área no cam-
bia, deducimos que todas estas disciplinas tienen el mismo valor medio
del stock y el mismo tiempo medio de espera.
La curvas de input/output son una herramienta excelente para anali-
zar stocks y tiempos simultáneamente. La única dificultad práctica es
que si se dibujan para un intervalo de tiempo grande, y si el dibujo es
pequeño, es difícil distinguir una curva de otra. Esto sucede porque, a
largo plazo, el input y output acumulados son siempre mucho mayores

que el tamaño del stock. A largo plazo, este (si se mantiene finito) es des-
preciable frente a los acumulados, que crecen sin límite. Por tanto, las
curvas de input-output se deben usar siempre sobre pequeños intervalos
de tiempo, siendo entonces de gran utilidad para examinar el comporta-
miento detallado del sistema.
En el modelo de Donner vamos a utilizar las curvas de input/output
para llevar la cuenta de los stocks.
2. Programa del modelo
Al igual que en casos anteriores, el programa estará formado por

más de un fichero. En DonerDatos.pss se definen las secciones Cons-
tants, Labels, Variables y Macros. Las variables definidas aquí serán
inicializadas en la sección Data del modelo.
Cuadro 1
Modelo «Donner». Fichero DonnerDatos.pss
FICHERO: DONNERDATOS.PSS
Constants
NProcesadores = 17; {--Número de procesadores que hay en el modelo--}
PerforaManual = 4; {--Procesador de la perforación manual de paneles--}
PerforaONC = 5; {--Procesador de la perforación automática--}
PerfilEstamp = 15; {--Procesador del perfilado por estampación--}
PerfilONC = 16; {--Procesador del perfilado en ONC--}
InspecFinal = 17; {--Procesador que representa la inspección final--}
Ts = 1; {--Índice del Tiempo de preparación de un lote en una operación--}
Tp = 2; {--Índice del Tiempo de proceso de un ítem en una operación--}

N = 3; {--Índice de Paneles en cada ítem procesado en una operación--}
{--Atributos de una transacción--}

AtLote = 2; {--Tamaño del lote--}
AtPuesto = 3; {--Número del puesto que está procesándose--}
AtTtotal = 4; {--Tiempo total de operación--}
AtToper = 5; {--Tiempo de la operación actual--}
Labels
Proceso; {--Bloque en el que comienza el proceso de producción--}
Variables
Tiempos ARRAY NProcesadores,3 ;{--Características de cada operación--}
PMedia; PVar; {--Coeficientes de la distribución LogNormal--}
Media; CoefVar; {--Media y Coef. variación del tamaño pedido--}

CurvaIn; CurvaOut; {--Curvas de input y output de los pedidos--}
CurvaInPan; CurvaOutPan; {--Curvas de input y el output de los paneles--}
TotalTime; {--Tiempo total de la simulación--}
Rate; {--Tasa de llegada de los pedidos--}
Decision; {--Tamaño de lote para utilizar OCN--}
Abierto; {--Tiempo del mes durante el que se aceptan pedidos--}
Ciclo; {--Total de minutos productivos del mes--}
@--- Variables auxiliares ---@
i; aux;
Macros
{--Cálculo del tiempo de operación total para un número de paneles dado--}
tiempo : function(numoper,lote)
if (tiempos[numoper,n] < 10000) then
return tiempos[numoper,ts] +
tiempos[numoper,tp]*Lote/tiempos[numoper,n]
else return tiempos[numoper,ts];
{--distribución del tamaño del lote--}

Lotsize : function () Return LNormal(pmedia,pvar);
{--Tiempo entre generación de pedidos. Al acabar el tiempo de pedido de-

mora hasta el inicio del siguiente mes--}
genera : function(periodo, open)

if mod(cl,periodo)< open then return rate
else return rate+periodo-mod(cl,periodo);
{--Devuelve la próxima estacion de proceso en el recorrido de un pedido--}

proximaEstacion: function(actual)
Locals proxima;
begin
if (actual == PerforaManual) or (actual == PerfilEstamp)
then proxima = actual + 2
else proxima = actual + 1,

if (proxima == PerforaManual) and (at[atLote] > decision)
then proxima = PerforaONC,
if (proxima == PerfilEstamp) and (at[atLote] > decision)
then proxima = PerfilONC,
return proxima
end;
{--Calcula y presenta las estadísticas del pedido--}

estadisticas : function()
begin
Fdrawxy (1,1,at[atLote],cl-TrTime-at[atTTotal]), {--Retraso vs lote--}
if at[atlote] < decision then Fdrawxy (2,1,cl,cl-TrTime-at[atTTotal])
else Fdrawxy (2,2,cl,cl-TrTime-at[atTTotal]), {--Retraso del pedido--}

curvaout = curvaout +1,
curvaoutPan = curvaoutpan + at[atLote],
Fdrawxy (3,1,cl,curvain-curvaout), {--total de pedidos en curso--}
Fdrawxy (4,1,cl,curvainPan-curvaoutPan), {--total circuitos en curso--}
return True
end;
Funciones del modelo
Tiempo (Noperacion, Lote): esta función calcula el tiempo de eje-

cución de una operación en función de los datos de la matriz de Tiem-
pos definida en la sección Data del programa. La matriz Tiempos es una
variable array de 17 filas y 3 columnas. Las filas indican la operación. La
primera columna es el tiempo de preparación, la columna segunda el
tiempo de realización de la operación por unidad de ítem, y la última co-
lumna el número de paneles que forman el ítem que se procesa en el
puesto. Por ejemplo la operación 3, agujereado, tiene un tiempo de pre-
paración de 10 min. y 0,5 min. por lámina como tiempo de proceso, una
lámina que contiene 8 circuitos. Las unidades de pedido del cliente son
siempre circuitos, y por lo tanto se requiere un cambio de unidades en
muchas de las operaciones. El tiempo de proceso de una operación
será siempre el tiempo de preparación más el tiempo de realización, y
este último dependerá del tamaño del pedido.
LotSize( ): devuelve el tamaño del pedido pasado por el cliente,
que sigue una distribución LogNormal.
Genera ( Periodo, Open): esta función se encarga de generar la
llegada de los pedidos según la tasa media de llegadas, un pedido por
hora, y el instante de tiempo en el que nos encontramos. Un mes son
9.600 min. y la compañía acepta pedidos durante los 9.600 primeros mi-
nutos del mes. Sin embargo, como el tiempo necesario para producir los
pedidos de un mes parece que va a ser mayor que 9.600 (requiriendo
horas extra) vamos a permitir hasta 15.000 min al mes de producción.
Esto permitirá simular el síndrome de final de mes, la acumulación de
trabajo a final de mes cuando la empresa se da cuenta de que no ha po-
dido servir todos los pedidos recibidos. En todos los casos, si llega un
pedido más tarde del momento 9.600 se pasará al mes siguiente.
Mediante la función Mod (Cl, Periodo) calculamos el minuto del
mes en el que nos encontramos. Si es menor que 9.600, entonces la
función devuelve el tiempo hasta la próxima llegada, Rate, que en este
caso es determinista ya que suponemos que los pedidos llegan de for-
ma uniforme. Esto seguirá así hasta agotar los 60 pedidos del mes, a ra-
zón de un pedido cada 9600/60 minutos. En este momento, la función

devolverá un intervalo que lleva la simulación al primer instante del mes
siguiente.
ProximaEstacion(actual): devuelve la estación de trabajo a la que
un pedido debe dirigirse para realizar la próxima operación. Normalmen-
te es actual + 1, pero hay estaciones alternativas, y se eligen unas u
otras en función del tamaño del pedido, usando una variable de deci-
sion. Fijando esta variable, los pedidos se envían a un puesto o a otro,
en función de su tamaño.
estadísticas(): recoge estadísticas del tiempo de estancia en la fá-
brica y del retraso, entendido como el tiempo que el pedido está en fá-
brica sin que nadie trabaje sobre él.
En el fichero System.pss se incluye la definición de la sección Sys-

tem del modelo. Este fichero contiene como comentario activo el fiche-
ro DonnerInfo.pss, que define la tabla que se utiliza como informe final
de la simulación.
Destaquemos también la presencia bajo los focos de cuatro variables
clave, asociadas en dos pares: (CurvaIn, CurvaOut) y (CurvaInpan,
CurvaOutpan). El primer par se refiere a pedidos y el segundo a pa-
neles. Estas variables son todo lo que se necesita para manejar las cur-
vas de input/output. CurvaIn y CurvaInpan llevan las curvas de
entrada y las otras dos, CurvaOut y CurvaOutpan, las de salida.
Unas se incrementan cuando se produce un ingreso. Las otras cuando se
produce un egreso.
Inicialmente supondremos que el sistema está vacío, es decir no hay
ningún pedido en marcha. Como ya hemos dicho, la producción de cada
mes, si es necesario, sigue más allá de los 9.600 minutos, hasta haber
agotado todos los pedidos. Por supuesto esto sucederá si en los 15.000
minutos posibles hay tiempo suficiente para producir todos los pedidos.
Al finalizar el mes la fábrica estará vacía, exactamente igual que al prin-
cipio de la simulación. Por tanto, en el segundo mes la simulación par-
tirá del mismo estado que tenía al inicio.
Cuando, para un modelo, este es el caso, se dice que el modelo es
regenerativo, o también que la simulación es regenerativa. El sistema
se regenera cada final de mes, cada evento de regeneración, y vuelve a
ser una réplica (probabilista) del sistema inicial. Esto tiene la importan-
te propiedad de hacer que los meses consecutivos sean independientes
desde el punto de vista estadístico. Por tanto, y dado que todos los ele-
mentos del modelo son estacionarios, meses consecutivos son observa-
ciones independientes de la misma distribución de probabilidad. En
esta propiedad se pueden basar métodos más sofisticados para estimar

el error estadístico de la simulación. No podemos llevar este tema más
allá, pero el lector interesado debe consultar [Iglehart].
Cuadro 2
Modelo «Donner». Fichero System.pss
FICHERO: SYSTEM.PSS
System
{--Genera durante 9600 minutos los 60 pedidos de forma repetitiva.
Pero el mes es de 15000 minutos para absorber el síndrome de final
de mes--}
GENERATE genera(ciclo,abierto),On;
ASSIGN begin
at[AtLote] = Lotsize,
at[AtPuesto] = 0,
at[atTTotal] = 0
end;
COMPUTE begin
curvain = curvain + 1,
curvainPan = curvainPan + at[atLote]
end;
{------Proceso de un lote de circuitos------}

{----- Routing------}
proceso: COMPUTE at[atPuesto] = ProximaEstacion(at[atPuesto]);
{---- Las estaciones-----}
QUEUE at[atPuesto],1,Fifo,wait,Off;
ASSIGN begin
at[atTOper] = tiempo(at[atPuesto],at[atLote]),
at[atTTotal] = at[atTTotal] + at[atTOper]
end;
WAITFOR at[atTOper];
LEAVE at[atPuesto],1,Cond(at[atPuesto] == InspecFinal,cb+1,Proceso);
@---- Estadisticas------------------------------------@
COMPUTE Estadisticas;
TABULATE 2,cl-TrTime-at[atTTotal]; {--Esperas improductivas--}
TABULATE 1,cl-TrTime; {--Plazo de entrega--}
TERMINATE 1;
@$DonnerInforme.pss@
endsystem;
Cuadro 3
Modelo «Donner». Fichero DonnerInfo.pss
FICHERO: DONNERINFO.PSS
{----- Informe final -----}
GENERATE TotalTime,1;
COMPUTE begin
GotoXY(1,1,0),
For i = 1 to NProcesadores Do begin
PrintR(Format(“%4d”,i)),
Aux = StatFac(i,Staverage) / Fs[i] * Ciclo,
PrintR(Format(“%7.1f”, Aux)),
PrintR(Format(“%7.1f”, Aux / Abierto)),
PrintR(Format(“%7.2f”,StatQ(i,STaverage)+StatFac
(i,STaverage)))
End
End;
TERMINATE 1;
El fichero Donner.pss contiene la definición de la sección Data y

coordina todos los demás ficheros, usando comentarios activos.
Cuadro 4
Modelo «Donner». Fichero Donner.pss
FICHERO: DONNER.PSS
{$DonnerDatos.pss}
Data
{-- Inicialización de las variables definidas en la sección Variables --}

VARS Tiempos = \29, 0, 10000,
20, 5/10, 8,
10, 5/10, 8,
15, 8/100, 1/500,
240, 4/1000, 1/500,
10, 75/100, 8,
5, 2/10, 8,
20, 2, 8,
20, 2/10, 8,
25, 85/10, 8,
5, 2/10, 8,
10, 2/10, 8,
45, 15/10, 8,
30, 5/10, 8,
50, 1, 1,
150, 5/10, 1,
45, 15/10, 1\;
VARS Media = 92;
VARS CoefVar = 210/100;
VARS Rate = 9600/60;
VARS Ciclo = 15000;
VARS Abierto = 9600;
VARS Decision = 100;
VARS TotalTime = 60000;
@ Capacidad de los procesadores @
VARS Fs[PerforaMAnual] = 7;
VARS Fs[PerforaONC] = 1;
{--definición de la tabla que aparece en el informe final--}
Table 1, nprocesadores+1, 4,
[“RESULTADOS”,“Num”,“Min.Usados”,“Rho Real”,“Ped.Medio”];
TIME TotalTime; {--Define el tiempo de terminación de la simulación--}
REPORT On; {--Detiene la simulación, hace aparecer la ventana de control--}
{--Sentencia de inicialización de los gráficos y la tabla del modelo--}

INITIAL begin
FdrawCont(1,GTitle,“RETRASO vs TAMAÑO PEDIDO”),
FDRawCont(1,GSerNoLine,1),
FdrawCont(2,GTitle,“RETRASO de cada PEDIDO”),
FDrawCont(3,GTitle,“Pedidos en el Sistema”),
FDrawCont(4,GTitle,“Paneles en el Sistema”),
FdrawCont(1,GserOrder,1),
PVar = SQRT(Ln (CoefVar * CoefVar + 1) ),
PMedia = Ln (Media) – PVar * PVar / 2,

End;
{--Fichero que contiene la sección System del modelo--}

{$DonnerSystem.pss}
Recordemos que tratamos de comprender los efectos del comporta-

miento de la empresa, especialmente los generados por la regla de en-
tregar todos los pedidos recibidos dentro del mes en el mismo mes.
Simularemos el funcionamiento de la compañía durante cuatro me-
ses. Como los tiempos de proceso vienen dados en minutos, tomaremos
como unidad del reloj de simulación los minutos, y cuatro meses serán
por tanto equivalentes a 60.000 minutos.
3. Resultados de la simulación
El gráfico de la figura 3 muestra los tiempos improductivos, tiempo

esperando en la planta durante el que no está siendo procesado, de cada
pedido en función del tamaño del pedido.
Figura 3
Tiempos de proceso vs tamaño pedido
Este retraso es el resultado de las interferencias con otros pedidos, y

si el pedido estuviera solo no se produciría. Los retrasos por panel en
los lotes grandes, a partir de 100 ítems (valor que determina la división
del proceso entre manual y automático) parecen ser sistemáticamente
menores que en los lotes pequeños. Éste es un indicio de la perturbación
que causan los grandes pedidos cuando se mezclan con pedidos peque-
ños.
El segundo gráfico (Figura 4) es un refinamiento del anterior ya que
ahora podemos ver la evolución del tiempo de retraso a lo largo del mes.
Figura 4
Retraso de los pedidos
Aunque la trayectoria es muy irregular, claramente aumenta a medi-

da que transcurre el mes, para disminuir de nuevo al principio del mes
siguiente. Esto es debido a la acumulación de pedidos por encima de la
capacidad del proceso, que aumenta la congestión, y las esperas. Es in-
teresante obtener este misma gráfica diferenciando los pedidos con lote
pequeño, de los pedidos con lote grande. He aquí la gráfica2:
Figura 5
Retraso de los pedidos
7000
6000
5000
4000
3000
2000
1000
-1000
0 1,0E+4 2,0E+4 3,0E+4 4,0E+4 5,0E+4 6,0E+4
X axis
2. No incluida en el modelo inicial, pero que el lector puede reproducir fácilmente

modificando la función Estadisticas().
La línea a trazos corresponde a pedidos con lote mayor que 100. La

continua son los demás pedidos. Los pequeños pedidos sufren menor
acumulación de retrasos al avanzar el mes, siendo el retraso relativa-
mente regular. Los pedidos grandes sufren más esperas a medida que
avanza el mes. Por tanto, si un cliente tiene un pedido grande debería
pasarlo a primeros de mes. Aunque para un pedido pequeño también se
aplica la regla, la diferencia es menos significativa.
Veamos la evolución de los stocks de pedidos y paneles en curso,
durante el mes:
Figura 6
Número de pedidos en el sistema
La gráfica 7 muestra el número de paneles en el sistema en el mo-

mento de la salida de un pedido, es decir los paneles que el pedido que
sale ha dejado atrás. La acumulación se produce de forma regular, de-
mostrando que el sistema no tiene capacidad para absorber la carga de
la demanda.
Figura 7
Número de paneles en el sistema
Para analizar la historia de cada pedido dibujamos las curvas de in-

put-output 3. Como dijimos, su utilidad disminuye a medida que aumen-
ta el horizonte de la simulación, por lo que las hemos restringido a un
solo mes.
La primera figura (8) muestra las curvas de I/O de pedidos. Cada
salto en una curva es la entrada, o salida, de un pedido. Las curvas
muestran los pedidos pequeños agrupados en pequeños núcleos, separa-
dos por pedidos grandes que los retrasan. El proceso de pedidos grandes
se nota por los aumentos bruscos de demora (distancia horizontal) entre
ambas curvas. Esto produce largos intervalos de tiempo en los que no
sale ningún pedido.
3. De nuevo, el programa presentado no incluye código para dibujar estas curvas,

pero el lector no tendrá muchos problemas para añadirlo al código presentado.
Figura 8
Input/output de los pedidos
70
60
50
40
30
20
10
-10
0 2000 4000 6000 8000 1,0E+4 1,2E+4 1,5E+4 1,6E+4
X axis
Figura 9
Input/output de los paneles
6000
5000
4000
3000
2000
1000
-1000
0 2000 4000 6000 8000 1,0E+4 1,2E+4 1,5E+4 1,6E+4
X axis
De las figuras se deduce que el tiempo de producción aumenta en

cantidades bruscas con los grandes pedidos, aunque disminuye cuando
se produce el proceso de pequeños pedidos. Las curvas muestran tam-
bién evidencia de que hay adelantamientos entre pedidos, y que por lo
tanto Fifo no es cierta. Esto hace que la lectura de las esperas se pueda
hacer sólo aproximadamente.
Veamos ahora la distribución de los tiempos de proceso de los pedi-
dos y la distribución del tiempo que permanece un pedido en el sistema,
o plazo de producción.
De hecho esta distribución es sólo orientativa. En este modelo no se
alcanza un régimen estacionario dentro del mes, y en cada momento de
tiempo los resultados provienen de poblaciones diferentes. El tiempo de
estancia tiene una fuerte dependencia del tiempo (la media va aumen-
tando con el tiempo) y por tanto el histograma no recoge observaciones
procedentes de la misma distribución. Un análisis por regresión sería
probablemente más útil. En cualquier caso, incluimos los histogramas
para satisfacer la curiosidad del lector 4.
Histograma 1: Histograma 2:
Tiempos de proceso Tiempo en el sistema
El fichero DonnerInfo.pss contiene las tablas que se usan para pre-

sentar al usuario los resultados resumidos (ver figura 10). Se dan resul-
tados para cada uno de los puestos de trabajo. Las diferentes columnas
son: los minutos utilizados (Min. Usados), la utilización del puesto de
trabajo (Rho Real), y el número medio de pedidos (Ped. Medio).
4. La tiene usted querido lector, ¿no? ¿No...? ¿De verdad?
Figura 10
Tabla informe final
Como en las colas, denotamos aquí por rho la tasa de ocupación del
centro. Esta tasa está calculada sobre las horas normales, durante las
que se admiten pedidos, 9.600 minutos en total. Puede verse que hay un
cuello de botella en el procesador 5, la ONC. Ésta debe trabajar un 20%
de tiempo adicional para poder atender toda la demanda del mes. Y esta
situación se da con un valor de la variable de decisión de 100 paneles.
Si se calcula la eficiencia de cada operación en términos del tiempo de
proceso unitario, se llega a la conclusión de que para tamaños del lote
inferiores a 100 también interesaría pasar la producción por la ONC.
Pero esto sólo haría que se agravaran las esperas. El cuello de botella en
la ONC provocaría aún mayores acumulaciones, y por tanto tiempo de
trabajo adicional al final del mes.
Queda para el lector usar la maquinaria presentada para evaluar qué
sucedería si se comprara otra ONC.
Digamos, para finalizar, que Donner debe decidir qué tipo de pe-
didos, con lote pequeño o lote grande, quiere tener. En el primer caso,
Donner será probablemente un proveedor de laboratorios e instituciones

que realizan muchas series cortas, de prueba o de productos especiales.
Probablemente para este segmento, la compañía necesita gran flexibili-
dad y un escrupuloso cumplimiento de los plazos de entrega. En el se-
gundo caso, estará entrando en el segmento de clientes de alto volumen,
por ejemplo, fabricantes de televisores, que eventualmente competirá en
precio. Mezclar las dos cosas normalmente llevará a no hacer ninguna
bien.
CASO 3
HERRERÍAS URANIO1
Herrerías Uranio fabrica bajo pedido piezas de materiales exóticos,

tales como titanio, uranio, etc., en pequeños lotes y usando distintos ti-
pos de máquinas herramienta. La compañía compite ofreciendo tiempos
de entrega cortos, y siendo capaz de producir una gran cantidad de dise-
ños. Para reducir al máximo la fecha de entrega, a la vez que las inver-
siones en equipo, el taller trabaja a tres turnos de 8 horas, con un total
de 30 empleados entre los tres turnos. Las máquinas de que dispone se
muestran en la tabla 1.
A medida que llegan los pedidos, y son aceptados por la empresa,
se mandan al departamento de ingeniería de producto. Este departa-
mento analiza las especificaciones, si es necesario pide los materiales
y herramientas especiales y determina la secuencia de operaciones que
hay que realizar, y en qué máquinas, para completar el trabajo. El de-
partamento prepara una hoja de ruta, en la que constan los tiempos es-
tándar de cada operación, hoja que se utiliza en la programación de la

producción. Debido a que cada pieza es diferente de las demás, los
tiempos de estándares se calculan por medio de unas complicadas fór-
mulas, que tienen en cuenta características de la máquina que realiza la
operación, la velocidad de mecanización propia del metal, etc. La pre-
cisión de estos tiempos es relativamente baja, y para aumentarla se pre-
cisarían cronometrajes, lo que es difícil debido a la poca repetitividad
de las operaciones.
1. RIVEROLA, J., Herrerías Uranio, Caso P-751, División de Investigación del

IESE, Barcelona, 1990.
Tabla 1
Máquinas disponibles
Tipo Número
Cantidad
de máquina de máquina
Sierra (SA) 1 1
Torno (EL) 2 1
Torno revolver (TL) 3 1
Limadora vertical (VM) 4 1
Limadora horizontal (HM) 5 1
Desbastadora (DE) 6 1
Perforadora (DR) 7 1
Fresadora (GR) 8 1
Horno tratamiento térmico (HT) 9 1
Inspección final (FI) 10 1
La empresa quiere lograr una alta utilización de sus centros de tra-

bajo. Pero los intentos de preparar un programa de producción no han
funcionado bien hasta ahora. Por ello, se está explorando suprimir toda
programación y sustituirla por una serie de reglas de prioridad, que se
puedan usar fácilmente para secuenciar los trabajos en cada máquina.
Algunas de las reglas de prioridad que se han propuesto son:
— Procesar aquél trabajo en cola que tiene la fecha de entrega más
cercana.
— Procesar aquél trabajo en cola que lleva más días en el taller. Es
decir, ordenar la producción por el método Fifo.
— Procesar aquél trabajo en la cola que tiene el tiempo de proceso
más corto.
Para estudiar el funcionamiento del taller bajo las diferentes reglas
de prioridad, se ha seleccionado una muestra de 15 trabajos, de un fi-
chero de hojas de ruta. Cada trabajo consta de 10 operaciones. Para
cada operación se sabe la máquina que hay que utilizar y el tiempo de
proceso 2.
Partiendo de esta muestra, queremos construir un modelo en PSPS,
con el que podremos observar el funcionamiento del taller, bajo las dis-
tintas reglas de prioridad.
2. Ver Anexo1: trabajos representativos.
CASO 3. HERRERÍAS URANIO 599
1. Programa del modelo
El modelo se encuentra estructurado en varios ficheros, en los que

se definen las secciones PSPS necesarias. El fichero principal, que se
encarga de mantener el orden entre las secciones, contiene los comenta-
rios activos necesarios para el secuenciado.
En primer lugar, el fichero UranioVars.pss muestra la definición de
las constantes, etiquetas y variables que utilizaremos a lo largo del mo-
delo.
Cuadro 1
Modelo «Uranio». Fichero UranioVars.pss
FICHERO: URANIOVARS.PSS
Constants
{----- Máquinas disponibles -----}
Sa=1; { Sierra}
El=2; { Torno }
Tl=3; { Torno revolver }
Vm=4; { Limadora vertical }
Hm=5; { Limadora horizontal }
Db=6; { Desbastadora }
Dr=7; { Perforadora }
Gr=8; { Fresadora }
Ht=9; { Horno tratamiento termico }
Fi=10; { inspección Final }
{----- Atributos de las transacciones pedidos -----}

Tipo = 2; { Tipo de pedido }

Tiempo = 3; { Tiempo de proceso de la operación }
FEnt= 4; { Fecha de Entrega }
Tllq = 5;
Nop = 6; { Número de operación }
CurrentOp = 7; { operación en curso }
{----- Varios -----}

NTipo = 15;
Prioridad = 3;
TotalT = 1200;
PintaGantt = True;
Labels
Origen;
Variables
i; z; Tot;
Srho; SJob; STeo;
Oper Array 10,15; { Matriz de las distintas operaciones }
Tiempos Array 10,15; { Tiempos de proceso de las operaciones }
TotalCola Array 10; { Tiempo total en la cola de una máquina }
HorasMaq Array 10; { Horas que la máquina está siendo utilizada }
Máquina Array 10; { Distintos tipos de máquinas disponibles }
Colorines Array 15; { Colores del diagrama de Gantt }
TCola stat Array 10;
El fichero UranioData.pss contiene la definición de la sección Data

del modelo, en la que se inicializan algunas de las variables definidas
anteriormente.
Cuadro 2
Modelo «Uranio». Fichero UranioData.pss
FICHERO: URANIODATA.PSS
Data
Vars oper =
\Sa,Sa,Sa,Sa,Sa,Sa,Sa,Sa,Sa,Sa,Sa,Sa,Sa,Sa,Sa,
Hm,Tl,Dr,Dr,Ht,Db,Tl,Db,Gr,Vm,Db,Ht,Db,Gr,Vm,
Ht,Hm,Dr,Hm,Db,El,Ht,El,Ht,Ht,Vm,Dr,Hm,Db,Vm,
Tl,Hm,Gr,Ht,Hm,Gr,El,Hm,Gr,El,Vm,Tl,Ht,Gr,Tl,
Hm,Db,El,Db,Ht,Hm,Dr,Gr,Hm,Db,Hm,Db,Tl,Gr,Tl,
Hm,El,Dr,Gr,Ht,El,Gr,Vm,Ht,Vm,Dr,Dr,Vm,Gr,El,
Hm,Ht,Gr,Dr,Ht,El,Tl,Dr,Vm,Vm,Gr,Tl,Dr,Gr,Vm,
El,Ht,Gr,Tl,Tl,Gr,Ht,Hm,Hm,Db,Ht,Gr,El,Ht,Tl,
El,Dr,El,Vm,Tl,Hm,Tl,Db,Vm,Ht,Tl,Dr,Tl,Db,Hm,
Fi,Fi,Fi,Fi,Fi,Fi,Fi,Fi,Fi,Fi,Fi,Fi,Fi,Fi,Fi\;
Vars tiempos =
\2,7,5,5,8,1,16,3,1,3,21,11,1,4,1,
1,11,4,14,1,1,1,7,1,5,1,16,1,8,6,
5,1,19,3,5,6,14,6,6,1,9,5,21,4,5,
17,8,1,5,1,8,2,1,2,1,6,1,7,5,2,
1,3,8,1,2,3,1,5,1,4,1,19,8,7,6,
4,13,3,5,3,17,7,2,7,1,1,6,6,10,7,
2,5,2,1,1,11,10,3,6,5,17,4,6,1,4,
1,2,6,2,1,4,2,24,9,3,9,2,1,10,6,
6,4,3,1,4,8,12,14,2,2,4,20,8,3,1,
7,5,3,13,1,5,9,4,2,3,13,6,4,8,7\;
Vars Maquina = \“Sa”,“El”,“Tl”,“Vm”,“Hm”,

“Db”,“Dr”,“Gr”,“Ht”,“Fi”\;
Vars Colorines = \CBLUE,CDKGRAY,CFUCHSIA,CGRAY,CGREEN,

CLIME,CMAROON,CNAVY,COLIVE,CPURPLE,
CTEAL,CRED,CSILVER,CTEAL,CYELLOW \;
Initial Begin
FdrawCont(1,Gsize,0,0,10,1),
FDrawCont(1,GTitle,“OCUPACION DE MAQUINAS”)
End;
Table 1,12,7,[“Tabla Resumen”, “Num.”, “Maquina”, “HProceSad.”,
“HCola”, “Rho”, “Num.Jobs”, “NS(MM1)”];
Gantt 1,10,0,400;
Facility 10;
Switch 0;
Time TotalT;
Report On;
El fichero Uranio.pss es el fichero principal del modelo y contiene

la definición de la sección System que describe el movimiento de las

transacciones. Al final de la sección System aparece como un comenta-
rio activo el fichero uranioInforme.pss. Este fichero contiene la defini-
ción de una tabla resumen, que mostrará el estado del sistema al final de
la simulación.
Cuadro 3
Modelo «Uranio». Fichero Uranio.pss
FICHERO: URANIO.PSS
{$UranioVars.pss}
{$UranioData.pss}
{----- Inicio de la simulación -----}

System
GENERATE Exponential(480/52),On;
COMPUTE begin
At[Tipo]= Uniform(1,15),
At[FEnt]= Cl + 126,
At[Nop] = 1
end;
{----- Entra en la operación número At[Nop] -----}
Origen:
COMPUTE begin
At[Tiempo] = Tiempos[At[Nop],At[Tipo]],
At[CurrentOp] = Oper[At[Nop],At[Tipo]],
TotalCola[At[CurrentOp]] = TotalCola[At[CurrentOp]] + At[Tiempo],
TCola[At[CurrentOp]] = TotalCola[At[CurrentOp]]
end;
QUEUE At[CurrentOp], 1, Tiempo, Wait, Off;
COMPUTE begin
TotalCola[At[CurrentOp]] = TotalCola[At[CurrentOp]] - At[Tiempo],
TCola[At[CurrentOp]] = TotalCola[At[CurrentOp]],
HorasMaq[At[CurrentOp]] = HorasMaq[At[CurrentOp]] + At[Tiempo],
if PintaGantt then
Bar(1,At[CurrentOp] -1,cl,cl+At[tiempo],colorines[At[tipo]])
End;
WAITFOR At[Tiempo];
LEAVE At[CurrentOp],1;
ASSIGN At[Nop]= At[Nop]+1, Cond(At[CurrentOp] # Fi,Origen,Cb+1);
{----- Plazo de entrega -----}
TTAB 1,cl-At[1];
TTAB 2,cl-At[FEnt];
TERMINATE 1;
{$UranioInforme.pss}
Endsystem;
Cuadro 4
Modelo «Uranio». Fichero UranioInforme.pss
FICHERO: URANIOINFORME.PSS
GENERATE TotalT,1;
COMPUTE begin
For i= 1 to 10 do begin
GotoXY(1,i,0),
PrintR(Format(“%6d”,i)),
PrintR(Maquina[i]),
PrintR(Format(“%6.2f”,HorasMaq[i]/TotalT*480)),
PrintR(Format(“%6.2f”,StatVar(&TCola[i],STAverage))),
Tot = StatFac(i,STAverage),
Srho = Srho + Tot,
PrintR(Format(“%6.3f”,Tot)),
Sjob = Sjob + statQ(i,STAverage)+Tot,
PrintR(Format(“%6.1f”,Tot+statQ(i,STAverage))),
Steo = Steo + Tot/(1-Tot),
PrintR(Format(“%6.1f”,Tot/(1-Tot))),
FdrawXY(1,1,i,Tot)
End,
GotoXY(1,11,0),
PrintR(“Total”),
GotoXY(1,11,2),
PrintR(“P.Entrega”),
PrintR(Format(“%6.3f”,StatTab(1,STAVERAGE))),
PrintR(Format(“%6.3f”,Srho/10)),
PrintR(Format(“%6.3f”,Sjob)),
PrintR(Format(“%6.3f”,Steo))
End;
TERMINATE 1;
Está claro que las diferentes máquinas de la fábrica van a estar re-
presentadas por procesadores, y la capacidad de cada uno de ellos va a
ser igual a 1, ya que cada máquina sólo es capaz de procesar un único
trabajo al mismo tiempo. Las transacciones, generadas por un bloque
GENERATE, representan los diferentes trabajos que van llegando a la
fábrica. Los trabajos se distinguen unos de otros por las distintas opera-
ciones que tienen que realizar; estas operaciones serán asignadas a los
atributos de la transacción que representa al trabajo.
Inicialmente supondremos que el sistema se encuentra vacío, es de-

cir, no hay ningún trabajo en marcha.
Las transacciones son generadas según una distribución exponen-
cial de media 480/50, el tiempo medio entre las llegadas a la fábrica de
dos pedidos consecutivos. Un bloque COMPUTE se encarga de asignar
las características del trabajo a los atributos de la transacción. Recorde-
mos que se trata de una muestra de 15 trabajos, y que cada uno de ellos
consta de 10 operaciones, que deben realizarse en máquinas concretas.
Una vez definidas las características del trabajo, la transacción se
dirige a otro bloque COMPUTE, en el que se asigna al atributo número
3 el tiempo de proceso (del array Tiempos que hemos inicializado, en
la sección Data, con los tiempos de proceso de cada operación para cada
tipo de trabajo).
El programa se organiza con un bucle, que las transacciones reco-
rren repetidamente realizando una operación cada vez. El contador de
operaciones es el atributo número 6 de la transacción en curso, e indica
el número de orden de la operación a realizar. La máquina que debe rea-
lizar la operación se obtiene del array Oper, indexado por el atributo
6, y se asigna al atributo número 7. En este mismo bloque se actualizan
los valores de los arrays TotalCola y TCola 3, que miden la longi-
tud de la cola de cada máquina, en horas de máquina.
En el bucle, la transacción intenta acceder a la máquina mediante un
bloque QUEUE. Las transacciones que encuentran el procesador ocupa-
do esperan a que quede libre en una cola. En el listado, la cola está or-
denada según el valor del tiempo de proceso (atributo número 3), imple-
mentando así la tercera regla de prioridad. Cuando la transacción
accede al procesador, un bloque COMPUTE actualiza los valores de los
arrays TotalCola y TCola. También se actualiza el valor del array
HorasMaq que indica el número de horas que se utiliza cada máquina.
Tras demorar la transacción por el tiempo de proceso de la opera-

ción, la transacción abandona el procesador y pasa a un bloque ASSIGN
que incrementa el número de la operación para que apunte a la siguien-
te. La transacción se dirige o bien al bloque origen, donde sigue el pro-
ceso con otra operación, o al bloque siguiente, en caso de haber comple-
tado todas las operaciones.
Cuando el reloj de simulación alcanza el valor de terminación, un
bloque GENERATE definido en el fichero UranioInforme.pss genera
3. Estos dos arrays son idénticos, la única diferencia es que TCola está definido
como un array de tipo stat y el sistema calculará estadísticas de sus valores de forma au-
tomática.
una única transacción, que se encarga de crear una tabla resumen, con
información sobre las máquinas de la fábrica.
Empezamos simulando el sistema bajo la regla Fifo. La tabla resu-

men muestra para cada una de las máquinas de la fábrica el número me-
dio de horas procesadas (el trabajo total realizado por la máquina), la
longitud media de la cola (medida en horas de máquina), la ocupación
media (Rho), el número medio de trabajos en cola y el número de traba-
jos en el sistema calculados teóricamente usando un modelo M/M/1.
Figura 1
Tabla resumen
También hemos generado una gráfica que muestra la ocupación me-

dia de cada una de las máquinas de la fábrica, y dos histogramas, en los
que podemos observar la distribución del tiempo total de proceso de un
trabajo, y la distribución de los retrasos y adelantos sobre la fecha de
entrega. En este último histograma 4 un valor negativo indica que el tra-
bajo ha sido entregado con retraso y un valor positivo que ha sido entre-
gado antes de la fecha.
4. Los histogramas del modelo se han definido utilizando el bloque TTAB. Como
vimos en el capítulo 9, el bloque TTAB se encarga de construir un histograma conside-
rando las observaciones como parte de una trayectoria aleatoria en el tiempo.
Figura 2
Ocupación de las máquinas
Histograma 1: Histograma 2:
Tiempo de proceso Retrasos y adelantos
3. El sistema como una red de colas
El sistema es determinista en todos sus parámetros excepto por la

tasa de llegada de transacciones. ¿Qué sucedería si fuera completamen-
te determinista? Vamos a probarlo haciendo que las llegadas se produz-
can a intervalos constantes. He aquí el resultado:
Figura 3
Tabla resumen
Algo han cambiado las cosas, pero no mucho. El punto clave es que
las esperas siguen existiendo, en algunos casos en forma suficiente para
parecer colas M/M/1. Pero, y esto es muy importante, en este último caso
no hay aleatoriedad alguna en el sistema. El fenómeno ya se insinuó en el
ejemplo 5 del capítulo 11. Pero aquí, con una escala mayor, se manifiesta
claramente. Para comprenderlo mejor contemplemos el diagrama de
Gantt para los primeros 400 instantes de tiempo. Helo aquí, en la figura 4:
Figura 4
Diagrama de Gantt
El lector debería intentar crear el diagrama de Gantt a mano. Al fin

y al cabo es un ejercicio sencillo, porque todos los números son deter-
ministas. Pero los productos fluyen en todas direcciones, y es imposible
precisar cuándo un producto va a llegar a un centro de proceso, no por
aleatoriedad, sino por complicación. El sistema no es aleatorio, ¡pero
nadie lo diría! Las secuencias de operación en cada máquina parecen to-
talmente al azar. Muchos elementos interaccionan en formas más o me-
nos caóticas.
Uranio se parece tanto a una red de colas que puede calcularse usan-
do estas técnicas, aunque sea determinista. En la tabla siguiente hemos
calculado los tiempos medios de proceso en cada centro y sus coeficien-
tes de variación, sobre todos los productos.
Figura 5
Medias y coeficientes de variación
sa el tl vm hm db dr gr ht fi
media 5,93 6,308 6,063 4,462 5,294 5,077 6,692 5,353 5,444 6
coef.Var. 0,969 0,76 0,743 0,510 1,292 1,035 0,949 0,744 0,794 0,581
Veamos lo que sucede al usarlos en un cálculo de colas, con las fór-

mulas del capítulo 12.
Figura 6
Cálculo de Ns
Tiempo entre llegadas 9,23
Centro media coef.Var. NS
sa 5,93 0,97 1,78
el 6,31 0,76 1,98

tl 6,06 0,74 1,75
vm 4,46 0,51 0,82
hm 5,29 1,29 1,46
db 5,08 1,03 1,23
dr 6,69 0,95 2,59
gr 5,35 0,74 1,28
ht 5,44 0,79 1,35
fi 6,00 0,58 1,60
Las estimaciones están dentro de los órdenes de magnitud de la simu-

lación. De hecho, si el lector usa un procedimiento más sofisticado que es-
time el coeficiente de variación de las llegadas, en vez de suponerlo igual

a 1, se obtienen resultados aún más parecidos. Esta técnica fue presentada
en el capítulo 12, en la sección de redes abiertas de colas generales.
4. Prioridades
¿Qué sucede si no usamos la disciplina Fifo como criterio de priori-

dad en la elección del próximo trabajo en un puesto determinado? Mu-
cho se ha escrito sobre este tema. Se han realizado cientos de simulacio-
nes con disciplinas de espera más o menos malévolas, para tratar de ver
si la eficiencia del taller aumenta al cambiar la regla de selección del
próximo trabajo. Al fin y al cabo, Fifo es el estándar ético cuando el
cliente está presente en el servicio. Pero en Uranio el cliente no ve el
proceso, y por tanto podemos usar cualquier disciplina que aumente la
productividad, si no degrada el servicio final.
No vamos a abrumar al lector con este tipo de detalles. Nos bastará
ilustrar cómo esto puede simularse usando los mecanismos que provee
PSPS. Toda prioridad en PSPS se basa en la ordenación de las transac-
ciones por uno de sus atributos. Esto es perfectamente general, puesto
que un atributo puede calcularse aplicando cualquier función. Las dos
únicas condiciones que limitan el uso de prioridades son:
1. La prioridad no puede depender del tiempo de servicio o del
tiempo de reloj. En general, el atributo que determina la priori-
dad debe poder calcularse antes de la llegada de una transacción.
Esto es así, porque la ordenación de las transacciones se realiza
por inserción, en el momento de la llegada, y no hay un proceso
de reordenación completo a cada llegada de una transacción.
Para las transacciones que no están en servicio, se puede obviar
esta limitación con un bloque especial que comentaremos breve-
mente más adelante. Pero las que ya han empezado el proceso no

tienen remedio sencillo.
2. Las disciplinas de espera no pueden ser interruptivas. Es decir,
no se puede interrumpir la estancia de una transacción en un pro-
cesador, para dar paso a otra que estaba en espera.
Muchas disciplinas de espera no dependen del tiempo, y son ade-
cuadas para simularlas en PSPS. Por ejemplo la prioridad SPT, Shortest
Processing Time, o tiempo de proceso más corto, se basa en ordenar las
transacciones de acuerdo con su tiempo de proceso. Para mantener esta
disciplina de espera basta insertar cada transacción dentro de la cola por
orden de tiempo de proceso, sin tener que cambiar la prioridad de todas
las demás. En este caso PSPS maneja el tema con facilidad.
Cuadro 5
Modelo «UranioPrio»
{$UranioPrioVars.pss}
{$UranioPrioData.pss}
{-----aquí se empieza la simulación---------------------}

system
GENERATE Exponential(480/52),On;
COMPUTE begin
at[Tipo]= Uniform(1,15),
at[FEnt]= cl + 126,
at[Nop] = 1
end;
{----Entra en la operación número at[Nop]---------------}
origen:
COMPUTE begin
at[tiempo] = Tiempos[at[Nop],at[Tipo]],
at[Priority] = (at[FEnt]-cl-Prior[at[Nop],
at[Tipo]])/(11-at[Nop]),
at[CurrentOp] = Oper[at[Nop],at[Tipo]],
totalCola[at[CurrentOp]] = totalCola[at[CurrentOp]] +
at[Tiempo],
TCola[at[CurrentOp]] = TotalCola[at[CurrentOp]]
end;
FREORDER at[CurrentOp],Priority,(at[FEnt]-cl-
Prior[at[Nop],at[Tipo]])/(11-at[Nop]);
QUEUE at[CurrentOp], 1, Priority, Wait, Off;

COMPUTE begin
totalCola[at[CurrentOp]] = totalCola[at[CurrentOp]] - at[Tiempo],
TCola[at[CurrentOp]] = TotalCola[at[CurrentOp]],
HorasMaq[at[CurrentOp]] = HorasMaq[at[CurrentOp]] + at[Tiempo],
if PintaGantt then z =
Bar(1,at[CurrentOp],cl,cl+at [tiempo],colorines[at[tipo]])
end;
WAITFOR at[Tiempo];
LEAVE at[CurrentOp],1;
ASSIGN at[Nop]= at[Nop]+1, cond(at[CurrentOp] ne fi,origen,cb+1);
{---- plazo de entrega ---------------------------------}

TTAB 1,cl-at[1];
TTAB 2,cl-at[FEnt];
TERMINATE 1;
{$UranioPrioInforme.pss}
endsystem;
En el caso Donner, y en relación con las curvas de input/output tu-

vimos oportunidad de ver que la espera media es la misma para todas
las disciplinas de espera que preservan el área entre las curvas de input
y de output. Para estas disciplinas de conservación del trabajo, lo único
que cambia es la distribución de las esperas entre los diferentes clientes.
Por esto se dice que estas disciplinas ofrecen justicia distributiva, pero
no eficiencia productiva. Cambian la distribución del servicio, pero no
el valor promedio del mismo.
La implantación de una prioridad que exija la reordenación comple-
ta de la lista de transacciones esperando a la llegada de cada transac-
ción, y no simplemente la inserción de la nueva transacción, se puede
lograr usando el bloque FREORDER, que reordena completamente la
lista de transacciones que esperan en una facility, o el bloque SREOR-
DER que hace lo mismo para el caso de un switch. En el cuadro 5 se
muestra el uso de estos bloques para simular una disciplina de espera
que se basa en una prioridad calculada como:
(FechaEntrega-Fecha_Actual)/ numero_de_Operaciones_remanentes
La transacción que primero se procesa es la de mayor tiempo res-

tante hasta la entrega por operación no realizada. Esta regla de priori-
dad suele dar muy buenos resultados, aumentando al mismo tiempo la

productividad y el servicio, este último medido por el número de clien-
tes con entregas realizadas a tiempo. El lector puede simularla con el
modelo que se incluye en el CD.
612
Anexo 1
Trabajos representativos
Trabajo 1 Trabajo 2 Trabajo 3 Trabajo 4 Trabajo 5 Trabajo 6
Número Tiempo Tiempo Tiempo Tiempo Tiempo Tiempo

de Máquina de Máquina de Máquina de Máquina de Máquina de Máquina de
operación proceso proceso proceso proceso proceso proceso
1 SA 2 SA 7 SA 5 SA 5 SA 8 SA 1
2 HM 1 TL 11 DR 4 DR 14 HT 1 DB 1
3 HT 5 HM 1 DR 19 HM 3 DB 5 EL 6
4 TL 17 HM 8 GR 1 HT 5 HM 1 GR 8
5 HM 1 DB 3 EL 8 DB 1 HT 2 HM 3
6 HM 4 EL 13 DR 3 GR 5 HT 3 EL 17
7 HM 2 HT 5 GR 2 DR 1 HT 1 EL 11
8 EL 1 HT 2 GR 6 TL 2 TL 1 GR 4
9 EL 6 DR 4 EL 3 VM 1 TL 4 HM 8
10 FI 7 FI 5 FI 3 FI 13 FI 1 FI 5
EL OFICIO DE LA SIMULACIÓN
Anexo 1
Trabajos representativos
(continuación)

Trabajo 7 Trabajo 8 Trabajo 9 Trabajo 10 Trabajo 11 Trabajo 12
Número Tiempo Tiempo Tiempo Tiempo Tiempo Tiempo
de Máquina de Máquina de Máquina de Máquina de Máquina de Máquina de
CASO 3. HERRERÍAS URANIO
operación proceso proceso proceso proceso proceso proceso
1 SA 16 SA 3 SA 1 SA 3 SA 21 SA 11
2 TL 1 DB 7 GR 1 VM 5 HT 1 HT 16
3 HT 14 EL 6 HT 6 HT 1 DR 9 DR 5
4 EL 2 HM 1 GR 2 EL 1 TL 6 TL 1
5 DR 1 GR 5 HM 1 DB 4 DB 1 DB 19
6 GR 7 VM 2 HT 7 VM 1 DR 1 DR 6
7 TL 10 DR 3 VM 6 VM 5 TL 17 TL 4
8 HT 2 HM 24 HM 9 DB 3 GR 9 GR 2
9 TL 12 DB 14 VM 2 HT 2 DR 4 DR 20
10 FI 9 FI 4 FI 2 FI 3 FI 13 FI 6
613
Anexo 1
Trabajos Representativos
(continuación)
Trabajo 13 Trabajo 14 Trabajo 15

Número Tiempo Tiempo Tiempo
de Máquina de Máquina de Máquina de
operación proceso proceso proceso
1 SA 1 SA 4 SA 1
2 DB 1 GR 8 VM 6
3 HM 21 DB 4 VM 5
4 HT 7 GR 5 TL 2
5 TL 8 GR 7 TL 6
6 VM 6 GR 10 EL 7
7 DR 6 GR 1 VM 4
8 EL 1 HT 10 TL 6
9 TL 8 DB 3 HM 1
10 FI 4 FI 8 FI 7
CASO 4
SHOULDICE HOSPITAL LIMITED1
Earle Shouldice, fundador del hospital que lleva su nombre, desa-

rrolló una técnica quirúrgica para la operación de hernias que era supe-
rior a otras técnicas.
En el hospital Shouldice se operaban únicamente hernias abdomina-
les externas. Por tanto la mayoría de las operaciones primarias (es decir,
las operaciones realizadas por primera vez) requerían sencillas interven-
ciones de unos 45 minutos de duración. Las operaciones primarias cons-
tituían un 82% de todas las operaciones llevadas a cabo en Shouldice en
1982. El 18% restante se componía de pacientes con hernias recidivan-
tes, reparadas anteriormente en otra clínica.
La típica operación ordinaria podía llevarse a cabo con el uso de una
sedación preoperatoria (pastilla para dormir) y un analgésico, además
de una anestesia local (una inyección de novocaína en la región de la in-
cisión). Esto permitía la deambulación inmediata del paciente y facili-

taba una recuperación rápida. Muchas de las operaciones de hernias re-
currentes o muy difíciles, al ser más complejas, podían tardar hasta 90
minutos o más. En algunos casos se administraba anestesia general.
El proceso experimentado por los pacientes de Shouldice dependía
de si vivían lo suficientemente cerca del hospital para visitar las insta-
laciones y obtener un diagnóstico. Los pacientes provenientes de otras
localidades a menudo se diagnosticaban por correo mediante un cues-
tionario de información médica.
1. HESSKET, J.L., Shouldice Hospital Limited, Caso P-655, División de Investiga-

ción del IESE, Barcelona, 1995.
Según la información expuesta en el cuestionario, un cirujano de

Shouldice determinaba el tipo de hernia que tenía el paciente, si existían
signos de que la cirugía podría estar asociada con algún riesgo, por
ejemplo, obesidad, una afección cardiaca o un paciente que había sufri-
do un infarto o una apoplejía en los últimos 6-12 meses, o si se requería
anestesia local o general. En este momento se fijaba la fecha de la ope-
ración, la información médica se introducía en una base de datos com-
puterizada y se le mandaba una tarjeta de confirmación. A un pequeño
grupo se le negaba el tratamiento, bien porque eran demasiado obesos y
representaban un riesgo médico excepcional, o porque se determinaba
que no tenían una hernia.
Los pacientes llegaban a la clínica entre la 1 y las 3 de la tarde del
día anterior a la operación. Después de una espera, normalmente de
unos 20 minutos, según la disponibilidad de los cirujanos, los pacientes
eran explorados en una de las 6 salas preparadas por los cirujanos que
habían terminado su programa de operaciones del día. Este examen no
requería más de 15 ó 20 minutos, a no ser que el paciente necesitara ser
tranquilizado. En esta exploración, ocasionalmente se descubría que un
paciente no había corregido su problema de obesidad; en otros a lo me-
jor se comprobaba que al final no tenían una hernia. En ambos casos se
mandaba al paciente de vuelta a casa.
Después de la exploración, el paciente tenía que esperar de 5 a 15
minutos para ver, en el despacho de contabilidad, a una de las dos per-
sonas encargadas de los ingresos. Allí se comprobaba la cobertura de su
seguro médico y se ultimaban diversos detalles, en un procedimiento
que normalmente no duraba más de 10 minutos.
A continuación se mandaba a los pacientes a una de las dos estacio-
nes de enfermería, donde se determinaban la hemoglobina (sangre) y
orina. Estas determinaciones requerían entre 5 y 10 minutos y se reali-
zaban en el acto. Después, aproximadamente una hora más tarde de lle-

gar al hospital, el paciente era conducido a una habitación, cuyo núme-
ro se indicaba en su brazalete.
La primera operación tenía lugar a las 7.30 de la mañana. Al termi-
nar la operación se invitaba a los pacientes a bajar de la mesa de ope-
raciones y caminar hasta la sala postoperatoria con la ayuda de los ci-
rujanos.
A lo largo del día tanto las enfermeras como los celadores animaban
a los pacientes a caminar.
El hospital empleaba a 12 cirujanos a plena dedicación. El progra-
ma de operaciones oscilaba entre 30 y 36 operaciones al día. Por tanto,
cada cirujano solía realizar de tres a cuatro operaciones diarias.
CASO 4. SHOULDICE HOSPITAL LIMITED 617
La jornada típica de un cirujano empezaba con un lavado a fondo

poco antes de la primera operación. Si la operación era rutinaria, nor-
malmente terminaban a las 8.15. Un cirujano podía llevar a cabo 3 ope-
raciones rutinarias y una cuarta de hernia recidivante (un procedimien-
to de 60-90 minutos) y terminar a tiempo para comer a las 12.30 en el
comedor del personal.
Después de comer, hasta 6 cirujanos que no tenían que operar por la
tarde subían a la segunda planta para examinar a los nuevos pacientes,
entre la 1 y las 3 de la tarde. Los demás pasaban a los quirófanos, para
completar las operaciones del día. La jornada de un cirujano terminaba
a las 5 de la tarde.
La planta baja de la clínica alojaba 5 quirófanos, un laboratorio, la
sala de reanimación y un área de aprovisionamiento central donde se
limpiaban y esterilizaban los instrumentos quirúrgicos.
En la primera planta de la clínica estaban las oficinas de recepción
y contabilidad, una gran sala de espera con capacidad para 50 personas,
y 6 salas de exploración. En la segunda planta de la clínica, situada en
la mayor parte de lo que era el edificio original, se encontraban las ofi-
cinas administrativas. Una tercera planta alojaba 14 habitaciones adi-
cionales, donde los pacientes podían esperar la asignación de una habi-
tación y su operación.
Shouldice deseaba encontrar la manera de aumentar la capacidad
del hospital, y a la vez conservar la calidad del servicio ofrecido.
1. Modelo PSPS de la clínica Shouldice
La simulación nos permitirá observar el funcionamiento de la clínica

bajo diferentes condiciones. La idea es definir un modelo que describa de
forma general el funcionamiento de la clínica. Una vez que hayamos

comprobado que el modelo describe correctamente el funcionamiento ac-
tual, podemos modificar cosas, por ejemplo el número de camas, y ver
si los servicios tienen capacidad suficiente para atender a más pacien-
tes, o si sería necesario aumentar el número de personas en alguno de
los servicios de la clínica.
El modelo que proponemos está formado por tres procesos. El pri-
mer proceso se encarga de programar las operaciones del día. El segun-
do se encarga del funcionamiento de los quirófanos y el tercero se en-
carga de la llegada de los pacientes a la clínica.
El caso Shouldice es interesante desde el punto de vista de la simu-
lación, por dos conceptos.
• Hay una secuencia complicada de interrupciones a horas progra-

madas, que deben tenerse en cuenta para programar las activida-
des de los quirófanos y las llegadas de pacientes. En PSPS esto se
logra usando switches y bloques GATE que retienen las transac-
ciones.
• Los médicos tienen una disponibilidad compleja. En primer lugar
está la limitación de las operaciones a 4, 3 simples y 1 complica-
da. A continuación está la condición de que los médicos que han
trabajado por la mañana son los mismos que por la tarde exami-
nan a los nuevos pacientes. Esto implicaría que hay que llevar la
cuenta de la historia de los médicos, por un lado para contar las
operaciones realizadas, y por otro para cambiarles de tipo, desde
cirujano a examinador de hernias. Esto parecería indicar la nece-
sidad de que los médicos fueran representados por transacciones.
Si el lector lo piensa un rato, y más adelante daremos un modelo
que tiene en cuenta estas condiciones, verá que no es sencillo im-
plantar este esquema. Aparecen en escena bloques complicados,
como el bloque GRAB, para manejar dos depósitos de transaccio-
nes, según el tipo de médico.
Si se analiza el modelo con ayuda de conceptos analíticos, se descu-
bren vías de simplificación, al constatar que hay propiedades del resul-
tado que van a variar muy poco con las condiciones del sistema, y que
el modelo puede simplificarse notablemente usando hipótesis cuidado-
samente seleccionadas. El modelo que se presenta puede provocar la
sensación de que «es poco realista», porque no imita el movimiento de-
tallado de los diferentes elementos del sistema real. Pero la razón es cla-
ra: si los imitara, el modelo sería mucho más embrollado y difícil de en-
tender, aunque los resultados serían prácticamente los mismos.
Esta aplicación de la «cuchilla de Ocam» no es fácil de hacer a prio-
ri, a no ser que se cuente con ciertas técnicas básicas. Una de las más
útiles es la teoría de las esperas, que expusimos en el capítulo 11. Otra
es el análisis de cargas que se presentó en el capítulo 8.
La utilidad del análisis de cargas es obvia. Un análisis de cargas tra-
ta de determinar la posición del cuello de botella dentro del sistema de
operaciones. Un cuello de botella es el procesador que limita el flujo to-
tal de producción. Su importancia en la construcción de modelos pro-
viene de que, para estimar el flujo producción del sistema completo,
hace falta modelar con precisión fundamentalmente los cuellos de bote-
lla. Y decimos «cuellos», en plural, porque es necesario estimar quiénes
pueden ser los cuellos de botella sobre el rango de parámetros que va-
mos a considerar en el análisis completo del sistema.
Como se recordará, para realizar un análisis de cargas se parte de

los datos sobre capacidad, producción y tiempo de operación de cada
procesador en cada ítem. Pero tanto los procesadores y su capacidad
como los tiempos de proceso deben estar disponibles para construir el
modelo de simulación. El único problema suele ser la estimación de las
necesidades de proceso, que típicamente requiere estimar el número de
visitas a cada procesador. Éste es parte del propósito del propio mode-
lo de simulación, por lo que a priori es difícil estimar las visitas, al no
contar con la ayuda del modelo. Pero en algunos casos esta estimación
es sencilla, y cuando esto sucede el análisis de cargas es casi inmedia-
to.
El Shouldice es uno de estos casos, siempre que supongamos que el
hospital se regenera entre días, es decir, que el estado al final de un día
es igual al del día anterior. Y esto en Shouldice es aproximadamente
cierto.
Por tanto, hagamos un análisis de cargas. Nos concentramos en el
flujo de ítems entre los procesadores en régimen permanente.
• Médicos. Hay 12 médicos, capaces de hacer 4 operaciones cada
uno. Como una operación tarda una hora (por el momento ignora-
remos la diferente complejidad de las operaciones), cada día se
pueden hacer 48 operaciones.
• Quirófanos. Hay 5 quirófanos. Como una operación tarda 1 hora,
en las 8 horas se pueden hacer 40 operaciones. Por el momento
los quirófanos limitan la capacidad de producción a 40 operacio-
nes. Por la mañana se pueden hacer 25 y por la tarde otras 15.
• Exploración. Hay 6 salas de exploración. Cada una de ellas nece-
sita un medico que haya completado su cupo de operaciones.
Como por la mañana se realizan 25 operaciones, pueden quedar
liberados 6 médicos, por lo que hay un médico disponible para

cada sala. Como el tiempo de exploración es de 17 minutos, se
pueden procesar 60/17 = 3,53 clientes por hora. Ya que los médi-
cos pueden estar 3 horas cada uno, se pueden procesar 3*6*3,53
= 63,54 clientes cada día. Como no se pueden hacer más de 40
operaciones, podemos concluir que la exploración no es el cuello
de botella.
• Contabilidad y análisis. De la misma forma se puede proceder
con los demás departamentos. Cada departamento puede estar
funcionando tanto tiempo como se quiera, hasta acabar de proce-
sar la cola de pacientes, siempre que termine dentro del mismo
día. Ninguno de ellos será cuello de botella. Pero debe prestarse
un servicio adecuado. Por tanto procederemos al revés. Veremos

cuánto tiempo de espera tendrá el cliente en cada servicio. Y de
ello deduciremos la calidad del servicio.
• Hospital. Si se procesan 40 clientes al día y están tres días en el
hospital, una aplicación de la Ley de Little muestra que el núme-
ro medio de clientes en el hospital es de 120. Como tenemos una
capacidad de 160, el hospital tampoco es cuello de botella, y po-
demos suponer que, cuando se requiera, siempre habrá una cama
disponible.
La conclusión es que el cuello de botella se halla en los quirófanos.
Hay médicos de sobra. Por tanto, convendrá que la simulación haga
hincapié en el proceso de los quirófanos. La asignación detallada de
tiempos de médicos no tiene importancia, a no ser que interfiera con la
capacidad de producción de los quirófanos, cosa que aquí no es proba-
ble. Por tanto, el modelo puede conformarse con tratar de forma aproxi-
mada tanto a los médicos, como al propio hospital.
En esta línea, supondremos que siempre hay médicos disponibles y
que siempre hay camas de hospital disponibles. Bajo estas condiciones,
sólo hay que modelar los quirófanos y, simplemente, llevar la cuenta de
los médicos usados. La disponibilidad de médicos, lo mismo que la de
camas, es perfecta y no interfiere con los resultados.
Esto es lo que hacemos en el modelo que se muestra en las tablas
adjuntas, y que describiremos a continuación. En el modelo sólo nos
concentramos en los quirófanos y en el proceso secuencial de atención
al cliente recién ingresado. Y esto lo hacemos como sigue:
1. Un proceso controla un switch, el switch número 1, que con un
bloque GATE, bloquea las transacciones de cirugía para tener en
cuenta el horario diario.
2. Una proceso clásico ENTER/LEAVE de acceso a un procesador,

y con un número de transacciones finitas, forma el núcleo de la
gestión de los quirófanos. Cada quirófano se representa por 1
transacción, que adquiere 1 médico y se demora por 1 operación.
La cuenta de médicos se lleva por medio de un procesador. De
esta forma, si se agotara la capacidad de médicos, el flujo queda-
ría limitado por el número total existente. Esta es una limitación
general, ya que no distingue entre horarios u operaciones realiza-
das.
3. Otro proceso que usa bloques ENTER/LEAVE trata la entrada
de los pacientes. No se manejan médicos porque, como ya he-
mos dicho, están siempre disponibles.
Programa del modelo
El programa está estructurado en tres ficheros. El primer fichero,

ShouldiceDefs.pss, contiene las definiciones de las constantes, varia-
bles y funciones utilizadas en el modelo. El segundo fichero, Shouldi-
ceData.pss, contiene la sección Data. Y por último el tercer fichero,
Shouldice.pss, es el fichero principal del programa, en el que se inclu-
yen los ficheros anteriores en forma de comentarios activos y la sección
System, que contiene las especificaciones para la simulación del mode-
lo en forma de bloques.
Cuadro 1
Modelo «Shouldice». Fichero ShouldiceDefs.pss
Fichero Shouldicedefs.pss
Constants
SalasExploracion = 1;
Contabilidad = 2;
análisis = 3;
Hospital = 4;
ColaQuirofanos = 5;
quirofanos = 6;
medicos = 7;
NumDocs = 12;
Labels
Otro;
rechazo;
programa;
Variables
TotalHora; TasaLlegadas;
NumQuirofanos;
i;
Macros
Hora:function(h0,m0) return h0*60+m0;
MinutoDia :Function(clock)
Return Mod(Cl,1440);
PrincipioDia :Function(clock)
Return Int(Clock/1440)*1440;
Tasa:Function(Tas,Hora0,Hora1)
If (Minutodia(cl) < Hora0) Then Return PrincipioDia(cl) + Hora0 - Cl
Else If (MinutoDia(cl) >= Hora1) Then Return
PrincipioDia(cl)+1440+Hora0-Cl
Else Return Tas;
Función Tasa( Tas, Hora0, Hora1 ): esta función genera el instante

de llegada de una operación según el instante de tiempo, Cl, en el que
nos encontremos. El parámetro Tas indica la tasa media de operacio-
nes. Hora0 y Hora1 indican el intervalo de tiempo en el que se puede
producir una llegada. Por ejemplo las operaciones sólo se realizan de
7.30 a 12.30.
La función calcula el minuto del día en el que nos encontramos, me-
diante la función MinutoDia. Si es menor que Hora0 (este caso sólo se
da cuando Cl = 0), entonces la función devuelve Hora0. Si el minuto del
día en el que nos encontramos es mayor que Hora1, devolverá el ins-
tante de tiempo correspondiente del día siguiente. Por último, si el minu-
to del día está dentro del intervalo definido por Hora0 y Hora1, la función
devuelve el valor del primer parámetro que es la tasa media de llegadas.
Función Hora(h0,m0): calcula el minuto del día para la hora dada
por h0 horas y m0 minutos después de la media noche.
Función MinutoDia( Cl ): esta función devuelve el valor Cl módulo
1440 2,que indica el minuto del día en el que nos encontramos.
Función PrincipioDia( Cl ): esta función devuelve el primer minuto
del día en el que nos encontramos. Suponemos que las unidades del re-
loj de simulación son minutos y que Cl = 1.500. Por tanto estamos en el
segundo día, entonces la función devuelve 1.440, que es el primer mi-
nuto del segundo día.
2. 1.440 es el número total de minutos que hay en un día.
Cuadro 2
Modelo «Shouldice». Fichero ShouldiceData.pss
FICHERO: SHOULDICEDATA.PSS
Data
Vars NumQuirofanos = 5;
Vars TotalHora = 40; {--Total pacientes por hora--}
Vars Tasallegadas = 60/TotalHora; {--Tiempo entre llegadas --}
Vars Fs[salasExploracion] = 6; {--Número Salas Exploración --}
Vars Fs[contabilidad] = 2; {--Número de personal de contabilidad--}
Vars Fs[analisis] = 2; {--Número Estaciones de Enfermería--}
Vars Fs[hospital] = 160; {--Número de camas --}
Vars Fc[hospital] = 160; {-Número de camas ocupadas en hospital--}
Vars Fs[medicos] = 12; {--Número de médicos--}
TIME 10000;
INITIAL begin
FdrawCont(1,GTitle,“Contenido y Cola en Contabilidad”),
FDrawCont(1,GSERNODOTS,1,2),
Fdrawcont(1,GSTEPLEFT,1,2),
Fdrawcont(1,GSERSOLID,1,2),
Fdrawcont(2,GSERNODOTS,1,2),
Fdrawcont(2,GSTEPFUN,1,2),
Fdrawcont(2,GSERUNORDER,1,2),
Fdrawcont(2,GSERSOLID,1,2),
Fdrawcont(3,GSERUNORDER,1),
Fdrawcont(3,GSERNODOTS,1),
Fdrawcont(3,GSTEPFUN,1)
End;
REPORT On;
Cuadro 3
Modelo «Shouldice». Fichero Shouldice.pss
FICHERO: SHOULDICE.PSS
{$ShouldiceDefs.pss}
{$ShouldiceData.pss}
System
{----------Control de las operaciones del día-----------}
GENERATE 0,1;
programa: WAITFOR hora(7,30);
SWITCH 1,On;
WAITFOR hora(12,30)-hora(7,30);
SWITCH 1,Off;
SWITCH 1,On;
SWITCH 1,Off;
WAITFOR hora(24,00)-hora(16,30),programa;
{-------------Operación de los quirofanos-----------------}

GENERATE 0,NumQuirofanos;
Otro: GATE 1;
LEAVE Hospital,1;
ENTER Medicos;
DRAWXY 2,[1,cl,fc[medicos]];
WAITFOR Erlang(60,4);
LEAVE medicos,1;
DRAWXY 2,[1,cl,fc[medicos]],otro;
{-------Llegada de los pacientes a la clínica------------}

GENERATE Tasa(TasaLlegadas,780,900),On;
ENTER Hospital,1,Fifo,NoWait,Rechazo;
DRAWXY 3,[1,cl,Qu[SalasExploracion]+fc[SalasExploracion]];
QUEUE SalasExploracion,1,Fifo,Wait,Off;
DRAWXY 2,[2,cl,fc[SalasExploracion]];
LEAVE SalasExploracion,1;
DRAWXY 2,[2,cl,fc[SalasExploracion]];
DRAWXY 3,[1,cl,Qu[SalasExploracion]+fc[SalasExploracion]];
QUEUE Contabilidad,1,Fifo,Wait,Off;
DRAWXY 1,[1,Cl,Qu[Contabilidad],2,Cl,Fc[Contabilidad]];
LEAVE Contabilidad,1;
QUEUE Analisis,1,Fifo,Wait,Off;
WAITFOR Erlang(15/2,2);
LEAVE Analisis, 1;
TERMINATE 1;
rechazo: TERMINATE 1;
Endsystem;
Empezaremos simulando un solo día, ya que como el sistema está

en régimen permanente, todos los días son iguales, excepto por varia-
ciones estadísticas dentro del día (se trata de una simulación regenerati-
va, igual que en el caso Donner). Notemos que la principal aportación
del modelo será el descubrimiento de las esperas que se producen en el
sistema, que es algo que no se puede calcular, por el momento, con las
técnicas que disponemos. La simulación nos permitirá ver qué sucede
dentro del día.
En el listado del modelo, hemos señalado en cursiva los bloques que
lo instrumentan, es decir que recogen señales y estadísticas para presen-
tarlas al usuario.
Para entender el funcionamiento hemos incluido tres gráficos: el de
uso de los médicos durante el día, el gráfico del total de clientes en con-
tabilidad y el gráfico del total de clientes en exploración. En una versión
más instrumentada, sería conveniente calcular y dibujar todas las curvas
de entrada/salida (véase caso Donner).
Figura 1
Número de quirófanos y médicos ocupados
-1
400 500 600 700 800 900 1000
X axis
La figura 1 muestra el número de quirófanos ocupados (curva oscu-

ra) y el número de médicos ocupados en la exploración (curva clara).
Los instantes de entrada y salida de un ítem dan lugar al «pelo» que tie-
nen las curvas en su parte superior. Si los tiempos de proceso en quiró-
fano fueran deterministas, los quirófanos se vaciarían cada hora, y en
concreto a las 13:30 no quedaría nadie en los quirófanos. La simulación
muestra que esto no sucede, porque las operaciones que han empezado
antes de las 13:30 no se interrumpen sino que se acaban (lo que es bas-
tante lógico...). Por ello el sistema no llega a vaciarse, quedando en ope-
ración 3 quirófanos a las 13:30 del primer día.
Figura 2
Estado de los departamentos exploración y contabilidad
Contenido y cola en exploración Contenido y cola en contabilidad
18 12
16
10
14
12 8
10 6
8
4
6
4 2
2
0
0
-2 -2
0 200 400 600 800 1000 0 200 400 600 800 1000
X axis X axis
Por otro lado las curvas de la figura 2 muestran las personas espe-
rando en exploración y contabilidad. Se llegan a acumular 16 pacientes
en exploración y la cola no termina hasta el minuto 920 aproximada-
mente, es decir hasta más allá las 15 horas. La punta se produce alrede-
dor del minuto 850, 14 horas. La situación en contabilidad es parecida,
pero aquí las colas no desaparecen hasta las 16,30 aproximadamente.
En el peor de los casos hay una persona que espera 1,30 horas en estos
departamentos. La calidad del servicio no es muy buena, en cuanto a
tiempos de espera, pero esto puede que no importe mucho a los pacien-
tes que van a operarse.
Si extendemos el tiempo de simulación a 14.400 unidades, es decir
a 10 días, obtenemos para las mismas curvas el resultado de la figura 3.
Vemos que la fluctuación estadística interdía es considerable. Podría-
mos recoger histogramas para estimar la distribución de las esperas, tra-
bajo que dejamos al lector.
Figura 3
Estado de los departamentos de exploración y contabilidad
Contenido y cola en exploración Contenido y cola en contabilidad
30 30
25 25
20 20
15 15
10 10
5 5
0 0
-5 -5
-2000 0 2000 4000 6000 8000 1,0E+4 1,2E+4 1,4E+4 -2000 0 2000 4000 6000 8000 1,0E+4 1,2E+4 1,4E+4
X axis X axis
En la tabla 4 presentamos las medias de ocupación de los procesa-

dores, obtenidas de la forma estándar. Las medias tabulares no son de-

masiado útiles en esta simulación. Los promedios están tomados sobre
tiempos que contienen intervalos notables de inactividad, que para los
médicos van desde las 16,30 hasta las 7,30. El cálculo del promedio tie-
ne en cuenta estas inactividades con un valor para médicos igual a 0, lo
que deforma las estimaciones. Pero se pueden hallar promedios de uti-
lización sobre tiempos más relevantes, con un sencillo cambio de esca-
las. Veamos el caso de los médicos. Nos interesa el promedio de utiliza-
ción sobre la jornada laboral. Por tanto, como los promedios tabulares
se toman sobre el tiempo total de 1.440 minutos, y los que nos interesan
abarcan desde las 7,30 hasta las 16,30, por un total de 990 - 450 = 540
minutos, se tiene que:
Promedio sobre la Jornada de médicos = Promedio Tabular * 1440/540

Basta multiplicar por 1440/540 = 2,66 cada promedio dado en la ta-
bla, para obtener el promedio deseado. Para los médicos el promedio
sobre la jornada es:
1,96 *2,66 = 5,2136
es decir, se ocupan un número medio de 5,21 médicos sobre un total de
12, con una utilización media de 5,21/12 = 0,43. La utilización de los
médicos es sólo del 43%. Esta baja ocupación es consecuencia de que
sólo 5 médicos están ocupados completamente durante la mañana y 5
más por la tarde, mientras que 6 (cinco de la mañana y uno adicional)
exploran.
Figura 4
Tabla de procesadores
Modelo complejo
Una imitación del comportamiento de los médicos, sin las simplifi-

caciones comentadas anteriormente, se encuentra en el disco que acom-
paña a este libro. El lector comprobará la complejidad adicional. Y si lo
usa para simular, verá que la diferencia de resultados es menor. Lo que
justifica nuestro enfoque, como debería suceder...
CASO 5
TEJIDOS ESPECIALES DENTEL1
La empresa Dentel se dedicaba a la fabricación de tejidos especia-

les. Dentro de los tejidos que fabrica se podían contar más de 1.000 va-
riedades distintas.
La empresa servía a una gran cantidad de clientes de todo el país y
estaba considerada como una de las fábricas más importantes del ramo.
El departamento técnico de la empresa era capaz de diseñar y fabricar
casi cualquier producto siempre que dispusiera de la maquinaria ade-
cuada para su producción.
Dentel trabajaba sobre pedido. Cada producto era un caso muy es-
pecial, que a menudo debía fabricarse bajo especificaciones del cliente.
El proceso de producción de Dentel estaba constituido esencialmente
por tres secciones: la de preparación, la de fabricación y la de acabado.
Tanto la sección de preparación como la de acabado no constituían
un problema, ya que ambas tenían capacidad sobrante.

Otro era el caso de la sección de fabricación, que estaba formada
por más de 1.000 máquinas distintas, agrupadas esencialmente en 4 gru-
pos, cada uno especializado en la fabricación de un tipo de producto. El
reparto de las máquinas era uniforme entre las gamas de productos, por
lo que cada subsección estaba compuesta por unas 250 máquinas y tra-
taba un 25% de la gama de productos de la empresa. Dentro de cada
subsección, las distintas máquinas eran en principio intercambiables en-
1. Riverola, J., Tejidos Especiales Dentel (A), Caso TM-125. División de Investi-
gación del IESE, Barcelona, 1999.
tre sí, de forma que un producto podía realizarse en cualquiera de las

máquinas, no siendo esto posible entre subsecciones.
Los clientes normalmente hacían pedidos en los que se relacionaban
varios tipos de productos, a veces con distintas fechas de entrega. La
empresa revisaba la factibilidad de esas fechas y comunicaba cualquier
cambio al cliente. La mayoría de los clientes especificaban una fecha
única para la entrega de cada pedido, en la que debían servirse los diver-
sos productos que lo componían.
Algunos clientes admitían entregas adelantadas, pero la mayoría de
ellos preferían que la entrega se realizara en la fecha prevista y por la
totalidad pedida.
Las fechas de entrega se acumulaban alrededor de los meses de ju-
nio y enero, momentos punta de la temporada. En estos meses podía ha-
ber varios cientos de pedidos en cartera. En otros meses, incluso no se
llegaba a tener suficientes pedidos para ocupar las máquinas.
Cuando los pedidos llegaban, se notificaba al departamento de pro-
ducción, donde se separaban por productos y cada uno de ellos se ano-
taba en una ficha, que se incorporaba a un fichero que contenía la carte-
ra completa de pedidos.
Cada día se realizaban cambios importantes en la estructura del fi-
chero de pedidos debido a distintas eventualidades. Se producían retra-
sos debidos a las alteraciones de la producción: cortes de energía eléc-
trica, averías de máquinas, problemas laborales, etc., que podían obligar
a una reestructuración de la asignación de pedidos a máquinas, e inclu-
so a la interrupción del proceso de fabricación de un pedido. Estas cir-
cunstancias producían cambios en la prioridad de otros pedidos.
Además, a medida que el tiempo transcurría, algunos de los pedidos
se iban convirtiendo en más urgentes que otros, debido a la proximidad
de su fecha de entrega, a no haber realizado entregas a cuenta o a otras
circunstancias, lo que obligaba a cambiar la prioridad relativa de los pe-

didos que aún no se habían lanzado.
Ignacio Cedreño, director de producción de Tejidos Especiales Den-
tel, quería atacar el problema de cómo cargar las máquinas para cumplir
de la mejor forma los plazos de entrega.
A fin de concretar la situación, Ignacio decidió preparar una versión
simplificada del problema con la que experimentar, y así tratar de ver
más claro cuáles eran los condicionantes de la situación y qué informa-
ción podía ayudar al encargado de la programación.
Se decidió a considerar sólo un grupo de 20 máquinas durante 15
días. Inicialmente supuso que todas las máquinas estaban sin carga y se
CASO 5. TEJIDOS ESPECIALES DENTEL 631
preparó la lista de pedidos, con sus fechas de servicio, que aparecen en

el siguiente cuadro.
Tabla1
Versión simplificada del problema de Dentel
Cliente Pedido (1) Entrega (2) Prioridad (3)
A100 6 3 A
A137 2 3 N
A400 4 4 A
B108 8 4 N
B400 10 5 N
A400 8 5 B
A238 6 5 N
B007 10 6 A
B009 12 6 A
C017 12 6 N
C018 10 6 N
A200 5 7 B
A203 5 7 N
A537 10 7 N
A211 14 7 A
A219 10 7 N
B105 4 7 N
B107 10 8 N
B217 5 8 N
A100 3 8 A
B455 3 8 N
B128 15 8 A
B213 10 9 N
B800 20 9 N
A431 10 9 N
A470 4 9 N
A503 10 10 N
A137 10 10 N
B001 8 11 N
B813 4 11 N
B802 4 12 N
(1) En días máquina.

(2) Referida a la fecha inicial (día 0). Debe entregarse al final del día señalado. Estas fechas repre-
sentan el momento en el que el pedido debe salir de tisaje para llegar a tiempo.
(3) A = Alta. Exige un cumplimiento riguroso de la fecha
N = Normal. Permite el retraso siempre que sea pequeño (1 ó 2 días).
B = Baja. Permite retrasos graves sin problemas.
La cuestión era ahora estudiar cómo se podía cumplir el programa

de entregas, incluyendo evidentemente la posibilidad de que llegaran
nuevos pedidos durante el plazo de producción de los ya existentes.
1. Enfoque del modelo
Para este caso, hemos construido el modelo de simulación más

complicado de los que se presentan en este libro. Por ello no vamos a
entrar en su descripción y remitimos al lector al CD adjunto, donde en-
contrará los listados completos, repartidos en 10 ficheros. Cada fichero
contiene documentación sobre su contenido, lo que debería facilitar la
lectura del código.
En este caso, la palabra simulación adquiere un significado ligera-
mente distinto al utilizado hasta ahora. Desde hace mucho tiempo, se
construyen simuladores para el entrenamiento de agentes que necesitan
practicar sobre situaciones reales, pero que no pueden hacerlo porque la
situación real es cara de preparar o simplemente peligrosa. La situación
más típica es el entrenamiento de pilotos de avión. Un piloto es funda-
mentalmente un conductor de un vehículo. Por tanto debe poseer un do-
minio notable de la forma de accionar aquél. Probablemente cualquiera
podría pilotar un avión en situaciones normales. De hecho, un piloto au-
tomático, un mecanismo, es capaz de hacerlo sin problemas. La dificul-
tad aparece en situaciones excepcionales, y para estas situaciones debe
prepararse el conductor novel. Pero hacer volar un avión para entrenar
a un piloto en circunstancias excepcionales es caro, y es peligroso. Para
evitarlo construimos una replica funcional del avión, que imita su fun-
cionamiento, y entrenamos al piloto sometiéndolo a circunstancias ex-
cepcionales simuladas, que no ponen en peligro su integridad física.
Este tipo de aplicaciones no están excesivamente desarrolladas en la
empresa. Pocas empresas poseen simuladores que les ayuden a entrenar
a sus directivos. A lo sumo, se realizan «Juegos de empresa» que son
una pobre réplica de la realidad, al concentrarse sólo en los aspectos
mentales de la misma.
Pero este tipo de enfoque es de gran importancia para el futuro del
aprendizaje en el trabajo. De hecho, es una de las pocas puertas de en-

trada de la tecnología en el mundo de la educación en general, y de la
ecuación en la empresa en particular. De hecho entroncan con los re-
cientes enfoques de la gestión del conocimiento [Muñoz-Seca & Rive-
rola].
De acuerdo con este enfoque, los adultos sólo aprenden cuando re-
suelven problemas. De manera que la forma de aprender de un adulto
que optimiza su aprendizaje es sumergiéndose en problemas reales. Sin
embargo, el grado de aprendizaje que el agente adquiere al resolver un
problema depende del reto que éste le plantea, que a su vez depende del
conocimiento que el agente tiene. La curva de la figura 1 [De Treville]
muestra la relación entre reto y aprendizaje.
En la figura se observan la curva que relaciona el tamaño del reto, en

las abcisas, con el grado de aprendizaje, en las ordenadas. Pueden obser-
varse tres zonas en la curva. La primera zona, a la izquierda, correspon-
de al caso en que el problema representa un reto muy pequeño para el
agente. En este caso, el agente encuentra el problema trivial, aplica el co-
nocimiento que posee y no aprende nada, o casi nada, de la experiencia.
Por el contrario, en la extrema derecha, el problema presenta un reto
muy grande para el agente, lo que hace que su resolución sea frustrante.
Por este motivo el agente aprende también poco. La zona central, o de
máximo aprendizaje, es la zona donde el reto es el adecuado para que el
agente resuelva el problema con aprendizaje máximo. Por supuesto un
problema no presenta el mismo reto para todas las personas: el tamaño
del reto depende la situación del conocimiento del agente.
Figura 1
Relación entre reto y aprendizaje
Trivial Frustrante
Reto
Si experimentar el problema real es caro o peligroso, la empresa

puede tratar de desarrollar mundos virtuales donde la experimentación
pueda desarrollarse de forma barata y segura para el agente. La simula-
ción es una de las herramientas a usar para este fin. Las implicaciones
de estas ideas son extensas e importantes, y no podemos entrar en deta-
lles aquí. Referimos al lector a la obra [Muñoz-Seca & Riverola] para
un tratamiento más completo del tema.
En línea con esta idea, aquí construimos un modelo, un mundo vir-

tual 2, y dejamos que el usuario lo maneje como si fuera la realidad. De
esta forma el decisor tiene una vivencia directa del problema y de lo que
un sistema informático puede hacer para él. El modelo es pues una he-
rramienta de aprendizaje por solución de problemas, que usa el modelo
para sumergir al decisor en el problema.
Nuestro agente en esta simulación es Cedreño, y por tanto el propó-
sito general del modelo será ayudar a Cedreño a entender mejor la es-
tructura general del problema al que se enfrenta, a través de una expe-
riencia directa.
2. El esquema general del modelo
Para simular el sistema, cada una de las veinte máquinas estará re-
presentada por un procesador. Todos los pedidos de los clientes estarán
almacenados en una lista 3 a la que apunta la variable Pedidos. Cada ele-
mento de esta lista es otra lista, que representará un pedido específico
de un cliente con sus características, como la fecha de entrega, el códi-
go del cliente o la prioridad, según el cuadro 1.
Cuadro 1
Estructura de la lista de un pedido
1. Número del pedido.

2. Días de máquina que requiere el pedido.
3. Fecha de entrega, relativa a cero (inicio de la simulación).
4. Prioridad: 3 máxima, 2 media, 1 baja.
5. Código del pedido.

6. Día en que llegó el pedido.
7. Fecha real de entrega.
8. Número de fragmentos por fabricar en cada momento.
9. Copia de la carga.
2. También podría llamarse construir «un Simulador de Vuelo», pero la expresión

«mundo virtual» queda mucho más científica.
3. Ver capítulo 18, Simulación de Procesos y Listas.
Como siempre que se programa con listas, el código hace hincapié

en esconder los detalles de la implantación. Por ello, todos los accesos
a esta estructura maestra están canalizados a través de funciones del
usuario, la mayoría de ellas contenidas y documentadas en el fichero
DentelMacros.pss.
Las características y funciones del modelo son:
1. Pedidos dinámicos. El modelo va a recibir los pedidos que se
dan en la tabla del caso. Pero estos pedidos sólo son los que se
hallan en mano en el momento de iniciar la simulación. A medi-
da que el tiempo transcurra irán llegando, presumiblemente, nue-
vos pedidos. Por tanto tendremos esta circunstancia en cuenta
generando nuevos pedidos en el tiempo, de acuerdo con unas ca-
racterísticas definidas en el fichero DentelGeneraPedidos.pss.
2. Asignación de prioridades a los pedidos. A cada pedido se le
asignará una prioridad de acuerdo con una función de prioridad
definida por el usuario. El sistema suministra una función inicial,
en el fichero DentelPrioridad.pss, que calcula una prioridad di-
námica a partir de una prioridad inicial preespecificada. Esta
prioridad es mayor cuanto mayor es la cercanía de la fecha de
entrega, y aumenta también con la carga remanente del pedido,
es decir con el trabajo que aún falta por realizar para cumplimen-
tarlo.
3. El sistema debe cargar las máquinas con los pedidos pendientes
de completar, teniendo en cuenta el estado de carga de cada má-
quina en cada momento, y tratando de respetar los planes reali-
zados con anterioridad. Por el momento, y para no añadir dema-
siado reto al problema, se supone que los planes trazados se
cumplen. La única aleatoriedad es la estructura y el número de
los nuevos pedidos.
4. La carga de las maquinas va ser realizada por el propio sistema.

Así el agente podrá observar lo que sucede en esta alternativa. La
asignación se hará de una forma simple 4, pedido a pedido, tratan-
do de llegar a tiempo en la fecha de entrega y tomando los pedi-
dos de acuerdo con su prioridad calculada. El agente puede mo-
dificar las prioridades de los pedidos manualmente, en cualquier
4. En las primeras versiones del modelo se usaban procedimientos sofisticados de

asignación de pedidos a máquinas, incluyendo el uso de procedimientos como los del
capítulo 19. Pero el tamaño del reto aumentaba sobremanera, ya que la mayoría de los
usuarios no tenía el conocimiento suficiente para entender qué sucedía con el proceso
de asignación de pedidos a máquinas.
momento antes de realizar una nueva carga. Para la elección de

la máquina a asignar, se tiene en cuenta el estado de carga de
cada máquina, tratando de cargar primero las más descargadas.
De esta forma se influye sobre los costes, tratando de modelar-
los. En ningún caso el modelo quiere tratar de optimizar el cos-
te 5.
5. El modelo debe construir y presentar al agente el diagrama de
Gantt de la carga de máquinas. Esta es una representación na-
tural del problema, y proporciona output sensorial de calidad al
agente 6. Adicionalmente, el decisor necesita de una visión ge-
neral del problema, para no perderse en los detalles que apare-
cen en el diagrama de Gantt, o en un listado de pedidos. Esta
información global sobre el estado de carga de la factoría y los
posibles retrasos que se puedan producir es el dominio natural
de las curvas de input-output (ver el caso Donner). El usuario
debe obtener estas curvas y seguir su evolución en todo mo-
mento.
3. El funcionamiento del modelo
Para ilustrar la forma en que se llevan a cabo las anteriores tareas,

damos a continuación una breve sinopsis del papel de las funciones cen-
trales del modelo.
5. Curiosamente, en muchos de nuestros cursos en que se usa este caso los directi-
vos quieren obtener la solución de coste mínimo, en la creencia equivocada de que con
un ordenador rápido basta para obtenerla. La solución de coste mínimo tiene muchas
propiedades malévolas. En primer lugar es complicada de obtener. Aunque se pueda, y
en este caso se puede obtener una solución decente con un procedimiento moderada-
mente complicado, no escala bien, por lo que es totalmente inaplicable al caso general.
También, el ordenador tarda mucho tiempo en obtenerla, lo que aburre al agente y des-
virtúa el proceso. Pero lo más importante es que la lógica de la solución óptima es difu-
sa y borrosa. Porqué las cosas ocurren como ocurren es complicado de entender y es
otro componente del reto y de la frustración del agente.
6. Dicho esto, digamos que en la versión presentada, el diagrama de Gantt presen-
ta las limitaciones típicas de estos diagramas en PSPS. La más importante es que la
identificación de las actividades que figuran en el diagrama sólo puede hacerse por el
color de la barra asociada. Para salvar el escollo, damos también una tabla de asignacio-
nes, en la que se muestra el pedido asignado a cada máquina en cada día. Pero en el
PSPS XXIII, con fecha prevista de aparición de la beta 10/2/2030 proporcionaremos
una implantación mejor del diagrama de barras.
Función Planifica_Produccion:
— Asigna a la variable Hoy el valor del reloj de simulación. Esta
variable indica el periodo en el que nos encontramos.
— Mediante la función InitTablas se encarga de actualizar los
arrays CargaMaquina y PlanProduccion que contienen
las cantidades obvias.
— Crea una tabla resumen de la lista de los PedidosEnCurso
mediante la función Resumen_de_Pedidos. Esta función
presenta al agente una tabla en la que cada fila representa un pe-
dido de un cliente, y las columnas las diferentes características
del mismo.
— Invita al agente a hacer cambios en la prioridad de los pedidos.
Por medio de un cuadro de diálogo. Si se hace algún cambio, la
función Leer_Prioridades lee los cambios.
— La función Creacion_Plan_Produccion crea el plan de
producción. Esta función añade cada uno de los pedidos de la
lista PedidosEnCurso, al plan de producción mediante la
función AnyadePedidos.
Función AnyadePedidos:
— Asigna a la variable d, el día de la fecha de entrega y a la varia-
ble c la carga, en días de máquina, del pedido que queremos in-
cluir.
— Mediante un bucle y las funciones InitEspacio y Maqui-
naDisponible, se calcula el espacio, en días de máquina,
que hay disponible hasta el día de la entrega del pedido. Si el es-
pacio disponible es menor que la carga del pedido, se vuelve a
repetir el cálculo, empezando un día más tarde. Cuando el espa-

cio libre calculado es menor que la carga del pedido salimos del
bucle. De esta forma obtenemos el tiempo más lejano en el que
se puede programar el pedido, y aún entregar a tiempo.
— Ahora se ordenan las maquinas de acuerdo con el tiempo dispo-
nible que aún tienen, empezando por la que dispone de más
tiempo.
— Mediante la función RevisarPlan se asignan máquinas al
pedido, empezando por la que dispone de más tiempo. La fun-
ción RevisarPlan modifica el array CargaMaquina, en el
que se indica la carga de cada máquina en todo momento. Tam-
bién modifica el array PlanProduccion en el que se resume
el resultado del proceso, es decir, el pedido que se realiza en

cada máquina y en cada periodo concreto.
Función GeneraDemandaDeUnDia:
— Determina el número de nuevos pedidos que llegan en el perio-
do consultando el array Demanda que se inicializa por datos.
— Si va a llegar algún pedido nuevo, la función Genera_Pedi-
do se encarga de crearlo. El pedido se añadirá a la lista de Pe-
didosEnCurso mediante la función AddToLista.
— Mediante la función CalculaPrioridades se asignan prio-
ridades a los pedidos.
— Ordena la nueva lista de PedidosEnCurso según las priori-
dades calculadas, en sentido descendente.
— Devuelve la nueva lista de PedidosEnCurso ordenada según
las prioridades.
Función Ajuste_Produccion:
— Tras haber pasado un periodo, ajusta los datos de producción
para tener en cuenta el trabajo realizado. En concreto, pone al
día la carga remanente por fabricar de cada pedido, disminuyén-
dolo en una unidad de tiempo.
— Mediante la función PorFabricar calcula el número total de
días que queda por fabricar en cada pedido.
— Si en un pedido ya no quedan unidades por fabricar, se ejecuta
la función AjustarEntregas, que elimina el pedido de la
lista de PedidosEnCurso. Una vez hecho esto, añade la fe-
cha real de entrega y el pedido a la lista PedidosEntrega-
dos mediante la función AddToLista.

— Devuelve el número de unidades que quedan por fabricar.
La función Planifica_Produccion se encarga de inicializar

la tabla resumen de pedidos que contiene la lista de los pedidos en cur-
so. Inicialmente esta tabla contiene la lista de los pedidos que aparece
en el fichero DentelPedidos.pss. Esta tabla se actualiza cada vez que se
hace un plan de producción, es decir cada vez que llega un pedido nue-
vo.
Figura 2
Pedidos en curso en el instante Cl = 1
Otra tabla muestra la situación del plan de plan de producción tal y

como ha sido calculado hasta la fecha.
Figura 3
User Table 2 en el instante Cl = 1
El contenido de esta tabla también se muestra en forma de diagrama

de Gantt.
Figura 4
Diagrama de Gantt en el instante Cl =1
Como hemos dicho, el sistema presenta también las curvas input-

ouput de los pedidos en curso. El gráfico contiene dos series de datos
distintos. La serie 1 muestra la curva de input, es decir, la carga de má-
quinas generada por los pedidos en cada periodo. La serie 2 presenta los
valores acumulados del número de máquinas disponibles, curva de out-
put máxima del sistema.
Figura 5
Curvas de input/output del sistema
Una vez que el pedido ha sido entregado el programa tabula plazo

real de entrega del mismo, es decir la diferencia entre la fecha de llega-
da del pedido y la fecha de entrega, que se tabula en un histograma.
Histograma 1:
Tiempo de permanencia
5. Experimentación
El lector debe ahora olvidarse de la simulación y de otras lindezas,

y sumergirse en el modelo. Su papel es entender y modificar. Para ello,
cuando el del sistema pregunta si se quieren hacer modificaciones, pue-
de responder SÍ y proceder a entrar datos en la tabla de pedidos en cur-

so. Una vez completadas las modificaciones debe pulsar el botón CON-
TINUE, para seguir simulando. Le deseamos que tenga «buen viento y
barca nueva», en su singladura por este océano.
Y de paso nos despedimos del lector, agradeciéndole el empeño y
buen humor que ha demostrado al haber llegado hasta aquí.
¡Gracias! ¡Y hasta siempre!
ÍNDICE DE MATERIAS
acontecimiento, 41-42, 204, 206, CAR, 467-470, 476-477, 482-483,

216-217, 225 485-487, 489, 494, 508, 515, 535,
— pendiente, 41-42, 64, 66 544
acontecimientos, 40-41, 202, 204, CDR, 467-470, 476-477, 482-483,
215-217, 336, 393, 525 486-487, 489, 509, 515
ADVANCE, 40, 59, 383-384 coeficiente de variación de llegadas,
aleatoriedad, 178, 197, 206 298
análisis de cargas, 191-194, 618-619 cola, 117, 190, 252, 277
ANTI, 179, 190 colas en régimen transitorio, 300,
aprendizaje, 632-634 421, 423
argumentos, 149-151, 153-157
comentarios, 77-78
aritmética de direcciones, 90, 153-
— activos, 78, 107
155, 241
COMPUTE, 91, 124, 126, 128-129,
ASSEMBLE, 318, 328
ASSIGN, 126, 131-132, 135-136, 131, 384
140, 146 cons, 468-469, 477, 483, 486-487,
átomos, 466-468, 472, 477, 484, 490- 489, 494
492 constantes, 73-75, 79-83, 105
coordinación centralizada, 313
coordinación de procesos, 305, 307,

backward, 531
bases de datos, 465, 478-479, 533, 309, 311, 313, 315, 317, 319, 321,
537, 550 323, 325, 327, 329, 562
beta (ver distribución Beta) coordinación local, 305-306
Binomial Negativa (ver distribución curvas de input/output, 578-579, 581-
Binomial Negativa) 582, 592, 636
bloque del usuario, 376
bloques, 38, 47 debugging, 481
búsqueda en profundidad, 505-506 decisión, 25
decisor, 19-20, 22-23, 25, 28
cadena de suministro secuencial, 386 demora, 40-42, 59
capacidad, 191-194 desarrollo en espiral, 560
desviación tipo, 188, 201, 203, 208- erlang (ver Distrib Eylang), 198, 207-
211, 214, 217 208, 211, 566-568, 624-625
diagrama de barras, 168, 636 espera media, 296, 581, 611
diagrama de bloques, 39, 41, 99-100, estimaciones asintóticas, 189, 191
123, 134, 139 etiquetas (véase labels)
diagrama de Gantt, 168-170, 295, eventos, 230
526, 600, 607, 636, 639-640 exponencial (ver distribución expo-
difusión, 406 nencial)
Dinámica de Sistemas, 427-437, 439, Expresión Pspal, 53, 79
441, 443-445, 447, 449, 451, 453,
455, 457, 459, 461, 463-464 facets, 513-515, 518, 521, 524
disciplina de cola, 253, 256 FACILITY, 118-120
disciplina de espera, 52-54, 252-254, Fdistribution, 221, 549
328, 609, 611 FdrawCont, 164-167
distribución Beta, 198, 212, 215, 636 FdrawXY, 164, 166
distribución Binomial, 302, 421, 425 fenómeno del cráter, 362
— Binomial Negativa, 302, 421, 425 Fifo, 37, 46, 253-254, 256-257, 605,
— de probabilidad, 89, 197-200, 208, 609, 624-625
217, 220, 226-227, 229, 236, 241, flujo, 430, 446, 618-620
412, 548, 578, 585 forward, 531, 537
— del tiempo de servicio, 253 frame, 369, 513-524, 527
— del tiempo entre llegadas, 131, FREORDER, 609-610
288 función, 150
— discreta, 219 — de distribución, 197-199, 201,
— exponencial, 199, 202-206, 215, 219-221, 225, 228-230, 412
217, 408 — densidad, 201-203, 207, 209-212,
— normal, 208-210, 404 225, 230, 253
— Poisson, 199, 215-219, 302, 425 — en línea, 150-152, 399-401
— Poisson Compuesta, 216 funciones gráficas, 164-165
DISTRIBUTION, 88-89, 219-221
DRAWXY, 160-164, 335, 339-340,
gama, 212, 441, 629

353
GANTT, 168-170
Dt, 400-403, 405-406, 410, 416, 422
gantt, diagrama de (ver Diagrama de
Gantt)
Ecuación diferencial aleatoria, 405 GATE, 40, 315-316, 495-496, 562-
encadenamiento directo, 531, 537 563, 618, 620, 624
encadenamiento retrogrado, 531 GENERATE, 39, 46, 48-51, 91, 99-
ENTER, 40, 51-60, 99-101, 105, 112, 101, 105, 119-120, 566-567, 586-
306-310, 312-313, 315, 317, 321- 587, 602-605, 610, 624
322, 325-328, 332, 335, 337, 339, GET, 313, 320, 324-326, 332
356-357, 359-360, 364, 566-568, GETGROUP, 562
620, 624 GotoXY, 171-173
entidades, 30, 32, 34-36, 98, 503 GRAB, 142, 327-328, 562, 618
ÍNDICE ONOMÁSTICO 645
gráficos, 159-160, 167, 561, 564, listas, 465, 467-475, 477-479, 481,
588, 625 483-493, 495, 497
GROUP, 142, 318, 562 locals, 150, 152-154, 568, 570-571,
GUPDATE, 165-167 583
lognormal (ver destrib LogNormal),
HISTO, 199-200, 205, 218 198, 210-211, 582, 584
histogramas, 199, 201 lote económico de pedido, 344-345
identificadores, 74-75, 82, 105 macros, 73-74, 94, 149-150, 156

INITIAL, 165-166 Markov, 237, 241, 243, 245-246, 249,
INTEGRATE, 399-403, 406, 408- 256
409, 411, 418-419, 421, 424, 427, media, 203, 208-209, 211-212
562 — longitudinal, 185
Inteligencia Artificial, 499, 501, 503, — transversal, 185
505, 507, 509, 511-513, 515, 517, — trayectoria, 183
519, 521, 523, 525, 527, 543 medias móviles, 237
MENTER, 321-322, 562
JOIN, 142, 318, 328, 562-563 métodos de búsqueda, 504-505
MGET, 313, 525-526, 562
modelos, 21, 23-28, 32, 37, 559, 574,
Labels
618
LEAVE, 40, 55-58, 60-62, 99-100,
movimiento browniano, 404-405
105, 306-310, 312-313, 316-317,
muestras independientes, 180
321, 328, 332, 335, 337, 339,
muestreo, 198
356-357, 360, 364, 562, 567, 586,
mundo continuo, 30
602, 609, 620, 624-625
— de entidades, 30, 32
lenguaje de problema, 372-373, 375-
— de procesos, 30, 32
376
mundos generales, 33
lenguaje Pspal, 27, 79-80, 94, 126,
mundos suaves, 31, 399, 401, 403,
128, 149, 490
405, 407, 409, 411, 413, 415, 417,
lenguaje PSPS, 11-12, 26, 28, 71, 76,
419, 421, 423, 425
78
Ley de Little, 255, 258, 390, 581, 620

líneas de producción, 331, 333, 335, nivel, 399-400, 402-404, 419, 430-
337, 339, 341, 343, 345, 347, 349, 431, 434, 436-437, 446, 449, 451,
351, 353-355, 357, 359, 361, 363, 454, 456, 459, 464, 562, 570
365 Normal (ver distribución Normal)
— secuenciales, 354 números, 75-76, 574, 608
lisp, 465-468, 472, 476, 478-494, — aleatorios, 175, 178-179, 190
534, 538-539, 542, 546, 551
Lista de Acontecimientos Pendientes, objetos, 511-515, 537
L.A.P., 63-64, 66, 120 — del usuario, 373
Lista de asociación, 470 ONDEBUG, 73, 565
Lista de Transacciones Paradas, L.T.P., órdenes pendientes de recibir, 369,
63, 66 371, 387
output, 110, 159, 161, 163-165, 167, RANDOMIZE, 177-180, 185, 190
169, 171, 173, 367-368, 370, 376, recorrido de control, 61
385-386, 389, 564, 578-583, 585, recorrido físico, 61-62
592-593, 609, 636, 640 Red de colas exponenciales abiertas,
— simulación, 110, 411 271
redes abiertas de colas generales,
pattern, 533-534, 536, 539-544, 550 297, 609
pedidos pendientes de lanzar, 369, redes semánticas, 511, 516, 521, 527
387 reducción de la varianza, 179, 190
pedidos pendientes de servir, 34, 368- Regla de Ocam, 223, 432
372, 492 reglas descriptivas, 530
Poisson, 199, 215-219, 425 reglas normativas, 530
— compuesta, 216-219 reloj físico, 41-42
—, Demanda modulada de, 245 reloj maestro, 41-42, 46, 49, 55, 59,
—, distribución (ver Distribución de 62, 64-65, 67, 101, 109-110, 120-
Poisson) 121, 169
—, proceso de, 249, 256 REPORT, 106, 109, 114
política Ss, 379, 393 RESET, 188-190
predicados, 471-472, 535 resultados simulación, 175, 572-573,
principio de Ocam (ver regla de 589, 605, 625, 638
Ocam) reto, 632-633, 635-636
PrintR, 171-173 retroalimentación, 121, 124
prioridades, 581, 609, 635, 637-638
probabilidad de rotura, 346-347, 349- Sample, 219, 221
350 sección CONSTANTS, 73, 80, 105
problemas de búsqueda, 501, 503 sección DATA, 73-74, 94, 103, 105
procesador/es, 36 sección LABELS, 73, 82-83
—, acceso a, 51, 101 sección MACROS, 73, 94, 149-150,
proceso de listas, 465, 467, 469, 471, 156
473, 475, 477, 479, 481, 483, sección ONDEBUG, 73
485-489, 491, 493, 495, 497
sección SYSTEM, 73, 95, 106

Procesos ARMA, 237-238, 240 sección VARIABLES, 73-74, 83
Procesos autorregresivos, 237 secuencia, 137-138
Procesos de Semi-markov, 237, 241, SELJOIN, 142, 562
243 semáforos, 33-34, 313-314, 316-317,
procesos de Wiener, 404-405, 407 320, 495
productos en mano, 369-372, 378 señales, 428, 430, 436, 444, 625
programa PSPS, 45-47, 71-73 servidores, 251-254, 256, 259, 264-
programas de bloques, 38-39 265, 267, 270, 272, 277-278, 280,
programming help, 103-104 285, 287, 289, 292, 294, 299,
301-302
QGATE, 315-317, 563 SGROUP, 142
QUEUE, 117-120 simulación, 17-28, 559
ÍNDICE ONOMÁSTICO 647
— continua, 303, 399, 401, 403-405, TABLE, 171-172, 588, 601

407, 409, 411-413, 415, 417, 419, TABULATE, 158, 199-201, 205, 207,
421, 423, 425 218, 567, 586
— estratégica, 427, 429, 431, 433, tasa de fallo, 206, 232-234, 533
435, 437, 439, 441, 443, 445, 447, — constante, 227
449, 451, 453, 455, 457, 459, 461, — lineal, 227-229
463 Tasa variables, 230
— mixta, 408 Teoría de los fenómenos de espera,
simulador, 10, 26, 30, 287, 634 252
sincronización, 142, 147 TERMINATE, 40, 48, 50-51, 99-101,
sistema determinista, 344 105, 109-110, 121, 125
Sistema estacionario, 190 Transacción, 35
sistema logístico, 322-323, 367, 369, —, atributos, 113, 382, 384, 401, 409,
371-377, 379, 381-383, 385, 387, 525, 567, 604
389, 391, 393-395, 397, 500 —, movimiento, 39-40, 42, 46, 61,
— secuencial, 376, 394 63, 95, 106, 601
— secuencial arborescente, 373-374 —, muerte, 48, 101
Sistemas de colas, 254, 257 transacciones, copia, 142
sistemas expertos, 529-530, 541, 550 transacciones, generación, 48, 101,
slots, 370, 382, 384, 513-518, 522, 524 562
SPLIT, 142-143, 146, 317 TRANSFER, 40, 137-138, 140-141
SPT, 609 trayectoria, 175-176, 181, 183-187,
SREORDER, 610 190
SSYNCRO, 142-143, 146 TTAB, 200-201
Stat, 93-94, 110-111, 549, 600, 604
STEP, 399-401, 403, 406, 410, 417, UNGROUP, 142, 327-329, 562
419, 424, 567 unidad logística fundamental, ULF,
Stock, 332-333 150, 367-369, 372
— en mano, 331-333, 336-338, 340- uniforme (distribución), 175, 198,
344, 346, 348-349, 353, 371, 377, 212-213, 584, 629
380, 385, 387-388, 392-394, 512
— intermedios, 355 variabilidad, 182, 188, 190, 210-211,

— medio, 345, 580-581 568
— neto, 369, 387, 389-390 variable, 73, 83-87, 89-94, 573, 584-
— total, 337-338, 340-342, 369, 380, 585, 595, 634, 637
389, 396-397, 573 — aleatoria, 176, 190, 197-198, 201,
strings, 75-76, 84, 171-173, 465 209-210, 216, 218-219, 225, 254,
subsistemas, 139, 141, 312 257, 349, 352
Switch, 40, 120, 314, 562, 601, 610, — array, 85-87, 89-90, 173, 584
620, 624 — array Funcionales, FArray, 91-93,
SYNCHRO, 142, 318, 562 232-233, 414-415, 423, 447, 451,
461
tablas, 170-171, 561, 565, 567, 594, — array virtual, VArray, 89-91, 153-
620 154, 248
— global, 152-154, 249, 314, 483 VARS, 55, 587-588, 600-601, 623
— lisp, 489, 534 ventana de texto, 71-72, 77, 102-103,
— local, 152-153 106-107
variables correlacionadas, 224, 236- — principal, 107
237 Ventana raíz, 107, 109
— dependientes, 223, 225, 227, 229,
231, 233, 235, 237, 239, 241, 243, WAITFOR, 40-41, 59-60, 99-100,
245, 247, 249 102, 105, 336, 339, 357, 360, 364
— escalates, 84
— stat, 93 YIELD, 335-336, 339
varianza, 179, 190, 212, 277, 298,
302-303, 348-350, 404, 421-425 Zipkin, 391-392, 394, 397, 527
EMPRESA Y ORGANIZACIONES
Libros IESE
F. K. Foulkes
Para un trabajo más satisfactorio
A. P. Sloan
Mis años en la General Motors
B. Roig
La empresa ante las realidades de fin de siglo (2.ª ed.)
D. Melé (Coord.)
(Conversaciones sobre Ética Empresarial y Económica)
Ética, mercado y negocios
Ética, trabajo y empleo
Ética en el gobierno de la empresa
Ética en la actividad financiera (2.ª ed.)
Ética en dirección comercial y publicidad
Consideraciones éticas sobre la iniciativa emprededora y la empresa fa-
miliar
Raíces éticas del liderazgo
J. M.ª Rodríguez Porras
El factor humano en la empresa. Apuntes
Instituto de Empresa y Humanismo (editor)
Capitalismo y cultura cristiana
J. Riverola, B. Cuadrado
Arte y oficio de la simulación. Un entorno completo y su uso en la me-
jora de los servicios
Manuales IESE
F. Pereira, E. Ballarín, J. M.ª Rosanas, J. C. Vázquez-Dodero

Contabilidad para dirección (20.ª ed.)
G. W. Plossl, O. W. Wight
El control de la producción y los stocks
G. A. Steiner
Planificación de la alta dirección
Tomo I (4.ª ed.)
Tomo II (4.ª ed.)
A. Valero y Vicente, J. L. Lucas
Política de empresa (5.ª ed.)
J. Farrán
Comercialización agroalimentaria
B. O’C. Leggett
Comunicación oral en la empresa
P. Fernández, J. Santomá
Finanzas para directivos (2.ª ed.)
J. Farrán, A. Agustín, J. C. Yábar, J. M. Rizo, R. Lacasta, J. Ireland
Distribución y logística
A. Valero y Vicente, E. Taracena Figueroa
La empresa de negocios y la alta dirección (2.ª ed.)
P. Agell y J. A. Segarra
Escuchando la voz del mercado. Decisiones de segmentación y posicio-
namiento
C. Chiesa de Negri
Fidelizando para fidelizar. Cómo dirigir, organizar y retener a nuestro
Equipo Comercial

Arte y Oficio de La Simulación - (PG 392 - 650)

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Arte y Oficio de La Simulación - (PG 392 - 650)

Загружено:

Авторское право:

Доступные форматы

392 EL ARTE DE LA SIMULACIÓN

Hacemos la simulación con los mismos datos de las secciones pre-

distribuciones de la demanda durante el plazo de entrega teórico del

En estos histogramas es fácil leer la probabilidad de tener stock re-

tes de tamaño aleatorio. Aunque la demanda total sea la misma,

4. No hay interferencias debidas a lotes, incluyendo los lotes de en-

6. Un sistema logístico más complejo

Sigamos examinando el comportamiento del sistema logístico de

{---Sistema logístico secuencial ----}

{---parámetros del sistema logístico--------}

{---Curvas de IO que se desea dibujar-------}

{-------Generación y subida de pedidos-----------------------}

Montemos una nueva red logística con esta estructura y simulemos.

A pesar de las fluctuaciones, podemos observar que el servicio en

Ahora el servicio es algo mejor que en el caso inicial. Por tanto el

constatar con un ejemplo sencillo. Supongamos que un mercado se cu-

ZIPKIN, Paul, Foundations of inventory management, McGraw-Hill,

la sección System podemos implementar de manera sencilla la simula-

1. Simulación Continua. Bloque INTEGRATE

El bloque INTEGRATE del PSPS se limita a programar la ejecución

La mayoría de procesos en tiempo continuo se pueden especificar

x (t + α) = x(t) + (llenado (x,t) – vaciado (x,t))α

El cálculo iterativo debe usar un valor de dt, el intervalo elemental

1. Moraleja: Usar bien el bloque INTEGRATE es un arte que se adquiere con la

Este ejemplo muestra la forma de simular el vaciado y llenado de

nivel = nivel - Cond(nivel> 0,Min(velocidad*dt,nivel)),

El modelo tiene dos bloques generadores. El primer bloque GENE-

al llegar al bloque INTEGRATE, la función Vaciado. Esta función

2. Movimiento Browniano y difusiones

Uno de los procesos aleatorios más usado en la simulación dis-

consistencia, es necesario que la media de la distribución sea proporcio-

2. Incrementos independientes, el incremento de la trayectoria en

coeficiente de difusión (diffusion coefficient). Ambos dependen, en ge-

2. Aunque el desarrollo es horriblemente complicado y sorprendente. Por ejemplo,

dia de los incrementos de las mismas. Por su parte, el coeficiente b(x,t)

bxt : function(x,t,k) return sqrt(k);

La simulación de una difusión es sencilla. Basta tratar la ecuación

El cuadro anterior muestra cómo generar este proceso. La figura 2

Es de destacar la irregularidad salvaje de las trayectorias, que no se

El proceso de Wiener tiene todo tipo de propiedades curiosas. Por

tos, valga que como aproximación a un proceso normal en tiempo con-

3. Simulación mixta discreta / continua

A menudo es necesario simultanear la simulación discreta con la

Una factoría dispone de un horno en el que se lleva a cabo el reco-

y el coeficiente de transmisión de calor, desde el entorno del horno has-

Programa del modelo:

Las transacciones que representan a los lingotes son generadas por

lingotes se asignan a los atributos de la transacción mediante un bloque

código sea reentrante, es decir ejecutable por varias transacciones a la

{--Mientras se espera se va enfriando--}

If fc[Horno] < fs[horno] then Return True

{--aproximación a la caida de temperatura del horno al entrar un

Cuando el lingote alcanza la temperatura deseada, la transacción

El modelo se puede instrumentar ahora para obtener diferentes pa-

El tiempo medio de estancia es 30 minutos y el coeficiente de varia-

Ejemplo 3: Simulación de una planta alcoholera

El proceso de destilación que se lleva a cabo en una planta produc-

La melaza llega de forma continua a la planta, que dispone de dos

Esquema del modelo:

Cuba melaza Torre de

En el modelo de la planta alcoholera, que desarrollamos a continua-

En este proceso continuo hay que modelar el retraso que se produce

Programa del modelo