Matemática Discreta (UNED) - Modelado de Sistemas de Eventos Discretos

MODELADO DE SISTEMAS
DE EVENTOS DISCRETOS
petición petición petición petición
recepción recepción recepción recepción
Fernando Morilla García Natividad Duro Carralero
Departamento de Informática y Automática
E.T.S. de Ingeniería Informática, UNED
Mayo, 2004
Contenidos
Tema 1 : Introducción al modelado de sistemas discretos
1.1 Sistemas y experimentos ………………………………………………………… 1
1.2 Modelado y simulación ………………………………………………………….. 2

1.2.1 Modelos matemáticos……………………………………………...……...…4
1.3 Modelado de sistemas de eventos discretos……………………………………… 6

1.3.1 Componentes del modelo……………………………………………………7
1.3.2 Naturaleza del modelo…………………………………………………….. 11
1.3.3 Paradigmas de modelado………………………………………………….. 12
1.4 Metodología de modelado…………………………………………………….....13

1.4.1 Formulación del modelo ………………..……………………………….... 13
1.4.2 Lenguajes de modelado y simulación.......………………………………… 14
1.4.3 Verificación y validación.………………...……………………………….. 15
1.5 Ejemplos de sistemas de eventos discretos …………………………………… 17

1.5.1 “Taquilla de un cine”……..……………………………………………….. 17
1.5.2 “Sistema simple de producción”………...………………………………… 19
1.5.3 “Semáforo de peatones”…………………...……………………………….20
1.5.4 “Carro que va y viene”…………………………………………………... 21
1.6 Técnicas de descripción funcional……………………………………………… 22

1.6.1 Diagramas de flujo u organigrama ………...……………………………. 23
1.6.2 Autómata finito………………………………..…………………………... 25
1.6.3 Grafo reducido…………………………………..………………………… 28
1.6.3.1 “Carros que van y vienen por raíles diferentes, sincronizados
en los extremos”………………………………………………... 30
1.6.3.2 Crítica al grafo reducido…………………………………………. 33
1.7 Ejercicios resueltos ……………………………………………………………...35
Tema 2 : Redes de Petri
2.1 Definición formal de las Redes de Petri ……………………………………… 49
2.2 Reglas del comportamiento dinámico de una Red de Petri…………………… 51

2.2.1 Marcado de una Red de Petri ………………………………………….. 51
2.2.2 Propiedades básicas de las transiciones de una Red de Petri …….…….52
2.2.3 Evolución y análisis de una Red de Petri ………………………….…...54
2.3 Configuraciones y propiedades básicas de las Redes de Petri………………... 57

2.3.1 Posibles configuraciones elementales de las Redes de Petri ….………. 57
2.3.2 Propiedades básicas de las Redes de Petri……………………………... 59
i
Contenidos
2.4 Concurrencia y sincronización.……………………………………………….. 64
2.5 Extensiones de las Redes de Petri…..………………………………………… 65

2.5.1 Redes de Petri Interpretadas…………………………………………… 65
2.5.2 Redes de Petri Coloreadas……………………………………………... 66
2.5.3 Consideraciones del modelado con RdP…………………………….….68
2.6 Ejercicios resueltos …………………………………………………………… 70
Tema 3 : Diseño e implementación de automatismos
3.1 Diseño de automatismos con GRAFCET.…………………………………..… 97

3.1.1 Conceptos básicos del GRAFCET…………………………………….. 99
3.1.1.1 Concepto de etapa………………………………………………… 100
3.1.1.2 Concepto de transición…………………………………………… 101
3.1.1.3 Concepto de unión orientada…………………...………………… 102
3.1.1.4 Concepto de macroetapa………………………………………….. 102
3.1.2 Reglas de evolución del GRAFCET………………………………….. 103
3.1.3 Estructuras en el GRAFCET…………………………………………. 105
3.1.3.1 Secuenciamiento lineal y paralelo………………………………... 105
3.1.3.2 Convergencia en <<O>>…………………………………………. 106
3.1.3.3 Divergencia en <<O>>…………………………………………… 107
3.1.3.4 Convergencia en <<Y>>…………………………………………. 108
3.1.3.5 Divergencia en <<Y>>…………………………………………… 108
3.1.3.6 Salto de etapas y bucles de repetición de una misma etapa………. 108
3.1.4 Ejemplos……………………………………………………………… 109
3.2 Implementación de automatismos con GRAFCET………………………….. 112

3.2.1 Obtención de funciones lógicas a partir del diagrama GRAFCET…... 113
3.2.2 Funciones lógicas de las estructuras lógicas…………………………..114
3.2.3 Ejemplos……………………………………………………………… 116
3.3 Diseño estructurado………………………………………………………….. 118

3.3.1 Necesidad de estructuración………………………………………….. 118
3.3.2 Modos de marcha……………………………………………………...119
3.3.2.1 Funcionamiento semiautomático…………………………………. 120
3.3.2.2 Funcionamiento automático….…………………………………... 122
3.3.3 Seguridad……………………………………………………………... 123
3.3.4 Diseño estructurado…………………………………………………... 125
3.3.4.1 Tipos de órdenes de forzado……………………………………… 125
3.3.4.2 Reglas de evolución del forzado………………………………….. 126
3.3.4.3 Características del forzado………………………………………...126
3.3.4.4 Implementación del forzado……………………………………… 127
3.4 Ejercicios resueltos ………………………………………………………….. 129
ii
Contenidos
Tema 4 : Formalismo DEVS (Discrete EVents dynamic Systems)
4.1 Modelos atómicos.…………………………………………………………… 143
4.2 Ejemplos de modelos atómicos……………………………………………… 147

4.2.1 Generador de eventos………………………………………………… 147
4.2.2 Transmisor o procesador……………………………………………... 151
4.2.3 Bloques de almacenamiento………………………………………….. 155
4.2.4 Bloques repartidores………………………………………………….. 165
4.3 Modelos acoplados…………………………………………………………... 167
4.4 Modelos en Paralelo…………………………………………………………. 169
4.5 Ejercicios resueltos ………………………………………………………….. 171
Anexo : Ejercicios para programar en ARENA
A.1 Modelos de autómatas de estado.………………………………….………… 191

A.1.1 Ejercicio 1: “Autómata cíclico con dos estados”……………………... 191
A.1.2 Variantes del ejercicio1………………………………………………. 193
A.1.3 Ejercicio 2: “Autómata con estados de espera y ocupado”…………... 198
A.1.4 Variantes del ejercicio2………………………………………………. 200
A.2 Modelos con estructura de red de Petri……………………………………… 204

A.2.1 Ejercicio 3: Encendido y apagado de una lámpara…………………… 204
A.2.2 Ejercicio 4: Carro que va y viene de derecha a izquierda……………..207
A.2.3 Ejercicio 5: Semáforo de peatones…………………………………… 209
A.2.4 Ejercicio 6: Carro que va y viene, con botón de parada……………… 211
A.2.5 Ejercicio 7: Montacargas……………………………………………... 214
A.2.6 Ejercicio 8: Carros que van y vienen…………………………………. 217
A.2.7 Ejercicio 9: Sistema de producción con dos robots, dos máquinas y dos
almacenes……………………………………………………………….. 221
A.3 Modelos sobre automatismos………………………………………………... 225

A.3.1 Ejercicio 10: Automatismo para encendido y apagado de una
lámpara………………………………………………………………….. 225
A.3.2 Ejercicio 11: Automatismo para control del carro que va y viene ……227
A.3.3 Ejercicio 12: Automatismo para control de los dos carros que van y
vienen, sincronizados en el extremo izquierdo…………………………. 232
A.3.4 Ejercicio 13: Automatismo para el control de tráfico en un cruce con dos
semáforos……………………………………………………………….. 235
A.3.5 Ejercicio 14: Automatismo para el control de un semáforo de
peatones…………………………………………………………………. 237
Bibliografía ………………………………………..……………………………….... 243
iii
Contenidos
iv
TEMA 1
Introducción al modelado de sistemas

discretos
Los Sistemas Discretos son sistemas dinámicos que, a diferencia de los sistemas
continuos, cambian de estado en instantes periódicos de tiempo, marcados por un reloj.
Por ejemplo, los sistemas secuenciales y los sistemas digitales son casos particulares de
sistemas discretos. Pero en esta asignatura nos interesaremos principalmente por el
modelado de Sistemas de Eventos Discretos, aquellos en los que los cambios de estado
se producen como consecuencia de eventos aleatorios.
Al comienzo del tema se da un repaso a los principales conceptos de modelado y

simulación, que son aplicables a cualquier tipo de sistemas, pero a continuación nos
centraremos en aquellos aspectos que son más relevantes en los sistemas de eventos
discretos. También se presentarán varios ejemplos, que a pesar de su simplicidad son
bastante representativos de los fenómenos que trataremos de modelar en esta asignatura.
Estos ejemplos nos servirán para repasar algunas técnicas de descripción funcional, que
ya se han visto en otras asignaturas, y para poner de manifiesto algunas limitaciones que
las hacen poco aconsejables para describir sistemas de eventos discretos en general.
1.1 SISTEMAS Y EXPERIMENTOS
En el sentido amplio del término, un sistema S es un objeto formado por un conjunto de

partes entre las que se establece alguna forma de relación, y del que interesa
fundamentalmente su comportamiento global (Aracil y Gordillo, 1997). Lo utilizaremos
indistintamente para referirnos a entidades reales o artificiales más o menos complejas,
cuyo comportamiento se quiera estudiar.
Con esta definición tan amplia, cualquier fuente potencial de datos puede, en efecto,
considerarse un sistema. Algunos ejemplos de sistema son:
• El sistema planetario formado por los planetas ligados por las fuerzas
gravitatorias que se ejercen entre ellos y el Sol.
1
Introducción al modelado de sistemas discretos
• Un sistema ecológico formado por diferentes poblaciones entre las que se

establecen relaciones de cooperación o de predación.
• Un sistema económico formado por los diferentes agentes entre los que se
producen relaciones de intercambio de bienes y prestación de servicios.
• Una empresa, en la que se coordinan sus distintos departamentos para, por una
parte, producir el producto o servicio que justifica su existencia y, por otra,
asegurar la adecuada retribución del trabajo y del capital en ella involucrados.
• Una planta de fabricación formada por máquinas, personal, dispositivos de
transporte y almacén.
• El servicio de emergencias de un hospital, incluyendo al personal, las salas, el
equipamiento y el transporte de los pacientes.
• Una red de computadores con servidores, clientes, dispositivos de disco y de
cinta, impresoras, etc.
• Un supermercado con control de inventario, cajeros y atención al cliente.
• Un parque temático con atracciones, tiendas, restaurantes, trabajadores, clientes
y aparcamientos.
Un procedimiento para conocer el comportamiento de los sistemas es la

experimentación. De hecho, éste ha sido el método empleado durante siglos para
avanzar en el conocimiento. Un experimento es el proceso de extraer datos de un
sistema sobre el cual se ha ejercido una acción externa (Urquía, 2003). Por ejemplo, el
encargado de un supermercado puede ensayar diferentes procedimientos de control del
inventario y de distribución del personal para determinar qué combinaciones
demuestran ser más rentables y proporcionan un mejor servicio.
Cuando es posible trabajar directamente con el sistema real, el método experimental

presenta indudables ventajas. Sin embargo, para que los resultados del experimento sean
válidos, debe garantizarse que no existen variables ocultas “confundidas” con las
variables experimentales. Por ejemplo, continuando con el modelo del supermercado, si
la afluencia de público durante el periodo en que se experimenta una estrategia de
servicio es significativamente mayor que durante el periodo en que se experimenta la
otra, no podrá extraerse ninguna conclusión válida sobre el tiempo medio de espera de
los clientes en la cola de las cajas.
En ciertas ocasiones es imposible experimentar con el sistema real, porque el sistema

aún no existe. Esta situación se plantea frecuentemente en la fase de diseño de nuevos
sistemas, cuando el ingeniero necesita predecir el comportamiento de los mismos antes
de que sean construidos. Y en la mayoría de las ocasiones la experimentación es
desaconsejable; ya sea por el elevado coste económico o temporal del experimento,
porque éste produciría malestar en los usuarios del sistema, etc. En estos casos, el
modelado y la simulación son las técnicas adecuadas para el análisis de sistema.
1.2 MODELADO Y SIMULACIÓN
Llamaremos modelo M a un objeto artificial construido para representar de forma

simplificada a un fenómeno o sistema real. Modelado al proceso mediante el cual se
construye un modelo de un aspecto problemático de la realidad. Y simulación al
conjunto de técnicas que permiten analizar sistemas arbitrarios de forma precisa, bajo
diferentes condiciones experimentales, haciendo uso de un modelo del sistema.
2
Los seres humanos, en nuestra vida cotidiana, empleamos continuamente modelos para
comprender y predecir el comportamiento de sistemas. Por ejemplo, considerar que
alguien es “amable” constituye un modelo del comportamiento de esa persona. Este
modelo nos ayuda a responder, por ejemplo, a la pregunta: ¿cómo reaccionará si le
pedimos un favor? También disponemos de modelos de los sistemas técnicos que están
basados en la intuición y en la experiencia. Por ejemplo, aprender a conducir un coche
consiste parcialmente en desarrollar un modelo mental de las propiedades de la
conducción del coche. Asimismo, un operario trabajando en determinado proceso
industrial sabe cómo el proceso reacciona ante diferentes acciones, y mediante el
entrenamiento y la experiencia, ha desarrollado un modelo del proceso. Todos estos
modelos, que son una representación informal de un cierto aspecto de la realidad, se
llaman modelos mentales. Son muy valiosos porque permiten recoger la experiencia de
los especialistas en el problema correspondiente y constituyen el punto de partida en
muchos procesos de modelado.
Otro tipo de modelos son los modelos verbales, en los cuales el comportamiento del
sistema se describe mediante palabras: si se aprieta el freno, entonces la velocidad del
coche se reduce. Los sistemas expertos son ejemplos de modelos verbales formalizados.
Es importante diferenciar entre los modelos mentales y los verbales. Por ejemplo,
nosotros usamos un modelo mental de la dinámica de la bicicleta cuando la
conducimos, sin embargo no es sencillo convertirlo a un modelo verbal.
Además de los modelos mentales y verbales, existe otro tipo de modelos que tratan de
imitar al sistema real. Son los modelos físicos, como las maquetas a escala que
construyen los arquitectos, diseñadores de barcos o aeronaves para comprobar las
propiedades estéticas, aerodinámicas, etc.
Finalmente, existe un cuarto tipo de modelos, los modelos matemáticos. En ellos, las
relaciones entre las cantidades que pueden ser observadas del sistema (distancias,
velocidades, flujos, etc.) están descritas mediante relaciones matemáticas. En este
sentido, la mayoría de las leyes de la naturaleza son modelos matemáticos. Por ejemplo,
para el sistema “masa puntual”, la Ley de Newton del movimiento describe la relación
entre la fuerza y la aceleración. Asimismo, para el sistema “resistencia eléctrica”, la Ley
de Ohm describe la relación entre la caída de tensión y el flujo de corriente.
En algunos casos, las relaciones matemáticas que constituyen los modelos son
relativamente sencillas y se pueden resolver analíticamente, obteniendo soluciones
generales bajo una forma simbólica. Cualquier solución particular se puede obtener
reemplazando los valores simbólicos por sus valores numéricos. Sin embargo, en la
mayoría de los casos, los modelos son más complejos y no se pueden resolver
analíticamente. En ellos es imposible llegar a una solución general y lo que se buscan
son soluciones particulares aplicando métodos numéricos, con ayuda del computador.
Este tipo de experimentos numéricos realizados sobre un modelo matemático quedan
claramente dentro del ámbito de la simulación.
Nótese que la complejidad de un sistema (Guasch y col. 2002) no debería medirse en

función del número de componentes o subsistemas que lo integran, ni tampoco en
función del número de ecuaciones necesarias para describir su comportamiento. En el
ámbito del modelado, la complejidad de un sistema no se entiende como una propiedad
3
inherente al comportamiento del mismo, sino más bien como una falta de metodología y
de herramientas que permitan especificar y formalizar el conocimiento que se tiene del
sistema con el objetivo de desarrollar un modelo que presente un comportamiento
similar al del sistema real. Algunos sistemas, que en el pasado habían sido considerados
complejos, ya no reciben tal consideración en la actualidad.
Así la simulación es considerada como el arte y la ciencia de experimentar con modelos.

Los resultados en simulación dependerán de la bondad del modelo y de la buena
elección del conjunto de experimentos. Mientras que un sistema real es válido para
cualquier experimento, un modelo sólo será válido en determinadas condiciones
experimentales. Para evitar este problema, la descripción del modelo debe ir
acompañada de la documentación de su marco experimental (conjunto de experimentos
para los que el modelo es válido).
El modelado representa el proceso de organizar y estructurar el conocimiento acerca de

un sistema dado. Realizando experimentos recopilamos conocimientos del sistema, que
al principio disponemos de una forma no estructurada. Al comprender cuáles son las
causas y cuáles los efectos, y disponiendo las observaciones tanto en orden espacial
como temporal, organizamos el conocimiento que se adquiere durante el experimento.
Puede decirse que el modelado representa la única actividad central que unifica toda la
conducta científica e ingenieril. Mientras la finalidad del científico es simplemente
observar y comprender el mundo que nos rodea, el ingeniero necesita modificarlo para
lograr determinados beneficios. Básicamente la ciencia es análisis y la ingeniería
diseño. Dentro de este contexto, el modelado se puede utilizar no sólo para el análisis
(el llamado problema directo) sino también para el diseño (llamado problema inverso).
1.2.1 Modelos matemáticos
La finalidad de un estudio de simulación (es decir, las preguntas que debe responder)
condiciona las hipótesis empleadas en la construcción del modelo, y éstas a su vez
determinan qué tipo de modelo resulta más adecuado al estudio. De hecho, un mismo
sistema puede ser modelado de múltiples formas, empleando diferentes tipos de
modelos, dependiendo de la finalidad perseguida en cada caso.
Existen diferentes clasificaciones de los modelos matemáticos, atendiendo a diferentes

criterios. A continuación se describen algunas de las clasificaciones más comúnmente
usadas.
Determinista o Estocástico
Un modelo matemático es determinista cuando su nuevo estado queda completamente

definido a partir del estado previo y de los valores instantáneos de todas sus variables de
entrada (señales de entrada y parámetros). Un ejemplo de modelo determinista es un
servicio al cual los clientes acceden ordenadamente, cada uno a una hora preestablecida
(de acuerdo, por ejemplo, con un libro de citas), y en el cual el tiempo de servicio a cada
cliente está igualmente preestablecido de antemano. No existe incertidumbre en la hora
de inicio o de finalización de cada servicio.
4
Por el contrario, un modelo es estocástico cuando alguna de sus variables de entrada

(señal de entrada o parámetro) es aleatoria. Las variables del modelo calculadas a partir
de variables aleatorias son también aleatorias. Por ello, la evolución de este tipo de
sistemas debe estudiarse en términos probabilísticos. Por ejemplo, considérese el
modelo de un parking, en el cual las entradas y salidas de coches se producen en
instantes de tiempo aleatorios. La aleatoriedad de estas variables se propaga a través de
la lógica del modelo, de modo que las variables dependientes de ellas también son
aleatorias. Este sería el caso del tiempo que transcurre entre que un cliente deja
aparcado su vehículo y lo recoge (tiempo de aparcamiento), del número de vehículos
que hay aparcados en un determinado instante, etc.
Las dificultades asociadas a la simulación de modelos estocásticos pueden invitarnos en

ocasiones a realizar hipótesis adicionales, con el fin de eliminar la incertidumbre en el
valor de las variables de entrada. Un ejemplo típico consiste en sustituir cada variable
de entrada aleatoria por otra determinista, cuyo valor sea la media de la distribución de
probabilidad de aquella. Este modelo determinista, obtenido de eliminar la
incertidumbre en el valor de las variables de entrada, proporcionará resultados no
aleatorios. Pero la simplificación hará que probablemente el modelo ya no sea una
representación del sistema válida para el objetivo del estudio.
Dinámico o Estático
Un modelo estático es una representación de un sistema en un instante de tiempo

particular, o bien un modelo que sirve para representar un sistema en el cual el tiempo
no juega ningún papel. En cambio, un modelo dinámico es una representación de un
sistema que evoluciona con el tiempo. El modelo estático se describe mediante un
conjunto de ecuaciones algebraicas, mientras que en el modelo dinámico intervienen
también otro tipo de ecuaciones.
De tiempo continuo, De tiempo discreto o Híbrido
Un modelo de tiempo continuo está caracterizado por el hecho de que el valor de sus
variables de estado puede cambiar infinitas veces (es decir, de manera continua) en un
intervalo finito de tiempo. Por ejemplo, el nivel de agua en un depósito. Los modelos de
este tipo se describen generalmente por conjuntos de ecuaciones algebraicas y
diferenciales.
En un modelo de tiempo discreto los cambios pueden ocurrir únicamente en instantes

separados en el tiempo. Sus variables de estado pueden cambiar de valor sólo un
número finito de veces por unidad de tiempo. Estos modelos se describen generalmente
por conjuntos de ecuaciones algebraicas y ecuaciones en diferencias, al menos cuando
los instantes de tiempo están espaciados de forma equidistante.
Tal como se ha indicado al comienzo de la sección, la decisión de realizar un modelo

continuo o discreto depende del objetivo específico del estudio y no del sistema en sí.
Un ejemplo de ello lo constituyen los modelos del flujo de tráfico de vehículos. Cuando
las características y el movimiento de los vehículos individuales son relevantes puede
realizarse un modelo discreto. En caso contrario, puede resultar más sencillo realizar un
modelo continuo.
5
Los modelos de tiempo discreto se utilizan frecuentemente en ingeniería para diseñar

controladores digitales o para simular sistemas controlados por computador. Debido a
que, como el microprocesador o el computador encargado del control necesita de un
cierto tiempo para medir las señales y para tomar las decisiones, la señal de control no
se actualiza de forma continua sino a intervalos regulares de tiempo. Si esta técnica se
utiliza para controlar un sistema que es por sí mismo continuo (como es normalmente el
caso) se habla de sistemas de control muestreados.
Los modelos de tiempo discreto pueden ser también versiones discretizadas de sistemas
continuos. Este es un hecho bastante común. Por ejemplo, si se aproxima (empleando el
método de Euler) la siguiente derivada, que describe un modelo de tiempo continuo
dx
= f(x, u, t)
dt
en el instante tk, con un intervalo de discretización ∆t, se obtiene el siguiente modelo de

tiempo discreto
x k +1 − x k
≅ f(x k , u k , t k ) → x k +1 ≅ x k + ∆t f(x k , u k , t k )
∆t
También se pueden definir modelos con algunas de sus variables de estado de tiempo
continuo y las restantes de tiempo discreto. Este tipo de modelos, con parte de tiempo
continuo y parte de tiempo discreto, se conocen como modelos híbridos.
De variables continuas, De variables discretas o Mixtos
Si todas las variables de estado del modelo pueden tomar cualquier valor intermedio en
sus respectivos rangos de variación, se dice que el modelo es de variables continuas. En
cambio si las variables de estado están cuantificadas o sólo pueden tomar ciertos
valores, pertenecientes a un conjunto finito de valores, se dice que el modelo es de
estados o eventos discretos. Un caso particular de modelo de estados discretos son las
máquinas secuenciales, también denominadas autómatas finitos. Pero en el modelado de
ciertos sistemas puede ser necesario utilizar variables de ambos tipos, continuas y
discretas, entonces se dice que el modelo es mixto.
En este punto es conveniente realizar una consideración acerca de los modelos de

tiempo continuo y de los modelos de variables continuas. Pues realmente ambos son
una idealización, ya que no existe ningún procedimiento de medida o de representación
de una variable o del tiempo que no tenga un límite de precisión, luego en la práctica
todas las variables (incluido el tiempo) son discretas. Sin embargo, para los
razonamientos teóricos, conviene considerar ciertas variables como continuas.
1.3 MODELADO DE SISTEMAS DE EVENTOS DISCRETOS
Durante siglos el desarrollo de sistemas dinámicos estuvo basado en el estudio de

modelos de ecuaciones diferenciales ordinarias y parciales. Estas permitieron modelar
exitosamente los sistemas dinámicos encontrados en la naturaleza (de hecho, los éxitos
de la física y esta línea de investigación fueron tan grandes que penetraron casi todo el
6
pensamiento científico). Pero por otro lado, la tecnología moderna ha permitido que el
hombre intente analizar, intente modelar o haya creado otros sistemas dinámicos que no
pueden ser descritos fácilmente por medio de ecuaciones diferenciales ordinarias o
parciales. Como ejemplos de tales sistemas podemos mencionar: una comisaría de
policía, un hospital, un taller de mantenimiento, un aeropuerto, un banco, un servidor
informático, una línea de producción o de ensamblado, una red de computadores, una
red de comunicaciones, un sistema de control tráfico aéreo o terrestre, etc.
En estos sistemas, que reciben el nombre de Sistemas Dinámicos de Eventos Discretos

(DEDS - Discrete Events Dynamic Systems) en oposición a los Sistemas Dinámicos de
Variables Continuas (CVDS - Continuous Variable Dynamic Systems), es habitual que
existan fuertes y complejas interacciones entre sus variables y que éstas respondan a
eventos discretos, algunos de ellos sin una causa o una temporalidad conocida, lo que
dificulta el conocer cómo evolucionará el sistema en su conjunto. Por ejemplo la llegada
de un paciente a un hospital dispara una serie de eventos (ingreso, asignación de planta,
habitación, cama, médico, etc.), que involucran a parte del personal del hospital
(celadores, enfermeras, médicos, etc.), que desencadenan otra serie de acciones (pruebas
médicas, operación, recuperación, etc.) y que dejan de tener importancia cuando el
paciente abandona el centro hospitalario. Además, cada evento modificará alguna de las
variables necesarias para describir el funcionamiento del hospital, como son el número
total de pacientes, las camas libres, los pacientes en espera, etc.
Aunque el “estado” del sistema sólo cambia en instantes de tiempo, generalmente

desconocidos, lo que sí se sabe es que el “estado” del sistema permanece inalterable
entre eventos, de ahí que en los modelos de sistemas de eventos discretos no sea
necesario tener en cuenta este tiempo de inactividad en el modelo. De acuerdo con esto,
casi todos los lenguajes de programación orientados a este tipo de sistemas aplican el
enfoque de “lista de eventos futuros” o “calendario de eventos”, donde los eventos que
se esperan aparecen ordenados de forma cronológica, y a ellos se irán incorporando
aquellos que se presenten de forma imprevista. Este enfoque se conoce como
“Modelado orientado a los eventos”.
Una forma alternativa, más natural y sencilla, de describir el funcionamiento de un

sistema de eventos discretos consiste en adoptar el punto de vista de las entidades y
describir su circulación a través del sistema. Este enfoque se centra en los procesos que
llevan a cabo las entidades o los que se realizan sobre ellas, por ello se le conoce como
“Modelado orientado a los procesos”. Su práctica es posible gracias al empleo de
lenguajes de simulación que traducen, de manera automática, la descripción orientada a
los procesos a una descripción orientada a los eventos. En definitiva, el código
ejecutable de cualquier simulación de sistemas de eventos discretos está orientado a los
eventos.
1.3.1 Componentes del modelo
En estos modelos suelen intervenir ocho tipos de componentes (las entidades, sus
atributos, las variables, los recursos, las colas, los contadores estadísticos, los eventos,
las actividades), que se describen brevemente a continuación. Para mayor claridad
iremos haciendo referencia al siguiente ejemplo (extraído de Urquía 2003): “Oficina de
atención al público, en la que trabaja un único empleado”.
7
Entidades
Las entidades son objetos dinámicos en la simulación, que son creados y se mueven por
el sistema, cambiando el valor de sus atributos, afectados por otras entidades y por el
estado del sistema. Las entidades pueden estar durante un intervalo de tiempo en el
sistema (entidades temporales) o bien permanecer indefinidamente circulando en él
(entidades permanentes). En el ejemplo anterior de la oficina, existe un único tipo de
entidad: “cliente”. Cada cliente que se encuentra en la oficina es una realización (o
instanciación, como se prefiera) de este tipo de entidad, que es creada a su llegada,
circula a través del sistema y es destruida cuando el cliente abandona la oficina. Si en el
modelo se hubieran definido diferentes tipos de clientes, que requirieran procesos de
atención diferentes o a los que se asignara diferente prioridad, cada tipo de cliente se
representaría como un tipo diferente de entidad o con la misma entidad pero distinto
atributo.
Atributos
Los atributos son características o propiedades de las entidades, permiten individualizar

cada instanciación de una determinada clase de entidad sin más que asignar valores a
sus atributos. Por ejemplo, algunos atributos que podrían definirse para el tipo de
entidad “cliente” son: la prioridad con que debe ser atendido o determinados datos
personales, como son el nombre y los apellidos, la edad, la nacionalidad, etc. En
general, el valor de los atributos diferirá de un cliente a otro y es lo que permite
diferenciarlos.
Variables
Las variables representan características del sistema que son independientes de los tipos
de entidades o del número de realizaciones existentes en determinado instante. Por
tanto, las variables no están asociadas a entidades en concreto, sino que pertenecen al
conjunto del sistema. Son accesibles desde todas las entidades y pueden ser modificadas
por todas las entidades. Puede considerarse que cada variable es como una pizarra
colgada en la pared, en la que se escribe el valor de la variable. Todas las entidades
pueden leer la pizarra, y también pueden borrar el valor escrito y escribir uno nuevo.
Algunas de las variables son intrínsecas a los elementos del modelo y, por ello surgen
en casi todos los modelos de simulación. Algunas de estas son: el número de entidades
(en nuestro caso, clientes) que hay en cada instante en cada cola, el número de recursos
(en nuestro caso, empleados) ocupados, el estado (ocupado o libre) de cada recurso, el
valor del reloj de la simulación (variable que va registrando el tiempo simulado), etc.
Por el contrario, otras variables surgen debido a necesidades concretas del modelo en
cuestión y se convierten en parámetros. Por ejemplo, supóngase que cada cliente tiene
que ser atendido consecutivamente por dos empleados diferentes, situados a cierta
distancia, y que el tiempo que emplea la entidad en ir de un empleado a otro se
considera fijo. Entonces, el valor de este tiempo de “tránsito” sería un parámetro del
modelo. Los parámetros permiten adaptar el modelo a sus diferentes aplicaciones. Por
ejemplo, mediante la modificación del tiempo de tránsito entre los dos puntos de
atención, puede adaptarse un mismo modelo para representar diferentes situaciones.
8
Asimismo, las variables pueden representar magnitudes cuyo valor cambie durante el
curso de la simulación. Por ejemplo: el número total de clientes que esperan, que están
siendo atendidos y que se encuentran en tránsito entre los dos puntos de atención.
Recursos
Los recursos pueden ser el personal (en nuestro caso, “el empleado”), las máquinas (por
ejemplo, si las entidades son piezas que deben ser procesadas), el espacio (por ejemplo,
en un almacén), etc. Una entidad captura un recurso cuando éste está disponible, a fin de
obtener un servicio de él, y lo libera una vez ha terminado.
El recurso puede ser individual o estar compuesto por un grupo de elementos

individuales, cada uno de los cuales se llama una unidad del recurso. Por ejemplo, el
caso de varios mostradores paralelos e idénticos de atención al público, puede
representarse como un recurso con tantas unidades como puntos de atención. El número
de unidades disponibles de un recurso puede variar durante el curso de la simulación,
representando mostradores que se cierran o abren.
Colas
Cuando una entidad no puede circular, debido tal vez a que necesita usar una unidad de
un recurso que en ese momento no se encuentra disponible, entonces la entidad necesita
un sitio donde esperar. Este es el propósito de la cola (colección de entidades asociadas
temporalmente o permanentemente y ordenadas de una manera lógica; por prioridad,
por tiempos de llegada, etc.), que normalmente está asociada a su correspondiente
recurso.
Acumuladores estadísticos
A fin de calcular el valor de las variables de salida, es preciso calcular durante el curso
de la simulación el valor de determinadas variables intermedias. Estas se llaman
acumuladores estadísticos. Algunos ejemplos son: el número total de clientes atendidos
hasta ese momento, la suma de los tiempos de espera en cola de los clientes hasta ese
momento, el número total de clientes que han comenzado a ser atendidos hasta ese
momento, el mayor tiempo de espera en cola hasta ese momento, etc. Los contadores
son inicializados a cero al comenzar la simulación. Cuando “algo sucede” en la
simulación (es decir, se ejecuta un evento), los contadores estadísticos afectados deben
ser convenientemente actualizados.
Eventos
Un evento es un suceso que ocurre en un determinado instante de tiempo (simulado) y

que puede cambiar el valor de los atributos, las variables y los acumuladores
estadísticos. Hay dos tipos de eventos: los internos, provocados por el propio sistema
(comienzo o fin de una actividad, etc.), y los externos que son provocados por causas
ajenas (por ejemplo la llegada de un cliente).
En los modelos de eventos discretos, los atributos, las variables y los acumuladores
estadísticos sólo pueden cambiar a consecuencia de la ejecución de los eventos. Los
9
cambios en sus valores se producen en los instantes en que son activados los eventos,
manteniéndose constantes durante el intervalo de tiempo entre eventos sucesivos.
En la “Oficina de atención al cliente”, pueden ocurrir los siguientes eventos:

• Llegada a la oficina de un nuevo cliente.
• Fin de servicio a un cliente.
Cada evento tiene asociado dos tipos de información:

• Su condición de activación, es decir, la condición que hace que el evento pase de
estar desactivado a estar activado.
• Las acciones que deben realizarse en el instante en que el evento es activado.
En función del tipo de su condición de activación, los eventos pueden clasificarse en

eventos en el tiempo y eventos en el estado:
• Los eventos en el tiempo son aquellos cuya condición de activación es que el
tiempo de la simulación alcance un determinado valor. El valor del instante de
tiempo simulado se almacena en una variable del modelo llamada reloj de la
simulación.
• La condición de activación de los eventos en el estado no es función exclusiva del
tiempo, sino que también es función de las variables del sistema, en definitiva del
propio estado del sistema.
Actividades
Las actividades son las tareas o acciones que tienen lugar en el sistema. Toda actividad
está siempre delimitada por dos eventos, el de comienzo y el de fin de la actividad, por
tanto tiene una duración temporal y, normalmente, precisa del uso de recursos.
Ejemplos de actividades son: la reparación de una máquina, el procesado de una pieza,
el transporte de un cliente, etc.
En la siguiente tabla se muestran algunos casos particulares de sistemas (Vázquez,

2003) y algunos de los componentes (por categoría) que intervendrían en su modelado:
Sistema Entidad Atributos Actividades Eventos Variables

Estado de una Nº de ventanillas ocupadas,
Banca Clientes Hacer un ingreso Llegada, salida
cuenta nº de clientes esperando.
Llegada a una Nº de viajeros en cada
Tren Pasajeros Origen, destino Viajar estación, llegada estación, nº de viajeros en el
al destino tren
Velocidad,
Soldadura, Arranque, Estado de las máquinas
Producción Máquinas capacidad,
torneado parada, rotura (ocupada, desocupada, rota)
tiempo de avería
Comunica- Llegada al Nº de mensajes en cola de
Mensajes Longitud, destino Transmisión
ciones destino transmisión
Sacar del Nivel de inventario,
Inventarios Almacén Capacidad Pedido
almacén demandas desatendidas
10
1.3.2 Naturaleza del modelo
Comparado con sistemas de variables continuas, fundamentales en la física, el

modelado y simulación de DEDS es un fenómeno relativamente reciente. Donde
además, la simulación aparece como una (casi la única) alternativa para estudiar el
comportamiento de estos sistemas tan complejos A pesar que pertenece al dominio de la
Investigación Operativa (desde el punto de vista que la IO puede pensarse como la
técnica de operaciones y eventos de sistemas hechos por el hombre), el desarrollo de
DEDS también ha recibido un gran ímpetu de la teoría de control y sistemas. En
particular, los conceptos de dinámica (constantes de tiempo, tiempo de respuesta,
frecuencia, controlabilidad) son importantes en el desarrollo de modelos y herramientas
de DEDS.
Como las variables de estado del sistema son discretas a tiempo continuo, el modelo
matemático tiene que ser un modelo dinámico de eventos discretos. Pero además en la
mayoría de los DEDS intervienen variables de entrada cuyo comportamiento es
aleatorio, luego el modelo tiene que ser de naturaleza estocástica.
En el ejemplo de la “Oficina de atención al cliente”, se deberían considerar dos

variables de entrada aleatorias:
• El tiempo que transcurre entre la llegada de un cliente y la llegada del siguiente.
• El tiempo que tarda el empleado en atender un cliente.
Las características de las dos variables de entrada quedarán definidas en las hipótesis de
modelado, por ejemplo podemos suponer que ambos “tiempos” son independientes del
instante de tiempo simulado y responden a una distribución de probabilidad concreta.
Sin embargo también sería fácil, y más realista, suponer que la afluencia de cliente es
mayor en ciertas horas del día “horas punta” que a otras “horas valle”. Del mismo modo
sería factible suponer que, según avanza la jornada laboral, aumenta el cansancio del
empleado, con lo cual aumenta el tiempo servicio. Pero también hubiera sido una
hipótesis aceptable suponer que según avanza la jornada laboral, el empleado es más
impaciente y despacha a los clientes en menor tiempo. Lo normal es realizar la hipótesis
de que ninguno de estos aspectos, u otros similares, son relevantes y que por tanto
ambos “tiempos” responden a una distribución de probabilidad conocida.
Otra posible dependencia que se puede presentar en el sistema real es la dependencia de

las variables de entrada con otras variables del sistema, por ejemplo es lógico imaginar
situaciones en las que una gran afluencia de clientes puede provocar una gran cola, que
provocará cierta presión en el empleado, y que éste tratará de aliviar abreviando en lo
posible los tiempos de atención. Decidir qué tipo de dependencias existen entre las
variables aleatorias y describir estas dependencias adecuadamente es sin duda una de las
tareas de modelado más delicadas y difíciles.
En ciertas condiciones es preciso distinguir entre dos tipos de DEDS: los de topología
fija y los de topología dinámica. Las interacciones entre los componentes de una
topología fija se pueden describir por un grafo en el cual los nodos representan los
componentes y los arcos representan los caminos posibles de interacción. Tales sistemas
se suelen representar como redes de colas en las que hay un conjunto fijo de estaciones
y clientes que se mueven de estación a estación. Las rutas posibles de clientes son fijas
(por ejemplo, sistemas de manufactura y redes de comunicación). En sistemas de
11
topología dinámica las interacciones son arbitrarias y dinámicas (Ej.: sistemas de

telefonía móvil). Los componentes de estos sistemas pueden moverse en cualquier
dirección e interactuar con los otros componentes. Los sistemas de topología dinámica
no suelen ser estrictamente DEDS ya que los componentes se pueden mover
continuamente, sin embargo, para el propósito de la simulación, el modelo de
movimiento físico en el sistema se discretiza en el tiempo.
1.3.3 Paradigmas de modelado
Llamaremos paradigma o formalismo a un conjunto de conceptos, leyes y medios que

sirven para definir un conjunto de modelos. Hay varios paradigmas para especificar
formalmente sistemas dinámicos de eventos discretos y todos ellos tienen existencia
conceptual independiente de los lenguajes de simulación que pueden usarse para llevar a
cabo las simulaciones. No se puede afirmar (Wainer, 1996) que ninguno de los
formalismos existentes sea mejor que otro para representar la gran variedad de
comportamientos de los sistemas reales, ya que dependiendo de diversos factores,
algunos son más naturales y producen simulaciones mas eficientes, otros son más
genéricos, pero no hay consenso para decidir qué formalismo tiene el mayor potencial.
Todos estos formalismos respetan las siguientes propiedades (Guasch y col., 2002):
• El formalismo debe ser independiente de los constructores y herramientas que
ofrecen los entornos de simulación.
• El modelo formalizado debe poder ser analizado para determinar relaciones entre
componentes y evaluar alternativas que permitan la simplificación del modelo.
• El formalismo debe permitir una fácil transformación a las representaciones
soportadas por los entornos de simulación.
• Algunos aspectos del modelo pueden dejarse sin especificar, sin que ello dificulte
la transformación a otras representaciones.
• El modelo debe poder ser definido en términos que no restrinjan su codificación a
un mecanismo particular de actualización del reloj del simulador.
Los formalismos que van a recibir una especial atención en esta asignatura son:
• Las Redes de Petri (Tema 2).
• El GRAFCET (Tema 3).
• El formalismo DEVS (Tema 4).
Las Redes de Petri (a las que usualmente nos referiremos a lo largo del texto como
RdP) permiten describir gráficamente los sistemas de eventos discretos (Silva, 1985)
(Guasch y col., 2002). Aunque las RdP no son el único formalismo que maneja los
eventos y actividades (muy importantes en los DEDS), suele ser de los más utilizados
porque permite representarlos de una forma más natural que otros formalismos y porque
es el único que representa de manera formal los conceptos de paralelismo/concurrencia
y sincronización.
El GRAFCET, que responde a las siglas de GRÁFico de Control de Etapas y

Transiciones, es un método gráfico de modelado y diseño de automatismos basado en
las Redes de Petri (Balcells y Romeral, 1997). Tiene su origen en la necesidad de
disponer de un método de descripción de procesos, independiente de la tecnología, que
pudiese ser interpretado por cualquier usuario no experto en automatización.
12
El formalismo DEVS (Discrete EVents dynamic Systems) fue propuesto por Zeigler en
1976 como una representación formal para los sistemas de eventos discretos (Zeigler y
col., 2000). Permite una descripción modular de los fenómenos a modelar
(aproximación modular) y ataca la complejidad usando una aproximación jerárquica.
Otros métodos formales empleados, pero que no veremos en esta asignatura son por
ejemplo:
• Los autómatas celulares (Wainer, 1996), propuestos originalmente por Neumann

y Ulam en 1970 como idealización de un proceso de reproducción biológica, se
están utilizando para representar el comportamiento de sistemas dinámicos de
variables y tiempo discretos (el tiempo, el espacio y los estados del sistema son
discretos). Un autómata celular es un conjunto infinito n-dimensional de celdas
ubicadas geométricamente, cuyos estados se actualizan individualmente de
acuerdo con una regla local. O sea el estado de una celda en un instante de tiempo
dado sólo depende de su propio estado en el instante previo y los estados de sus
celdas.
• Los diagramas de actividades (Paul, 1993). Proporcionan una representación

gráfica similar a las RdP. En un diagrama de este tipo, el modelo se ve como un
conjunto de entidades que interaccionan entre ellas.
• Grafos de eventos (Schruben, 1983). Es una metodología apropiada para los

simuladores orientados a eventos. Son grafos dirigidos que muestran las
relaciones existentes entre eventos. Los eventos han de ser definidos, numerados y
representados como nodos en el dígrafo y los grafos son conectados por arcos que
indican como un evento lleva a la aparición de otros.
• Las redes de colas, que permiten describir las tareas realizadas por el sistema
mediante un conjunto de estaciones de trabajo. Cada estación de trabajo tiene su
propio conjunto de servidores, que atienden las peticiones que llegan a la estación,
y una cola de espera. El flujo de actividades se formaliza mediante la notación de
colas, interconectando las distintas estaciones y otros elementos pasivos
característicos de los sistemas orientados a eventos discretos (Guasch y col.
2002).
1.4 METODOLOGÍA DE MODELADO
Modelado y simulación están muy unidos, sobre todo en sistemas de eventos discretos
debido a la complejidad comentada en el apartado 1.2. En esta asignatura abordaremos
ambos aspectos: desde la formulación del modelo (modelo conceptual) hasta su
programación en un entorno de simulación y la posterior validación.
1.4.1 Formulación del modelo
La esencia del arte del modelado son la abstracción y la simplificación. Se trata de

identificar el pequeño conjunto de características o propiedades del sistema suficientes
13
para servir a los objetivos específicos del estudio. A grandes rasgos, la metodología de
modelado podría ser la siguiente:
• Escoger las variables de salida, lo cual resulta relativamente sencillo una vez
definido el objetivo de estudio.
• Identificar qué componentes del sistema afectan a las variables de salida y decidir,
para cada uno de ellos, si deber ser incluido en el modelo o si debe ser
considerado parte del entorno del modelo. En este último caso, el componente es
representado mediante entradas al modelo.
• Determinar y representar las relaciones funcionales entre los componentes, es
decir, la lógica del modelo.
La tarea de modelado implica la búsqueda de un punto de equilibrio: el modelo debe

representar los aspectos del sistema real con el grado de detalle requerido, pero de modo
que sea lo más sencillo posible. Ya que aumentando la complejidad del modelo no
necesariamente se consigue aumentar su realismo.
Una buena práctica consiste en realizar el modelo de manera iterativa: comenzar con un
modelo muy simple, cuya complejidad puede posteriormente ir aumentándose
fácilmente. Para ello, el modelo debe realizarse de manera modular y jerárquica,
dividiendo el sistema en submodelos y modelando todos ellos con un nivel semejante de
complejidad. Este modelo inicial puede construirse muy rápido y puede servir de punto
de discusión sobre posteriores refinamientos en el modelado (se entiende por
“refinamiento” del modelo el aumento en su nivel de detalle). Añadiendo
progresivamente los refinamientos al modelo, y comparando los resultados obtenidos
con los del modelo más sencillo, puede estimarse el impacto de cada conjunto de
refinamientos sobre la respuesta del modelo. En determinado punto de este proceso de
aumento gradual de la complejidad del modelo, los refinamientos añadidos tienen un
efecto pequeño, es decir, influyen despreciablemente en las conclusiones del estudio,
con lo cual se concluirá que no es preciso incorporarlos.
1.4.2 Lenguajes de modelado y simulación
Durante la década de los 60 las simulaciones se realizaban usando lenguajes de

programación procedurales, de propósito general, como es el caso de FORTRAN.
Como puede suponerse, la escritura de estos programas resultaba una tarea larga,
costosa, tediosa y propensa a errores, ya que el programador debía tener en cuenta hasta
el más mínimo detalle de la simulación del modelo. Esta metodología de modelado se
denomina modelado orientado a los eventos.
Con el fin de poder reutilizar parte del código, se desarrollaron bibliotecas de funciones,
que realizaban algunas de las tareas rutinariamente requeridas en una simulación y que
podían ser invocadas desde el programa de simulación. Sin embargo, los modelos
debían ser programados prácticamente desde el principio cada vez que se introducían en
ellos modificaciones importantes. En resumen, la simulación era una técnica muy
costosa y especializada, sólo al alcance de empresas capaces de realizar grandes
inversiones económicas.
Ante la gran dificultad (algunos autores hablan de imposibilidad) de realizar estudios

complejos de simulación basados en esta metodología, se desarrolló una nueva
14
metodología de modelado: el modelado orientado a los procesos. Esta metodología

permite describir el modelo de manera más “natural”, más próxima al razonamiento
humano. En la década de los años 70 aparecieron los lenguajes de simulación de
propósito general para modelos de tiempo discreto, que posibilitaron la práctica de esta
nueva metodología. Estos entornos de simulación traducían automáticamente la
descripción orientada al proceso del modelo (realizada por el usuario), a la descripción
orientada a los eventos, expresada en un determinado lenguaje de programación, cuya
ejecución constituye la realización del experimento de simulación. Algunos de estos
lenguajes de simulación son todavía usados en la actualidad: GPSS, SIMSCRIPT,
SLAM, SIMAN, etc.
Durante la década de los 80 los lenguajes de simulación evolucionaron. Aparecieron

nuevas versiones que recogían los dos conceptos fundamentales siguientes:
• La separación en actividades distintas de las etapas (funcionalmente distintas) de
modelado, especificación del experimento y análisis de las salidas.
• El aprovechamiento de todas las capacidades disponibles en el momento para el
manejo de bases de datos, capacidades gráficas y de verificación del programa.
Los avances experimentados en todos los ámbitos de la computación durante la primera

mitad de la década de los 90, posibilitaron el desarrollo de los entornos de modelado:
una capa software construida sobre el lenguaje de simulación con el fin de facilitarle al
usuario la descripción del modelo. Los entornos de modelado proporcionan interfaces
de usuario muy intuitivas con menús, diálogos, etc. El usuario construye el modelo
seleccionando los componentes (pinchando y arrastrando el icono) y conectándolos
gráficamente. La animación y otras capacidades gráficas permiten visualizar la
evolución del sistema durante la simulación. El interfaz gráfico de usuario del entorno
de modelado también permite acceder a los niveles inferiores en la descripción del
modelo: a la descripción de partes del modelo usando el lenguaje de simulación e
incluso el lenguaje de programación.
Un ejemplo es el entorno de modelado Arena, que soporta el uso combinado de

diferentes niveles de descripción: elementos de alto nivel parametrizables por el usuario
y elementos de bajo nivel que el usuario puede definir usando el lenguaje de simulación
SIMAN o los lenguajes de programación Visual Basic o C/C++. El alumno de esta
asignatura tendrá ocasión de practicar con este entorno de modelado, pues se ha incluido
como anexo a los apuntes un tema especialmente dedicado a la programación de
modelos en Arena.
1.4.3 Verificación y validación
Los procesos de verificación y la validación son conceptualmente distintos:

• La finalidad de la verificación es comprobar que no se han cometido errores al
traducir el modelo, bien usando un entorno de modelado o mediante un lenguaje
de simulación o de programación.
• La validación consiste en comprobar que el modelo supone una aproximación
adecuada de la realidad para los objetivos particulares del estudio de simulación.
15
Sin embargo, cuando los resultados de la simulación nos parecen “extraños” o erróneos,
no siempre está claro si es debido a que nos hemos equivocado al traducir el modelo o a
que las hipótesis de modelado no son las adecuadas.
Verificación
Entre otros, pueden usarse los siguientes procedimientos para verificar el modelo:
• Verificación manual de la lógica. Consiste en ejecutar la simulación durante un
periodo de tiempo corto y comprobar manualmente los resultados obtenidos.
• Comprobación submodelo a submodelo. Se trata de verificar individualmente que
cada submodelo produce los resultados esperados para todos los posibles tipos de
entradas.
• Comprobación con soluciones conocidas. Consiste en ajustar el modelo de modo
que represente un sistema de solución conocida y comparar ésta con los resultados
de la simulación.
• Test de sensibilidad. Puede modificarse el valor de un parámetro, dejando los
demás fijos, con el fin de medir la sensibilidad del modelo respecto a ese
parámetro. La comparación de la sensibilidad observada en las simulaciones, con
la que sería de esperar en el sistema real, puede proporcionar pistas útiles.
Validación
Puede considerarse que la validación del modelo tiene tres vertientes diferentes.
Consiste en determinar:
• Si el modelo representa adecuadamente al sistema real (comprobación de la
estructura del modelo).
• Si los datos generados de la simulación del modelo reproducen de forma adecuada
el comportamiento del sistema real (comprobación del comportamiento del
modelo).
• Si el usuario del modelo tiene confianza en los resultados obtenidos de las
simulaciones (comprobación de la confianza del usuario en el modelo). Involucrar
al usuario final en todas las fases del diseño y la construcción del modelo
generalmente hace que este aspecto de la validación del modelo sea mucho más
sencillo.
Puesto que el modelo se construye para un propósito específico, la validez sólo puede
ser evaluada con relación a este propósito. La validación del modelo es un proceso
continuo durante su diseño, desarrollo y uso. Existen diferentes grados de validación: la
confianza en el modelo va acumulándose según el modelo va superando pruebas y se
van encontrando más puntos de coincidencia entre el comportamiento del modelo y el
del sistema real. La verificación y la validación de un modelo son procesos que
realmente nunca finalizan.
En todo este proceso de validación, no debe perderse de vista que el objetivo del
ingeniero dedicado al modelado es la realización de modelos útiles, en un tiempo
razonable y con un coste razonable. Por este motivo, más que preguntarse en qué
medida se ajusta el comportamiento simulado al comportamiento real del sistema, es
más adecuado preguntarse en qué medida las diferencias entre el modelo y el sistema
son lo suficientemente significativas como para afectar a las conclusiones derivadas del
uso del modelo.
16
1.5 EJEMPLOS DE SISTEMAS DE EVENTOS DISCRETOS
Las principales características de los sistemas de eventos discretos pueden resumirse en

los siguientes puntos:
• Son asíncronos. Porque algunos eventos pueden ocurrir en cualquier momento,
sin ningún tipo de periodicidad ni de continuidad.
• Están dirigidos por eventos. Cuando ocurre un suceso cambia el estado del
sistema.
• Son secuenciales. Porque puede haber eventos que guarden una cierta secuencia,
tal que para que ocurra uno, antes debe de haber ocurrido el anterior.
• Son no deterministas. Porque no se sabe cuándo ocurren los eventos o porque no
se sabe cuándo ocurren los cambios en los parámetros del sistema.
• Presentan concurrencia. Porque varios eventos pueden ocurrir al mismo tiempo.
• Pueden representar conflictos o exclusión mutua. El conflicto se presenta
cuando un recurso es compartido por varias entidades y se resuelve haciendo que
no se puedan presentar al mismo tiempo dos solicitudes del recurso.
• Pueden presentar parada por interbloqueo o deadlock. Por ejemplo, el robot
ha cogido una pieza de la máquina 1 y la máquina 2 requiere la pieza y no la
recibe.
A continuación se presentan cuatro ejemplos de sistemas con el fin de fijar los

conceptos relativos a sus componentes y a sus características.
1.5.1 “Taquilla de un cine”
Es un ejemplo muy parecido al de la “Oficina de atención al público”. Por el sistema,

que tiene un único recurso “la taquilla” y una sola actividad “la venta de entradas”,
fluye una única entidad “la persona que desea comprar entradas”. El sistema se puede
representar por:
Dos variables de estado:

taquilla : estado de la taquilla (0 libre, 1 ocupada)
n : número de personas en la cola (valor entero)
Un parámetro: tiempo de atención (que puede ser constante o responder a algún tipo
de distribución probabilística)
Y los dos eventos siguientes:

e1 : una persona llega al cine con la intención de comprar entradas (evento
externo)
e2 : una persona abandona la taquilla porque ya ha comprado sus entradas
(evento interno)
Las acciones asociadas a los eventos son:
La llegada de una persona al cine provoca una acción diferente según el estado de la
taquilla. Si (taquilla=0) la taquilla está libre, la persona pasa a ser atendida, con lo
17
cual la taquilla pasa a estar ocupada (taquilla=1). Pero si (taquilla=1) la taquilla está
ocupada, la persona pasa a engrosar la cola (n=n+1).
La salida de una persona de la taquilla provoca una acción diferente según el estado
de la cola. Si (n=0) no nay nadie en la cola, la taquilla pasa a estar libre (taquilla=0).
Pero si (n>0) hay alguien en la cola, la primera persona de la cola pasa a la taquilla,
disminuyendo la cola en una unidad (n=n-1).
Las condiciones de activación de los eventos son:
El evento externo se activa de forma aleatoria, pues la llegada de una persona al cine
es totalmente aleatoria. Mientras que el evento interno (la salida de una persona de la
taquilla) sólo se produce cuando la taquilla ha estado ocupada (taquilla=1) un
intervalo de tiempo igual al tiempo de atención.
Una posible medida del comportamiento del sistema podría venir dada por el “tiempo
medio que necesita una persona para conseguir sus entradas”. Para determinarlo (pero
no es la única forma de hacerlo) habría que incorporar a la única entidad del sistema, la
persona, dos atributos: el instante de tiempo en el que llega al cine y el instante de
tiempo en el que abandona la taquilla. Al primer atributo se le asignaría el valor
instantáneo del reloj, cuando se disparara el evento externo (llegada de la persona al
cine), y al segundo atributo se le asignaría el valor instantáneo del reloj cuando se
disparara el evento interno (la persona abandona la taquilla). Los dos atributos habría
que combinarlos con dos acumuladores estadísticos; uno que vaya contando el número
de personas que han pasado por el cine y otro que vaya acumulando el tiempo que ha
tardado cada persona en conseguir sus entradas (es decir, la diferencia entre el segundo
y el primer atributo). El cociente entre el segundo acumulador y el primer acumulador
nos daría la medida que andábamos buscando.
Este sistema, que es muy simple, se podría complicar algo si se incorporan otra serie de
consideraciones, como por ejemplo que:
C1. El cine expende localidades para varias salas, con horarios uniformemente
distribuidos en el tiempo.
C2. Algunas personas desisten de conseguir una localidad, bien en el momento que
llegan por el tamaño que tiene la cola o después de haber permanecido un
tiempo en la cola, pues piensan que ya no van a conseguir la localidad deseada.
C3. Hay dos taquillas, y las entradas se pueden comprar indistintamente en
cualquiera de ellas.
Mientras que una taquilla aislada, atendiendo a una sola proyección, se vería obligada a
atender a casi todas las personas en los intervalos de tiempo previos a la función. La
existencia de varias salas (consideración C1), haría que la taquilla tuviera una actividad
bastante continua si los horarios de las funciones están bien distribuidos en el tiempo.
Si una persona desiste de comprar la entrada en el momento de llegar, tendrá poca

influencia en el comportamiento del sistema, es como si esa persona no hubiera llegado
nunca. Sin embargo si la persona ya estaba en la cola, entonces el evento “la persona
desiste de comprar la entrada” (consideración C2) sí tiene gran influencia en el
calendario de eventos y en el comportamiento del sistema.
18
La existencia de dos taquillas (consideración C3) siempre activas no complicaría

demasiado el análisis del sistema, pues las personas terminarían distribuyéndose
equitativamente entre ambas taquillas o en función de la eficacia que tenga cada
taquilla. Otra cosa distinta es si se permite que alguna taquilla deje de prestar servicio y
bajo qué condiciones. Estaríamos ante un sistema donde los recursos (las dos taquillas)
son dinámicos.
1.5.2 “Sistema simple de producción”
El sistema consta de una máquina a la que van llegando piezas para ser procesadas. Las
piezas aguardan en una cola si la máquina no está libre y salen del sistema una vez que
han sido procesadas. Es un ejemplo muy parecido al anterior, las entidades son las
“piezas”, el recurso es “la máquina” y la actividad “el procesado de piezas”, pero por
tratarse de un sistema productivo se presta a incorporar más medidas de las prestaciones
del sistema. Para representarlo se necesitan:
Dos variables de estado:

maquina : estado de la máquina (0 libre, 1 ocupada)
n : número de piezas en la cola (valor entero)
Un parámetro: tiempo de procesado (que puede ser constante o responder a algún

tipo de distribución probabilística). También puede ocurrir que sea dependiente del
tipo de pieza, si es así dejaría de ser un parámetro del sistema para convertirse en un
atributo de la entidad “pieza”.

e1 : la llegada de una pieza al sistema de producción (evento externo)
e2 : la salida de una pieza de la máquina (evento interno)
Los eventos tienen condiciones de activación similares al ejemplo anterior e involucran

las siguientes acciones:
Acción asociada al evento externo: Si (maquina=0) la máquina está libre, se

comienza el procesado, con lo cual la máquina pasa a estar ocupada (maquina=1).
Pero si (maquina=1) la máquina está ocupada, la pieza debe esperar en la cola
(n=n+1).
Acción asociada al evento interno: Si (n=0) no nay ninguna pieza en la cola, la

máquina pasa a estar libre (maquina=0). Pero si (n>0) hay alguna pieza en la cola, la
primera pieza de la cola pasa a la máquina, disminuyendo la cola en una unidad
(n=n-1).
El comportamiento del sistema podría venir dado por las siguientes medidas:
• El número total de piezas procesadas.
• El número de piezas en la cola.
• El tiempo medio de espera de las piezas en la cola.
• Tiempo medio de procesado.
• Porcentaje de ocupación de la máquina.
19
Pero también es importante definir en qué condiciones se quiere evaluar al sistema, que
quedan especificadas por los siguientes datos de la simulación:
• Estados de la máquina (libre) y de la cola (vacía) al inicio de la simulación.
• Instantes de llegadas de todas y cada una de las piezas.
• Tiempo de procesado para todas y cada una de las piezas.
• Duración del experimento.
1.5.3 “Semáforo de peatones”
Supongamos un semáforo de peatones con dos luces (roja y verde) para controlar el
paso de peatones por una calle bastante transitada por vehículos (Deschamps y Ángulo,
1989). La situación normal del semáforo es con la luz verde encendida, para dejar paso
a los vehículos. Cuando un peatón desea cruzar la calle, aprieta un pulsador y durante
un periodo de tiempo, el semáforo se pone en rojo para los vehículos; luego vuelve a la
situación normal. En este sistema, como en los dos ejemplos anteriores, hay un único
recurso “el semáforo” pero compartido simultáneamente por todos los peatones (el
único tipo de entidad del sistema) que se disponen a cruzar, sin necesidad de guardar
cola. El semáforo realiza su función “la regulación del tráfico” combinando dos
actividades complementarias “el paso de vehículos” y “el paso de peatones”. El sistema
se puede modelar con:
Tres variables lógicas de estado, aunque se podrían utilizar sólo dos (una para el
semáforo y otra para el pulsador):
V : para indicar que el semáforo está en “verde” (V=1) o no lo está (V=0).
R : para indicar que el semáforo está en “rojo” (R=1) o no lo está (R=0).
P : para indicar el estado del pulsador, P = 0 indica que no hay petición de
ningún peatón y P = 1 para indicar que se ha recibido una petición
Un parámetro: tiempo de paso para los peatones (constante)
Y los tres eventos siguientes:

e1 : un peatón ha pulsado porque desea cruzar (evento externo)
e2 : el semáforo cambia a rojo (evento interno)
e3 : el semáforo cambia a verde (evento interno)
El evento externo (la pulsación de un peatón) provoca una acción diferente según el
estado del pulsador. Si (P=0) porque en ese momento no hay ninguna petición
pendiente, la petición es atendida (P=1). Pero si ya había una petición (P=1), P
permanece en el valor 1, ya que, a diferencia de los dos ejemplos anteriores en los
que había cola de espera, no es necesario acumular la nueva petición.
El primero de los eventos internos (cambio a rojo) provoca una activación del estado
“rojo” (R=1) y una desactivación del estado “verde” (V=0). Pero también debe
provocar la desactivación (P=0) de la petición del peatón para indicar que ésta ya ha
sido atendida.
20
El segundo de los eventos internos (cambio a verde) provoca una activación del
estado “verde” (V=1) y una desactivación del estado “rojo” (R=0). Pero también
debe provocar la desactivación (P=0) de la petición del peatón, por si hubiera habido
alguna mientras que el semáforo estuvo en rojo.
El evento externo se activa de forma aleatoria, pues la llegada de un peatón es

totalmente aleatoria. El “cambio a rojo” se activará siempre que exista la petición de
algún peatón (P=1) y el semáforo estuviera en el estado “verde” (V=1). El “cambio a
verde” se activará automáticamente cuando el semáforo haya estado en rojo (R=1) un
intervalo de tiempo igual al tiempo de paso para los peatones.
Este semáforo es poco realista, pues por simplicidad se ha supuesto que sólo tiene dos
luces cuando lo normal es un semáforo tenga tres (verde, ámbar y rojo) para los coches
y dos (rojo y verde) para los peatones. Pero además desde el punto de vista funcional, el
sistema presenta un problema: los coches no tienen asegurado un tiempo de paso
mínimo. Esto ocurre porque la petición del peatón se atiende inmediatamente, luego se
puede dar el caso de que la llegada escalonada (pero frecuente) de peatones provoque
que el semáforo esté con mucho frecuencia en “rojo” para los coches, no haciendo bien
la función de regulación de tráfico para la que estaba pensado.
1.5.4 “Carro que va y viene”
Supongamos un carro C, tal como se describe en el apartado 1.3.3 del libro de M. Silva
(1985), capaz de moverse por un tramo de raíl desde un extremo A al extremo B y
viceversa gracias a la acción de dos motores, véase figura 1.1. Un motor hace que el
carro se mueva hacia la derecha y el otro motor hace que se mueva hacia la izquierda. El
carro está inicialmente en el extremo A y se pone en marcha, hacía la derecha, si se
pulsa el botón M; en caso contrario el carro permanecerá parado. Al llegar al extremo B,
el carro cambía de sentido y empieza a moverse hacia la izquierda. Cuando el carro
vuelve al extremo A, se para si el botón M no está pulsado; en caso contrario comienza
un nuevo ciclo. La presencia del carro en cualquiera de los extremos se detecta gracias a
dos contactos eléctricos.
i d
M
C
A B
Figura 1.1 Carro que va y viene.
El comportamiento del sistema se puede describir con el estado (M) del botón y los tres
estados del carro {R, D, I}. Donde:
• M = 0 representa que el botón no está pulsado (impidiendo el movimiento hacia
la derecha del carro) y M = 1 que sí lo está (permitiendo el movimiento hacia la
derecha del carro).
21
• R representa el estado en reposo del carro, que sólo se puede presentar en el

extremo A.
• D e I representan los estados en movimiento del carro, hacia la derecha y hacia
la izquierda respectivamente.
Y los tres eventos siguientes:

e1 : se ha pulsado el botón M (evento externo)
e2 : el carro ha alcanzado el extremo derecho B (evento interno)
e3 : el carro ha alcanzado el extremo izquierdo A (evento interno)
La pulsación del botón provoca siempre un cambio en el estado del pulsador. Si

(M=0), la pulsación del botón hace que su estado cambie a (M=1). Y si (M=1), la
pulsación del botón hace que su estado cambie a (M=0). Pero también puede
provocar un cambio en el estado del carro (de R a D) si éste estaba en “reposo” en el
extremo A.
El carro deja de moverse hacia la derecha para hacerlo hacia la izquierda (cambio de
D a I) cuando alcanza el extremo B con independencia del estado del botón.
El carro cambia de sentido (cambio de I a D) cuando alcanza el extremo A si el botón

está pulsado (M = 1), en caso contrario se para (cambio de I a R).
La pulsación del botón es aleatoria. El extremo B se puede alcanzar si el carro ha

estado el suficiente tiempo moviéndose hacia la derecha. El extremo A se puede
alcanzar si el carro ha estado el suficiente tiempo moviéndose hacia la izquierda.
Tal como se ha planteado el ejemplo, se trata de un sistema con única identidad “el
carro” que tiene sus estados de reposo y de movimiento hacia la derecha a hacia la
izquierda condicionados por un botón. Pero la entidad siempre está presente, nunca
abandona el sistema, pues realmente es el componente que da significado a éste. No se
puede hablar de recursos en este sistema, pero el carro se podría considerar como el
único recurso si sus movimientos entre los extremos A y B se aprovecharan para
transportar algún tipo de material.
1.6 TÉCNICAS DE DESCRIPCIÓN FUNCIONAL
A continuación vamos a recordar algunas técnicas o diagramas de descripción

funcional, que los alumnos han empleado en otras asignaturas, aplicándolas a los
ejemplos del apartado anterior. Se pondrán de manifiesto algunas limitaciones que las
hacen poco aconsejables para describir sistemas de eventos discretos en general. Y
aprovecharemos para presentar otros sistemas más complejos en los que tales diagramas
se vuelven ineficaces y se han visto desplazados por un tipo de diagrama “el grafo
reducido”. El grafo reducido es la antesala a uno de los paradigmas de modelado de los
sistemas de eventos discretos, “las redes de Petri”, que se verán en el tema 2. Y también
22
se utiliza como apoyo gráfico a la descripción de modelos atómicos DEVS, que se verán
en el tema 4.
1.6.1 Diagrama de flujo u organigrama
La figura 1.2 recoge los organigramas para las acciones asociadas a los dos eventos de
la “taquilla del cine”. En cambio, la figura 1.3 recoge un organigrama del sistema total
“taquilla del cine” bajo la metodología de “Modelado orientado a los procesos”, es
decir, describe el flujo de las entidades (“las personas”, en este caso). En el organigrama
de la figura 1.3 se observa claramente que:
• La llegada de una persona al cine puede provocar que ésta pase a ser atendida
inmediatamente porque la taquilla está libre o que pase a la cola para ser atendida
más tarde.
• Mientras haya personas en la cola, se irán atendiendo por orden de llegada y la
taquilla permanecerá ocupada.
• Cuando la cola se vacía, la taquilla queda libre y así estará hasta que llegue otra
persona al cine.
En este organigrama también se pueden distinguir claramente las acciones asociadas a

los dos eventos, pero no hay que interpretarlo como un conjunto de acciones
secuenciadas en el tiempo, ya que al mismo tiempo que una persona llega al cine otra
persona puede estar abandonando la taquilla o pasando de la cola a la taquilla para ser
atendida. Cada acción tiene su propia temporización.
Llegada de una Una persona abandona

persona al cine la taquilla
NO SÍ NO SÍ
Taquilla libre Cola vacía
La persona La primera persona

La persona se La taquilla
comienza a ser de la cola comienza a
pone a la cola queda libre
atendida ser atendida
Figura 1.2 Flujos de acciones asociadas a los eventos de la “taquilla del cine”.
23
Una persona llega

al cine
NO SÍ
Taquilla libre
La persona pasa
La persona se
a la taquilla
pone a la cola
La persona
permanece un tiempo
en taquilla
La persona abandona
la taquilla
SÍ NO
Cola vacía
Se libera la La primera persona de

taquilla la cola pasa a la taquilla
Figura 1.3 Diagrama del flujo de personas en la “taquilla del cine”.
A continuación se describen, mediante pseudocódigos, las rutinas y las distintas partes

del programa principal para experimentar en simulación sobre el “sistema simple de
producción”, obteniendo las correspondientes medidas del comportamiento.
Datos del experimento:
vt = vector con los instantes de tiempo de llegada de cada pieza

vtp = vector con los tiempos de procesado que requiere cada pieza
duracion = duración del experimento
maquina = 0 /* máquina libre */
n=0 /* cola vacía */
Inicialización de variables:
cpp = 0
cpc = 0
actp = 0
actc = 0
reloj = 0
Rutina: Llegada de una pieza
ti = reloj /* Asigna instante de llegada a la pieza */
24
tp = tpi /* Asigna el tiempo de procesado correspondiente a la pieza */

if maquina = 0 /* ¿Está libre la máquina? */
maquina = 1 /* Captura la máquina */
Actualiza lista de eventos; indicando que en tfp = reloj + tp finalizará el procesado de una
pieza
else
tci = reloj /* Asigna instante de entrada de la pieza en la cola */
n = n+1 /* Contador de piezas en la cola */
end
Rutina: Fin del procesado de una pieza
actp = actp + tp /* Acumula el tiempo que la pieza ha necesitado para ser

procesada */
cpp = cpp+1 / * Contador de piezas procesadas */
if n = 0 /* ¿Está vacía la cola? */
maquina = 0 /* Libera a la máquina */
else
apunta el índice j a la primera pieza de la cola (la que lleva más tiempo)
tc = reloj – tj /* Calcula el tiempo que lleva la pieza en la cola
actc = actc + tc /* Acumula el tiempo que la pieza ha estado en la cola */
tp = tpj /* Asigna el tiempo de procesado correspondiente a la pieza */
cpc = cpc + 1 /* Contador de piezas que han pasado por la cola antes de ser
procesadas */
Actualiza lista de eventos; indicando que en tfp = reloj + tp finalizará el procesado de una
pieza
end
Cálculo final de las prestaciones del sistema:
Número total de piezas procesadas = cpp

Número de piezas en la cola = n
Tiempo medio de espera en la cola = actc / cpc
Tiempo medio de procesado = actp / cpp
Porcentaje de ocupación de la máquina = 100 actp / duracion
1.6.2 Autómata finito
La descripción de sistemas discretos en los que se identifica un número finito de

situaciones o estados internos se puede llevar a cabo mediante una máquina secuencial
denominada autómata finito. Si a un autómata se le aplica una sucesión de señales de
entrada, distribuidas en el tiempo, producirá una salida que es función de la última
combinación de las entradas y de su estado interno, o sea, de la historia de las mismas a
lo largo del tiempo. Existen dos tipos básicos de autómatas, el de Moore y el de
Huffman-Mealy (Dormido y col., 2002).
Se define el autómata finito (AF) de Huffman-Mealy como una quíntupla:
MAF = < E, S, Q, δ, λ >

Donde
E = {Ei} es el conjunto finito de nombres y valores de las entradas (alfabeto de

entrada)
S = {Sj} es el conjunto finito de nombres y valores de las salidas (alfabeto de
salida)
25
Q es el conjunto finito de estados (internos) del autómata

δ : Q x E → Q, es la función de transición; determina cuál es el estado futuro para
cada combinación de entradas en función del estado actual
λ : Q x E → S, es la función de salida; determina cuál es la salida para cada
combinación de entradas en función del estado actual
En el autómata finito (AF) de Moore, cuyas salidas reciben el nombre de

incondicionales porque dependen únicamente del estado, la función de salida se
simplifica λ : Q → S. Siempre es posible pasar de una descripción a otra, con la
salvedad de que el número mínimo de estados necesarios para representar un sistema
mediante un AF de Moore siempre será mayor o igual al número mínimo de estados del
correspondiente AF de Huffman-Mealy.
En definitiva, dado el enunciado de un sistema susceptible de ser modelado por un AF,

debemos:
1) Identificar: el número de entradas y sus valores, el número de salidas y sus

valores, y los estados internos del sistema. En uno de los estados, conocido como
el estado inicial, se encontrará el autómata cuando aún no ha recibido ninguna
entrada.
2) Formular las dos funciones (función de transición y función de salida) que

representan el comportamiento dinámico entrada-salida del sistema. Esta
formulación es dependiente del tipo de análisis o de implementación que se quiera
hacer del sistema, por lo que en su camino tendremos que hacer uso de algún tipo
de metodología o formalismo. La primera aproximación, quizás las más fácil y
más recomendable, es la de tipo algorítmico, mediante un diagrama de estados.
En el diagrama de estados cada estado se representa por un círculo y las
transiciones mediante flechas. Si se ha optado por un AF de Huffman-Mealy, en
cada transición hay que indicar la combinación de entradas que la provoca y las
salidas que se generan mientras dure esa combinación de entradas. Y si se ha
optado por un AF de Moore, en cada transición se indica la combinación de
entradas que la provoca y las salidas se indican en cada estado.
El sistema “semáforo de peatones con dos luces” se puede modelar como un autómata
finito con:
• Una entrada lógica, la correspondiente al pulsador. Que podemos llamar x, con
dos posibles valores, x = 0 para indicar que no hay petición de ningún peatón y x
= 1 para indicar que se ha recibido una petición.
• Dos salidas lógicas, que podemos llamar y0 e y1, para representar en “0” y “1”
respectivamente el estado “apagada” o “encendida” de las dos luces (verde y
roja) que tiene el semáforo.
• Dos estados internos; uno representado por la letra V para indicar que el
semáforo está en “verde” y otro, representado por la letra R, para indicar que el
semáforo está en “rojo”. El estado V es estable, el semáforo permanecerá en él
indefinidamente mientras no haya petición de un peatón, mientras que el estado
R es transitorio, el semáforo permanecerá en él el tiempo estimado para que los
peatones crucen la calle.
26
La figura 1.4 muestra un esquema del sistema y su posible diagrama de estados. El

modelo al que se ha llegado es un AF de Moore con dos estados (V y R), donde la
pareja de salidas toma el valor “1 0” cuando el semáforo está en V y el valor “0 1”
cuando está en R. El estado V no se abandona salvo que haya una petición (x = 1) de
los peatones, y el estado R se abandona siempre que haya transcurrido un ciclo de reloj,
con independencia de que el peatón haya hecho otra petición o no.
x
V
10
señal de entrada
C
x V y0
señales de x
salida
R y1
R
01
Figura 1.4 Esquema del semáforo peatonal y su diagrama de estados.
El comportamiento del “carro que va y viene” se puede describir mediante un

autómata finito con tres variables lógicas de entrada {M, A, B}, dos variables lógicas de
salida {d, i} y tres estados internos {R, D, I}. Donde:
• La entrada M se utiliza para representar el estado del botón; M = 0 representa que
el botón no está pulsado (impidiendo el movimiento hacia la derecha del carro) y
M = 1 que sí lo está (permitiendo el movimiento hacia la derecha del carro).
• La entrada A se utiliza para indicar la no presencia (A = 0) o presencia (A = 1) del
carro en el extremo A.
• La entrada B se utiliza para indicar la no presencia (B = 0) o presencia (B = 1) del
carro en el extremo B.
• La salida d se utiliza para controlar un relé que desconecta (d = 0) o conecta (d =
1) el motor que mueve al carro hacia la derecha.
• La salida i se utiliza para controlar un relé que desconecta (i = 0) o conecta (i = 1)
el motor que mueve al carro hacia la izquierda.
• R representa el estado en reposo del carro, que sólo se puede presentar en el
extremo A.
• D e I representan los estados en movimiento del carro, derecha e izquierda
respectivamente.
La figura 1.5 muestra el posible diagrama de estados con estructura de AF de Moore. El

diagrama refleja que:
• El carro abandona el estado de reposo R para pasar al estado D, con salidas d=1 e
i=0, cuando se presenta la combinación de entradas M A B , es decir cuando el
carro se encuentra en el extremo A (A = 1, B = 0) y se pulsa el botón (M = 1).
27
• El carro deja de moverse hacia la derecha para hacerlo hacia la izquierda (cambio
de D a I), con salidas d=0 e i=1, cuando se alcanza el extremo B (A = 0, B = 1)
con independencia del estado del botón.
• El carro cambia de sentido (cambio de I a D) cuando alcanza el extremo A si el
botón está pulsado (M = 1, A = 1, B = 0), en caso contrario, para la combinación
(M = 0, A = 1, B = 0), se para (cambio de I a R), con salidas d=0 e i=0.
A diferencia del diagrama de estados del semáforo, donde sólo había una entrada con
dos posibles valores, en el diagrama de estados del carro hay determinadas
combinaciones de entrada que no se pueden presentar (por ejemplo; A y B no pueden
tomar simultáneamente el valor lógico 1 pues el carro no puede estar en los dos
extremos al mismo tiempo).
M A B
R
00
M A B
D
M A B 10
A B
A
M A B
I
01
Figura 1.5 Diagrama de estados para el carro que va y viene.
El diagrama de estados, así concebido, refleja todos los posibles estados globales del
sistema y todas las posibles evoluciones del sistema. Por tanto se trata de una
descripción exhaustiva del sistema. Su utilización es poco aconsejable en sistemas
complejos porque cuando aumenta el número de variables de entrada, aumentan
considerablemente el número de combinaciones de entrada y las transiciones a
considerar, pero además (el ejemplo del carro es bastante representativo) porque en
estos sistemas es habitual que un gran número de combinaciones de entrada no tengan
sentido físico en determinados estados.
1.6.3 Grafo reducido
A continuación vamos a introducir una herramienta de descripción funcional

aparentemente similar al diagrama de estados. Se trata del grafo reducido (GR), descrito
por M. Silva (1985). Se diferencia del diagrama de estados porque en él no se analizan y
representan las combinaciones de entrada que provocan las transiciones sino las
condiciones lógicas que las provocan, es decir, cualquier función lógica de las entradas.
Por ejemplo, en el caso del carro que va y viene, con tres estados {R, D, I} posibles, la
única condición lógica que lo puede sacar del estado R es que se pulse el botón, pero
28
además como sólo puede estar parado en el extremo izquierdo A, cuando abandona el
estado R lo hace moviéndose hacia la derecha, es decir, pasando al estado D. La única
condición lógica que puede sacar al carro del estado D es que haya alcanzado el
extremo derecho B, y lo hace cambiando el sentido de su marcha, es decir, pasando al
estado I. Por último la única condición lógica que puede sacar al carro del estado I es
que haya alcanzado el extremo A, y lo hace cambiando el sentido de su marcha (paso al
estado D) si el pulsador está pulsado o parándose (paso al estado R) si el pulsador no
está pulsado.
En la figura 1.6 (a) puede verse el grafo reducido resultante, respecto al diagrama de
estados sólo han desaparecido las tres transiciones que hacían al carro permanecer en
uno de sus tres estados y las salidas asociadas a los estados, pero el grafo aún se puede
reducir más si consideramos que como la permanencia en el estado R está condicionado
por el estado del pulsador, el paso de I a D cuando el botón está pulsado se puede
realizar pasando (con tiempo de permanencia infinitesimal) por el estado R. El grafo
reducido definitivo es entonces el representado en la figura 1.6 (b). Donde además
aparecen diferenciadas (Zeigler y col., 2000) las transiciones de estado internas,
provocadas por el propio carro cuando alcanza los extremos A y B, en trazo discontinuo
de la transición de estado externa, provocada por el botón, en trazo continuo.
R R
M M
A
M A D D
B M A B
I I
(a) (b)
Figura 1.6 Grafos reducidos para el carro que va y viene.
El grafo reducido para el “semáforo de peatones” puede quedar como muestra la figura
1.7. Donde está recogida la transición de V a R, indicada por trazo continuo,
condicionada a la petición del peatón, que no es necesario explicitar porque es la única
entrada que tiene el sistema. Y la transición de R a V, indicada por trazo discontinuo,
para indicar que se trata de una transición interna del sistema, que no está condicionada
por la entrada del sistema sino por el tiempo de permanencia en el estado R.
V R
Figura 1.7 Grafo reducido para el semáforo de peatones.
29
La “taquilla del cine” se puede describir mediante el grafo reducido de la figura 1.8.
Donde ha sido necesario acudir a una representación bidimensional, puesto que el
comportamiento del sistema depende del estado de la taquilla, representado en el eje de
ordenadas, y del estado de la cola, representado en el eje de abscisas. Las llegadas de las
personas están recogidas en las transiciones con trazo continuo, y las salidas están
recogidas en las transiciones con trazo discontinuo.
Ocupada
Libre
0 1 2 3 Personas en la cola
Figura 1.8 Grafo reducido para la taquilla del cine.
1.6.3.1 “Carros que van y vienen por raíles diferentes, sincronizados en los
extremos”
Se propone modelar con un GR el comportamiento de dos carros, que van y vienen por
raíles diferentes, a diferentes velocidades, pero sincronizados en los extremos izquierdos
y derechos. La política de sincronización obliga a que un carro no pueda cambiar de
dirección hasta que el otro no haya llegado y por tanto que ambos carros partan a la vez
de sus respectivos extremos izquierdos o derechos. El sistema dispone además de un
pulsador M para hacer (si no está pulsado) que ambos carros permanezcan en reposo en
los extremos izquierdos respectivos (A y C) y para conseguir (si está pulsado) que
ambos carros se muevan hacia la derecha.
El comportamiento del sistema, véase la figura 1.9, se puede describir con los siguientes
siete estados internos:
1 Ambos carros están en reposo en sus respectivos extremos izquierdos (el carro 1
en el extremo A y el carro 2 en el extremo C).
2 Ambos carros están moviéndose hacia la derecha.
3 El carro 1 ha llegado al extremo B y el carro 2 aún está moviéndose hacia la
derecha.
4 El carro 2 ha llegado al extremo D y el carro 1 aún está moviéndose hacia la
derecha.
5 Ambos carros están moviéndose hacia la izquierda.
6 El carro 1 ha llegado al extremo A y el carro 2 aún está moviéndose hacia la
izquierda.
7 El carro 2 ha llegado al extremo C y el carro 1 aún está moviéndose hacia la
izquierda.
Y las siguientes 9 transiciones (una externa y 8 internas):
30
1→2 Cuando se pulsa el botón estando ambos carros en sus extremos izquierdos.
2→3 Cuando el carro 1 alcanza el extremo B.
2→4 Cuando el carro 2 alcanza el extremo D.
2→4 Cuando el carro 2 alcanza el extremo D.
4→5 Cuando el carro 1 alcanza el extremo B.
5→6 Cuando el carro 1 alcanza el extremo A.
5→7 Cuando el carro 2 alcanza el extremo C.
6→1 Cuando el carro 2 alcanza el extremo C.
7→1 Cuando el carro 1 alcanza el extremo A.
i1 d1
1
M
C1
2
A B B D
M i2 d2
C 3 4 A
C2
D B
5
C D A C
6 7
Figura 1.9 Esquema y grafo reducido del sistema compuesto por dos carros que van y vienen.
A la descripción anterior se ha llegado analizando el comportamiento secuencial de los

carros, pero también se podría haber llegado por un camino más largo, analizando
primeramente las combinaciones de los estados parciales de sus dos componentes (el
carro 1 y el carro 2), descartando las que no son posibles y ordenándolas
adecuadamente. Mientras el carro que operaba solo nunca llegaba a pararse en el
extremo derecho, cuando se ha combinado con un segundo carro sí puede llegar a
pararse en el extremo derecho (basta con que llegue al extremo antes de que lo haga el
otro carro). Además, la parada del carro en el extremo izquierdo, que antes sólo
dependía del estado del botón, ahora también se puede deber a que esté esperando la
llegada del otro carro. En definitiva cada carro presenta cuatro estados parciales (dos de
reposo y dos de movimiento): RI = “reposo en el extremo izquierdo”, D = “moviéndose
hacia la derecha”, RD = “reposo en el extremo derecho” e I = “moviéndose hacia la
izquierda”.
Por tanto existen 16 (4x4) posibles combinaciones de estados individuales, de los cuales
sólo siete estados son posibles físicamente y han tenido su consideración en el grafo
reducido.
RI1 RI2 Se ha considerado como estado 1.

RI1 D2 Estado imposible según el enunciado, pues ambos carros reanudan su
marcha hacia la derecha al mismo tiempo.
31
RI1 RD2 Estado imposible según el enunciado, pues los carros se esperan en los
extremos izquierdo o derecho para reanudar la respectiva marcha a la
vez.
RI1 I2 Se ha considerado como estado 6.
D1 RI2 Estado imposible según el enunciado, pues ambos carros reanudan su

marcha hacia la derecha al mismo tiempo.
D1 D2 Se ha considerado como estado 2.
D1 RD2 Se ha considerado como estado 4.
D1 I2 Estado imposible según el enunciado, pues cuando ambos carros se
mueven, lo hacen siempre en la misma dirección.
RD1 RI2 Estado imposible según el enunciado, pues los carros se esperan en los
extremos izquierdo o derecho para reanudar la respectiva marcha a la
vez.
RD1 D2 Se ha considerado como estado 3.
RD1 RD2 Estado que no es necesario según el enunciado, pues el primer carro
que llega al extremo derecha espera al otro y reanudan
inmediatamente la marcha, sin que en ningún momento los dos estén
en reposo.
RD1 I2 Estado imposible según el enunciado, pues ambos carros reanudan su
marcha hacia la izquierda al mismo tiempo.
I1 RI2 Se ha considerado como estado 7.

I1 D2 Estado imposible según el enunciado, pues cuando ambos carros se
mueven, lo hacen siempre en la misma dirección.
I1 RD2 Estado imposible según el enunciado, pues ambos carros reanudan su
marcha hacia la izquierda al mismo tiempo.
I1 I2 Se ha considerado como estado 5.
En definitiva, la principal diferencia del grafo reducido de la figura 1.9 con el grafo
reducido de la figura 1.6 (b) es que los estados utilizados en la descripción representan
estados globales del sistema, son combinaciones de los estados parciales de sus dos
componentes (el carro 1 y el carro 2). Además, mientras en el grafo reducido de la
figura 1.6 (b) sólo existe una posible secuencia de estados, que pueda describir cómo el
carro que ha partido del reposo puede volver a estar parado: R – D – I – R. En el grafo
reducido de la figura 1.9 existen cuatro posibles secuencias para representar un mismo
fenómeno “los dos carros que han partido del reposo vuelven a estar parados en sus
respectivos extremos izquierdos”:
1 – 2 – 3 – 5 – 6 – 1 (si el carro 1 ha sido el más rápido tanto en la ida como

en la vuelta)
1 – 2 – 3 – 5 – 7 – 1 (si el carro 1 ha sido el más rápido en la ida y el carro 2

ha sido el más rápido en la vuelta)
1 – 2 – 4 – 5 – 6 – 1 (si el carro 2 ha sido el más rápido en la ida y el carro 1

ha sido el más rápido en la vuelta)
32
1 – 2 – 4 – 5 – 7 – 1 (si el carro 2 ha sido el más rápido tanto en la ida como

en la vuelta)
1.6.3.2 Crítica al grafo reducido
Los GR son importantes porque incorporan los conceptos de receptividad y de

sensibilidad, que son los que permiten simplificar en gran medida la descripción de un
sistema. Se dice que un sistema es receptivo a un cierto evento o condición si éste es
capaz de hacer evolucionar su estado. La receptividad a un determinado evento es
función del estado del sistema. En el ejemplo del semáforo, el sistema es receptivo al
pulsador del peatón sólo si el semáforo está en verde. En el ejemplo del carro, el sistema
es receptivo al pulsador M sólo si el carro se encuentra parado en el extremo A, en el
resto de los casos el sistema evoluciona independientemente del estado del pulsador. El
sistema es receptivo al contacto eléctrico situado en el extremo derecho B (izquierdo A)
si el carro se está moviendo hacia la derecha D (izquierda I). En el ejemplo de los dos
carros, el sistema es receptivo al pulsador M sólo si ambos carros están en reposo
(estado 1). El sistema es receptivo al contacto eléctrico situado en el extremo derecho B
del primer raíl si ambos carros están moviéndose hacia la derecha (estado 2) o sólo lo
está haciendo el carro 1 (estado 4). Y así sucesivamente se pueden poner más ejemplos
de receptividad.
La sensibilidad es un concepto dual de la receptividad, se dice que un sistema es

sensible a cierto evento o condición si éste es capaz de hacer que evolucionen sus
salidas sin que evolucione su estado interno. Ninguno de los ejemplos anteriores sirven
para ilustrar este concepto, pero una ligera modificación del enunciado del carro sí que
serviría para ello. Basta suponer que existe una cuarta entrada al sistema, concretamente
un pulsador de STOP, capaz de hacer que se paren temporalmente cualquiera de los dos
motores. La descripción del sistema, representada por el grafo reducido de la figura 1.6
(b), seguiría siendo válida con sólo introducir la información de que las acciones d e i
asociadas a los estados D e I están condicionadas por la entrada STOP. Si el carro está
en el estado D con motor conectado (salida d=1), la pulsación del botón STOP no
provocaría cambio de estado, pero si provocaría un cambio en la salida (d=0) para
desconectar temporalmente el motor.
Sin embargo cuando en un sistema existen evoluciones paralelas, simultáneas, su

descripción mediante un GR no es eficiente porque:
• Requiere un gran número de estados. Por ejemplo, se puede comprobar (Silva,

1985) que si en lugar de dos son tres los carros que van y vienen sincronizados, se
necesita un GR con 15 estados globales, superior a los 12=4+4+4 estados
parciales en los que se pueden encontrar los tres elementos que componen el
sistema. También, en el último de los ejercicios propuestos del tema, podrá
comprobar que para describir el comportamiento de “dos carros que circulan por
raíles diferentes con un tramo común” se necesita un GR con 42 estados globales,
superior a los 14=7+7 estados parciales en los que se pueden encontrar los dos
elementos que componen el sistema.
• No permite modificaciones locales del comportamiento del sistema sin poner en

tela de juicio toda la descripción realizada; es decir, no es flexible. Por ejemplo,
33
trate de analizar qué cambios tendría que introducir en el grafo de la figura 1.9 si
en el enunciado de los “dos carros que van y vienen sincronizados” se dice que “el
carro 1 está obligado a permanecer como mínimo un cierto tiempo parado en el
extremo B antes de cambiar de sentido”. ¿Hubiera sido más rápido plantear un
nuevo grafo?
• No permite una descripción descendente del sistema (por refinamientos

sucesivos). Por ejemplo, suponga los grafos reducidos de la figura 1.10, que
describen un sistema informático que realiza una tarea compuesta de dos tareas en
paralelo (T1 y T2). El grafo (a) incluye cuatro transiciones (FT=“fin de tarea”) y
cuatro estados: “1” para representar el inicio de ambas tareas, “2” para representar
que el sistema ha finalizado T1 pero aún está realizando la tarea T2, “3” para
representar el caso análogo T1 en fase de realización y T2 finalizada, y “4” para
representar que ambas tareas han finalizado. El grafo (b) resulta de considerar que
la tarea T1 consta de dos subtareas T11 y T12 secuenciales. En su construcción ha
sido necesario incluir dos nuevos estados, el “5” y el “6” para indicar la
finalización de la primera parte de la tarea T1, manteniendo parte de la
descripción original. Si posteriormente se decide considerar que la tarea T2
también consta de dos subtareas T11 y T12 secuenciales, el nuevo grafo tendrá 16
estados y 24 transiciones (Silva, 1985), y sólo los estados inicial y final
conservarán el significado original.
1 FT11 FT2
FT1 FT2 5 3
2 3 FT12
FT2 FT11
2 6
FT2 FT1
4 FT12
FT2
4
(a) (b)
Figura 1.10 Grafos reducidos de un sistema informático.
Es precisamente para evitar o disminuir los inconvenientes comentados anteriormente

por lo que se introducen las redes de Petri (Silva, 1985), a las que está dedicado el tema
2. Éstas aparecen como una generalización natural de los grafos reducidos que permite
la consideración directa de las evoluciones simultáneas. El concepto de estado global
del sistema utilizado en los grafos reducidos se verá sustituido por el concepto de
marcado de la red, según el cual un estado del sistema estará definido por un conjunto
de subestados (estados locales o actividades) de los elementos que componen el sistema.
34
1.7 EJERCICIOS RESUELTOS
EJERCICIO 1.1
Se pretende analizar el funcionamiento de una compañía dedicada a la

comercialización de cierto producto. La compañía, que actúa como intermediaria entre
el proveedor y los clientes, dispone de un almacén para el producto. La clave de la
rentabilidad de la compañía está en realizar una gestión adecuada del inventario de
este almacén. Deberá intentar satisfacer las demandas de los clientes, pero
manteniendo el nivel del inventario lo más bajo posible, con el fin de minimizar los
costes de almacenamiento. La política de atención al cliente es la siguiente: si un
cliente solicita una cantidad de producto inferior a la almacenada, se le sirve
inmediatamente, en caso contrario se le sirve lo que haya en el almacén en ese
momento y el resto cuando la llegada de nuevo producto lo permita. Y la política de
petición al proveedor es como sigue: cada primero de mes la compañía hace una
evaluación de su inventario (que puede ser negativo si hay clientes a los que no se le ha
servido todo lo que pidieron) y decide no pedir si hay una mínima cantidad de producto
o pedir lo que falta hasta completar un nivel de inventario. Enumere los eventos que
pueden representar este sistema y trace los flujos de acciones asociadas a cada uno de
ellos.
Este ejercicio está sacado de un ejemplo que se analiza extensamente en el apartado 5.4
de Urquía 2003. Se remite a los alumnos a ese apartado si quieren ver la solución,
aunque no es necesario que consulten todos los detalles. Sólo los tres eventos “pedido
de cliente”, “llegada de producto” y “evaluación del inventario”, que permiten
representar al sistema, y las acciones asociadas a cada uno de ellos.
EJERCICIO 1.2
a) ¿Qué componentes son necesarios para describir el comportamiento de los “carros

que van y vienen por raíles diferentes, sincronizados en los extremos”, véase la figura
1.9? Enumere los eventos, las acciones asociadas y las condiciones de activación.
b) Refleje mediante un organigrama el flujo de los carros. ¿Encuentra alguna analogía
entre el organigrama y el grafo reducido de la figura 1.9?
a) En este sistema no hay entidades temporales, hay dos entidades permanentes: el carro
1 y el carro 2. Que además son del mismo tipo y para las que se puede considerar un
único atributo; el “estado de la entidad”. Que puede tomar tres valores: R=“reposo”,
D=“moviéndose hacia la derecha” e I=“moviéndose hacia la izquierda”. Los raíles
podrían tener la consideración de recursos, pero como cada carro se mueve por un raíl
diferente y no compiten por ello, no es necesario considerar ningún recurso en el
sistema. Los posibles eventos son:
e1 : se ha pulsado el botón M (evento externo)

e2 : el carro 1 ha alcanzado el extremo derecho B (evento interno)
e3 : el carro 2 ha alcanzado el extremo derecho D (evento interno)
e4 : el carro 1 ha alcanzado el extremo izquierdo A (evento interno)
e5 : el carro 2 ha alcanzado el extremo izquierdo C (evento interno)
35
AE1. La pulsación del botón provoca siempre un cambio en su estado; de “no

pulsado” a “pulsado” o de “pulsado a no pulsado”. Pero también puede provocar un
cambio en el estado de los carros (de R a D) si éstos estaban en “reposo” en los
extremos A y C respectivos.
AE2. Cuando el carro 1 alcanza el extremo B pueden ocurrir dos cosas, que se pare a
esperar a que el carro 2 llegue al extremo D, o que deje de moverse hacia la derecha
para hacerlo hacia la izquierda (cambio de D a I) si el carro 2 ya estaba en el extremo
D. En esta segunda situación, el carro 2 dejará de estar parado y comenzará a
moverse hacia la izquierda.
AE3. Cuando el carro 2 alcanza el extremo D se desencadenarán las acciones

reciprocas del evento anterior.
AE4. Cuando el carro 1 alcanza el extremo A pueden ocurrir tres cosas. 1) Que se
pare a esperar a que el carro 2 llegue al extremo C. 2) Que deje de moverse hacia la
izquierda para hacerlo hacia la derecha (cambio de I a D) si el carro 2 ya estaba en el
extremo C y el botón está pulsado. En esta segunda situación, el carro 2 dejará de
estar parado y comenzará a moverse hacia la derecha. 3) Que se pare porque, aunque
el carro 2 ya estaba en el extremo C, el botón está sin pulsar.
AE5. Cuando el carro 2 alcanza el extremo C se desencadenarán las acciones

La pulsación del botón es aleatoria. El extremo B se puede alcanzar si el carro 1 ha

estado el suficiente tiempo moviéndose hacia la derecha. El extremo D se puede
alcanzar si el carro 2 ha estado el suficiente tiempo moviéndose hacia la derecha. El
extremo A se puede alcanzar si el carro 1 ha estado el suficiente tiempo moviéndose
hacia la izquierda. El extremo C se puede alcanzar si el carro 2 ha estado el suficiente
tiempo moviéndose hacia la izquierda.
b) El comportamiento de los carros se puede describir mediante el siguiente

organigrama de la figura 1.11.
36
NO
El botón está
pulsado
SÍ
Los dos carros se

ponen en marcha
hacia la derecha
El carro 1 ha
SÍ llegado a B
NO
El carro 2 ha NO
llegado a D
SÍ
El carro 1 se El carro 2 se
para en B para en D
El carro 2 ha NO El carro 1 ha NO
llegado a D llegado a B
SÍ SÍ
para en D para en B
Los dos carros se

ponen en marcha
hacia la izquierda
El carro 1 ha
llegado a A
SÍ
NO
El carro 2 ha NO
llegado a C
SÍ
para en A para en C
El carro 2 ha NO El carro 1 ha NO
llegado a C llegado a A
SÍ SÍ
para en C para en A
Figura 1.11 Organigrama de los carros que van y vienen.
Se observa una total analogía entre el organigrama de la figura 1.11 y el grafo reducido
de la figura 1.9, pero además se observa que es más fácil trazar el grafo reducido aunque
haya que complementarlo con información sobre el significado de los estados y de los
eventos.
37
EJERCICIO 1.3
a) Una oficina de información turística está formada por un grupo de tres trabajadores.
A esta oficina llegan pidiendo información dos tipos de turistas: unos que solamente
necesitan mapas o folletos informativos, con lo que el tiempo de atención por parte de
los informadores es pequeño, y otros que piden información más detallada y se precisa
más tiempo para atenderlos. ¿Qué componentes son necesarios para describir este
sistema? Enumere los eventos, las acciones asociadas y las condiciones de activación.
b) El director de la oficina ha decidido contratar a estudiantes de turismo para que
puedan realizar prácticas. Pero a diferencia de los trabajadores, los estudiantes sólo
pueden trabajar media jornada. ¿Qué componentes son necesarios para describir el
nuevo sistema si el director ha decidido mantener la funcionalidad pero utilizando sólo
un trabajador y el resto estudiantes?
a) Es un ejemplo parecido al de la “Oficina de atención al público”. En el que hay más

recursos (tres trabajadores) para atender a los clientes (turistas), y además hay dos tipos
de turistas; los que solicitan folletos y los que solicitan información detallada. Luego la
única entidad “turista” que fluye por el sistema tiene un atributo que puede tomar dos
valores: “folletos” e “informacion”. Este atributo tiene consecuencias en la actividad del
sistema, es decir, cuando el turista pasa a ser atendido, pues según el enunciado el
turista que solicita folletos requiere un tiempo de atención menor que el turista que
requiere información detallada. Sin embargo el enunciado no especifica nada sobre que
el tipo de servicio solicitado se discrimine cuando el turista llega a la oficina, por tanto
podemos suponer que el sistema funciona con una sola cola.
En definitiva el sistema se puede representar por:
Cuatro variables de estado:

3 trabajadores : estado del trabajador (0 libre, 1 ocupado)
n : número de turistas en la cola (valor entero)
Dos parámetros: tiempo de atención al turista que solicita folletos y tiempo de

atención al turista que solicita información detallada (que pueden ser constantes o
responder a algún tipo de distribución probabilística)

e1 : un turista llega a la oficina (evento externo)
e2 : un turista abandona la oficina porque ya ha sido atendido (evento interno)
La llegada de un turista a la oficina provoca una acción diferente según el estado de

los trabajadores. Si hay algún trabajador libre, el turista pasa a ser atendido, con lo
cual el trabajador correspondiente pasa a estar ocupado. Pero si todos los
trabajadores están ocupados, el turista pasa a engrosar la cola (n=n+1).
La salida de un turista de la oficina provoca una acción diferente según el estado de

la cola. Si no hay nadie en la cola, el trabajador que estaba atendiéndolo pasa a estar
libre. Pero si hay alguien en la cola, el primer turista de la cola pasa a ser atendido
38
por el trabajador que acaba de atender al otro turista, disminuyendo la cola en una
unidad (n=n-1).
El evento externo se activa de forma aleatoria, pues la llegada de un turista a la

oficina es totalmente aleatoria. Mientras que el evento interno (la salida de un turista
de la oficina) sólo se produce cuando un trabajador ha estado ocupado un intervalo
de tiempo igual al tiempo de atención requerido por el turista; pequeño si se ha
tratado de una solicitud de folletos y grande si se ha tratado de una solicitud de
información detallada.
b) Según el enunciado podemos suponer que los estudiantes tienen la misma capacidad
de atención que los trabajadores luego cada trabajador se puede sustituir por un
estudiante. Pero además, como los estudiantes trabajan a media jornada, para cubrir la
jornada de trabajo completa se necesitan un estudiante con turno de mañana y otro
estudiante con turno de tarde. En definitiva, para mantener la funcionalidad con un
trabajador y el resto estudiantes, el director debe contratar cuatro estudiantes, dos con
turno de mañana y dos con turno de tarde. Para describir la nueva situación vale el texto
anterior, salvo que “trabajador” se puede interpretar como recurso (trabajador o
estudiante) y sólo habría que incluir un nuevo evento (“el cambio de turno”), que se
activaría siempre a la misma hora del día. Las acciones asociadas a este evento son: los
estudiantes del turno de tarde ocupan los puestos de los estudiantes del turno de mañana
si éstos estaban libres, si alguno estaba “ocupado” la sustitución se aplaza el tiempo
necesario hasta que el turista es atendido.
EJERCICIO 1.4
Suponga una “oficina de denuncias de una comisaría de policía” que atiende un

distrito de una ciudad. Los ciudadanos pueden poner las denuncias personalmente en la
comisaría o vía telemática (por teléfono o por Internet), en este segundo caso están
obligados a pasar por la comisaría para ratificar y firmar su denuncia. De ahí que
cuando una persona llega a la oficina de denuncias se le pregunta si viene a poner la
denuncia o a ratificarla y se le asigna turno en la correspondiente cola. Cada cola está
atendida por un policía, pero cuando una cola se queda vacía el policía que ha
quedado libre tiene la consigna de atender ciudadanos de la otra cola hasta que llegue
algún denunciante de la modalidad (denuncia o ratificación) en la que él está
especializado.
a) ¿Qué componentes son necesarios para describir este sistema? Enumere los eventos,
las acciones asociadas y las condiciones de activación.
b) Refleje mediante un organigrama el flujo de personas por la oficina de denuncias.
a) En este sistema las entidades son las “personas”, con un atributo (el motivo que le ha
llevado a la oficina) que tiene dos valores “denuncia” o “ratificación”. Los recursos son
los dos policías (policia_D y policia_R) que atienden la oficina, uno especializado en
las “denuncias” y otro en las “ratificaciones”, pero ambos capacitados para atender las
dos modalidades. Se contemplan dos colas, la “cola de las denuncias” y “la cola de las
ratificaciones”. En principio podemos pensar que sólo existen dos eventos: “la llegada
de un ciudadano” a la oficina y “la salida” de la comisaría después de haber sido
39
atendido en la oficina de denuncias, sin necesidad de distinguir entre el motivo que le ha

llevado a ella.
La llegada de una persona a la oficina provoca una acción diferente según el motivo
que le ha llevado a la oficina y la situación de los recursos:
• Si “denuncia” y el policía especializado en denuncias está libre, la persona pasa a
ser atendida inmediatamente, con lo cual el policia_D pasa a estar ocupado.
• Si “denuncia” y el policia_D está ocupado, habrá que dirigirlo al policia_R si éste
está libre o a la cola de denuncias si el policia_R está ocupado.
• Si “ratificación” y el policia_R está libre, la persona pasa a ser atendida
inmediatamente, con lo cual el policia_R pasa a estar ocupado.
• Si “ratificación” y el policia_R está ocupado, habrá que dirigirlo al policia_D si
éste está libre o a la cola de ratificaciones si el policia_D está ocupado.
La salida de una persona de la comisaría provoca una acción diferente según la

situación de los recursos y el estado de las dos colas:
• Si el policía especializado en denuncias queda libre y hay ciudadanos en la cola
de denuncias, la primera persona de esta cola pasa a ser atendida, con lo cual el
policia_D vuelve a estar ocupado.
• Si policia_D queda libre y no hay ciudadanos en la cola de denuncias pero sí en
la cola de ratificaciones, la primera persona de esta cola pasa a ser atendida, con
lo cual el policia_D vuelve a estar ocupado.
• Si policia_D queda libre y no hay ciudadanos en ninguna de las colas, el
policia_D permanece libre, al menos hasta que llegue algún ciudadano.
• Si el policia_R queda libre y hay ciudadanos en la cola de ratificaciones, la
primera persona de esta cola pasa a ser atendida, con lo cual el policia_R vuelve
a estar ocupado.
• Si policia_R queda libre y no hay ciudadanos en la cola de ratificaciones pero sí
en la cola de denuncias, la primera persona de esta cola pasa a ser atendida, con
lo cual el policia_R vuelve a estar ocupado.
• Si policia_R queda libre y no hay ciudadanos en ninguna de las colas, el
policia_R permanece libre, al menos hasta que llegue algún ciudadano.
El evento externo se activa de forma aleatoria, pues la llegada de un ciudadano a la

oficina es totalmente aleatoria. Mientras que el evento interno (la salida de una persona
de la comisaría) se puede producir cuando cualquiera de los policías ha estado
atendiendo al ciudadano correspondiente un tiempo adecuado al motivo de su visita a la
comisaría (denuncia o ratificación).
b) En la figura 1.12 se muestra el organigrama que representa el flujo de personas por la

oficina y el uso de los recursos (policia_D y policia_R). En el organigrama no se ha
hecho explícito, pero se sobreentiende, que la persona después de ser atendida durante
el tiempo adecuado al motivo de su visita a la comisaría (denuncia o ratificación).
40
Una persona llega a

la oficina
Denuncia Ratificación
Denuncia o
ratificación
NO NO NO La persona pasa
Policia_D libre Policia_R libre Policia_D libre
a la cola_R
SÍ SÍ SÍ
NO SÍ
Policia_R libre
La persona pasa a La persona pasa a
ser atendida durante ser atendida durante
La persona pasa La persona pasa a un tiempo t_R un tiempo t_R La persona pasa a
a la cola_D ser atendida durante ser atendida durante
un tiempo t_D un tiempo t_D
SÍ NO SÍ NO
cola_R vacía cola_D vacía
La primera persona de La primera persona de

SÍ NO SÍ NO
la cola_R pasa a ser cola_R vacía la cola_D pasa a ser
cola_D vacía
atendida durante un atendida durante un
tiempo t_R tiempo t_D
Se libera el La primera persona de Se libera el La primera persona de

policia_R la cola_D pasa a ser policia_D la cola_R pasa a ser
atendida durante un atendida durante un
tiempo t_D tiempo t_R
Figura 1.12 Flujo de personas en la oficina de denuncias.
41
EJERCICIO 1.5
Representar mediante un grafo reducido el comportamiento de los siguientes sistemas:

• Un autómata con dos estados (“S1” y “S2”) que cambia de estado de forma
cíclica cada vez que recibe un evento externo.
• El encendido y apagado de una lámpara mediante el correspondiente
pulsador.
• Un contador de eventos módulo 5. Es decir, un sistema capaz de contar sólo
de 0 a 4 y vuelta a empezar.
• Un autómata con dos estados, S1=“espera” y S2=“ocupado”, que arranca
en el estado “espera” y cambia al estado “ocupado” cada vez que recibe un
evento externo, permaneciendo en este estado un tiempo fijo después del
cual vuelve al estado “espera”.
• Un semáforo de peatones, donde la petición del peatón no se atiende de
forma inmediata, sino garantizando el tiempo de permanencia en “verde”.
En el primer autómata no hay eventos internos, el siguiente grafo reducido recoge las
dos posibles transiciones (de S1 a S2 y de S2 a S1) debidas a un evento externo (flecha
continua).
S1 S2
El mismo grafo reducido vale para representar el encendido y apagado de la lámpara

provocado por el pulsador, donde LA = “lámpara apagada” y LE = “lámpara
encendida”.
LA LE
El grafo reducido que permite representar al contador módulo 5 es muy similar a los
grafos anteriores, pues sólo hay transiciones debidas a eventos externos entre un número
de estados finitos (en este caso cinco, representados por los digitos 0, 1, 2, 3 y 4).
0 2
4 3
A diferencia de los cuatro sistemas anteriores, en los que sólo había eventos externos, en
este sistema se produce un evento interno (temporizado) desde el estado “ocupado”
representado por una flecha discontinua. Los dos eventos, el externo y el interno,
42
conforman un proceso cíclico entre los dos estados del sistema. En el estado “ocupado”
también se pueden representar eventos externos, pero no es necesario considerarlos en
el grafo reducido puesto que, al no ser atendidos por el sistema, no ocasionan ninguna
transición de estado.
espera ocupado
El comportamiento básico de un semáforo de tráfico se puede modelar con un autómata

cíclico con tres estados en los que cada estado tiene asignado un tiempo de permanencia
distinto; por ejemplo 1 minuto en el estado “verde”, 10 segundos en el estado “ámbar” y
1 minuto en el estado “rojo”. Las transiciones entre los tres estados se producen como
eventos internos, cuando se ha cumplido el tiempo de permanencia en el estado
correspondiente. Pero si además el semáforo atiende peticiones de peatones (eventos
externos) y no las atienda de forma inmediata sino garantizando el tiempo de
permanencia mínimo en el estado “verde”, para describir su comportamiento se necesita
un cuarto estado de “espera en verde” donde podría permanecer indefinidamente si no
llega ningún peatón. El grafo reducido es muy parecido al del sistema anterior, basta
considerar que el proceso que mantiene “ocupado” al semáforo sin atender la petición
del peatón es un proceso secuencial que se compone de los tres estados del semáforo
estándar.
espera en
verde
verde
ocupado
ámbar
rojo
EJERCICIO 1.6
Justificar razonadamente que el comportamiento básico de un conjunto de dos

semáforos de tráfico encargados de regular un cruce se puede modelar con un
autómata cíclico con seis estados. ¿Qué situación representa cada uno de los estados,
que tiempo de permanencia le asignaría a cada estado?
Si suponemos que cada semáforo puede estar en uno de sus tres estados posibles
(“rojo”, “ámbar” y “verde”), llegaremos a que el conjunto de dos semáforos podría estar
en uno cualquiera de los nueve estados (las nueve combinaciones de estados
individuales) que están representados en la tabla 1.2. Sin embargo un análisis
pormenorizado de estas nueve combinaciones nos lleva a la siguiente conclusión: tan
sólo 5 de esas combinaciones deberían estar permitidas si queremos que el conjunto de
dos semáforos realice la función (regulación de tráfico) para la que está diseñado, las
43
otras cuatro no deben permitirse. En la segunda columna de la tabla 1.2 se ha indicado

la permisividad o no permisividad de cada una de las combinaciones. Por ejemplo, es
inmediato comprender que no se puede permitir que ambos semáforos estén en “verde”.
Tampoco se puede permitir que ambos semáforos estén en “ámbar” pues ello supondría
que instantes antes ambos semáforos han estado en “verde”. Y por último, por temas de
seguridad, a sabiendas que los conductores no pueden frenar instantáneamente tampoco
se puede permitir la combinación “ámbar” y “verde”.
Combinaciones posibles de dos semáforos Combinaciones permitidas

“rojo” y “rojo” Si
“verde” y “rojo” Si
“ámbar” y “rojo” Si
“rojo” y “verde” Si
“verde” y “verde” No
“ámbar” y “verde” No
“rojo” y “ámbar” Si
“verde” y “ámbar” No
“ámbar” y “ámbar” No
Tabla 1.2 Combinaciones posibles y combinaciones permitidas en un cruce con dos semáforos.
Pero si queremos combinar esos cinco estados de forma cíclica nos encontramos que el
orden de la tabla 1.2 presenta una situación bastante crítica; el paso instantáneo de la 3ª
fila (“ámbar” y “rojo”) a la 4ª fila (“rojo” y “verde”) podría provocar colisiones debido
a que los conductores tratarán de apurar el paso cuando su semáforo esté en “ámbar”.
Luego es prudente y recomendable incluir en el tránsito entre esos dos estados el paso
por el estado más seguro, el estado (“rojo” y “rojo”). En definitiva, el comportamiento
básico de un conjunto de dos semáforos de tráfico encargados de regular un cruce se
puede modelar con un autómata cíclico con los seis estados representados en la tabla
1.3. En dicha tabla están también asignados los tiempos de permanencia en cada estado,
basándonos en los tiempos del ejercicio anterior se ha considerado asignar 60 segundos
en los estados donde uno de los semáforos está en verde y de 10 segundos en el resto de
los casos. El ciclo completo dura 160 segundos que se podría reducir algo si a la
situación de ambos semáforos en “rojo” se le asigna menos tiempo.
Estados de los semáforos Tiempo de permanencia

(en segundos)
“rojo” y “rojo” 10
“verde” y “rojo” 60
“ámbar” y “rojo” 10
“rojo” y “rojo” 10
“rojo” y “verde” 60
“rojo” y “ámbar” 10
Tabla 1.3 Ciclo seguro de seis estados en un cruce con dos semáforos.
44
EJERCICIO 1.7
Dos carros transportan, como muestra la figura 1.13, cierto material desde dos puntos
de carga A y E hasta un punto de descarga D. Cada carro tiene su propio botón para
permitir el movimiento cíclico de ida y vuelta (A-D-A y E-D-E) respectivamente pero
con las siguientes características:
• Hay un punto de espera eventual (B en el caso del primer carro y F en el caso
del segundo carro) hasta que el tramo común (C-D) de la trayectoria de ambos
carros esté libre
• En caso de demanda simultánea del tramo común (recurso compartido), el
segundo carro siempre tiene prioridad
• No se consideran despreciables los tiempos de carga y descarga.
a) Enumere los eventos, las acciones asociadas y las condiciones de activación que
describen este sistema.
b) Evaluar cuántos estados serían necesarios para representar el comportamiento
individual de los carros y el comportamiento del sistema mediante un grafo reducido.
i1 d1
M1 C1
A
i2 d2
B C D
M2 C2 F
Figura 1.13 Carros que van y vienen por raíles con un tramo común.
a) Los posibles eventos son:
e1 : se ha pulsado el botón M1 (evento externo)

e2 : se ha pulsado el botón M2 (evento externo)
e3 : el carro 1 ha alcanzado el punto B (evento interno)
e4 : el carro 2 ha alcanzado el punto F (evento interno)
e5 : un carro ha alcanzado el extremo D (evento interno)
e6 : el carro 1 ha alcanzado el punto A (evento interno)
e7 : el carro 2 ha alcanzado el punto E (evento interno)
Las acciones asociadas a los eventos y sus condiciones de activación quedan recogidas a
continuación:
AE1. La pulsación del botón M1 provoca siempre un cambio en su estado; de “no

pulsado” a “pulsado” o de “pulsado a no pulsado”. Pero también puede provocar un
cambio en el estado del carro 1 (de R a D), si el carro estaba en “reposo” en el
extremo A. La pulsación del botón es totalmente aleatoria, pero también podríamos
suponer que responde a la acción de un operario después de haber cargado el carro 1.
AE2. La pulsación del botón M2 provoca las acciones reciprocas del evento anterior.
45
AE3. El carro 1 puede alcanzar el punto intermedio B cuando está moviéndose hacia
la derecha (hacia el extremo común D) o cuando está moviéndose hacia la izquierda
(hacia el extremo A). En el primer caso pueden ocurrir dos cosas, que continúe
moviéndose hacia la derecha porque el tramo común está libre o que se pare a
esperar a que el carro 2 abandone el tramo común. En el segundo caso el carro debe
continuar moviéndose hacia la izquierda.
AE4. Cuando el carro 2 alcanza el punto intermedio F se desencadenarán las

acciones reciprocas del evento anterior.
AE5. Cuando uno de los carros, que está moviéndose hacia la derecha en el tramo
común C-D, alcanza el extremo D deben ocurrir dos cosas, que se pare el tiempo
necesario para efectuar la descarga y que transcurrido ese tiempo reanude su marcha
en dirección contraria (hacia la izquierda).
AE6. Cuando el carro 1, que está moviéndose hacia la izquierda en el tramo propio
A-B, alcanza el extremo A pueden ocurrir dos cosas, en función del estado del botón
M1, que se pare indefinidamente en el extremo A hasta que el botón sea pulsado o
puesto que el botón está pulsado, se pare sólo el tiempo necesario para efectuar la
carga y que transcurrido ese tiempo reanude su marcha en dirección contraria (hacia
la izquierda).
AE7. Cuando el carro 2 alcanza el extremo E se desencadenarán las acciones

b) El comportamiento individual de cada uno de los carros se puede describir mediante

un grafo reducido con siete estados: REI = “reposo en el extremo izquierdo”, DTP =
“moviéndose hacia la derecha en el tramo propio”, RPI = “reposo en el punto
intermedio”, DTC = “moviéndose hacia la derecha en el tramo común”, REC = “reposo
en el extremo común”, ITC = “moviéndose hacia la izquierda en el tramo común”, ITP
= “moviéndose hacia la izquierda en el tramo propio”.
Respecto al sistema completo; podríamos pensar que existen 49 (7x7) posibles

combinaciones de estados individuales para describir el comportamiento del sistema.
Pero no es así, pues hay determinadas combinaciones que no son posibles físicamente,
ya que estarían en contra de lo enunciado. Por ejemplo, el carro 1 sólo puede estar
parado en el punto intermedio si el carro 2 está ocupando el tramo común, luego de las
siete posibles combinaciones del estado RPI1 con los siete estados individuales del
carro 2 (REI2, DTP2, RPI2, DTC2, REC2, ITC2, ITP2) sólo están permitidas las tres
siguientes:
RPI1 DTC2
RPI1 REC2
RPI1 ITC2
Algo similar ocurre con el carro 2, que sólo puede estar parado en el punto intermedio si
el carro 1 está ocupando el tramo común. Por tanto las siguientes siete combinaciones
de estados individuales
46
RPI1 REI2
RPI1 DTP2
RPI1 RPI2
RPI1 ITP2
REI1 RPI2
DTP1 RPI2
ITP1 RPI2
no están permitidas, luego se necesitan 42=49–7 estados globales para describir el

comportamiento del sistema mediante un grafo reducido. Este número es muy superior a
los 14=7+7 estados parciales en los que se pueden encontrar los dos elementos que
componen el sistema.
47
48
TEMA 2
Redes de Petri
Las Redes de Petri (a las que usualmente nos referiremos a lo largo del tema como RdP)
son una herramienta matemática que permite modelar comportamientos de sistemas de
muy distinta naturaleza. Los principales campos de aplicación de este formalismo
matemático son los sistemas legales, los sistemas operativos, la descripción de software
en general, la descripción de hardware de computadores y de sistemas discretos de
control con evoluciones concurrentes, la descripción de automatismos lógicos y de los
lenguajes formales. No obstante en nuestro caso concreto, las Redes de Petri serán
utilizadas fundamentalmente para la descripción de sistemas de eventos discretos.
La ventaja fundamental de las Redes de Petri como formalismo matemático de

descripción de modelos de sistemas de eventos discretos, es que permiten representar
los eventos y las actividades de una forma natural y relativamente sencilla, en
comparación con otros formalismos matemáticos existentes. De ahí que sea uno de los
formalismos más utilizados. También es el único formalismo que representa de manera
formal los conceptos de paralelismo y sincronización, que posteriormente estudiaremos
y comprobaremos lo importantes que son a la hora de describir el comportamiento de un
sistema dado. Por otro lado las RdP están en creciente utilización, porque permiten
modelar y analizar de forma sencilla subsistemas de control de sistemas discretos que
incorporan evoluciones concurrentes, aunque no son el único modelo de descripción
capaz de modelar este tipo de evoluciones.
2.1 DEFINICIÓN FORMAL DE LAS REDES DE PETRI
Una RdP es un grafo orientado en el que intervienen dos tipos de nodos unidos
alternativamente mediante arcos, estos son:
• Los nodos lugar (representados gráficamente por circunferencias). En cuyo interior

puede haber un número positivo o nulo de marcas, que son puntos representados en
el interior del nodo lugar y cuyo conjunto en un instante determinado de tiempo
representan lo que se denomina el marcado de un RdP, concepto que posteriormente
se analizará con un mayor detalle.
49
Redes de Petri
• Los nodos transición (representados gráficamente por segmentos rectilíneos).
Una característica fundamental de las RdP es que dos nodos del mismo tipo nunca
pueden ir unidos mediante un arco. Desde el punto de vista de la descripción funcional
del sistema que se quiere modelar, las transiciones o nodos transición se asocian a los
eventos que pueden aparecer en la dinámica del sistema y los lugares o nodos lugar se
asocian a las distintas actividades, o acciones, que realiza el sistema.
Matemáticamente una RdP se puede definir a partir de la siguiente quíntupla (Guasch y

col., 2002):
RdP = (P,T,A,W,M0)
Donde:
• P = {P1, P2, .., Pn} es el conjunto de nodos lugar.
• T = {T1, T2, .., Tn} es el conjunto de nodos transición.
• A ⊂ (P x T) ∪ (T x P) es el conjunto de arcos de la RdP, que se

define como el producto cartesiano de todos
los nodos P y T. Se suele denominar matriz de
incidencia.
• W = A |→ {1,2,3, ..} ∀ Ai representa el peso asociado a cada arco.
• M0 = Pi |→ {1,2,3, ..} ∀ Pi, representa el número de marcas iniciales en

cada nodo lugar.
La RdP así definida es una RdP ordinaria y marcada, donde el estado del sistema viene
totalmente determinado por el número de marcas que hay en todo momento en cada
nodo lugar, luego se puede describir a través del vector P. Por tanto, cada nodo lugar de
la RdP sirve para describir tanto las colas de espera que presenta el sistema, como las
condiciones impuestas sobre el estado del sistema en el que se encuentran los elementos
que constituyen dicha cola de espera. El número de marcas en el interior de un nodo
lugar representa el número de elementos que están en una cola de espera determinada
del sistema y también, el estado de una condición concreta en caso de que dicha
condición se cumpla en ese nodo. Por otro lado, los arcos que conectan los nodos
transición con los nodos lugar suelen llevar asociados un peso que describe el número
de condiciones necesarias para que un determinado evento representado por una
transición de la RdP pueda ser activado.
Para analizar, representar y estudiar una RdP dada, es necesario definir las funciones
E(Tj) y S(Tj), que representan respectivamente las funciones de los conjuntos de
entrada y salida de una transición dada Tj. Matemáticamente:
E(Tj) = {Pi ∈ P, (Pi, Tj) ∈ A} S(Tj) = {Pi ∈ P, (Tj, Pi) ∈ A}
Teniendo presentes ambas funciones se puede definir que:
50
Redes de Petri
• Un nodo lugar P se denomina lugar de entrada de una transición T, si existe un arco

orientado de P a T.
• Un nodo lugar P se denomina lugar de salida de una transición T, si existe un arco

orientado de T a P.
2.2 REGLAS DEL COMPORTAMIENTO DINÁMICO DE UNA RED DE PETRI
2.2.1 Marcado de una Red de Petri
Se denomina marcado de un RdP dada al conjunto y disposición de las marcas en toda

la red, en un instante concreto de tiempo. A continuación, se presentan las reglas básicas
acerca del marcado de una RdP, que están totalmente ligadas al comportamiento de ésta
y que nos sirven para poder describir y analizar dicha red en todo instante de tiempo:
• Un nodo lugar posee un número positivo o nulo de marcas.
• Cada marca se representa mediante un punto dentro del nodo lugar

correspondiente.
• El marcado de un RdP se suele representar con un vector M, con tantos elementos

como nodos lugar tenga la red y cuyo componente i-ésimo es el número de marcas
del nodo lugar Pi. En la figura 2.1 se muestra un ejemplo de RdP y a la derecha de
ella, el vector M0 que representa el marcado inicial de dicha red. Se observa como
dicho vector tiene seis elementos, tantos como nodos lugar o circunferencias se
pueden ver en la red. Sólo las posiciones del vector M correspondientes a los
nodos lugar P1 y P4 tienen el valor de 1, que representa que en ambos nodos hay
una marca. El resto de los nodos lugar de la red no contienen ninguna marca, por
lo que el elemento correspondiente en su vector de marcado M vale cero.
P1 P4
t1 Vector de marcado inicial de la red
P2 P5 M0 = [1, 0, 0, 1, 0, 0]T
t2 t4
1 marca en P1 y P4
P3 P6
0 marcas en P2, P3, P5 y P6
t3 t5
Figura 2.1 Ejemplo de marcado de una Red de Petri.
51
Redes de Petri
2.2.2 Propiedades básicas de las transiciones de una Red de Petri
En este apartado vamos a comentar las propiedades más significativas asociadas a las
Redes de Petri (Guasch y col., 2002), las cuales son de gran utilidad a la hora de
representar un modelo de un sistema con este tipo de formalismo.
• Una transición se dice habilitada, sensibilizada o activada, si cada uno de los

nodos lugar de entrada tiene al menos W(Pj,Ti) marcas. Donde W(Pj,Ti)
representa el peso del arco que une el nodo Pj con la transición Ti. Si el arco no
tiene peso asociado se entiende que este peso es uno. Matemáticamente dicha
condición se expresaría como sigue:
M(Pj) ≥ W(Pj,Ti) para todo Pj ∈ E(Ti)
En la figura 2.1 la transición t1 es una transición habilitada, sensibilizada o

activada, porque todos los nodos lugar de entrada que llegan a ella (que son P1 y
P4) tienen una marca y el peso asociado a ambos arcos (el de P1 a t1 y el de P4 a
t1) es también de uno. Por el contrario, en esa misma figura, las transiciones t2, t3,
t4 y t5 no están habilitadas porque los nodos lugar de entrada que llegan a
cualquiera de estas transiciones no tienen marca alguna y los arcos asociados
tienen un peso de valor uno.
• Una transición activada, habilitada o sensibilizada puede dispararse en cualquier

momento.
• En una transición se produce un disparo cuando se quitan en los nodos lugar de

entrada de la transición tantas marcas como marque el arco asociado entre el nodo
correspondiente y la transición, y se añaden en los nodos lugar de salida de la
transición tantas marcas como indiquen los arcos asociados entre ellos. En la
figura 2.1 sólo hay una transición habilitada, o lo que es lo mismo factible de ser
disparada, y ésta es la transición t1 tal y como ya se ha comentado con
anterioridad. Cuando se produce el disparo de esta transición lo que ocurre es que
las marcas de los nodos lugar de entrada a ella, P1 y P4, desaparecen y los nodos
lugar de salida de la transición, P2 y P5, se actualizan incorporando cada uno de
ellos una marca en su interior. El estado de la RdP tras disparar la transición t1
quedaría como se muestra en la figura 2.2.
52
Redes de Petri
P1 P4
t1
Vector de marcado actual de la red
P2 P5
M = [0, 1, 0, 0, 1, 0]T
t2 t4
1 marca en P2 y P5
P3 P6 0 marcas en P1, P3, P4 y P6
t3 t5
Figura 2.2 Ejemplo de marcado de la RdP de la figura 2.1 tras disparar t1.
En la figura 2.3 se muestra un ejemplo práctico de la utilización de las tres reglas

anteriores. En la parte izquierda de la figura se observa una RdP con 4 nodos lugar (P1,
P2, P3 y P4) y un único nodo transición t1. Los nodos lugar P1 y P2, tienen 4 y 2
marcas en su interior respectivamente, y son nodos lugar de entrada a la transición. Los
nodos lugar P3 y P4, tienen 1 y 0 marcas en su interior respectivamente, y son nodos
lugar de salida de la transición. La transición t1 está activada o habilitada, dado que el
nodo lugar P1 contiene 4 marcas y el peso asociado al arco (P1, t1) es 3 (por tanto el
peso del arco es menor que el número de marcas del nodo lugar) y además el número de
marcas del nodo lugar P2 es 2 y el peso asociado a este arco (P2, t1) es 1 (de nuevo el
peso es menor que el número de marcas del nodo lugar seleccionado). Si alguna de las
dos condiciones no se cumpliese, la transición t1 no estaría activada y por lo tanto no se
podría disparar.
P1 P2 P1 P2
3 1 3 1
t1 t1
2 3 2 3
P3 P4 P3 P4
Figura 2.3 Resultado de disparar la transición activada t1.
En la parte derecha de la figura 2.3 se muestra el nuevo estado de la RdP de la izquierda

tras haber disparado en el instante deseado la transición t1. De esta forma y tras el
disparo, los nodos lugar de entrada a la transición, P1 y P2, quedan ambos con una sola
marca en su interior, dado que se han borrado en ellos tantas marcas como el peso
asociado a cada uno de sus arcos de unión con el nodo transición t1 (por tanto del nodo
lugar P1 se han quitado 3 marcas y del nodo lugar P2 se ha quitado una marca). El
hecho de disparar la transición modifica también el número de marcas que han de
contener los nodos lugar de salida, P3 y P4, donde aparecerán 3 marcas en cada uno de
ellos. El número de marcas contenido en cada nodo lugar de salida de la transición se
corresponde con la suma del número de marcas que había en dichos nodos antes de
disparar la transición t1 más el peso del arco que une dicha transición con cada uno de
esos nodos. De esta forma como el nodo lugar P3 tenía una marca y su arco asociado
53
Redes de Petri
tiene un peso de 2, tras el disparo de la transición t1 en el nodo lugar P3 habrá un total

de 3 marcas, tal y como se muestra en la figura 2.3. Del mismo modo, como el nodo
lugar P4 no tenía ninguna marca y el peso asociado a su arco de unión con la transición
t1 es 3, tras disparar la transición el nodo lugar P4 tendrá un total de tres marcas en su
interior.
2.2.3 Evolución y análisis de una Red de Petri
Conocidas tanto las condiciones de marcado de una RdP como las condiciones de
disparo de sus transiciones, lo que nos va a interesar es saber cómo evoluciona, o cómo
es posible que lo haga, una RdP dada. Para describir la evolución del marcado y el
disparo de las transiciones de una RdP dada, se utiliza lo que se conoce como árbol de
cobertura de la RdP, mediante el cual se describe el conjunto de vectores de marcado
por los que pasa la evolución de la red, o lo que es lo mismo, los posibles caminos que
la evolución de la red podría seguir en función de las transiciones factibles de ser
disparadas y disparadas en realidad.
El principal objetivo del estudio de la evolución de una RdP, o lo que es lo mismo, del
análisis del modelo que representa, consiste en determinar su comportamiento
dinámico. Ahora bien, para llevar a cabo un análisis exhaustivo de la red, el cual
permite a su vez verificar y validar el modelo que se está representando con ella, es
imprescindible:
• Determinar los posibles bloqueos del sistema.
• Encontrar los posibles caminos de alcanzar el estado final de la red partiendo del
estado inicial, así como establecer el coste de cada uno de esos posibles caminos.
• Obtener el conjunto de posibles estados a los que se puede llegar a partir del
estado inicial de la red.
Los tres puntos que acabamos de comentar están totalmente relacionados y se deducen
fácilmente de la observación del árbol de cobertura asociado a la RdP objeto de estudio.
La construcción del árbol de cobertura de una RdP dada consiste en determinar el
conjunto de estados o vectores de marcado M a los que se puede acceder desde el estado
o marcado inicial M0, Para lo cual, se establecen las siguientes reglas de construcción
del árbol:
• La raíz del árbol es el vector de marcado inicial de la RdP.
• Para cada uno de los nodos del árbol se generan tantos hijos como transiciones
activadas o sensibilizadas haya. Por lo que los nodos hijos son los vectores de
marcado de la red una vez disparadas las transiciones correspondientes. Los arcos
que conectan un nodo padre con uno hijo se marcan con el nombre de la
transición que se ha disparado.
• Cuando se genera un nodo hijo que ya existe en algún otro nivel anterior del árbol,
se enlaza con él y este camino ya ha terminado.
54
Redes de Petri
Veamos a continuación un ejemplo de la generación del árbol de cobertura de la RdP

mostrada en la figura 2.4.
El marcado inicial de la red propuesta es M0 = [0 1 0]T. El hecho de que el vector de

marcado tenga tres elementos, significa que la RdP objeto de estudio tiene tres nodos
lugar. La información de dicho vector nos dice también el número de marcas que hay en
cada uno de ellos inicialmente, por lo que sabemos que el primer nodo lugar y el tercero
no tienen marcas en su interior y el segundo tiene una marca.
P1
[0, 1, 0 ]
t1
t2
P2
[0, 0, 1 ]
t2
t4
t3
P3
[1, 0, 0 ]
t3 t4
t1
Figura 2.4 Árbol de cobertura de una Red de Petri.
De la observación de figura 2.4, con ese marcado inicial es posible establecer que la
transición t2 está habilitada porque su nodo lugar de entrada P2 tiene una marca y el
arco que une P2 con t2 tiene un peso unidad. El resto de las transiciones de la figura
inicialmente no están habilitadas porque sus nodos de entrada están vacíos y sus arcos
de conexión tienen el peso unidad. Si se dispara la transición t2 lo que se hace es borrar
la marca del nodo lugar P2 y poner una marca en el nodo lugar P3, de esta forma el
vector de marcado quedaría como M = [0 0 1]T. En esta nueva situación hay dos
transiciones posibles de ser disparadas (t3 y t4), aunque sólo una de ellas puede ser
disparada porque el nodo lugar P3 no tiene suficientes marcas para disparar ambas a la
vez. Se presentan pues dos posibles caminos en la RdP, dependiendo de la transición
que se dispare en un momento concreto. Si se dispara la transición t3, el siguiente
marcado de la red sería M = [0 1 0] T = M0, es decir, regresamos al estado de partida.
Por el contrario si se dispara la transición t4 el siguiente marcado de la red sería M = [1
0 0]T. Habiendo disparado t3 hemos vuelto a la posición inicial por lo que la evolución
de la red comenzaría a repetirse, lo que significa que esta rama de la RdP ya está
explorada dado que el comportamiento del sistema se repite. No obstante si se ha
disparado t4, se tiene una nueva situación que no se había tenido hasta ahora. En esa
nueva posición la única transición posible de ser disparada sería t1 y al dispararse
volveríamos también al marcado inicial. Por tanto el árbol de cobertura de la RdP de la
figura 2.4 es el que se muestra en esa misma figura y cuya evolución acabamos de
describir.
Se puede observar que para dar por finalizado el árbol de cobertura se debe llegar a un
punto en el cual regresemos al estado de partida o bien se llegue a una situación donde
55
Redes de Petri
no haya ninguna transición más factible de ser disparada. Si esto último ocurriera,
indicaría problemas en el modelado del sistema objeto de estudio.
Otro ejemplo de árbol de cobertura de una RdP es el que se muestra en la figura 2.5, que
hace referencia a la RdP mostrada en la figura 2.1 y que es algo más complejo que el
que acabamos de describir. La RdP que ahora vamos a analizar consta de 6 nodos lugar,
por lo que su vector de marcado tiene seis componentes. Inicialmente los nodos P1 y P4
tienen una marca y el resto ninguna y los pesos de todos los arcos de conexión entre
lugares y transiciones son la unidad.
A partir del marcado inicial M0 = [1 0 0 1 0 0]T la única transición habilitada es t1, dado
que los dos nodos lugar de entrada a ella tienen una marca, por tanto sólo hay un posible
camino para el árbol. Si se dispara, desaparecen las marcas en P1 y P4 y aparecen
nuevas marcas en P2 y P5, concretamente una en cada nodo. El nuevo marcado sería
M1 = [0 1 0 0 1 0]T. Ahora se pueden disparar dos transiciones, la t2 y la t4. Si se
dispara t2, que representa la rama de la izquierda en la red desaparece la marca de P2 y
se coloca en P3, dando lugar al siguiente vector de marcado M2 = [0 0 1 0 1 0]T. Por el
contrario si se dispara t4 desaparece la marca de P5 y se coloca en P6, dando lugar al
siguiente vector de marcado M3 = [0 1 0 0 0 1]T. De esta forma tenemos representado
hasta el tercer nivel del árbol de cobertura de la figura 2.5.
M0 [1, 0, 0, 1, 0, 0 ]
t1
M1 [0, 1, 0, 0, 1, 0 ] t4
t2
M2 [0, 0, 1, 0, 1, 0 ] M3 [0, 1, 0, 0, 0, 1 ]
t3 t4 t2 t5
M4 [1, 0, 0, 0, 1, 0 ] M5 [0, 0, 1, 0, 0, 1 ] M8 [0, 1, 0, 1, 0, 0 ]

t4 t3 t5 t2
M6 [1, 0, 0, 0, 0, 1 ] M7 [0, 0, 1, 1, 0, 0 ]
t5 t3
Figura 2.5 Árbol de cobertura de la figura 2.1.
A continuación vamos a seguir analizando el comportamiento del sistema siguiendo las

evoluciones de cada rama hasta el final. Partiendo del marcado M2, es posible disparar
dos transiciones, la t3 y la t4. Si se dispara t3 desaparece la marca de P3 y se sitúa en
P1, dando lugar a M4 = [1 0 0 0 1 0]T. Por el contrario, si se dispara t4 partiendo de M2
56
Redes de Petri
se borra la marca que hay en P5 y se coloca una en P6, dando lugar a M5 = [0 0 1 0 0

1]T. En este nuevo nivel desde el marcado M4 sólo se puede disparar la transición t4, lo
que conlleva borrar la marca de P5 y ponerla en P6, dando lugar al siguiente marcado
M6 = [1 0 0 0 0 1]T. En este nuevo estado sólo se puede disparar t5 y si se hace se borra
la marca de P6 y se coloca en P4, volviendo por tanto al estado inicial, por lo que esta
rama ya no tendría mas caminos ni habría que seguir analizándola.
Si continuamos analizando a partir de M5, en esta situación se pueden disparar t3 y t5.

Si se dispara t3 se borra una marca de P3 y se coloca una en P1, llegando al marcado
M6 = [1 0 0 0 0 1]T ya definido. Si por el contrario desde M5 se dispara t5, se borra una
marca de P6 y se coloca una nueva en P4, llegando a un nuevo estado M7 = [0 0 1 1 0
0]T.
A continuación vamos a analizar que ocurre cuando se parte de estos dos nuevos
últimos marcados M6 y M7. En M6 sólo se puede disparar la transición t5 y al hacerlo
llegamos al marcado M0. En M7 sólo se puede disparar la transición t3 y al hacerlo
también llegamos a M0, por lo que hemos agotado estas dos nuevas ramas del árbol.
Volviendo de nuevo al tercer nivel del árbol de cobertura habíamos dejado un marcado
sin explorar que se correspondía con el marcado M3 = [0 1 0 0 0 1]T. En este marcado
hay dos transiciones factibles de disparar t2 y t5. Si se dispara t2 se borra una marca de
P2 y se pone una en P3 llegando de nuevo a M5 = [0 0 1 0 0 1]T, marcado ya definido y
cuya evolución ya se conoce. Si se dispara t5 se borra una marca de P6 y se pone una en
P4 llegando a un nuevo marcado M8 = [0 1 0 1 0 0]T. Estando en este nuevo marcado,
sólo se puede disparar t2 y si se hace se llega de nuevo a M7 = [0 0 1 1 0 0]T, que es
conocido y se conoce su evolución, por lo que el árbol de cobertura de la red estaría
completo.
2.3 CONFIGURACIONES Y PROPIEDADES BÁSICAS DE LAS REDES DE

PETRI
2.3.1 Posibles configuraciones elementales de las Redes de Petri
Existen diferentes configuraciones elementales posibles en una RdP (Guasch y col.,

2002), (http://ttt.upv.es/jldiez/curso_aui), mediante las cuales se puede construir
cualquier red que se desee y que modele el comportamiento de un sistema concreto.
Este hecho representa una de las mayores ventajas de las RdP, dado que permite
representar de forma sencilla los distintos mecanismos que constituyen los procesos
orientados a eventos discretos. Entre estas estructuras elementales cabe destacar las
siguientes:
• Ejecución secuencial: es una estructura lineal que sirve para reflejar la

dependencia causal entre efectos. En la figura 2.6 (a) se muestra una estructura de
este tipo. Se puede ver la secuencialidad de la red en que es necesario disparar la
transición t1 para poder disparar más tarde la transición t2. El hecho de disparar
t1, la única transición habilitada inicialmente, conlleva borrar la marca que hay en
P1 y poner una marca en P2. Este hecho deshabilita la transición t1 y habilita la
t2, la cual pasa a ser factible de ser disparada, y así sucesivamente si la secuencia
lineal continuase.
57
Redes de Petri
P1 P1 (c)
t1
P2 t1 t2
t1 t2
t2
P3 (b)
P1 (d)
(a)
Figura 2.6 Configuraciones elementales de las Redes de Petri.
• Nodo O, se denomina de esta forma a una estructura en la que un nodo lugar tiene
varios arcos de entrada entradas y/o varios arcos de salida. (Ver figura 2.6 (b)).
Este hecho lleva consigo dos posibles configuraciones a su vez:
o Toma de decisiones o Selección, se produce cuando desde un mismo nodo

lugar se pueden activar distintas transiciones, y por lo tanto, el disparo de una
ellas supone la deshabilitación del resto a no ser que el nodo lugar tenga
suficientes marcas como para poder activar varias transiciones a un mismo
tiempo. El proceso debe elegir si es el caso, cuál es la transición que va a
disparar en cada momento de entre las habilitadas. En la figura 2.6 (c) se
muestra la configuración descrita, el nodo lugar P1 puede disparar tanto la
transición t1 como la transición t2 pero debe seleccionar, o decidir, cuál es la
transición que va disparar en un momento determinado. Cuando dispare una de
las dos, la otra quedará sin posibilidad de disparo hasta que se vuelva a marcar
el nodo lugar P1.
o Agrupación o Atribución, se produce cuando distintas transiciones convergen a

un mismo nodo lugar. En la figura 2.6 (d) se muestra este caso. Cualquier
transición, tanto la t1 como la t2 ha podido marcar el nodo lugar P1, dado que
hay dos caminos posibles para marcar este nodo. El hecho de quién la ha
marcado dependerá de la transición que se haya disparado.
• Nodo Y, se denomina de esta forma a una estructura en la que una transición tiene
varios arcos de entrada o varios arcos de salida (ver figura 2.7 (a)). Este tipo de
configuración permite la creación o extinción de las evoluciones simultáneas en
una RdP. Al igual que lo que ocurría con la estructura de Nodo O, esta nueva
configuración presenta dos posibles configuraciones a su vez:
o Concurrencia y Distribución, se produce cuando el disparo de una transición

marca distintos nodos lugar a la vez, dando como resultado la posible
activación de varias transiciones nuevas a un mismo tiempo. Se puede decir
también que dos transiciones son concurrentes, si son causalmente
independientes. En la figura 2.7 (b) se muestra esta configuración, la transición
t1 al ser disparada marca el nodo lugar P1 y el nodo lugar P2 con los pesos
correspondientes a sus arcos de conexión y de esta forma las transiciones t2 y
58
Redes de Petri
t3 son activadas de forma simultánea y podrán ser disparadas a continuación

también de forma simultánea, o no, dependiendo de lo que se desee.
(b)
t1
P1 P2
t2 t3
P1 P2
t1
(a) (c)
Figura 2.7 Configuraciones elementales de la estructura en Nodo Y.
o Conjunción y Sincronización, se plantea cuando varios nodos lugar confluyen

en una misma transición, y por lo tanto, para la activación de esa transición es
preciso el marcado previo, con el peso correspondiente de todos los nodos
lugar de entrada que confluyen en ella. De este modo es preciso sincronizar el
marcado de los nodos lugar de entrada a la transición para poder activar o
habilitar dicha transición y posteriormente dispararla si se desea. Esta
configuración se muestra en la figura 2.7 (c), donde se observa como los nodos
lugar P1 y P2 confluyen en la misma transición t1, la cual necesita que ambos
estén marcados con al menos una marca para poder ser activada. En el caso de
la figura que se muestra la transición t1 aún no está habilitada y por lo tanto no
se puede disparar.
2.3.2 Propiedades básicas de las Redes de Petri
Se dice que una transición de una RdP dada es viva para un marcado M0 inicial, si para
todo marcado M al que se puede acceder a partir del marcado inicial M0, existe un
marcado M’ sucesor de M, a partir del cual se puede disparar esa transición. Como
consecuencia de que una transición sea viva, se dice que una RdP es viva para un
marcado M0 inicial dado, si todas sus transiciones son vivas para ese marcado. Es decir,
para ese marcado M0 inicial dado, si en las posibles evoluciones de la RdP todas las
transiciones que contiene son susceptibles de poder ser disparadas en algún momento.
Por el contrario, se dice que una RdP no es viva, para un marcado M0 inicial dado, si en
las posibles evoluciones de la RdP se llega a una situación en la que no se puede
disparar al menos una de las transiciones que constituyen dicha RdP. Cuando se
producen este tipo de situaciones es posible sospechar que el sistema objeto de estudio
es incorrecto o presenta algún problema de modelado. Simplemente modificando el
marcado inicial de una RdP, ésta puede pasar de ser viva a no serlo y a la inversa.
Una RdP es binaria, si el número máximo de marcas en cada uno de los nodos lugar
que la forman es uno. En una red de este tipo los nodos lugar estarán marcados con una
marca o bien, estarán sin marcar.
59
Redes de Petri
Una RdP es limitada, si el número de marcas en cada uno de los nodos lugar que la
forman no crece indefinidamente. Por el contrario, una RdP es no limitada cuando el
marcado de alguno de sus nodos lugar puede crecer de forma indefinida tras la
activación de una o más de sus transiciones. En general este tipo de redes, al igual que
lo ocurría con las RdP no vivas, suelen responder a modelos incorrectos.
Se dice que dos transiciones simultáneamente habilitadas están o entran en conflicto, si

descienden de un mismo nodo lugar y éste no dispone de marcas suficientes para poder
disparar las dos transiciones simultáneamente. El conflicto se hace efectivo, o se
produce, cuando los eventos asociados a ambas transiciones se verifican
simultáneamente. En la figura 2.8 se muestra un ejemplo de conflicto entre las
transiciones t1 y t2 de la figura. El nodo lugar P2 es de entrada a las dos transiciones de
la figura pero sólo posee una marca por lo que si dispara t1 no puede disparar t2, y a la
inversa, aunque a priori las dos transiciones están habilitadas en el momento que en P2
hay una marca. Se dice entonces que se produce un conflicto entre las transiciones t1 y
t2 si los eventos asociados a ambas se cumplen al mismo tiempo.
P1 P2 P3
t1 t2
Figura 2.8 Ejemplo de conflicto entre dos transiciones.
Teniendo en cuenta la definición general de un RdP dada en el apartado 2.1, una RdP
ordinaria no marcada Q, se define como la siguiente cuádrupla
(http://ttt.upv.es/jldiez/curso_aui):
Q = (P, T, Pre, Post)
Donde:
• Pre: P x T → {0, 1} es la aplicación o función de incidencia de

entrada Pre(Pi, Tj), que vale 1 si hay arco de Pi
a Tj y 0 si no lo hay. Su representación es en
forma matricial.
• Post: T x P → {0, 1} es la aplicación o función de incidencia de

salida Post(Pi, Tj), que vale 1 si hay arco de Tj
a Pi y 0 si no lo hay. Su representación es en
forma matricial.
60
Redes de Petri
Decir que la RdP es ordinaria implica que sus funciones de incidencia sólo pueden
tomar los valores 0 y 1 (De ahí la definición anterior). Y el hecho de que la RdP sea no
marcada implica que no se incluya en su definición el vector de marcado inicial.
A partir de las dos aplicaciones o funciones de incidencia de entrada y salida que

forman parte de la definición de la red, se puede definir lo que se conoce como la matriz
de incidencia U de una RdP ordinaria de la siguiente manera:
U = Post (P,T) – Pre (P,T)
La matriz U definida tiene el mismo significado que la matriz A de incidencia de una

RdP general (definida en el apartado 2.1), sólo que particularizada para el caso de una
RdP ordinaria. De esta forma, la matriz de incidencia de la RdP ordinaria está
representada por una matriz cuyos elementos serán siempre 1’s, 0’s o –1’s, los cuales
nos dan información acerca de los arcos de conexión que constituyen la RdP. La
información de la matriz de incidencia se distribuye de forma que las filas hacen
referencia a los nodos lugar P y las columnas a los nodos transición t. De esta manera se
sabe que:
• Si el elemento Uij de la matriz de incidencia es igual a cero, significa que no

existe ningún tipo de conexión entre el nodo lugar Pi y el nodo transición tj.
• Si el elemento Uij de la matriz de incidencia es igual a uno, significa que existe un

arco de conexión dirigido desde el nodo transición tj al nodo lugar Pi.
• Si el elemento Uij de la matriz de incidencia es igual a menos uno, significa que

existe un arco de conexión dirigido desde el nodo lugar Pi al nodo transición tj.
La figura 2.9 muestra un ejemplo de una RdP ordinaria no marcada y su matriz de

incidencia U. Analizando dicha RdP se puede determinar el valor de la matriz de
incidencia asociada a ella. Por ejemplo es sencillo establecer en función de la
observación de la figura 2.9 que sólo los elementos de la función de incidencia de
entrada Pre(P1,t1), Pre(P4,t1), Pre(P2,t2), Pre(P5,t4), Pre(P3,t3), Pre(P6,t5), y de la
función de incidencia de salida Post(P1,t3), Post(P4,t5), Post(P2,t1), Post(P5,t1),
Post(P3,t2), Post(P6,t4) son iguales a 1 (dado que representan los únicos arcos de
conexión que se tienen en la red). Y que el resto de los elementos de las funciones de
incidencia de entrada y salida de dicha red son iguales a 0. En función de estos valores
es sencillo calcular la representación de la matriz de incidencia asociada a la RdP de la
figura que quedaría tal como se muestra en la parte derecha de la citada figura 2.9.
61
Redes de Petri
t1 t2 t3 t4 t5
P1 P4
-1 0 1 0 0 P1
t1
1 -1 0 0 0 P2
P2 P5
U= 0 1 -1 0 0 P3
t2 t4 -1 0 0 0 1 P4
1 0 0 -1 0 P5
P3 P6
0 0 0 1 -1 P6
t3 t5
t1 t2 t3 t4 t5 t1 t2 t3 t4 t5
0 0 1 0 0 P1 1 0 0 0 0 P1
1 0 0 0 0 P2 0 1 0 0 0 P2
Post =
0 1 0 0 0 P3 Pre = 0 0 1 0 0 P3
0 0 0 0 1 P4 1 0 0 0 0 P4
1 0 0 0 0 P5 0 0 0 1 0 P5
0 0 0 1 0 P6 0 0 0 0 1 P6
Figura 2.9 Ejemplo de una RdP ordinaria no marcada y su matriz de incidencia asociada.
Del análisis de la matriz de incidencia de una RdP, se puede establecer también cuál es
el comportamiento dinámico o evolución de la red. Por ejemplo mirando la matriz de
incidencia de la figura 2.9 podemos establecer que es lo que pasa cuando se dispara una
transición cualquiera, suponiendo por supuesto que dicha transición estuviese
habilitada. Si por ejemplo se dispara la transición t2, para ver que es lo que ocurriría en
la red debemos mirar la segunda columna de la matriz de incidencia donde vemos que la
fila correspondiente a P2 lleva asociado un –1 y la correspondiente a P3 un 1. El resto
de las filas de esa columna tienen un valor de 0. Lo que me están indicando estos
valores es que se debe quitar una marca en el nodo lugar P2 y poner una marca en el
nodo lugar P3 si se dispara la transición t2, el resto de los nodos lugar de la red ante este
disparo no varían dado que no guardan relación alguna con la transición disparada tal y
como informa la matriz de incidencia asociada a la red. Si se observa el dibujo de la red
se ve que efectivamente eso es lo que debería ocurrir.
Si se analiza cualquier otra columna de la matriz de incidencia, por ejemplo la quinta,

que representa el disparo de la transición t5, lo que debe ocurrir tras su disparo caso de
estar habilitada es que se ponga una marca en el nodo lugar P4 y se quite una en el nodo
lugar P6. El resto de los nodos lugar no sufren modificación alguna. Se puede concluir
por tanto, que la evolución de una RdP, además de con el árbol de cobertura, también se
puede analizar con la matriz de incidencia.
62
Redes de Petri
Una RdP ordinaria y marcada R se define en función de la RdP ordinaria y no marcada

como sigue:
R = <Q, M0>
Donde:
• Q es una RdP ordinaria no marcada, tal y como la definida previamente.
• M0 es el marcado inicial de la RdP.
Si definimos ‘s’ como el vector característico, cuyo componente j-ésimo contiene el

número de veces que se dispara una transición ti dada, la ecuación fundamental de una
RdP ordinaria y marcada viene expresada como sigue:
Mk = M0 + U s
El vector Mk lo que hace es describir la evolución del marcado de la red, en función de

las transiciones que se van disparando en la misma. Observación: la ecuación
fundamental sólo dará resultados coherentes si el vector característico es factible para
ese marcado inicial. Por tanto valores negativos en el vector Mk indicará que esas
transiciones no se pueden disparar.
Veamos un ejemplo de ello, utilizando la RdP de la figura 2.9 e imponiendo el siguiente

vector de marcado inicial M0 = [0 0 1 1 0 0]T y el siguiente vector de actuación de la red
o vector característico s = [1 1 2 0 0]T.
Lo que estamos indicando con el vector de marcado es que en la citada red inicialmente
sólo los nodos lugar P3 y P4 tendrán una marca y el resto tendrán cero marcas. Por otro
lado, con la información del vector característico se está estableciendo que a lo largo de
la evolución de la red que se quiere analizar se va a disparar a una vez la transición t1,
una vez la transición t2 y dos veces la transición t3. El resto de las transiciones no se
dispararán nunca. Por tanto utilizando la formulación que acabamos de definir, la
ecuación fundamental, que representa la evolución de la RdP de la figura 2.9 para ese
vector de marcado inicial y la secuencia de disparos representada en el vector
característico, quedaría como sigue:
0  - 1 0 1 0 0 1
0   1 1   
   -1 0 0 0   1  0 
1   0 1 -1 0 0   0 
 +   2 =  
1   - 1 0 0 0 1   0 
0   1 0 0 -1 0 0 1
    0  
0  0 0 0 1 - 1 0
El vector columna de la derecha representa el vector de marcado final Mk después de

haber disparado 1 vez la transición t1, otra la t2 y otras 2 la transición t3 en el orden en
el que sea factible en función de las marcas que en cada momento haya en la red y
teniendo en cuenta el marcado inicial propuesto M0. La matriz central representa la
matriz de incidencia de la red anteriormente calculada.
63
Redes de Petri
Si analizamos la evolución de la figura 2.9 paso a paso, se ve que efectivamente se llega

a esa situación. Con el marcado inicial que se propone M0 = [0 0 1 1 0 0]T, la única
transición habilitada y factible de ser disparada es la transición t3. Por tanto se debe
disparar por primera vez t3 para iniciar la secuencia propuesta. Tras el disparo se
obtiene el siguiente vector de marcado M1 = [1 0 0 1 0 0] T. En este momento, la única
transición habilitada es la transición t1, que forma parte de la secuencia de disparos del
vector característico. Por tanto se dispara la citada transición y se obtiene el siguiente
vector de marcado M2 = [0 1 0 0 1 0] T. En este punto están habilitadas tanto la
transición t2 como la transición t4, pero conociendo el vector característico que se
propone, la transición que debe ser disparada es la transición t2. Si se dispara dicha
transición se obtiene el siguiente vector de marcado M3 = [0 0 1 0 1 0] T. Con este
nuevo marcado, de nuevo hay dos transiciones habilitadas que son la t3 y la t4, pero
igual que antes a partir del conocimiento del vector característico propuesto, la
transición que debe ser disparada es la transición t3. De esta forma, si se realiza este
último disparo ya se han cumplido todos los disparos que se requerían en el vector
característico del enunciado. Disparando la transición t3 se obtiene el siguiente vector
de marcado final M4 = [1 0 0 0 1 0] T, que por supuesto coincide con el que se ha
obtenido mediante la ecuación fundamental de las Redes de Petri.
2.4 CONCURRENCIA Y SINCRONIZACION
Dos conceptos fundamentales relacionados básicamente con la evolución de las RdP,

que ya han sido mencionados al hablar de las posibles configuraciones que pueden
presentar las RdP son los conceptos de concurrencia y sincronización. Ambos
conceptos convierten a las RdP en uno de los formalismos de representación de eventos
discretos más importantes que existen, debido a que sólo con el formalismo de RdP es
posible representar de manera formal estos conceptos (Silva, 1985).
ts
P1 Pn+1
Pn Pn+m
tt
Figura 2.10 Ejemplo de concurrencia.
Tal y como ya se comentó anteriormente, se dice que dos transiciones de una RdP son
concurrentes si son casualmente independientes. En la figura 2.10 se muestra un
ejemplo de dos transiciones concurrente dentro de una misma red. Se ve en ella como el
disparo de la transición ts conlleva el marcado de los nodos lugar P1 y Pn+1. Otro
concepto relacionado con el de concurrencia es el de evolución concurrente, cuyo
ejemplo se muestra también en la figura 2.10. Las dos transiciones de la red que se
representan tienen evoluciones concurrentes entre ellas, por un lado está el camino que
se recorre desde P1 a Pn y por otro el que se recorre de Pn+1 a Pn+m. Lo único que
64
Redes de Petri
sabemos con certeza de la evolución de la red, es que la transición tt no podrá ser

disparada hasta que no estén marcados a un mismo tiempo los nodos lugar Pn y Pn+m.
La sincronización implica el disparo de dos o más transiciones independientes al

mismo tiempo. En la figura 2.11 se muestra un ejemplo de ello, para que la transición tt
pueda ser activada y posteriormente disparada deben de estar marcados tanto el nodo
lugar Pi como el Pk, para lo cual si el disparo se desea en un momento concreto se habrá
de sincronizar el marcado de dichos nodos. Eso sí, una vez activada tt si se produce el
disparo la activación y marcado de los nodos lugar Pj y Pl se realiza al mismo tiempo,
es decir, simultáneamente.
Pi Pk
tt
Pj Pl
Figura 2.11 Ejemplo de sincronización.
En los ejemplos mostrados hasta el momento, los conceptos de concurrencia y

sincronización se presentan de forma independiente. Ahora bien, es posible que en una
RdP dada ambos conceptos aparezcan de forma conjunta llegando así a la necesidad de
compartir recursos. Tal es el caso de lo que ocurre en la figura 2.12, donde ti y tk están
habilitadas debido a que el nodo lugar Pr tiene una marca, no obstante no se podrán
disparar ambas transiciones a un mismo tiempo mientras en dicho nodo lugar sólo haya
una marca, por lo que sólo se puede utilizar un recurso.
ti tk
Pr
tj tl
Figura 2.12 Ejemplo de compartición de recursos.
2.5 EXTENSIONES DE LAS REDES DE PETRI
2.5.1 Redes de Petri Interpretadas
Veamos a continuación el concepto de las RdP interpretadas aplicándola al ejemplo del

“carro que va y viene”, presentado en el apartado 1.5.4. La RdP asociada a este sistema
podría ser tal como la mostrada en la figura 2.13, con su árbol de cobertura asociado.
La interpretación de la red sería la siguiente: Se tienen tres estados, un estado de parada

representado por el nodo lugar P1, un estado de movimiento hacia la derecha
representado por el nodo lugar P2 y un estado de movimiento hacia la izquierda
representado por el nodo lugar P3. Inicialmente el carro está en reposo en el extremo A,
65
Redes de Petri
como indica la marca en el nodo P1, hasta que se pulsa el botón (P) y
consiguientemente se dispara la transición t1, haciendo que el carro se mueva hacia la
derecha. El nodo lugar P2 al que se ha llegado representa el movimiento hacia la
derecha que no cesa hasta llegar al extremo B. La llegada a B se representa con el
disparo de la transición t2 de la red, provocando el cambio de sentido, ahora el carro se
moverá camino de A, o sea, hacia la izquierda. El movimiento hacia la izquierda se
representa con el nodo lugar P3, el cual puede habilitar dos transiciones distintas. La
transición t3 representa que el carro sigue en movimiento porque ha llegado a A estando
el botón pulsado, o sea que va al nodo lugar P2. La transición t4 indica que el carro ha
llegado a A pero como el botón no está pulsado, regresa al estado inicial.
P1
P t1 [1, 0, 0 ]Reposo
t1
P2
[0, 1, 0 ]Derecha
t2
B t2
[0, 0, 1 ]Izquierda
P3
t3 t4
P-A t3 P-A t4
Figura 2.13 Ejemplo de una RdP interpretada.
2.5.2 Redes de Petri Coloreadas
Las RdP son una herramienta de modelado que ofrece el formalismo necesario para
representar tanto el estado de cada uno de los componentes que constituyen el sistema
como la secuencia de eventos que se pueden desencadenar a partir de cada estado del
sistema. No obstante, las RdP no permiten especificar el flujo de información que suele
reflejarse mediante datos asignados a entidades cuyos valores cambian en función de los
eventos que aparecen. Estas entidades en las RdP coloreadas se reflejarían como marcas
de distintos colores en los correspondientes nodos lugar de la red.
Las RdP coloreadas permiten construir modelos más compactos y paramétricos, lo que
facilita considerablemente su mantenimiento y su posterior codificación. Estos modelos
requerirían de estructuras con un número elevado de componentes si fueran
desarrollados con el formalismo de las RdP (Guasch y col., 2002).
La principal diferencia que aportan las RdP coloreadas frente a las RdP ordinarias es la
capacidad de asociar a cada marca de un nodo lugar un tipo de datos concreto
denominado color de la marca. El uso de colores en las RdP es equivalente al uso de
distintos tipos de datos en los lenguajes de programación, lo cual dota a las RdP
coloreadas de la potencia necesaria para formalizar el modelo de cualquier sistema, por
complejo que éste sea. Matemáticamente, una RdP coloreada puede definirse a partir de
la siguiente tupla:
66
Redes de Petri
RdPC = (∑, P,T,A, N, C, G, E, I)
Donde:
• ∑ = {C1, C2, ...., Cn} es el conjunto finito y no vacío de colores. Con ellos
se permite especificar los atributos que deben
definirse para cada tipo de entidad (tipo de datos en
los lenguajes de programación).
• A = {A1, A2, .., An} es el conjunto de arcos de la red.
• N función nodo, N(Ai), que asocia a cada arco sus

nodos terminales (origen y destino). Ambos nodos
han de ser diferentes, es decir, si uno es un nodo
transición el otro es un nodo lugar y a la inversa.
• C conjunto de funciones color C(Pi), que asocia a cada

nodo lugar el color de marcas que le corresponde y
los distintos valores posibles de ese color.
• G función guarda asociada a los nodos tipos transición

G(Ti), se suele utilizar para desinhibir el evento
asociado a la transición en función de los valores de
los colores de las distintas marcas de los nodos lugar
de la red que se quiere procesar.
• E expresiones asociadas a los arcos E(Ai), que

especifican los valores de los colores asociados a las
distintas marcas del nodo lugar de entrada a la
transición que debe escogerse de entre las posibles
marcas (entidades) almacenadas en el nodo lugar
para habilitar el evento.
• I función de inicialización I(Pi), que especifica los

valores de los colores de las marcas inicialmente
almacenadas en los nodos lugar.
Ahora bien para complementar la definición anterior es necesario explicar algunas

cosas, tales como:
• El estado inicial de la red se determina ejecutando las expresiones de

inicialización asociadas a cada nodo lugar, las cuales determinan el número de
marcas en cada nodo y también los valores de los colores de las marcas. Por lo
tanto, este tipo de expresiones permiten obtener el marcado inicial M0.
67
Redes de Petri
• Los colores de las marcas pueden ser inspeccionados mediante las expresiones de
arco de llegada a las transiciones, lo que permite activarlas no sólo en función del
número de marcas en los nodos lugar de entrada a las transiciones sino en función
del color de las marcas disponibles en dichos nodos lugar. Al mismo tiempo estas
expresiones modelan también los efectos de salida de la transición modificando
los colores de las marcas de los nodos lugar de salida.
• Las guardas son muy similares a las expresiones de arco, aunque son expresiones
booleanas que imponen ciertos valores a los colores de las marcas, que pueden ser
seleccionados para activar una transición dada.
• Cada nodo lugar sólo podrá tener marcas de un mismo color o tipo de entidad.
• Las técnicas de análisis presentadas para las RdP siguen siendo válidas, aunque
ahora los vectores de marcado además del número de marcas en cada nodo,
necesitan los distintos valores de los colores de cada una de las marcas.
Quizás la ventaja más destacable de las RdP coloreadas es que como las expresiones de
arco permiten parametrizar las transiciones, éstas se pueden codificar para representar
de forma sencilla una clase de eventos en lugar de uno único como ocurría con las RdP
convencionales. Algunos ejemplos representativos del uso de las RdP coloreadas se
pueden encontrar en el libro de (Guasch y col., 2002).
2.5.3 Consideraciones del modelado con RdP
Las RdP representan una herramienta de modelado independiente de cualquier

tecnología, clara, fácil de utilizar y no ambigua, que comprende los conceptos básicos
de receptividad y sensibilidad, por los cuales es posible obtener descripciones de los
sistemas a modelar con un mínimo de información conocida y suficiente para
sintetizarlos. Además las RdP son ideales como metodología de modelado para capturar
las relaciones causales y de precedencia entre eventos y situaciones, es decir, facilitan la
representación de evoluciones simultáneas, las cuales son algo clave a la hora de
modelar y simular el comportamiento de un sistema dado.
La especificación de un modelo orientado a eventos discretos usando el formalismo de

las RdP permite obtener información del sistema, tanto si se analiza el comportamiento
de la red como si se estudia su estructura. Aunque a lo largo de este capítulo se han
introducido algunas técnicas de análisis de las RdP realmente el análisis del
funcionamiento del sistema se suele hacer mediante simulación, por lo que dicho
comportamiento se obtendrá a partir de la evolución del estado del sistema mediante un
simulador orientado a eventos discretos. No obstante, las RdP permiten dar una primera
aproximación al problema de validación del correcto funcionamiento del sistema, a
través del conocimiento de la estructura y del marcado de la red.
La formalización con RdP permite representar de forma muy natural clientes o

peticiones, recursos y procesos como marcas situadas en los distintos nodos lugar.
Ahora bien esta generalidad tiene el inconveniente de no disponer de símbolos
especiales para las distintas entidades, lo que conlleva en algunos casos a una difícil
interpretación de la red.
68
Redes de Petri
Otra característica importante de las RdP es que con ellas se puede formalizar cualquier
tipo de sincronización de forma muy básica, tal y como se ha comentado con
anterioridad, representando esto una de las mayores ventajas del formalismo.
Por último comentar que las RdP coloreadas reducen la dimensión del modelo porque
aumentan su abstracción, permitiendo que las marcas lleven asociada una información
que hemos denominado color.
En resumen, las RdP son muy útiles, fundamentalmente porque:
• Representan de forma explícita los estados y eventos del modelo.
• Los fenómenos de concurrencia, sincronismo y dependencia causal se representan

de forma muy sencilla.
• El conjunto de recursos restringidos se representa de forma explícita en el modelo.
• Hay muy pocas reglas, lo que facilita su aprendizaje.
• Su representación gráfica es muy intuitiva.
• Su semántica es precisa y sin ambigüedades.
• Es independiente de la herramienta de simulación que se emplee.
69
Redes de Petri
EJERCICIO 2.1
a) Construir la RdP de un proceso que modele el encendido y apagado de una lámpara.

Supóngase que inicialmente la lámpara está apagada y que tras el pulsado de un
interruptor se enciende. En este estado permanecerá hasta que se pulse de nuevo el
interruptor y pase a la situación de apagada y así sucesivamente.
b) ¿Serviría la RdP construida en el apartado (a), para modelar el encendido y

apagado de una lámpara bajo el supuesto de que inicialmente la lámpara estuviera
encendida?
El comportamiento de la lámpara se puede modelar con dos estados que nos indiquen
cuando la lámpara en cuestión se encuentra encendida o apagada. Cada uno de estos
estados estaría asociado a las distintas actividades que la RdP puede llevar a cabo. Por
otro lado, los eventos que vamos a representar en la red irán asociados a las distintas
pulsaciones del interruptor que enciende y apaga la lámpara. La RdP asociada es la que
se muestra en la figura 2.14.
P1: Estado que representa que la lámpara está apagada.

P1
P2: Estado que representa que la lámpara está encendida.
t1
t1: Evento de pulsar el interruptor en dirección de encendido.
P2
t2: Evento de pulsar en interruptor en dirección de apagado.
t2
Figura 2.14 Red de Petri solución del ejercicio 2.1.
En respuesta al apartado (b) del ejercicio, se puede decir que efectivamente la RdP
mostrada como solución del apartado (a) en la figura 2.14, también sería válida para este
apartado. No obstante, si inicialmente se considera que la lámpara está encendida en
lugar de apagada, la RdP que representa el comportamiento sería la misma sólo que P1
tendría el significado de P2 y a la inversa, y lo mismo para las transiciones.
Otra forma de resolverlo es simplemente teniendo en cuenta que serviría la misma red,
basta que inicialmente se tuviese el marcado inicial [0 1]T, en lugar del marcado inicial
[1 0]T que es el que se muestra en la figura 2.14. La RdP funcionaría de la misma
manera que antes, de encendida pasaría a apagada y a la inversa, según las pulsaciones
del interruptor.
EJERCICIO 2.2
a) Construir la RdP de un sistema que modele el encendido y apagado de una lámpara

como la del ejercicio 2.1, sólo que ahora se debe permitir la posibilidad de poder
conectar el sistema desde un agente externo.
70
Redes de Petri
b) Ampliar dicha RdP permitiendo también la desconexión del sistema desde un agente
externo.
c) Comprobar el funcionamiento de la última RdP modelada mediante su árbol de

cobertura, considerando como marcado inicial la puesta en marcha del sistema.
Considerando la RdP solución del ejercicio anterior (ver figura 2.14), la posibilidad de
que el sistema de encendido y apagado de la lámpara se pudiese conectar desde un
agente externo trae consigo la necesidad de un nuevo estado en la RdP (un nuevo estado
inicial), que implemente esta función.
La RdP resultante es la que se muestra en la figura 2.15. Dicha RdP incorpora un nuevo
estado y una nueva transición para representar al agente externo de conexión del
sistema. El resto de estados (P2 y P3), y de transiciones (t2 y t3) son las mismas del
ejercicio anterior, aunque con distinta numeración.
P1 P1: Estado inicial, que representa la espera para la puesta en

marcha del sistema.
t1
P2: Estado que representa que la lámpara está apagada.
P2 P3: Estado que representa que la lámpara está encendida.
t2 t1: Evento de conexión del sistema.
P3 t2: Evento de pulsar el interruptor en dirección de encendido.
t3
t3: Evento de pulsar en interruptor en dirección de apagado.
Considerando la propuesta del apartado (b) del ejercicio hace que la RdP se complique
aún más. Se trata de permitir que la RdP mostrada en la figura 2.15 regrese al estado P1
en lugar de a P2, una vez que se ha realizado el primer ciclo de apagado y encendido de
la lámpara. La RdP asociada sería entonces la mostrada en la figura 2.16. Tanto los
estados P1, P2 y P3 como las transiciones t1, t2 y t3 tienen exactamente el mismo
significado que en la red de la fiura 2.15. La única diferencia que aporta la red solución
de este apartado, figura 2.16, es la incorporación de la transición t4, que sólo debe ser
disparada cuando se desee desconectar el sistema. No obstante, la RdP de la figura 2.16
presenta la limitación de que sólo se puede desconectar cuando la lámpara está
encendida.
71
Redes de Petri
P1
t1
P2
t2
P3
t3 t4
Figura 2.16 Red de Petri solución del ejercicio 2.2.b
Si se quisiese que la lámpara también fuera posible desconectarla cuando está apagada,
la secuencialidad de P2 a P3 debe romperse y P2 debe presentar dos caminos de salida.
Por un lado el actual, de P2 a P3 disparando t2 (pulsado del interruptor en dirección de
encendido) y por otro lado el camino de P2 a P1 disparando una nueva transición t5,
cuya funcionalidad es la misma que la de la transición t4. Con esta consideración se
propone la siguiente RdP como solución al apartado (b) del ejercicio, mostrada en la
figura 2.17.
P1
t1
P2
t2 t5
P3
t3 t4
Figura 2.17 Red de Petri solución completa del ejercicio 2.2.b.
En respuesta al apartado (c) del ejercicio partimos de la RdP presentada en la figura

2.17, con el marcado inicial M0 = [1 0 0]T, que es el único marcado capaz de inicializar
la red. El árbol de cobertura que describe su comportamiento es el que se muestra en la
figura 2.18. Partiendo del marcado inicial sólo es posible disparar t1, con lo que se llega
a M1 = [0 1 0]T. A partir de ahí se puede disparar la transición t5 para desconectar la red
y volver por tanto al marcado inicial, o disparar la transición t2 cuyo propósito es
encender la lámpara, por lo que siguiendo este camino se llega al vector de marcado M2
= [0 0 1]T. Una vez en esta situación se puede, o apagar de nuevo la lámpara disparando
la transición t3, obteniendo el marcado M1, o desconectar el sistema volviendo al estado
inicial de puesta en marcha, de forma que el vector de marcado sería de nuevo M0, para
lo cual se debe disparar la transición t4. El árbol de cobertura de esta forma estaría
completamente analizado.
72
Redes de Petri
[1, 0, 0 ]
t1
[0, 1, 0 ]
t2
t5
[0, 0, 1 ]
t3 t4
Figura 2.18 Árbol de cobertura de la RdP de la figura 2.17.
EJERCICIO 2.3
Construir la RdP de un proceso que modele el comportamiento de un semáforo.

Supóngase que inicialmente el semáforo está en verde y que mediante transiciones de
eventos temporizadas pasa a ámbar y de ahí a rojo, cerrando el ciclo y regresando de
nuevo al verde.
El comportamiento del sistema que queremos modelar es muy similar al del ejercicio
anterior. La diferencia fundamental está en el número de estados del sistema que ahora,
en lugar de los dos anteriores (encendido -- apagado) son tres (verde – ámbar – rojo).
Pero además, el evento que produce el cambio de color en el semáforo no es una acción
externa como antes sino que es temporizada. Cuando se incluyen este tipo de eventos en
las RdP, a estas se las suele denominar RdP temporizadas. La RdP solución del
ejercicio será la que se muestra en la figura 2.19.
P1 P1: Estado que representa que el semáforo está en verde.
t1 P2: Estado que representa que el semáforo está en ámbar.
P3: Estado que representa que el semáforo está en rojo.

P2
t1: Evento temporizado que pasa el semáforo de verde a ámbar.

t2
t2: Evento temporizado que pasa el semáforo de ámbar a rojo.

P3
t3
t3: Evento temporizado que pasa el semáforo de rojo a verde.
Al igual que ocurría en el ejemplo de la lámpara se puede incluir en el proceso un

estado inicial de partida que represente que el semáforo está desconectado y que
inicialmente se conecta mediante un interruptor. De esta forma, se necesitaría un estado
más P0 colocado por encima de P1 y del que sólo se saldría pulsando este interruptor.
La pulsación del interruptor vendría representada por una transición t0 que tras
73
Redes de Petri
dispararse llegaría al nodo lugar P1, y ya el resto de la red sería el mismo que acabamos
de representar y comentar.
También del mismo modo que en la lámpara es posible permitir en un momento

determinado la desconexión del semáforo. Para ello cuando se cierre un ciclo de
colores, es decir a la salida de P3 se deben colocar dos transiciones factibles de
dispararse. Una de ellas t3, cuyo significado es que el semáforo continúa en
funcionamiento y se pone de nuevo en verde, y otra que representaríamos por ejemplo
con t4 y que debería dispararse cuando se desease regresar al estado P0 de desconexión
del semáforo. No obstante, y del mismo modo que en el ejercicio 2.2.b se puede
permitir la desconexión del semáforo en cualquier punto, por lo que a la salida de P1,
P2 y P3 se tendrían dos posibles caminos, uno de ellos el actual y otro que fuese al
estado de conexión / desconexión.
EJERCICIO 2.4
a) Construir la RdP de un proceso que modele la regulación de un cruce con dos

semáforos. Se ha de tener en cuenta que cuando uno de ellos esté abierto el otro debe
de estar cerrado y a la inversa. Supongamos que inicialmente el semáforo 1 está en
verde y el semáforo 2 está en rojo.
b) Construir el árbol de cobertura partiendo de la situación inicial comentada en el

apartado (a).
Evidentemente en la resolución del apartado (a) de este problema se han de conjugar

dos ciclos de colores de un semáforo convencional como el representado en el ejercicio
2.3 (ver figura 2.19). Por tanto, un ciclo de colores para cada uno de los dos semáforos
que componen el cruce. Por ello una posible RdP solución de este problema podría ser
la que se muestra en la figura 2.20. En ella los tres primeros estados tienen el mismo
significado que en el ejercicio anterior y los tres siguientes son idénticos a los tres
primeros pero referidos al segundo semáforo.
P1: Estado que representa que el semáforo 1 está en verde.
P2: Estado que representa que el semáforo 1 está en ámbar.
P3: Estado que representa que el semáforo 1 está rojo.
P4: Estado que representa que el semáforo 2 está en verde.
P5: Estado que representa que el semáforo 2 está en ámbar.
P6: Estado que representa que el semáforo 2 está rojo.
74
Redes de Petri
P1 P6
t1
P2
t2
P3 P4
t3
P5
t4
t1: Evento temporizado que representa el paso de verde a ámbar.
t2: Evento temporizado que representa el paso simultáneo de ámbar a rojo en el

semáforo 1 y de rojo a verde en el semáforo 2. Para que la transición se dispare se deben
cumplir ambas cosas, que el semáforo 1 esté en ámbar y que el 2 esté en rojo.
t3: Evento temporizado que representa el paso del semáforo 2 de verde a ámbar.
t4: Evento temporizado que representa el paso del semáforo 2 de ámbar a rojo y el del
semáforo 1 de rojo a verde. Para que la transición se dispare se deben cumplir ambas
cosas, que el semáforo 2 esté en ámbar y que el 1 esté en rojo.
La RdP propuesta (veasé figura 2.20) simula el cruce de dos semáforos con cambio de
colores simultáneo entre los dos semáforos, de forma que cuando uno pasa a estado de
color rojo, el otro pasa automáticamente a color verde. En un cruce real esto no debe
hacerse así, sino que durante un periodo de tiempo breve los dos semáforos deben
permanecer en rojo para evitar choques entre los coches que están cruzando y los que
van a cruzar. Vea el ejercicio 1.6.
Este problema no se presenta en la siguiente RdP (veasé figura 2.21) donde la transición
t2 se ha desglosado en dos transiciones (t21 y t22) y el estado P3, que representaba la
permanencia del primer semáforo en rojo, también se ha descompuesto en otros dos
(P31, P32). A continuación se comentan los nuevos estados y transiciones de la RdP de
la figura 2.21 que no existen en la anterior RdP mostrada (figura 2.20):
P31: Estado que representa que el semáforo 1 está rojo y al cual sólo se accede cuando
también está en rojo el semáforo 2.
75
Redes de Petri
P32: Estado que representa la permanencia en rojo del semáforo 1 mientras el semáforo
2 realiza el ciclo de colores.
P1 P62
t1
P2
t21
P31
t22
P32 P4
t3
P5
t41
P61
t42
Figura 2.21 Red de Petri solución ampliada del ejercicio 2.4.
t21: Evento temporizado que representa el paso de ámbar a rojo en el semáforo 1.
t22: Evento temporizado que representa el paso de rojo a verde en el semáforo 2 y la

permanencia en rojo del semáforo 1. Por ello, para que la transición se dispare se debe
cumplir que los dos semáforos estén en rojo durante un periodo de tiempo de forma
simultánea, que es controlado por la transición.
De forma análoga para el ciclo del segundo semáforo, la transición t4 se ha desglosado

en 2 transiciones (t41, t42) y el estado P6 en dos estados (P61, P62), cuyos significados
se comentan a continuación:
P61: Estado que representa que el semáforo 2 está rojo y al cual sólo se accede cuando
también está en rojo el semáforo 1.
P62: Estado que representa la permanencia en rojo del semáforo 2 mientras el semáforo
1 realiza el ciclo de colores.
t41: Evento temporizado que representa el paso de ámbar a rojo en el semáforo 2.
76
Redes de Petri
t42: Evento temporizado que representa el paso de rojo a verde en el semáforo 1 y la

permanencia en rojo del semáforo 2. Por ello, para que la transición se dispare se debe
cumplir que los dos semáforos estén en rojo durante un periodo de tiempo de forma
simultánea que es controlado por la transición.
El resto de transiciones y estados tienen el mismo significado que en la RdP mostrada

en la figura 2.20.
En relación con el árbol de cobertura pedido en el apartado (b) del ejercicio vamos a
hacer el de esta última RdP (figura 2.21), que es más completa que la anterior (figura
2.20). El marcado inicial responde a la situación de que el primer semáforo está en
verde (nodo lugar P1 con una marca) y el segundo semáforo está en rojo. Teniendo en
cuenta la diferenciación de rojos que se ha hecho para el modelo de la red, el rojo inicial
del segundo semáforo debe ser un rojo permanente que permita que el primer semáforo
lleve a cabo su ciclo de colores, por tanto el nodo lugar P62 debe ser marcado. El resto
de los nodos lugar que componen la red estarán sin marcar. Por tanto, si M = [P1 P2
P31 P32 P4 P5 P61 P62]T representa el vector de marcado, M0 = [1 0 0 0 0 0 0 1]T
es el marcado inicial. El árbol de cobertura de la red es el que se muestra en la figura
2.22.
[1, 0, 0, 0, 0, 0, 0, 1]
t1
[0, 1, 0, 0, 0, 0, 0, 1]
t21
[0, 0, 1, 0, 0, 0, 0, 1]
t22
[0, 0, 0, 1, 1, 0, 0, 0]
t3
[0, 0, 0, 1, 0, 1, 0, 0]
t41
[0, 0, 0, 1, 0, 0, 1, 0]
t42
Figura 2.22 Árbol de cobertura de Red de Petri solución ampliada del ejercicio 2.4.
Como se puede observar en el árbol de cobertura, el comportamiento de la red es

totalmente lineal. Los cuatro primeros elementos del vector describen el
comportamiento del primer semáforo y los cuatro últimos los del segundo semáforo.
77
Redes de Petri
EJERCICIO 2.5
Construir una RdP que modele el comportamiento de un semáforo que incluye

pulsador de peatones. Se debe tener en cuenta que el semáforo en este caso,
permanecerá en posición de verde hasta que un peatón pulse el interruptor para pasar.
De esta forma, se genera un ciclo en el cual el semáforo pasará a las fases de ámbar y
rojo para permitir el paso del peatón. Inicialmente supóngase que el semáforo está
desconectado y permítase también la desconexión del mismo por un operador externo,
pero sólo cuando el semáforo está en verde a espera de que un peatón apriete el
pulsador.
La RdP que se propone como solución es la que se muestra en la figura 2.23, donde el
conjunto (P3, P4, P5, t4, t5, t6) representa un ciclo de colores de un semáforo
convencional, como el descrito en el ejercicio 2.3.
P1: Estado inicial, que representa la espera para la puesta en marcha del semáforo.
P2: Estado que representa que el semáforo está en verde de forma permanente hasta
que se desconecte o un peatón pida el paso.
P3: Estado que representa que el semáforo está en verde pero que va a pasar a
comenzar un ciclo de colores para permitir el paso del peatón que ha activado t3.
P4: Estado que representa que el semáforo está en ámbar.
P5: Estado que representa que el semáforo está en rojo.
P1 t1: Evento no temporizado de conexión del

semáforo, que implica la puesta en verde del
t1
mismo.
P2 t2: Evento no temporizado que representa la

desconexión del semáforo por parte de un
t2 t3 operador.
P3
t3: Evento no temporizado que representa que
t4
el semáforo está en verde y alguien ha apretado
el pulsador de paso de peatones.
P4
t4: Evento temporizado que representa el paso
t5 de verde a ámbar una vez pulsado el interruptor
por parte de un peatón.
P5
t5: Evento temporizado que representa el paso
t6
de ámbar a rojo una vez pulsado el interruptor
por parte de un peatón.
78
Redes de Petri
t6: Evento temporizado que representa el paso de rojo a verde una vez que el peatón a
pasado.
Se puede observar que en la red intervienen dos tipos de eventos bien diferenciados. Por
un lado están los que hemos llamado temporizados, y que se corresponden con los del
modelo del semáforo convencional (t4, t5 y t6). Tal y como indica su nombre estos
eventos se producen en un instante de tiempo determinado previamente conocido, o
establecido, una vez que estamos en el ciclo de colores del semáforo. Por otro lado
tenemos una serie de eventos no temporizados que representan eventos convencionales
y que sólo se producen por la acción de un operador externo (t1, t2 y t3), pero de los
cuales no sabemos a priori cuando se van a producir.
Un detalle importante a considerar en el modelo de la red es que tenemos dos estados

que representan el color verde del semáforo. Esto es necesario porque si no existiese
nada más que el primer estado de verde, una vez que se produjese el pulsado del
interruptor por parte del peatón, el semáforo pasaría de forma automática a color ámbar,
lo cual no responde a lo que ocurre en la realidad.
Por último, considérese como ejercicio la posibilidad de que el semáforo pudiese ser
desconectado o apagado en cualquier momento durante su funcionamiento (y no sólo
desde el estado P2 como ocurre en la RdP de la figura 2.23). Y diseñe la RdP necesaria
para ello.
EJERCICIO 2.6
Construir una RdP que modele el comportamiento de un montacargas utilizado en la

reparación de un edificio para trasladar cosas entre el suelo de la calle y el tejado.
Supóngase que el montacargas siempre está operando externamente y que no tiene
parada en las distintas plantas del edificio.
Si suponemos que inicialmente el montacargas está a pie de calle, y parado, hasta que se
le ordene comenzar a subir. Cuando se pulse este botón (que asociaremos a un evento)
el montacargas comenzará a subir hasta que llegue al tejado. Evidentemente en realizar
está subida tardará un tiempo que para nosotros será conocido. Llegado al tejado el
montacargas parará, hasta que se le ordene bajar mediante otro evento, representado por
el pulsado de otro botón. De esta forma realizará la misma acción que en la subida pero
descendiendo. Una posible RdP que representa el proceso que acabamos de describir es
la que se muestra en la figura 2.24.
P1: Estado inicial, que representa la espera en planta de calle del montacargas.
P2: Estado que representa la subida del montacargas.
P3: Estado que representa la espera en el tejado del montacargas a que se pulse la tecla
de bajada.
P4: Estado que representa la bajada del montacargas.
79
Redes de Petri
P1
t1: Evento no temporizado que representa la puesta en
marcha en dirección de subida del montacargas, debido al
t1 pulsado del botón de subida.
P2 t2: Evento temporizado que representa la llegada del

montacargas al tejado.
t2 t3: Evento no temporizado que representa la puesta en

marcha en dirección de bajada del montacargas, debido al
pulsado del botón de bajada.
P3
t4: Evento temporizado que representa la llegada del

t3 montacargas al suelo.
P4
t4
P1 P5 Ahora bien, en la RdP de la figura 2.24 no están

explícitas las peticiones de bajada y de subida, que
se pueden incorporar a través de dos nodos lugar
t1 que representen los botones de pulsado de bajada y
de subida, los cuales son pulsados desde el
P2 exterior, y modificarían la RdP de la figura 2.24,
convirtiéndola en la que se muestra en la figura
2.25.
t2
En la RdP de la figura 2.25, los estados y
transiciones de igual nombre que en la RdP de la
P3 P6
figura 2.24 tienen el mismo significado y los
nuevos son los que describen a continuación:
t3
P5: Estado que representa la espera a que alguien
pulse la tecla de subida.
P4
P6: Estado que representa la espera en el tejado del
t4
montacargas a que se pulse la tecla de bajada.
Figura 2.25 Red de Petri solución mejorada del ejercicio 2.6.
La RdP de la figura 2.25 funciona adecuadamente si el pulsador de subida o bajada está

dentro del montacargas y el operador no lo puede pulsar hasta que el montacargas está
parado. No obstante, si estuviese fuera del montacargas podría ocurrir que alguien
80
Redes de Petri
pulsase la petición de subida cuando el montacargas aún esta bajando, de este modo P2
tendría una marca y en el momento que P1 fuese marcado desde t4, comenzaría a subir
de forma inmediata. Para evitar la posibilidad de que el montacargas suba y baje de
forma indefinida sin posibilidad de cargarlo, es necesario introducir en la RdP de la
figuar 2.25 dos nuevos estados, P7 y P8. P7 representa que el montacargas ha llegado al
tejado y está siendo cargado o descargado. Y P8 representa que el montacargas ha
llegado a pie de calle y está siendo cargado o descargado. Las transiciones t7 y t8
representan eventos temporizados del tiempo empleado en la carga y descarga del
montacargas. Cuando se produce alguno de estos dos eventos, la RdP alcanza un estado
a partir del cual si la tecla de subida/bajada ha sido pulsada comenzará de nuevo a
moverse.
Teniendo en cuenta estas consideraciones, la RdP definitiva sería la que se muestra en la

figura 2.26.
P1 P5
t1
P2
t2
P7
t7
P3 P6
t3
P4
t4
P8
t8
Figura 2.26 Red de Petri solución definitiva del ejercicio 2.6.
81
Redes de Petri
EJERCICIO 2.7
a) Construir la RdP que modele el comportamiento de un ascensor que atiende a un

edificio de 5 plantas (Bajo, 1º, 2º, 3º y 4º). Teniendo en cuenta que el ascensor debe
atender peticiones tanto de dentro como de fuera y que el ascensor se supone que tiene
memoria, es decir, que guarda las peticiones que va recibiendo.
b) Construir el árbol de cobertura asociado a la RdP generada en el apartado (a),

suponiendo como marcado inicial que el ascensor está en la planta calle y que se
realizan las siguientes peticiones:
- Desde la planta tercera se solicita el ascensor.

- Tomando el ascensor en ese piso se solicita que baje al primero.
- Desde la planta cuarta se solicita el ascensor.
- Tomando el ascensor en ese piso se solicita que baje al segundo.
El problema planteado en el apartado (a) de este ejercicio es considerablemente más

complicado que el planteado en los ejercicios anteriores. Cada piso del edificio tendrá
que estar representado por un estado de la red, así como los periodos de subida y de
bajada entre ellos. No obstante, el problema de diseño se plantea en la memorización de
las plantas que se desean bajar y subir en cada momento. Pues en cada planta se deberá
comprobar tanto el interruptor de bajada como el de subida. También se debe tener en
cuenta que mientras se gestione una petición, el resto deberán estar en una cola que se
formará por orden de llegada, de forma que dos peticiones no se pueden solapar.
La RdP que se propone como solución es la mostrada en la figura 2.27. En ella se tiene
un único estado P5 para gestionar las subidas y otro P6 para gestionar las bajadas, tanto
de peticiones cursadas desde fuera como desde dentro del ascensor. Ambos estados
serán marcados desde una cola que gestiona las peticiones de subida y bajada
incorporando en el estado respectivo, tantas marcas como pisos se desean subir o bajar
en cada petición. Es decir, el número de marcas a introducir en el estado
correspondiente será igual al valor absoluto de la diferencia entre el número del piso al
que se quiere ir (pulsación desde dentro del ascensor), o bien el número del piso desde
el que se solicita el ascensor (pulsación desde planta), menos el número del piso en el
cual se encuentra el ascensor cuando se dispone a atender la petición cursada.
El significado de cada uno de los estados y transiciones de la RdP mostrada en la figura

2.27 se comenta a continuación, teniendo en cuenta que debido al aumento significativo
del número de ellos se han utilizado subíndices aclaratorios en los distintos nodos de la
misma, que permitan identificar de forma más sencilla el significado de la RdP.
P0: Estado inicial, que representa la espera en planta de calle del ascensor.
Ps1: Estado que representa la subida desde la planta calle al primer piso.
P1: Estado que representa la espera en el primer piso del ascensor.
Ps2: Estado que representa la subida desde el primer piso al segundo piso.
P2: Estado que representa la espera en el segundo piso del ascensor.
82
Redes de Petri
Ps3: Estado que representa la subida desde el segundo piso al tercer piso.
P3: Estado que representa la espera en el tercer piso del ascensor.
Ps4: Estado que representa la subida desde el tercer piso al cuarto piso.
P4: Estado que representa la espera en el cuarto piso del ascensor.
P5: Estado que representa el pulsador de subidas del ascensor.
P6: Estado que representa el pulsador de bajadas del ascensor.
P0
t8 ts1
Pb0 Ps1
tb0 t1
P1
t7 ts2
Pb1 Ps2
P6 P5
tb1 t2
P2
t6
ts3
Pb2
Ps3
tb2 t3
P3
t5 ts4
Pb3 Ps4
tb3 t4
P4
ts1: Evento no temporizado que representa la petición de subida del ascensor de la

planta calle al primer piso. Para poder disparar esta transición es necesario que el
ascensor esté en planta calle (una marca en P0) y que en el pulsador de subidas (P5)
haya al menos una marca.
83
Redes de Petri
t1: Evento temporizado que representa que el ascensor ha llegado al primer piso desde
la planta calle.
ts2: Evento no temporizado que representa la petición de subida del ascensor del primer
piso al segundo piso. Para poder disparar esta transición es necesario que el ascensor
esté en el primer piso (una marca en P1) y que en el pulsador de subidas (P5) haya al
menos una marca.
t2: Evento temporizado que representa que el ascensor ha llegado al segundo piso desde
el primer piso.
ts3: Evento no temporizado que representa la petición de subida del ascensor del
segundo piso al tercer piso. Para poder disparar esta transición es necesario que el
ascensor esté en el segundo piso (una marca en P2) y que en el pulsador de subidas (P5)
t3: Evento temporizado que representa que el ascensor ha llegado al tercer piso desde el
segundo piso.
ts4: Evento no temporizado que representa la petición de subida del ascensor del tercer
piso al cuarto piso. Para poder disparar esta transición es necesario que el ascensor esté
en el tercer piso (una marca en P3) y que en el pulsador de subidas (P5) haya al menos
una marca.
t4: Evento temporizado que representa que el ascensor ha llegado al cuarto piso desde el
tercer piso.
tb3: Evento no temporizado que representa la petición de bajada del ascensor del cuarto
piso al tercer piso. Para poder disparar esta transición es necesario que el ascensor esté
en el cuarto piso (una marca en P4) y que en el pulsador de bajadas (P6) haya al menos
una marca.
t5: Evento temporizado que representa que el ascensor ha llegado al tercer piso desde el
cuarto piso.
tb2: Evento no temporizado que representa la petición de bajada del ascensor del tercer
piso al segundo piso. Para poder disparar esta transición es necesario que el ascensor
esté en el tercer piso (una marca en P3) y que en el pulsador de bajadas (P6) haya al
menos una marca.
t6: Evento temporizado que representa que el ascensor ha llegado al segundo piso desde
el tercer piso.
tb1: Evento no temporizado que representa la petición de bajada del ascensor del
segundo piso al primer piso. Para poder disparar esta transición es necesario que el
ascensor esté en el segundo piso (una marca en P2) y que en el pulsador de bajadas (P6)
t7: Evento temporizado que representa que el ascensor ha llegado al primer piso desde
el segundo.
84
Redes de Petri
tb0: Evento no temporizado que representa la petición de bajada del ascensor del primer
piso a la planta calle. Para poder disparar esta transición es necesario que el ascensor
esté en el primer piso (una marca en P1) y que en el pulsador de bajadas (P6) haya al
menos una marca.
t8: Evento temporizado que representa que el ascensor ha llegado a la planta calle desde
el primer piso.
La nomenclatura se ha dispuesto de tal manera que para subir una planta se utilizan un
conjunto (tsn, Psn, tn, Pn) de nodos lugar y transición y para bajarla se utiliza un
conjunto similar de nodos lugar y transiciones para representar la bajada.
En respuesta al apartado (b), el árbol de cobertura que analiza el comportamiento de la

red para ese conjunto de peticiones es el que se muestra en la figura 2.28. El árbol de
cobertura de la red será distinto para cada una de las distintas secuencias de peticiones
del ascensor que se puedan plantear, teniendo en cuenta que independientemente de la
planta en la que se encuentre el ascensor inicialmente, se realizan peticiones de
movimiento (bien de subida, bien de bajada) desde fuera o desde dentro del ascensor, el
sistema no realiza ninguna acción. En esta red a diferencia del resto de las redes que se
han analizado en otros ejemplos anteriores mediante su árbol de cobertura existen dos
nodos lugar (P5 y P6) que son marcados desde el exterior mediante un gestor de
peticiones, en lugar de ser marcados por la secuencialidad de la propia red como ocurría
en los casos anteriores. Dicho gestor retendrá en una cola las posibles peticiones del
ascensor de forma que sean atendidas en el orden adecuado y no se produzcan conflictos
entre ellas.
Teniendo en cuenta estas consideraciones y que el vector de marcado es: M = [P0 Pb0
Ps1 P1 Pb1 Ps2 P2 Pb2 Ps3 P3 Pb3 Ps4 P4 P5 P6] T, el marcado inicial de la red
sería: M0 = [1 0 0 0 0 0 0 0 0 0 0 0 0 0 0]T.
Se puede observar que aunque el formato del árbol es secuencial, el árbol es mucho más
complejo debido al mayor número de nodos lugar y transición de la red.
85
Redes de Petri
[1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0] [0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 0, 0, 0, 0, 2]
llamada desde el tercer piso tb2
[1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 3, 0] [0, 0, 0, 0, 0, 0, 0, 1, 0, 0, 0, 0, 0, 0, 1]
ts1 t6
[0, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 2, 0] [0, 0, 0, 0, 0, 0, 1, 0, 0, 0, 0, 0, 0, 0, 1]
t1 tb1
[0, 0, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 2, 0] [0, 0, 0, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0]
ts2 t7
[0, 0, 0, 0, 0, 1, 0, 0, 0, 0, 0, 0, 0, 1, 0]
t2 llamada desde el cuarto piso
[0, 0, 0, 0, 0, 0, 1, 0, 0, 0, 0, 0, 0, 1, 0]
ts3
[0, 0, 0, 0, 0, 0, 0, 0, 1, 0, 0, 0, 0, 0, 0]
t3
bajar al primer piso
[0, 0, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 3, 0]
[0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 0, 2]
ts2
tb3
[0, 0, 0, 0, 0, 1, 0, 0, 0, 0, 0, 0, 0, 2, 0]
[0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 0, 0, 0, 1]
t2
t5
[0, 0, 0, 0, 0, 0, 1, 0, 0, 0, 0, 0, 0, 2, 0]
[0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 0, 0, 0, 0, 1]
ts3
tb2
[0, 0, 0, 0, 0, 0, 0, 0, 1, 0, 0, 0, 0, 1, 0]
[0, 0, 0, 0, 0, 0, 0, 1, 0, 0, 0, 0, 0, 0, 0]
t3
t6
[0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 0, 0, 0, 1, 0]
ts4
[0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 0, 0, 0]
t4
bajar al segundo piso
Figura 2.28 Árbol de cobertura de la Red de Petri solución del ejercicio 2.7.
86
Redes de Petri
EJERCICIO 2.8
a) Modelar el siguiente sistema de producción mediante una RdP. El sistema consta de

dos robots, dos máquinas y dos almacenes, que cooperan de la siguiente forma:
1. El primer robot (R1) transporta las piezas que se encuentran en el primer

almacén (A1) y las transporta hasta la primera máquina (M1) para su
manufacturación.
2. La máquina M1 realiza la primera operación sobre las piezas.
3. Finalizado el proceso de M1, el segundo robot (R2) transporta las piezas
desde la primera máquina (M1) a la segunda máquina (M2).
4. Una vez que M2 finaliza la operación sobre la pieza en cuestión, el robot R2
transporta la pieza manufacturada hasta el segundo almacén (A2).
La resolución de este problema (Guasch y col., 2002) claramente se puede dividir en

dos partes, un primer subsistema donde se modele la operación de la primera máquina
M1 sobre la pieza y un segundo subsistema donde se modele la operación de la segunda
máquina M2. El modelo final de todo el proceso vendrá representado por la unión de los
dos subsistemas.
Parece claro, que para que el sistema comience a funcionar lo primero que debemos
tener son piezas dispuestas a ser manufacturas, es decir, piezas en el almacén A1.
Además es necesario que la máquina M1 esté dispuesta para comenzar a funcionar y
que el robot R1 esté libre para que pueda transportar la pieza. Cuando se den estas dos
circunstancias se pondrá en funcionamiento el proceso y por lo tanto el robot R1
transportará la primera pieza desde A1 a M1. Cuando la pieza llega a M1 comenzará a
ser procesada, lo cual tardará un determinado tiempo, y el robot R1 quedará libre.
Finalizado el proceso, la pieza esperará en M1, hasta que el robot R2 llegue a por ella y
la traslade. Hasta aquí habríamos descrito el funcionamiento del primer subsistema del
modelo global, que modelaba el comportamiento de la máquina M1. Por tanto, con lo
expuesto hasta ahora el modelo de este subsistema vendría representado por la RdP de
la figura 2.29.
P1: Estado que representa el almacén A1. El número de marcas que contenga se
corresponderá con el número de piezas que quedan por manufacturar.
P2: Estado que representa la disponibilidad de la máquina M1 para empezar a funcionar.
P3: Estado que representa que el robot R1 está libre y por lo tanto dispuesto a comenzar
a transportar piezas.
P4: Estado que representa el transporte de la pieza en cuestión, por parte del robot R1,
desde el almacén A1 hasta la máquina M1.
P5: Estado que representa el procesamiento de la pieza en cuestión, por parte de la

máquina M1.
P6: Estado que representa que la máquina M1 está ocupada con una pieza procesada que
está esperando a ser transportada por el segundo robot R2 hacia la máquina M2 para
finalizar su manufacturación.
87
Redes de Petri
P1 P2 P3
t1: Evento que indica que el comienzo del
t1
proceso. Esta transición es disparada cuando
la máquina M1 está operativa, hay piezas en
A1 dispuestas a ser tratadas y el robot R1
P4 está libre.
t2: Evento que indica que el robot R1 ha

t2
depositado la pieza en la máquina M1 para
que comience su procesamiento. El disparo
de esta transición lleva consigo que la pieza
P5
comience a procesarse y que el robot R1
quede libre de operación.
t3
t3: Evento que indica el fin de procesamiento
por parte de M1.
P6
Figura 2.29 Red de Petri solución del comportamiento de la máquina M1.
Una vez que la pieza se encuentra en la máquina M1 pendiente de transporte,

comenzaría el proceso de la segunda máquina, segundo subsitema del modelo global.
Entonces, igual que antes, si hay pieza manufacturada en M1, el robot R2 está libre y la
máquina M2 también está libre comenzará el segundo procesamiento de la pieza que se
está tratando. Igual que en el procesamiento de la máquina M1 el siguiente paso sería el
transporte de la pieza por parte del robot R2, desde M1 a M2. Cuando la pieza llega a
M2 comenzará a ser procesada, lo cual tardará un determinado tiempo, y el robot R2
quedará libre al igual que la máquina M1. Finalizado el proceso, la pieza esperará en
M2, hasta que el robot R2 llegue a por ella, para lo cual debe estar libre, y la traslade al
almacén de recogida A2. De esta forma cuando la pieza llegue al almacén A2, la
máquina M2 y el robot quedarán libres de nuevo. Por tanto, el modelo de este segundo
subsistema vendría representado por la RdP de la figura 2.30.
P7: Estado que representa la disponibilidad de la máquina M2 para empezar a funcionar.
P8: Estado que representa que el robot R2 está libre y por lo tanto dispuesto a comenzar
a transportar piezas.
P9: Estado que representa el transporte de la pieza en cuestión, por parte del robot R2,
desde la máquina M1 a la máquina M2.
P10: Estado que representa el procesamiento de la pieza en cuestión, por parte de la

máquina M2.
P11: Estado que representa que la máquina M2 está ocupada con una pieza procesada
que está esperando a ser transportada por el robot R2 hacia el almacén de recogida A2.
P12: Estado que representa el transporte de la pieza por parte del robot R2 desde M2 a
A2.
88
Redes de Petri
P7 P6 P8 P13: Estado que representa el almacén A2.
t4: Evento que indica la continuación del

t4
proceso en su segunda fase. Esta transición
es disparada cuando la máquina M2 está
P9 operativa, hay piezas procesadas en M1 y
el robot R2 está libre.
t5 t5: Evento que indica que el robot R2 ha

depositado la pieza en la máquina M2 para
que continue su procesamiento. El disparo
P2 P10 de esta transición implica que la pieza
comience a procesarse y que el robot R2 y
t6 la máquina M1 queden libres.
P11 t6: Evento que indica el fin de

procesamiento de la pieza por parte de M2.
t7
t7: Evento que se dispara cuando la pieza
está a la espera de transporte y R2 está
P12 libre.
t8 t8: Evento que indica que la llegada de la

pieza al almacén A2.
P13
Figura 2.30 Red de Petri solución del comportamiento de la máquina M2.
Por último la RdP global del proceso será la unión de las dos anteriores (figuras 2.29 y
2.30) a través de los nodos lugar que tienen en común. Dicha RdP es la que se muestra
en la figura 2.31.
Se debe observar que con el marcado inicial elegido en la figura 2.31, la segunda pieza
podrá comenzar a procesarse cuando la marca que represente a la primera se pase al
estado P10, es decir, cuando se dispare la transición t5. Esto quiere decir que
dependiendo del número de piezas y de los tiempos de manufactura y transporte las dos
máquinas podrán estar procesando al mismo tiempo.
89
Redes de Petri
P7 P8
P1 P2 P3 t4
P9
t1
P4 t5
t2 P10
t6
P5
P11
t3
t7
P6
P12
t8
P13
Figura 2.31 Red de Petri solución completa del ejercicio 2.8.
EJERCICIO 2.9
a) Modelar el siguiente sistema de producción mediante una RdP. El sistema consta de

dos máquinas (M1 y M2), dos cintas transportadoras con un palet en cada una de ellas
(C1 y C2) y dos tipos de piezas (a y b) para ser procesadas. La secuencia de
operaciones posibles, ha de respetar las siguientes restricciones:
1. Para una pieza del tipo a el proceso comienza en la máquina M1. Finalizada
la operación, se emplea C1 para transportar la pieza a M2 y tras ser
procesada sale del sistema.
2. Para una pieza del tipo b el proceso es el mismo que para la pieza tipo a
pero empleando C2 en el transporte.
3. Las máquinas no pueden realizar operaciones consecutivas sobre el mismo
tipo de pieza.
4. Para que M1 quede libre una vez finalizado el proceso de una pieza tipo a es
necesario que C1 se encuentre al lado de la máquina.
5. Para que M1 quede libre una vez finalizado el proceso de una pieza tipo b es
90
Redes de Petri
b) Construir el árbol de cobertura asociado a la RdP generada en el apartado (a), con

un vector de marcado inicial que represente que la máquina M1 está procesando una
pieza de tipo a, el palet C1 está en posición superior, la máquina M2 está procesando
una pieza del tipo b y el palet C2 está también en la posición superior.
En la resolución del apartado (a) de este problema se va a considerar que el almacén es

infinito y por lo tanto siempre hay piezas tipo a y tipo b que en un momento
determinado necesitan ser procesadas. Por otro lado, los palets C1 y C2 tendrán dos
posiciones, superior e inferior.
Con estas consideraciones vamos a ver como se formalizaría la RdP solución a este
problema. En primer lugar suponemos un estado P1 para representar que la máquina M1
está procesando una pieza tipo a. La liberación de esta máquina por parte de la pieza se
produce cuando la pieza ha sido procesada y el palet C1 está a su lado (restricción 4,
supongamos que estar cerca de M1 es estar en posición superior y cerca de M2 en
posición inferior), estado representado por el nodo lugar P2. Esto supone el disparo de
una transición que podría ser t1. Disparada la transición, el palet C1 comienza el
transporte hasta llegar al estado que represente que dicho palet está en la posición
inferior (P3). Por otro lado, la máquina M1 comienza a procesar una pieza del tipo b
(P4).
Cuando el palet C1 esté próximo a la máquina M2, o sea en posición inferior y la

máquina M2 haya procesado una pieza de tipo b en último lugar (nodo lugar P5), se
disparará una nueva transición t2 que hará que la máquina 2 pase a procesar la pieza
tipo a correspondiente (P6), y el palet C1 regrese a la posición superior, próxima a M1
(nodo P2).
Cuando la máquina M1 acaba de procesar la pieza tipo b (nodo P4), si el palet C2 se

encuentra en posición superior (nodo P7), se disparará una transición t3, que lo que hace
es enviar el palet C2 con la pieza tipo b hasta la su posición inferior próximo a M2
(nodo P8) y poner a la máquina M1 de nuevo a procesar una pieza tipo a (nodo P1).
Cuando el palet C2 llega a su posición inferior (nodo P8) próxima a la máquina M2 y

ésta ha acabado de procesar una pieza tipo a (nodo P6), será factible disparar una
transición t4, que haga regresar el palet C2 a su posición superior y que la máquina M2
tras procesar una pieza tipo a pase a procesar una tipo b (nodo P5).
Por tanto, resumiendo lo que acabamos de comentar los nodos lugar y transición de la
RdP solución (veasé figura 2.32) tendrán el siguiente significado:
P1: Estado que representa a la máquina M1 procesando piezas del tipo a.
P2: Estado que representa al palet C1 en posición superior.
P3: Estado que representa al palet C1 en posición inferior.
P4: Estado que representa a la máquina M1 procesando una pieza del tipo b.
P5: Estado que representa a la máquina M2 procesando una pieza del tipo b.
91
Redes de Petri
P6: Estado que representa a la máquina M2 procesando una pieza del tipo a
P7: Estado que representa al palet C2 en posición superior.
P8: Estado que representa al palet C2 en posición inferior.
t1: Evento que indica el fin de procesamiento de la pieza a por parte de la máquina M1 y
el comienzo del transporte de la pieza a por parte de C1 desde la máquina M1 a la
máquina M2.
t2: Evento que indica el fin de procesamiento de la pieza b por parte de la máquina M2
y la disponibilidad de C1 cerca de la máquina M2 con una pieza del tipo a pendiente de
ser procesada por la máquina M2, así como su regreso a la posición superior.
t3: Evento que indica el fin de procesamiento de la pieza b por parte de la máquina M1
y el comienzo del transporte de la pieza b por parte de C2 desde la máquina M1 a la
máquina M2.
t4: Evento que indica el fin de procesamiento de la pieza a por parte de la máquina M2 y
la disponibilidad de C2 cerca de la máquina M2 con una pieza del tipo b pendiente de
ser procesada por la máquina M2, así como su regreso a la posición superior.
P1 P2
t1
P7 P4 P3 P5
t3 t2
P8 P6
t4
Para representar el árbol de cobertura de la RdP mostrada en la figura 2.32 con las
consideraciones de marcado inicial comentadas en el apartado (b) del enunciado, el
vector de marcado inicial de la red, sería el mismo que está plasmado en la figura 2.32,
es decir, M0 = [1 1 0 0 1 0 1 0]T. Por tanto el árbol de cobertura sería el que se muestra
en la figura 2.33.
92
Redes de Petri
[1, 1, 0, 0, 1, 0, 1, 0]
t1
[0, 0, 1, 1, 1, 0, 1, 0]
t3 t2
[1, 0, 1, 0, 1, 0, 0, 1] [0, 1, 0, 1, 0, 1, 1, 0]
t2
t3
[1, 1, 0, 0, 0, 1, 0, 1]
t4 t1
[0, 0, 1, 1, 0, 1, 0, 1]
t4
Figura 2.33 Árbol de cobertura de la Red de Petri solución del ejercicio 2.9.
EJERCICIO 2.10
Modelar la siguiente línea de producción mediante una RdP. El sistema consta de dos
máquinas (M1 y M2), dos manipuladores para transportar una pieza cada uno de
forma independiente. Se tienen dos tipos de piezas (a y b) que deben ser para ser
procesadas, según las siguientes especificaciones:
1. Se deben realizar dos operaciones sobre una pieza de tipo a. La primera en

la máquina M1 y la segunda en la máquina M2.
2. Se deben realizar dos operaciones sobre una pieza de tipo b. La primera en
la máquina M2 y la segunda en la máquina M1.
3. Para que una pieza del almacén pueda acceder a una máquina es
conveniente que ésta se encuentre libre y que se tenga una unidad de
transporte libre.
4. Una vez asignada a una pieza una unidad de transporte, ésta no queda libre
hasta que finaliza la segunda operación.
5. Tras concluir la primera operación la pieza es transportada
automáticamente a la segunda máquina, si ésta está libre. Si no espera hasta
que esté libre, no pudiéndose liberar la primera máquina.
6. Tras concluir la segunda operación, la pieza sale del sistema, liberando de
forma automática tanto la unidad de transporte empleada como la máquina
empleada en la segunda operación.
7. No puede haber más de una pieza tipo a o b, procesándose al mismo tiempo
sobre la línea de producción.
Una posible RdP solución de este problema puede ser la que se muestra en la figura
2.34, donde la parte izquierda de la red describe el tratamiento de la pieza de tipo a y la
parte derecha el tratamiento de la pieza de tipo b. Por ello, ambas subredes son muy
93
Redes de Petri
similares y tienen un nodo lugar de acceso común en el que se modela el número de

máquinas manipuladoras de transporte libre que hay en cada momento.
En la figura 2.34 se han utilizado algunos trazados de líneas diferentes simplemente

para aclarar visualmente el comportamiento de la RdP.
P1 P2 P6 P7
t1 t4
P3
P4 P8
t2 t5
P5 P9
t3 t6
En concreto, la descripción de los nodos lugar y transición que componen la RdP de la

figura 2.34 es la siguiente:
P1 y P6: Estados que representa el límite de piezas de tipo a (P1) y de tipo b (P6), que
hay en todo momento en la RdP.
P2 y P7: Estados que representan que la máquina M1 (P2) y la máquina M2 (P7) están
libres y por lo tanto dispuestas a operar.
P3: Estado que representa el número de transportadoras libres en la línea en todo

momento.
P4 y P8: Estados que representan el procesamiento de una pieza de tipo a por parte de la
máquina M1 (P4) y el procesamiento de una pieza de tipo b por parte de la máquina M2
(P8).
P5 y P9: Estados que representan el procesamiento de una pieza de tipo a por parte de la
máquina M2 (P5) y el procesamiento de una pieza de tipo b por parte de la máquina M1
(P9).
t1 y t4: Eventos que indican el comienzo de proceso de manufacturación de una pieza

de tipo a en la máquina M1 (t1) y el comienzo de proceso de manufacturación de una
94
Redes de Petri
pieza de tipo b en la máquina M1 (t4). Para que estas transiciones se puedan disparar
debe ocurrir que la máquina con la que se quiere trabajar esté libre, que haya en los
almacenes piezas del tipo correcto para ser procesadas y que haya manipuladoras de
transporte libres para poder transportar las piezas de una máquina a otra en la parte
central del proceso de manufactura.
t2 y t5: Eventos que indican el transporte y cambio de máquina de la pieza de tipo a (t2)
y de la pieza de tipo b (t5). Para que estas transiciones se disparen la máquina M1 debe
haber acabado su trabajo sobre la pieza de tipo a (t2) y la máquina M2 debe de haber
acabado su trabajo sobre la pieza de tipo b (t5). Para que estas transiciones se puedan
disparar debe ocurrir también que la máquina con la que se quiere trabajar esté libre. Al
dispararse cada una de ellas conlleva que la máquina que acaba de llevar a cabo el
trabajo sobre la pieza en cuestión vuelve a quedar libre y por tanto disponible para
realizar un nuevo trabajo.
t3 y t6: Eventos que indica el fin de procesamiento de la pieza de tipo a por parte de la
máquina M2 (t3) y el fin de procesamiento de la pieza de tipo b por parte de la máquina
M1 (t6). Al dispararse cada una de estas transiciones conlleva que la máquina que acaba
de llevar a cabo el trabajo sobre la pieza en cuestión vuelve a quedar libre, que la
manipuladora de transporte utilizada en el proceso también quede libre y que las piezas
de tipo a y b regresen a sus lugares de origen respectivos.
95
Redes de Petri
96
TEMA 3
Diseño e implementación de
automatismos
La creciente complejidad de los procesos y la disponibilidad de controladores cada vez

más potentes y con un mayor número de funciones, obligan a emplear métodos de
diseño más globales y sistemáticos. La clave de estos métodos está en estudiar los
posibles estados de cada componente del sistema, en lugar de estudiar la naturaleza
física de los mismos, y en representar cada uno de los componentes funcionales de
forma independiente a la tecnología que se vaya a utilizar para implementarlos
(cableada o programada). Esto es posible porque las nuevas formas de representación se
basan fundamentalmente en el concepto de etapa, que simplifica en gran medida la
síntesis de los automatismos.
A partir de estas ideas, los trabajos efectuados por las comisiones de AFCET
(Association Française pour la Cybernétique Economique et Technique) y de ADEPA
(Agence Nationale pour le Developpment de la Production Automatisée) iniciados en la
década de los setenta, han dado como resultado la definición de un diagrama funcional
denominado GRAFCET (Graphe de Comands Etape/Transition). Este tema se dedica al
diseño e implementación de automatismos utilizando GRAFCET.
3.1 DISEÑO DE AUTOMATISMOS CON GRAFCET
GRAFCET (GRÁFico de Control de Etapas y Transiciones) es un método gráfico para

el modelado y diseño de automatismos basado en las Redes de Petri. Los diagramas
funcionales que genera el método permiten describir los comportamientos de los
automatismos en relación con las informaciones que reciben. Para ello se debe imponer
un funcionamiento riguroso del mismo, que evite incoherencias, bloqueos y conflictos.
Los gráficos funcionales resultantes de esta metodología permiten ir mas allá de una
simple descripción e interpretación gráfica de un proceso, haciendo que el GRAFCET
se haya convertido en una potente herramienta de diseño de sistemas lógicos,
constituida por una serie de reglas bastante simples (Balcells y Romeral, 1997).
97
Diseño e implementación de automatismos
Una de las características principales del método GRAFCET es que no busca la

minimización de puertas lógicas, ni de memoria, en el diseño del automatismo. No
obstante, es ventajoso porque sí que emplea una metodología de diseño rigurosa y muy
estructurada, que da como resultado diagramas funcionales muy claros y fácilmente
legibles por cualquier usuario, incluso aunque no sea un experto en el diseño de
automatismos. Por otro lado, una ventaja adicional del método GRAFCET es que en
cada nivel de descripción los diagramas funcionales obtenidos pueden ser corregidos o
modificados, sin necesidad de volver a tratar partes ya analizadas en el proceso.
En la actualidad muchos autómatas programables incorporan ya instrucciones de

programación que permiten introducir directamente el grafo de GRAFCET. En otros
casos, se dispone de software capaz de compilar un grafo GRAFCET al lenguaje
máquina que se utilice, permitiendo en ambos casos una gran flexibilidad y rapidez de
diseño, con grandes ventajas para las fases de verificación, explotación o modificación
posterior del automatismo. A pesar de todo ello, no debe confundirse GRAFCET con un
lenguaje de programación.
Los principios básicos que inspiraron la creación del GRAFCET se pueden resumir
como sigue (ver figura 3.1):
• El interés del diseño se debe centrar en la función que va a realizar el automatismo

y no en su estructura física, o en la tecnología a emplear para llevarlo a cabo.
• Todo sistema automático tendrá dos partes, una de control y otra operativa. La
primera comprende todo lo relacionado con la automatización del proceso y la
segunda el resto del sistema. Finalmente, todo el conjunto debe ser capaz de
comunicarse con el mundo exterior.
• La etapa es el elemento básico de todo diagrama funcional realizado con

GRAFCET, y se define como una acción realizada por el automatismo objeto de
diseño.
• El proceso a diseñar debe dividirse en macroetapas, y estas a su vez en etapas

elementales, de forma que cada etapa elemental tenga asociada una variable de
estado y que las acciones que realiza dependan sólo de relaciones
combinacionales entre las entradas y las salidas.
• Generar el gráfico de evolución, indicador de la secuencia de operaciones o

etapas, así como las condiciones lógicas para pasar de una etapa a otra. Estas
condiciones se denominan transiciones en el lenguaje del GRAFCET. En este
paso se obtienen las ecuaciones lógicas de las variables de estado que describen la
parte secuencial del automatismo.
• Establecer las ecuaciones combinacionales asociadas a cada etapa.
• Finalmente, implementar el sistema con tantas puertas y biestables como sean

necesarios.
98
FASE DE DIAGRAMA FUNCIONAL

ESPECIFICACIÓN
DEF. MACROETAPAS
CONDICIONES DE TRANSICIÓN MACROETAPAS
DESCOMPOSICIÓN MACROETAPAS EN ELEMENTALES
FASE DE
DISEÑO
SIST. PROGRAMABLE SIST. CABLEADO
PROGRAMA DISEÑO HARDWARE
SIMULACIÓN IMPLEMENTACIÓN
IMPLEMENTACIÓN PRUEBAS
SIST. PROGRAMABLE EXPLOTACIÓN
FASE DE MANTENIMIENTO
EXPLOTACIÓN
Figura 3.1 Pasos de un diseño basado en GRAFCET.
El diseño con GRAFCET se basa fundamentalmente en identificar la parte secuencial de

un proceso dado, o lo que es lo mismo, en determinar el número de estados distintos
necesarios para describir el proceso. El número de estados será finito, por lo que en el
diseño habrá que determinar el conjunto de estados que se repiten de forma cíclica en el
proceso. Cada estado vendrá representado por una etapa del diagrama y será
identificado con una variable de estado.
3.1.1 Conceptos Básicos del GRAFCET
Un diseño con GRAFCET se compone de:
• Un conjunto de Etapas, o estados, a los que van asociados las acciones del
proceso.
• Un conjunto de Transiciones, a las que se asocian las receptividades o

condiciones lógicas que deben cumplirse para que la transición pueda llevarse a
cabo y se permita de esta forma el paso de una etapa a otra.
• Un conjunto de Uniones Orientadas o líneas de evolución, que unen las etapas

con las transiciones y las transiciones con las etapas.
99
• En ocasiones y dependiendo de la complejidad del diagrama se pueden utilizar

Macroetapas, las cuales a su vez estarán constituidas por etapas elementales
perfectamente unidas mediante transiciones.
En el diseño del automatismo con GRAFCET se debe tener siempre presente que
cuando se recorra el gráfico de evolución resultante, por cualquier camino posible, se
debe alternar siempre una etapa y una transición. La regla básica de sintaxis del
GRAFCET es que entre dos etapas debe existir una y sólo una condición de transición.
3.1.1.1 Concepto de etapa
Cada ETAPA del GRAFCET representa uno de los estados posibles del sistema y se
debe corresponder con las distintas situaciones factibles del sistema, en las que todo o
parte del órgano de mando del mismo es invariante respecto del conjunto de entradas y
salidas del sistema automatizado. En toda etapa, la relación entre sus entradas y sus
salidas es puramente combinacional, por tanto puede ser representada mediante puertas
lógicas.
El símbolo empleado para representar una etapa en una estructura GRAFCET es un

cuadrado con un número, o símbolo, en su interior que la identifica. En ocasiones las
etapas pueden llevar asociadas etiquetas, que normalmente servirán para describir el
proceso o estado que representan (ver figura 3.2, etapa situada más a la izquierda en la
figura).
10 10 10
ETAPA ETAPA ETAPA

ACTIVA INICIAL
Figura 3.2 Representación de una etapa cualquiera, una etapa activa y una etapa inicial con GRAFCET.
Se denomina etapa inicial a aquella en la que arranca el sistema por primera vez (ver
apartado 3.1.2), y gráficamente se suele representar con un cuadrado de línea doble (ver
figura 3.2, etapa situada más a la derecha en la figura).
En un momento concreto y según la evolución del proceso una etapa dada puede estar
activa o inactiva. Teniendo en cuenta que el conjunto de las etapas activas definen la
situación en la que se encuentra el proceso, se puede decir que una etapa está activa
cuando el proceso está realizando la acción que lleva asociada, e inactiva en caso
contrario. Gráficamente la etapa activa se representa como una etapa cualquiera con una
marca distintiva, por ejemplo un punto, dentro del cuadrado que representa la etapa (ver
figura 3.2, etapa situada en el centro de la figura).
En ocasiones y para simplificar la compresión del diagrama GRAFCET, las acciones

asociadas a cada etapa se suelen incluir en el diagrama funcional como rectángulos
anexos a los cuadrados que representan las etapas, con una etiqueta identificativa de la
acción a realizar en cada una de ellas.
100
3.1.1.2 Concepto de transición
Las TRANSICIONES representan las condiciones lógicas necesarias para que finalice
la actividad de una etapa y se inicie la de la etapa o etapas inmediatamente consecutivas.
Toda transición representa una barrera que asocia al menos dos etapas consecutivas y
cuyo franqueamiento hace posible la evolución del sistema. Por tanto, se dice que una
transición indica la posibilidad de evolución entre etapas, cuando se consuma, al
producirse de esta forma lo que se conoce como el franqueo de la transición. El
franqueo de una transición provoca el paso del proceso desde una situación dada a otra
distinta, la cual vendrá descrita por la nueva etapa (o etapas) que se activa al franquear
la transición.
Gráficamente las transiciones del GRAFCET se representan mediante una línea

perpendicular a las líneas de evolución, o uniones orientadas, que unen unas etapas con
otras. En ocasiones esta línea perpendicular (que representa la transición) puede llevar
asociada otra paralela a las uniones orientadas, e incluso, cada transición para una mejor
identificación puede ir numerada en el grafo funcional del GRAFCET, normalmente a
la izquierda de la línea perpendicular anteriormente citada.
En la figura 3.3 se muestran las dos formas descritas para representar una transición. En
ambos casos la transición entre las etapas 10 y 11 del GRAFCET, que ha sido
identificada mediante la etiqueta “(1)”.
10 10
(1) (1)
11 11
Figura 3.3 Posibles representaciones de una transición en GRAFCET.
Una transición puede estar validada o no validada. Se dice que lo está cuando todas las
etapas inmediatamente anteriores a esta transición están activadas.
Las condiciones lógicas asociadas a las distintas transiciones del GRAFCET se obtienen
por combinación de unas variables denominadas receptividades. Estas variables son
proposiciones lógicas que pueden ser verdaderas o falsas, y son función de las entradas
y de las variables internas del proceso. Gráficamente las receptividades suelen ir escritas
de forma literal, o simbólica, a la derecha del símbolo de la transición. Ahora bien, si
van en forma simbólica será necesaria una tabla de correspondencia entre los símbolos
del grafo funcional y las condiciones asociadas a las transiciones. Si no hay condición
asociada a una transición dada, se dice que la receptividad es verdadera siempre, y se
suele representar con un –1, o sin ningún símbolo.
101
3.1.1.3 Concepto de unión orientada
Las UNIONES ORIENTADAS también conocidas como líneas de evolución o arcos

del diagrama GRAFCET sirven para unir las distintas etapas que representan
actividades consecutivas, y mientras no se diga lo contrario (mediante por ejemplo una
flecha) se supondrá por convenio que la dirección es siempre de arriba hacia abajo.
Gráficamente se representan mediante líneas horizontales, o verticales, aunque también
se admiten líneas oblicuas en el diagrama, si con ello se consigue dar una mayor
claridad al mismo.
En ocasiones la evolución de algunas etapas puede estar condicionada por la misma

transición, para lo cual se utilizan en el diagrama lo que se conoce como trazos
paralelos (ver figura 3.4). En la figura se pone de manifiesto que para poder franquear
Tn será necesario que estén activas las etapas 10 y 11, y que el franqueo de la transición
supone la activación simultánea de las etapas 12 y 13, y la desactivación de las etapas
10 y 11.
10 11
Tn
12 13
Figura 3.4 Trazos paralelos en GRAFCET.
3.1.1.4 Concepto de macroetapa
Los procesos a diseñar deben dividirse en macroetapas, y éstas a su vez en etapas

elementales, de forma que cada etapa elemental tenga asociada una variable de estado y
que las acciones que realiza dependan sólo de relaciones combinacionales entre las
entradas y las salidas. De esta forma cada macroetapa representará realmente un
pequeño diagrama funcional en GRAFCET, capaz de realizar un conjunto de tareas,
relacionadas entre sí.
Gráficamente una macroetapa se representará tal y como se muestra en la figura 3.5 (el
diagrama tiene representadas las etapas 6 y 7 del GRAFCET y la macroetapa M1),
teniendo en cuenta que todo diagrama descrito por una macroetapa comenzará y
finalizará en una etapa y nunca en una transición.
102
T6
M1
T7
Figura 3.5 Representación de una macroetapa en GRAFCET.
3.1.2 Reglas de evolución del GRAFCET
Las reglas de evolución permiten definir, e interpretar, de forma unívoca el

comportamiento dinámico del sistema. Este tipo de reglas pueden hacer referencia a las
etapas, o a las transiciones, y en ocasiones pueden ser redundantes entre sí. Las reglas
básicas de evolución del GRAFCET son las siguientes:
1. A cada etapa se le asocia una variable de estado de tipo bit.
2. En una etapa hay dos estados posibles: etapa activa o etapa inactiva. Si la
variable de estado de la etapa vale 1 se dice que está activa y si vale 0 que está
inactiva (ver figura 3.6).
3. En un arranque en frío del GRAFCET se activarán todas las etapas iniciales y

quedarán inactivas todas las demás. Se define como arranque en frío a la
inicialización de un proceso automático sin guardar memoria ninguna de las
situaciones anteriores.
4. En un arranque en caliente del GRAFCET pueden activarse las etapas iniciales,

o mantener el contexto o estado anterior al arranque en caliente. Se define como
arranque en caliente a la reinicialización de un proceso automático, que guarda
memoria de alguna situación anterior. La situación suele corresponder a un
rearranque sin pérdida de contexto, o lo que es lo mismo, a un rearranque que
tiene memorizadas las variables de estado del proceso.
5. En una ejecución normal del proceso una etapa no inicial se activa cuando la
etapa anterior esté activada y se cumplan las condiciones lógicas de la transición
existente entre ambas.
103
Inactiva 4 4 Inactiva
Franqueada T1 T1 Franqueada
Activa 5 5 Inactiva
Validada T2 T2 Franqueada
Activable 6 6 Activa
No validada T3 T3 Validada
Figura 3.6 Reglas de evolución de las etapas y transiciones del GRAFCET.
6. Una etapa se desactiva cuando se cumplen las condiciones lógicas de las

transiciones siguientes, y la transición o transiciones en cuestión se efectúan, o
lo que es lo mismo, se franquean.
7. Una transición puede estar en cuatro posibles situaciones (ver figura 3.6):
o No validada, la etapa o etapas inmediatamente anteriores o siguientes no

están activas.
o Validada, la etapa o etapas inmediatamente anteriores están activas, pero

no se cumple la condición lógica de la transición.
o Franqueable, la etapa o etapas inmediatamente anteriores están activas, y

se cumple la condición lógica de la transición, o lo que mismo, la
receptividad asociada a la transición es cierta. Esta situación es
transitoria y la transición pasará rápida y obligatoriamente al estado de
franqueada.
o Franqueada, la etapa o etapas inmediatamente siguientes se han

activado, y se han desactivado la etapa o etapas inmediatamente
anteriores.
8. Una transición sólo se puede franquear si está previamente validada.
9. Las transiciones franqueables serán inmediatamente franqueadas.
10. Si hay varias transiciones franqueables simultáneamente serán franqueadas

simultáneamente.
11. Al franquear una transición se desactivan de forma inmediata todas las etapas
inmediatamente anteriores.
104
12. Si en un momento concreto una etapa se activa y se desactiva de forma

simultánea, por defecto la etapa quedará activa. Con esta regla se resuelven
algunos casos de indeterminación e incoherencia, los cuales se presentan en muy
pocas ocasiones, y además en la medida de lo posible deben ser evitados.
13. El gráfico de evolución expresado en GRAFCET ha de ser siempre cerrado, sin

dejar ningún camino abierto, dado que si no se plantearían problemas de
incoherencia, o situaciones en las que el proceso no podría continuar.
3.1.3 Estructuras en el GRAFCET
En el diseño de un automatismo implementado con GRAFCET, además de estructuras

lineales como las que se pueden ver en las figuras precedentes, se pueden tener
estructuras más complejas en las que se presenten bucles, tomas de decisiones, o la
posibilidad de realizar tareas simultáneas que deban sincronizarse. Para realizar estas
acciones, el GRAFCET dispone de unas estructuras básicas a partir de las cuales pueden
derivarse otras más complejas, y generar de este modo diferentes diagramas de proceso.
Como es sabido, las tres funciones lógicas básicas en función de las cuales se puede
implementar cualquier circuito combinacional son las puertas: <<Y>>, <<O>> y
<<NO>>. Pues bien, debido al paralelismo que existe entre los circuitos secuenciales y
el tipo de procesos que se pueden implementar en el GRAFCET, es posible representar
todos ellos utilizando sólo estructuras de este tipo. Por ello, las estructuras básicas a
implementar en GRAFCET se pueden resumir en las siguientes:
• Secuenciamiento lineal y paralelo.
• Convergencia en <<O>>.
• Divergencia en <<O>>.
• Convergencia en <<Y>>.
• Divergencia en <<Y>>.
• Salto de etapas y Bucles de repetición de una misma secuencia.
3.1.3.1 Secuenciamiento lineal y paralelo
El secuenciamiento lineal es la estructura del GRAFCET más sencilla posible,

consistente en un conjunto de etapas consecutivas unidas por una línea de evolución, o
unión orientada, y condiciones lógicas de transición. Sus propiedades básicas son:
• En cada tramo lineal sólo una etapa debe estar activa en un momento
determinado, lo contrario establecería una incoherencia en el diseño del diagrama.
105
• Una etapa se activa si lo está la anterior y la receptividad de la transición que la

separa es cierta. (Esta propiedad representa una de las reglas básicas de evolución
del GRAFCET comentada en el apartado 3.1.2).
• La activación de una etapa implica la desactivación de la etapa anterior de forma

inmediata.
• Una estructura lineal puede ser parte de otra más compleja.
Dependiendo del proceso es posible que sea necesario realizar dos o más secuencias
lineales en paralelo. En un diseño con GRAFCET esto es posible combinando diversas
secuencias lineales, tal y como se muestra en la siguiente figura 3.7. De esta forma se
produce una activación de secuencias simultáneas, aunque las evoluciones de las etapas
activas en cada una de las secuencias son independientes.
4 7
T1 T3
5 8
T2 T4
6 9
Figura 3.7 Secuenciamiento paralelo de dos secuencias lineales.
3.1.3.2 Convergencia en <<O>>
Una estructura de convergencia en <<O>> se presenta cuando se puede acceder a una

misma etapa desde dos o más etapas anteriores (ver figura 3.8). Para que la etapa en la
que confluyen el resto de las etapas se active, debe cumplirse que la transición cuya
receptividad sea cierta coincida con la etapa que está activa en el nivel anterior. Se debe
tener presente, que sólo una de las receptividades de las transiciones que llegan a la
etapa de convergencia debe cumplirse en un mismo instante de tiempo, evitando de este
modo un conflicto entre etapas.
106
8 9
T8 T9
10
Figura 3.8 Convergencia en <<O>>.
En la figura 3.8 para poder activar la etapa 10, debe estar activa la etapa 8 y cumplirse
la condición lógica de la transición T8, o bien, debe estar activa la etapa 9 y cumplirse
la condición lógica de la transición T9, pero nunca deben suceder las dos cosas al
mismo tiempo.
3.1.3.3 Divergencia en <<O>>
Una estructura de divergencia en <<O>> se presenta cuando se puede acceder a

distintas etapas desde una única etapa (ver figura 3.9), es decir, desde una etapa es
posible iniciar distintos caminos en el diagrama. Cuando la etapa donde se produce la
bifurcación está activa, es posible activar distintas etapas, y su activación dependerá de
si la condición lógica asociada a la transición de la etapa en cuestión, se cumple o no se
cumple. Para que no se produzcan incoherencias en el diseño, todas las transiciones
asociadas a las distintas etapas a las que se puede acceder desde la etapa que genera la
divergencia, deben ser excluyentes.
T8 T9
8 9
Figura 3.9 Divergencia en <<O>>.
En la figura 3.9 a partir de la activación de la etapa 7, se pueden activar tanto la etapa 8

como la etapa 9. Si la condición asociada a T8 es cierta, se activará la etapa 8 y si la que
es cierta es la condición asociada a T9 se activará la etapa 9. Ahora bien, las
condiciones lógicas de las transiciones T8 y T9 deben ser excluyentes para que no se
puedan activar de forma conjunta las etapas 8 y 9.
Debido a que los procesos que se representan en un GRAFCET han de ser cerrados,
siempre que se produzca una divergencia en <<O>> deberá existir una convergencia en
<<O>> en algún lugar del grafo y a la inversa.
107
3.1.3.4 Convergencia en <<Y>>
8 9
T10
10
Figura 3.10 Convergencia en <<Y>>.
Una estructura de convergencia en <<Y>> se presenta cuando se produce un esquema

similar al de la figura 3.10, donde varias etapas convergen en una misma transición, y
además se impone que todas las tareas que confluyan en la transición de convergencia
deben haber finalizado, para que el proceso pueda continuar. En la figura 3.10, para que
la etapa 10 se active deben estar activas la etapa 8, la etapa 9, y además cumplirse la
condición lógica asociada a la transición T10.
3.1.3.5 Divergencia en <<Y>>
Una estructura de divergencia en <<Y>> se presenta cuando se produce un esquema

similar al de la figura 3.11, donde a partir de la activación de una etapa y el franqueo de
una transición, el proceso puede evolucionar por distintos caminos de forma simultánea,
es decir, activar distintas etapas. En la figura 3.11, cuando la etapa 7 se active y se
cumpla la condición lógica asociada a la transición T7, se activarán simultáneamente las
etapas 8 y 9.
T7
8 9
Figura 3.11 Divergencia en <<Y>>.
Al igual que ocurría con las bifurcaciones en <<O>>, debido a que los procesos que se
representan en un GRAFCET han de ser cerrados, siempre que se produzca una
divergencia en <<Y>> deberá existir una convergencia en <<Y>> en algún lugar del
grafo, y a la inversa.
3.1.3.6 Salto de etapas y bucles de repetición de una misma secuencia
El salto de etapas permite saltar una o varias etapas de una secuencia dada, por ejemplo,
cuando las acciones a efectuar en estas etapas lleguen a ser inútiles, o no tengan ningún
108
objeto. Por el contrario, un bucle, o repetición de una secuencia, permite volver a

comenzar una misma secuencia, mientras que una condición establecida no se cumpla.
En la figura 3.12 se muestran las estructuras de ambas acciones. El GRAFCET de la
izquierda representa un salto entre etapas, si estando activa la etapa 4 se cumple la
condición lógica asociada a la transición Ts, el franqueo de esta transición activaría la
etapa 7 y desactivaría la etapa 4, saltando las etapas 5 y 6. En el GRAFCET de la
derecha de la figura 3.12 se tiene la representación de un bucle, de forma que cuando se
active la etapa 6 se puede seguir hacia la 7 o regresar hacia la etapa 5, en función de las
condiciones lógicas de las transiciones implícitas en el bucle.
4 4
T1 T1
5 5
Ts Ts
T2 T2
6 6
T3 T3
7 7
Salto Bucle
Figura 3.12 Salto de etapas y bucle de repetición.
3.1.4 Ejemplos
Si recuperamos el ejemplo del “carro que va y viene”, presentado en el apartado 1.5.4,

y recordamos la RdP que tenía asociada, véase la figura 2.13. La descripción con la
metodología GRAFCET nos lleva al diagrama de la figura 3.13, muy similar a la RdP y
al grafo reducido de la figura 1.6 (a). Con una etapa inicial E0, para representar que “el
carro está parado”, la etapa E1 para representar que “el carro está moviéndose hacia la
derecha desde A hacia B” y la etapa E2 para representar que “el carro está moviéndose
hacia la izquierda desde B hacia A”.
La etapa E0, que estará activa cuando el carro se encuentre parado en el extremo A y el
botón esté sin pulsar, se desactivará en el momento que se pulse el botón. Esta acción
está representada en el GRAFCET mediante la transición P. Cuando se franquea esta
transición se desactiva la etapa inicial y se activa la siguiente etapa del diagrama, E1.
Por tanto, esta etapa lleva asociada la acción de desplazamiento a la derecha del carro,
que se representa en el diagrama con la acción D. La única forma de salir de la etapa E1
es llegar al punto B, que se representa en el diagrama con la transición B, y que debe
109
franquearse para pasar de la etapa E1 a la E2, etapa que lleva asociada la acción de
desplazamiento a la izquierda del carrito, representada con la acción I. Una vez en la
etapa E2 pueden ocurrir dos cosas para salir de ella, que se llegue de nuevo al punto A y
el motor se pare, representado con la transición AP , o que el carrito llegue al punto A y
vuelva otra vez a desplazarse hacia la derecha en dirección al punto B, representado por
la transición AP. En el primer caso, la etapa siguiente a la E2 es la etapa inicial E0 y en
el segundo caso la etapa siguiente a E2 es la etapa E1.
E0
E1 D
E2 I
AP AP
Figura 3.13 Diagrama GRAFCET del “carro que va y viene”.
Si recuperamos el ejemplo de los “carros que van y vienen por raíles diferentes”,
representado en la figura 1.9 pero suponemos que sólo están sincronizados en el
extremo izquierdo como consecuencia del botón. La descripción con la metodología
GRAFCET nos lleva al diagrama de la figura 3.14, donde se ha supuesto que el carrito 1
puede moverse entre los puntos A1 y B1 en ambos sentidos, y el carrito 2 entre dos
puntos A2 y B2. Cuando un carrito se mueve hacia la derecha significa que se desplaza
desde Ai hacia Bi y cuando se mueve hacia la izquierda, entonces se traslada desde Bi
hacia Ai. La etapa inicial E0, representa que ambos carros están parados en los
respectivos extremos A1 y A2, mientras que las demás etapas representan estados
individuales de cada uno de los carros. E1 y E3 representan los dos estados en
movimiento del carro 1, E5 el estado de llegada al extremo A1 del carro 1. E2, E4 y E6
representan los dos estados similares del carro 2.
Cuando se pulse el botón, representado por la transición P, se desactiva la etapa inicial

E0 y se activan las etapas E1 y E2. Esta estructura representa, tal y como ya sabemos,
una divergencia en <<Y>>, que representa el desplazamiento de los dos carritos desde
A1 hacia B1 y desde A2 hacia B2, respectivamente. Por consiguiente, estas dos etapas
llevan asociadas la acción de desplazamiento a la derecha del carrito1, que
110
representamos con la acción D1 y la acción de desplazamiento a la derecha del carrito2,

que representamos con la acción D2.
E0
E1 D1 E2 D2
B1 B2
E3 I1 E4 I2
A1 A2
E5 E6
A1 A2 P A1 A2 P
Figura 3.14 Diagrama GRAFCET de los carros que van y vienen sincronizados en el extremo izquierdo.
Igual que ocurría en el ejemplo anterior, la única forma de salir de estas dos etapas es
que el carrito1 llegue al punto B1 y comience a desplazarse hacia la izquierda en
dirección a A1 y que el carrito2 llegue al punto B2 y comience a desplazarse hacia la
izquierda en dirección a A2. La llegada al punto B1 del primer carrito se representa con
la transición B1 y la llegada al punto B2 del segundo carrito se representa con la
transición B2. La transición B1 se activará para que el primer carrito pase de la etapa E1
a la etapa E3 y la transición B2 para que el segundo carrito pase de la etapa E2 a la
etapa E4. Ambas etapas llevan asociadas la acción de desplazamiento del carrito
correspondiente hacia la izquierda, lo que para el primer carrito lo representamos como
la acción I1 y para el segundo como la acción I2.
Igual que ocurría en el ejemplo de un solo carrito, una vez situados en este tipo de
etapas pueden ocurrir dos cosas para salir de ellas, que se llegue de nuevo al
correspondiente punto A y el motor se pare, o que se llegue a ese mismo punto pero que
el motor no se pare. La problemática con la que nos encontramos ahora, que no existía
en el anterior ejemplo, es que como los puntos de retorno son los mismos para ambos
carritos, se necesita diseñar una estructura de convergencia en <<Y>> para poder
111
proponer la activación de las correspondientes transiciones. Tal y como se comentó en

los apartados teóricos siempre que se tuviese una divergencia en <<Y>>,
posteriormente el GRAFCET llevaría implícita una convergencia en <<Y>> para que el
diagrama fuese cerrado. En este punto, en ambas ramas del diagrama (una de ellas
representa el comportamiento del carrito 1 y la otra la del carrito 2), los carritos pasarán
a unas nuevas etapas E5 (carrito 1) y E6 (carrito2), tras franquear las transiciones A1 y
A2 respectivamente. En estas etapas no se realiza ninguna acción sencillamente se
plantea la convergencia de ambos caminos, para proceder a preguntar cuál va ser el
comportamiento siguiente del sistema. Si los carritos situados en sus respectivos puntos
A paran sus motores regresarán a la etapa inicial E0, para lo cual se debe franquear la
transición A1A 2P . Por el contrario, si esto no es así y los motores siguen encendidos,
se habrá franqueado la transición A1A2P, y los dos caminos regresarán al punto del
diagrama donde estos caminos comenzarán de nuevo, es decir, allí donde se producía la
activación de las etapas E1 y E2, respectivamente.
3.2 IMPLEMENTACION DE AUTOMATISMOS CON GRAFCET
Una vez realizado el GRAFCET del proceso que se desea controlar, el paso siguiente
consiste en obtener las condiciones de activación de las distintas etapas que lo
componen y de las acciones asociadas a esas etapas, es decir, llevar a cabo lo que se
conoce como la implementación del GRAFCET. Con este propósito se realiza un
proceso de normalización del GRAFCET, en el cual se irán obteniendo a partir del grafo
las condiciones booleanas de activación de cada una de sus etapas y de las acciones que
en ellas se realizan. Para obtener estas condiciones de activación se han de tener en
cuenta dos premisas:
• Una etapa se activará cuando esté activa la etapa inmediatamente anterior y la

receptividad asociada a la transición que las une sea cierta. De este modo la
activación de la etapa llevará consigo la desactivación de la etapa previa que
estaba activada.
• La acción asociada a la etapa en cuestión se ejecutará si la etapa asociada a ella

está activa.
Conseguidas las dos premisas citadas, el siguiente paso es implementar el proceso en un

lenguaje de programación apropiado para el controlador que se haya escogido como
unidad de control del proceso. Los objetivos principales de la implementación serán:
• Representar por medio de ecuaciones el automatismo dado por un GRAFCET

previamente diseñado.
• Aumentar la destreza en el diseño de automatismo mediante GRAFCET.
112
T4
E3
AND
4 T4 MEMORIA E4
E5 OR
AND T5
Entradas Salida
activación E4
Memoria AND
Binaria 5 T5 MEMORIA E5
E6 OR
OR
Entradas T6
desactivación
T4
E5
AND
6 T6 MEMORIA E6
E7 OR
T7
Figura 3.15 Implementación interna de una etapa.
Para llevar a cabo la implementación de un proceso elegido, se debe establecer que el

concepto de Etapa es equivalente al de Memoria Binaria que puede tomar dos valores
lógicos, que son: 0 o 1. La implementación constará de dos partes, una realizada
mediante lógica cableada, que utilizará biestables y puertas, y otra realizada mediante
lógica programada, que conllevará la programación de las distintas ecuaciones lógicas.
De esta forma un ejemplo podría ser el mostrado en la figura 3.15.
3.2.1 Obtención de funciones lógicas a partir del diagrama GRAFCET
En este apartado se va a describir el paso desde un diagrama GRACFET a una ecuación

lógica con la que se puede describir la activación, o desactivación, de una etapa dada en
el diagrama.
Si representamos con Q el estado de una etapa dada, con S la condición de activación de

una etapa y con R la condición de desactivación, se puede expresar la ecuación de
conexión y desconexión entre etapas de cualquiera de las dos formas que se muestra a
continuación:
Q t + ∆t = S + R Q t Q t + ∆t = R (S + Q t )
La condición de activación, S, se describe mediante la etapa en la que se encuentra el

GRAFCET y la transición asociada a esta etapa para que se active. Mientras que la
condición de desactivación, R, viene descrita tan sólo por la etapa que se desactiva
debido a la activación de la etapa siguiente y de la transición asociada a ella. En la
figura 3.16 se muestra un fragmento de un diagrama GRAFCET en el que se puede
definir las condiciones de activación y desactivación de la etapa En de la siguiente
manera:
113
En-1
Tn-1
En
Tn
En+1
Figura 3.16 Módulo secuencial de etapas.
S = E n−1Tn−1 R = E n+1
Por lo que la ecuación de conexión y desconexión entre etapas para este diagrama
podría expresarse de cualquiera de las dos siguientes maneras:
E n = E n−1Tn−1 + En+1E n E n = En+1 (E n−1Tn−1 + E n )
3.2.2 Funciones lógicas de las estructuras lógicas
Si en lugar de tener un diagrama GRAFCET lineal, tal y como el mostrado en la figura

3.16, tuviésemos un diagrama GRAFCET que representase algunas de las estructuras
lógicas comentadas en apartados anteriores, esto daría lugar a otro tipo de ecuaciones
algo más complejas para describir la activación de una etapa dada. En concreto, a
continuación se van a describir las distintas funciones lógicas, que representan cada una
de las cuatro estructuras lógicas comentadas en el apartado 3.1.3, que son la divergencia
y convergencia en <<O>>, y la divergencia y convergencia en <<Y>>.
En En - 1 En - 2
Tn - 1 Tn - 2
Tn + 1 Tn + 2
En + 1 En + 2
En
Figura 3.17 Divergencia y Convergencia en <<O>>.
Las ecuaciones de conexión que representan estas cuatro estructuras lógicas siguiendo
el mismo criterio que antes, son las siguientes:
114
• La divergencia en <<O>>, representada por el diagrama de la izquierda en la

figura 3.17 tendrá la siguiente ecuación de conexión de la etapa En, para la cual
se tienen las condiciones de activación (S) y desactivación (R) referidas a esa
misma etapa:
S = E n−1Tn−1 R = E n+1 + E n+2
E n = E n−1Tn−1 + En+1En+ 2E n
• La convergencia en <<O>>, representada por el diagrama de la derecha en la

figura 3.17 tendrá la siguiente ecuación de conexión de la etapa En, para la cual se
tienen las condiciones de activación (S) y desactivación (R) referidas a esa misma
etapa:
S = E n−1Tn−1 + E n−2 Tn−2 R = E n+1
E n = E n−1Tn−1 + E n−2 Tn−2 + En+1E n
• La divergencia en <<Y>>, representada por el diagrama de la izquierda en la

figura 3.18 tendrá la siguiente ecuación de conexión de la etapa En, para la cual
se tienen las condiciones de activación (S) y desactivación (R) referidas a esa
misma etapa:
S = E n−1Tn−1 R = E n+1 E n+ 2
E n = E n−1Tn−1 + ( En+1 + En+ 2 ) E n
• La convergencia en <<Y>>, representada por el diagrama de la derecha en la

figura 3.18 tendrá la siguiente ecuación de conexión de la etapa En, para la cual se
tienen las condiciones de activación (S) y desactivación (R) referidas a esa misma
etapa:
S = E n−1 E n−2 Tn−1 R = E n+1
E n = E n−1 E n−2 Tn−1 + En+1 E n
En En - 1 En - 2
Tn
Tn-1
En + 1 En + 2 En
Figura 3.18 Divergencia y Convergencia en <<Y>>.
115
De entre todas las etapas posibles en un diagrama GRAFCET, la etapa de inicialización

del diagrama responde a una serie de características especiales entre las cuales se
encuentra la función lógica que la representa, que queda como sigue:
E n = E n−1 Tn−1 + En+1 E n + ∑E ∀n

n Ci = ∑ En
∀n
El término Ci en una ecuación de conexión / desconexión de una etapa dada implica que
dicha etapa es una etapa inicial del diagrama GRAFCET, lo que significa que el
momento de la inicialización el resto de las etapas del diagrama se encuentran
desactivadas y que la etapa en cuestión es activada por un agente externo y no por una
transición ocurrida entre etapas.
3.2.3 Ejemplos
Ejemplo 3.2.3.1: Se pide analizar las funciones lógicas de cada una de las etapas y
acciones que se presentan en el diagrama GRAFCET de la figura 3.19.
E0
E1 L
Figura 3.19 Ejemplo de GRAFCET.
El GRAFCET de la figura 3.19 tiene dos etapas E0 y E1, y una acción asociada a la
etapa E1, representada con una L. La etapa E0 representa la etapa inicial del diagrama,
que debe poder ser activada de forma externa, aunque en el caso concreto del ejemplo el
diagrama representa un bucle que permite volver a la etapa E0 cuando estando activada
la etapa E1 se franquea la transición B. Todo esto debe tenerse en cuenta a la hora de
establecer la función lógica que representa la etapa en cuestión. La etapa E1 es una
etapa sencilla, que se encuentra en una estructura lineal del diagrama GRAFCET por lo
que su función lógica dependerá, tal y como se ha visto en la parte teórica, de cómo
están en un momento determinado de la evolución del diagrama sus etapas
inmediatamente anterior y posterior. En cuanto a la acción L se activa cuando lo hace la
etapa E1, por lo que su función lógica será muy sencilla.
Teniendo presente lo dicho las funciones lógicas de E0, E1 y L son las que se muestran
a continuación:
116
E0 = E1 B + E1 E0 + ∑E
∀n
n = E1 B + E1 E0 + E0 + E1
E1 = E0 A + E0 E1 L = E1
Teniendo en cuenta el comportamiento citado en el ejemplo y observando el diagrama,

las funciones lógicas que representan el comportamiento de las etapas E0 (inicial), E1,
E2 y las acciones D y L, son las siguientes:
E 0 = E 2 A P + E1 E 0 + ∑E
∀n
n = E 2 A P + E1 E 0 + E 0 + E1 + E 2
E1 = E 0 P + E 2 AP + E 2 E1 E 2 = E1 B + E0 E1 E 2
D = E1 I = E2
En este ejemplo se puede ver como la función lógica de la etapa E0 viene representada
por la función lógica una etapa inicial típica. La función lógica de la etapa E1 viene
representada por la función lógica de una estructura de convergencia en <<O>>. Y la
función lógica de la etapa E2 viene representada por la función lógica de una estructura
de divergencia en <<O>>.
Las funciones lógicas asociadas a cada etapa, así como las funciones lógicas de las
acciones asociadas se muestran a continuación:
E0 = E5E6 A1 A2 P + ( E1 + E2 ) E0 + ∑E
∀n
n = E5E6 A1 A2 P + ( E1 + E2 ) E0 + E0 + E1 + E2 + E3 + E4 + E5 + E6
E1 = E0 P + E5E6 A1 A2 P + E3 E1 E2 = E0 P + E5E6 A1 A2P + E4 E2
E3 = E1 B1 + E5 E3 E4 = E2 B2 + E6 E4
E5 = E3 A1 + E0 (E1 + E2 ) E5 E6 = E4 A2 + E0 (E1 + E2 ) E6
D1 = E1 D2 = E 2 I1 = E3 I2 = E4
Al igual que en el ejemplo anterior, la etapa inicial viene representada por E0. En esta
etapa es donde comienza a funcionar el diagrama GRAFCET, pero también se regresa a
ella cuando finaliza el movimiento de los dos carros, de modo que es posible inicializar
de nuevo el funcionamiento del mismo. Cuando se activa la transición P, es decir, se
ponen en funcionamiento los dos carros, se desactiva la etapa E0 y se activan de forma
117
simultánea las etapas E1 y E2 (debido a la estructura de divergencia en <<Y>> que se

muestra en la parte superior de la figura 3.14). La activación de las etapas E1 y E2 lleva
asociada la ejecución de las acciones D1 y D2. La activación de estas dos etapas
conlleva la ejecución de dos caminos independientes, el de la izquierda para los
movimientos del carro1 y el de la derecha para los movimientos del carro2, dentro de la
estructura del diagrama.
Del camino relativo al carro1 se deduce que para activar la etapa E3 es necesario
franquear la transición B1 y desactivar la etapa E1. Del mismo modo, el camino del
carrito2 la activación de la etapa E4 conlleva franquear la transición B2 y desactivar la
etapa E2. La activación de las etapas E3 y E4 lleva asociada la ejecución de las acciones
I1 e I2.
Siguiendo con la descripción de ambos caminos, para activar la etapa E5 debe

franquearse la transición A1 y desactivarse la etapa E3. No obstante, para expresar la
función lógica que representa la activación de esta etapa debe tenerse en cuenta que a
continuación se tiene en el diagrama una estructura de convergencia en <<Y>>, que
permite alcanzar dos etapas distintas en función de la transición que se franquee a
continuación. Del mismo modo en el camino de la derecha, para activar la etapa E6
debe franquearse la transición A2 y desactivarse la etapa E4. Al igual que para la etapa
E5, al representar su función lógica debe tenerse en cuenta que a continuación se
presenta la estructura de convergencia en <<Y>> recién comentada.
Una vez activadas las etapas E5 y E6 para proseguir existen dos caminos. O bien se
activa la transición A1A2P y se regresa al punto del diagrama donde está la estructura
de divergencia en <<Y>> antes comentada, o bien, se activa la transición A1 A 2 P y se
regresa a la etapa inicial.
3.3 DISEÑO ESTRUCTURADO
Los objetivos básicos a abordar en este apartado son los siguientes

(http://ttt.upv.es/jldiez/curso_aui):
• Estudiar los conceptos que justifican la necesidad de estructuración en el diseño

del modelo de un sistema, y también las herramientas que ayudan a
implementarlo.
• Aumentar más la destreza en el diseño de automatismos mediante GRAFCET,

haciendo uso del diseño estructurado y de las órdenes de forzado.
3.3.1 Necesidad de estructuración
Uno de los aspectos fundamentales de la estructuración a la hora de diseñar el modelo

de un sistema es la posibilidad de resolver problemas cada vez más complejos y
complicados, de forma que estructurando, o descomponiendo, el problema inicial en
problemas más pequeños, y de más sencilla resolución, resulte más fácil el llegar a una
solución satisfactoria para el problema inicial. A este tipo de estructuración se le suele
118
denominar representación jerarquizada, y fundamentalmente se suele estructurar

atendiendo sobre todo a diversos aspectos de funcionamiento del sistema.
Algunas de las complicaciones más significativas que suelen presentar los problemas de
automatización, y que se suelen identificar fácilmente con las distintas partes a diseñar
en las que se va a descomponer el sistema inicial, son entre otras las que se enumeran a
continuación:
• La inclusión de diferentes modos de marcha y funcionamiento.
• Las condiciones de seguridad y vigilancia, tales como el posicionamiento de

alarmas y emergencias.
• Otras cuestiones como el autodiagnóstico.
Cada una de estas partes será comentadas con un mayor detalle en apartados posteriores,
donde se pondrá de manifiesto las causas más significativas por las cuales es necesario y
útil, la estructuración de un problema de cara a obtener la mejor solución para él.
Uno de los principales motivos de la conveniencia de utilizar un diseño estructurado es

el hecho de poder analizar de forma más adecuada y precisa el problema que se está
estudiando. De esta forma se consigue una mejor compresión posterior del modelo, que
representará la solución del problema planteado.
3.3.2 Modos de marcha
Se define como modos de marcha a los distintos modos de funcionamientos en los que
pueden operar los sistemas automatizados, los cuales fundamentalmente se pueden
agrupar en tres:
• Modo de marcha indefinido, en el cual la ejecución del ciclo de funcionamiento

del proceso se realiza de forma indefinida, tras la autorización de puesta en
marcha inicial de dicho proceso por parte del operador.
• Modo de marcha uno a uno, en el cual la ejecución del ciclo de funcionamiento

del proceso se realiza uno en uno, es decir, de ciclo en ciclo. Para ello es necesaria
la autorización de puesta en marcha inicial del proceso por parte del operador,
cada vez que se ejecuta un nuevo ciclo en dicho proceso.
• Modo de marcha paso a paso, en el cual el operador ejerce un control permanente

sobre la activación de una o de más etapas del proceso, es decir, la ejecución de
cada ciclo del proceso se hace paso a paso, teniendo siempre la autorización del
operador en cada paso.
Gráficamente se podría establecer el esquema de la figura 3.20 para diferenciar los

posibles modos de marcha de funcionamiento de un proceso.
119
M o d o s d e M a rc h a
M a rc h a s a u to m á tic a s M a rc h a s d e
In te rv e n c ió n
F u n c io n a m ie n to F u n c io n a m ie n to
se m ia u to m á tic o a u to m á tic o
Figura 3.20 Clasificación de los modos de marcha de un proceso.
En la figura 3.20 los modos de marcha, u operación, de un proceso se clasifican

inicialmente en dos grupos: automáticos o de intervención. Los primeros, llamados
modos de marcha automáticos, son lo que vamos a tratar con más detalle en estos
apuntes, los cuales a su vez se subdividen en otros dos: modos de marcha con
funcionamiento semiautomático y con funcionamiento automático. Los segundos,
llamados modos de marcha de intervención, requieren un control estricto del
funcionamiento del proceso por parte del operador, tanto para llevar a cabo el ajuste del
proceso, como la puesta a punto de dicho proceso en todo momento. Este tipo de modo
es equivalente al que anteriormente llamamos modo de marcha paso a paso.
A continuación vamos a pasar a describir con más detalle los dos tipos de
funcionamiento en los que se subdividen los clasificados como modos de marcha
automáticos, y que se pueden ver reflejados en el esquema de la figura 3.20.
3.3.2.1 Funcionamiento semiautomático
Se considera que un proceso actúa, u opera, en modo de marcha automático con

funcionamiento semiautomático, cuando su funcionamiento se engloba en alguno de los
dos siguientes grupos:
• Funcionamiento ciclo a ciclo, que implica que en cada ejecución del ciclo de
funcionamiento del proceso se evalúa si está activado el arranque del ciclo (en la
figura 3.21 se representa mediante la transición AC) y si las condiciones iniciales
del mismo (en la figura 3.21 se representa mediante la transición Ci) son
adecuadas para comenzar dicha ejecución. Este tipo de funcionamiento se engloba
en lo que anteriormente llamamos modo de marcha uno a uno, en el cual era
necesaria la autorización de puesta en marcha inicial del proceso por parte del
operador (es decir, en la figura 3.21 franquear las transiciones AC y Ci), cada vez
que se ejecuta un nuevo ciclo en dicho proceso. La representación del
funcionamiento se muestra en la figura 3.21.
120
AC-Ci
FIN
Figura 3.21 Funcionamiento semiautomático ciclo a ciclo.
• Funcionamiento ciclo único, que implica que el proceso sólo se ejecutará una vez
debido a que la condición de repetición del ciclo es la contraria a la que lo activa
(ver figura 3.22). En la representación de la figura 3.22 se debe tener en cuenta
que la transición AC es la inversa de la transición AC.
AC-Ci
FIN
AC
Figura 3.22 Funcionamiento semiautomático ciclo único.
121
3.3.2.2 Funcionamiento automático
Se considera que un proceso actúa, u opera, en modo de marcha automático con

funcionamiento automático, cuando su funcionamiento se engloba en alguno de los dos
siguientes grupos:
• Funcionamiento automático con parada, que implica la posibilidad de parar el

funcionamiento del proceso en un punto concreto del ciclo de ejecución, como por
ejemplo después de la activación de la etapa inicial. El proceso lo que hace es
preguntar por la activación de una transición dada, en función del funcionamiento
de otro diagrama GRAFCET anexo. En la figura 3.23 se muestra un ejemplo de
este tipo de funcionamiento, donde la condición de parada en la ejecución del
proceso es la transición Ci-E20, lo que indica que si se cumplen las condiciones
iniciales y está activada la etapa 20 entonces el ciclo se ejecuta, y sino, el proceso
se para. No obstante, en el ejemplo de la figura 3.23 la condición para que la etapa
20 se active depende del funcionamiento de otro diagrama GRAFCET, anexo al
que describe el funcionamiento del proceso. La activación de esta etapa depende
de dos transiciones, la del arranque del ciclo (representada por la transición AC en
la figura 3.23) y la de parada del ciclo (representada por la transición pciclo en la
figura 3.23). También es necesaria la definición de la transición pciclo, que es la
inversa de pciclo, es decir, la no parada del ciclo.
Ci-E20
10 parada
AC-pciclo
MARCHA
20
AUTOMÁTICA
pciclo
FIN
Figura 3.23 Funcionamiento automático con parada.
122
AC - Ci
FIN- AUTO
FIN- CICLO A CICLO
Figura 3.24 Funcionamiento automático conmutable.
• Funcionamiento automático conmutable, que implica la posibilidad de combinar

dos modos de funcionamiento para un mismo proceso. Por un lado se permite que
el proceso se comporte en modo de funcionamiento automático puro, es decir,
ejecutando un ciclo tras otro de forma indefinida, o bien, que el proceso se
comporte en modo de funcionamiento ciclo a ciclo. Para ello, sólo es necesario
que al final de cada ciclo de ejecución el diagrama GRAFCET que representa el
proceso, éste tenga dos posibles caminos dependiendo de la transición que se
activa en un momento concreto de la evolución de dicho diagrama. (este tipo de
funcionamiento es el que se representa en la figura 3.24).
3.3.3 Seguridad
Se define como seguridad la ausencia de peligro tanto para personas como para
instalaciones. Para conseguir alcanzar unas condiciones de seguridad adecuadas es
necesario hacer reaccionar al automatismo de forma conveniente ante posibles fallos, o
defectos, en algunos de sus componentes, teniendo en cuenta que estos objetivos de
seguridad no se consiguen asegurando la fiabilidad, o distintas probabilidades de
funcionamiento del proceso, o la disponibilidad o ausencia de paradas existentes en el
mismo.
Son aspectos básicos a tener en cuenta para alcanzar unos objetivos de seguridad
analizar los posibles riesgos que éste puede correr, especificando la probabilidad y la
gravedad de estos riesgos, así como tener siempre presente el cumplimiento de la
normativa legal dentro del tipo de proceso del cual se desea asegurar su funcionamiento.
123
ALARMAS
LOCALES GENERALES
A AZ
BZ BZ
A AZ
Figura 3.25 Alarmas locales y generales.
Uno de los factores a tener en cuenta a la hora de diseñar la seguridad de un

automatismo es diseñar las posibles señales de alarma que puede provocar el proceso, y
también las posibles emergencias que un proceso dado puede establecer. Las alarmas
posibles de un automatismo se suelen clasificar en locales y generales, tal y como se
muestra en la figura 3.25. La diferencia fundamental entre ambas es que en las alarmas
locales sólo se pregunta por el estado de la alarma (representada por la transición Z en
la figura 3.25) en aquellos pasos del diagrama donde es posible que se produzca y en las
alarmas generales, se pregunta por el estado de la alarma cada vez que se franquea una
transición.
En cuanto a las emergencias, se pueden establecer de dos tipos, con secuencia o sin
secuencia:
• Con secuencia de emergencia. En este caso antes de franquear la transición que

permite el paso de una etapa a otra, la cual siempre lleva asociada la transición de
que no se ha producido ninguna emergencia, se abre otro posible camino para la
evolución del proceso donde se le pregunta por la posible activación de una
emergencia dada. Una vez en este camino, el proceso no ejecuta ninguna acción
hasta que se activa la emergencia, en ese momento la ejecuta y la desactiva
regresando a la etapa inicial del diagrama del proceso.
124
• Sin secuencia de emergencia. En este caso existen dos posibilidades lo que se

conoce como congelación del automatismo, cuyo diagrama GRAFCET se
corresponde con el diagrama derecho de la figura 3.25, y lo que se conoce como
inhibición de la acciones, lo cual lleva implícito un diagrama GRAFCET igual
que el anterior, sólo que cada etapa del diagrama lleva una acción ON/OFF
asociada.
3.3.4 Diseño estructurado
Se define como diseño estructurado del diagrama GRAFCET de un proceso dado,

cuando para llegar a la generación de este diagrama el problema inicial se descompone
en una serie de sub-problemas, cada uno de los cuales a su vez lleva asociado un
diagrama GRAFCET. De esta forma y atendiendo a lo anteriormente expuesto, para
realizar el diseño de un diagrama GRAFCET global, sería preciso generar una serie de
diagramas GRAFCET parciales para cada una de las partes del diseño anteriormente
comentadas, las cuales establecen los distintos ordenes de jerarquía en los que se
descompone el proceso, y que son:
• Modo de marcha.
• Seguridad.
• Producción.
Ahora bien, la pregunta clave a la hora de implementar la estructura del diagrama

GRAFCET de un proceso dado, basándose en un diseño estructurado, está en cómo
implementar las distintas partes en las que se subdivide el problema, para lo cual se
debe establecer lo que se conoce como órdenes de forzado.
Mediante una buena implementación de estas órdenes de forzado fundamentalmente se

puede:
• Modificar la situación de un diagrama GRAFCET parcial desde otro diagrama

GRAFCET parcial.
• Establecer relaciones entre distintos GRAFCET parciales.
• Hacer al sistema final coherente y determinista.
3.3.4.1 Tipos de órdenes de forzado
Existen distintos tipos de órdenes de forzado que pueden clasificarse en las siguientes:
• Forzado por impulso. De esta forma se considera el forzado como una acción
impulsional que activará la, o las, etapas forzadas por el diagrama GRAFCET
principal. El GRAFCET forzado evolucionará mientras esté activa la etapa del
diagrama GRAFCET principal que lo forzó. Su representación gráfica es tal como
la que se muestra en la figura 3.26.
125
F/GF:{0}*
Figura 3.26 Representación gráfica de un forzado por impulso.
• Forzado por nivel. De esta forma se considera el forzado como una acción de
nivel que se mantendrá activa siempre que la etapa correspondiente al diagrama
GRAFCET principal lo esté. Por lo tanto, el GRAFCET forzado no evolucionará
hasta que deje de ser forzado. Su representación gráfica es tal como la que se
muestra en la figura 3.27.
F/GF:{0}
Figura 3.27 Representación gráfica de un forzado por nivel.
3.3.4.2 Reglas de evolución del forzado
Existen distintas reglas de evolución del forzado, que son de utilidad para llevar a cabo
su implementación en un diagrama GRAFCET dado. A continuación se comentan las
más significativas:
• El forzado es una orden interna, distinta de las salidas del diagrama GRAFCET,
consecuencia de la evolución del proceso. Por lo tanto, los diagramas GRAFCET
forzados han de alcanzar de forma inmediata las situaciones impuestas por el
propio diagrama.
• El forzado es prioritario a cualquier otra actividad impuesta sobre el modelo, tales

como evolución, salidas, etc.
• Las reglas generales de evolución del GRAFCET, comentadas en apartados

anteriores de este mismo tema, se aplicarán siempre en coherencia con las órdenes
de forzado impuestas en el diagrama.
3.3.4.3 Características del forzado
Existen también una serie de características que sirven para identificar una orden de
forzado, las cuales se comentan a continuación:
• La orden de forzado se aplica de un diagrama GRAFCET parcial a otro diagrama

GRAFCET parcial.
• La orden de forzado no debe permitir ninguna ambigüedad o incoherencia en su

definición. De esta forma si un diagrama GRAFCET parcial fuerza a otro, lo
recíproco es imposible. Al igual que si en un instante de tiempo concreto, un
126
diagrama GRAFCET parcial sólo puede ser forzado por un único diagrama
GRAFCET parcial.
3.3.4.4 Implementación del forzado
Comentados los distintos tipos de órdenes, reglas de evolución y características de

forzado, en este apartado vamos a proceder a la implementación de dichas órdenes,
atendiendo sobre todo a su clasificación en cuanto al tipo de orden.
Si el forzado es por impulso, un ejemplo clarificador de su funcionamiento podría ser el

que se muestra en la figura 3.28. En ella se muestra el proceso de encendido//apagado
de una lámpara cuando se pulsa un interruptor. Para ello en la figura se tienen dos
diagramas GRAFCET, un GRAFCET principal situado a la izquierda de la figura y otro
forzado situado a la derecha. El diagrama principal está constituido por dos etapas. Para
pasar de la primera etapa (E5, etapa inicial) a la segunda (E6) es necesario franquear la
transición P, que representa la pulsación del interruptor, y por lo tanto, lleva consigo el
encendido de la lámpara. La activación de la etapa E6 lleva consigo una acción que
representa a su vez una orden de forzado por impulso, lo que implica la ejecución del
diagrama que se presenta a la derecha de la figura 3.28. El diagrama forzado también
está constituido por dos etapas. El paso de la primera a la segunda lleva consigo el
encendido de la lámpara, y el paso de la segunda a la primera el apagado de la misma.
Las ecuaciones asociadas son las siguientes:
E5 = E5 E6 + E 6 P + ∑E
∀n
n E0 = (E0 E1 + E1 Y) E 6 + E 6
E 6 = E 6 E5 + E5P E1 = (E1 E0 + E0 X) E 6
GRAFCET PRINCIPAL GRAFCET FORZADO
E5 E0
P X
E6 F/GF:{0}* E1 LUZ
P Y
Figura 3.28 Ejemplo de forzado por impulso.
Si el forzado es por nivel, usando el mismo ejemplo que para el anterior, todo es muy
similar, lo único que en el diagrama forzado, la etapa E0 de este diagrama debe ser una
etapa inicial. Atendiendo a las ecuaciones, la diferencia más significativa entre ambos es
127
que se debe modificar la ecuación de E0 atendiendo a que es una etapa inicial, y

además, que ahora el diagrama forzado se puede mantener activo aunque E6 no lo esté,
cosa que no ocurría antes. Ver figura 3.29.
Las ecuaciones asociadas serían entonces las siguientes:
E 5 = E5 E6 + E 6 P + ∑E
∀n
n E 0 = (E 0 E1 + E1 Y + ∑E
∀n
n ) E6 + E6
E 6 = E 6 E5 + E 5 P E1 = (E1 E0 + E 0 X) E 6
GRAFCET PRINCIPAL GRAFCET FORZADO
E5 E0
P X
E6 F/GF:{0} E1 LUZ
P Y
Figura 3.29 Ejemplo de forzado por nivel.
128
EJERCICIO 3.1
Construir el diagrama GRAFCET de un proceso que modele el encendido y apagado de

una lámpara. Supóngase que inicialmente la lámpara está apagada y que tras el
pulsado de un interruptor se enciende. Muéstrese también las ecuaciones lógicas
asociadas.
El comportamiento de la lámpara se puede modelar con dos etapas que nos indiquen
cuando la lámpara en cuestión se encuentra encendida o apagada, según el siguiente
diagrama GRAFCET (ver figura 3.30).
E0
E1 L
Figura 3.30 Diagrama GRAFCET solución del ejercicio 3.1.
El diagrama GRAFCET de la figura 3.30 es muy similar a la de la RdP propuesta como

solución para este mismo ejercicio en el tema 2 (ver figura 2.14). Tenemos una etapa E0
que representa el estado inicial en el cual la lámpara está apagada. Cuando se pulsa el
interruptor para encenderla, representado por la activación de la transición I, se
desactiva la etapa E0 y se activa la etapa E1, que representa la lámpara encendida.
Desde esta etapa sólo se puede salir si se vuelve a pulsar el interruptor pero en la
dirección de apagado, es decir, activando la transición I . En este caso la etapa E1 se
desactiva y se vuelve a activar la etapa E0. Por otro lado, cuando se activa la etapa E1 se
realiza la acción de iluminar la habitación que hemos representado en el GRAFCET con
la acción L.
Las ecuaciones lógicas asociadas al diagrama GRAFCET de la figura 3.30 son las
siguientes:
_
E 0 = E1 I + E1 E 0 + ∑E
∀n
n E1 = E 0 I + E0 E1
L = E1
Siguiendo las reglas comentadas a lo largo del capítulo, la ecuación lógica de toda etapa
función de su condición de activación (etapa precedente y transición que se debe activar
129
para llegar a ella), de la etapa activa y de la condición de desactivación negada (etapa

posterior), y además en el caso de la etapa inicial del diagrama se debe tener en
consideración el estado del resto de las etapas. Las acciones sólo serán función de la
etapa en la cual se generan.
Se puede observar que de las ecuaciones lógicas se concluye que la etapa E0 se activa,
es decir, la lámpara estará en su posición de apagado cuando se comience a operar con
el sistema, puesto que es la etapa inicial (tercer término de la ecuación), o cuando
estando encendida previamente se pulse el interruptor en la dirección de apagado
(primer término de la ecuación). La ecuación de la etapa E1, que representa la lámpara
encendida estará activa cuando habiendo estado la lámpara previamente apagada se
pulse el interruptor en la dirección de apagado y se garantice que la lámpara está
apagada.
EJERCICIO 3.2
Construir el diagrama GRAFCET, así como las condiciones lógicas de activación de

sus etapas, para un sistema que modele el encendido y apagado de una lámpara como
la del ejercicio 3.1, pero permitiendo ahora que el sistema se pueda conectar y
desconectar desde un agente externo.
Teniendo en cuenta el diagrama GRAFCET modelado para el ejercicio anterior (ver

figura 3.30), la posibilidad de que el sistema de encendido y apagado de la lámpara se
pudiese conectar y desconectar desde un agente externo en cualquier momento, lleva
consigo la necesidad de más etapas en el diagrama GRAFCET (ver figura 3.31), al igual
que ocurría con las redes de Petri en el tema 2 (ver figura 2.17).
E2
E0
C I
E1 L
C I
130
Manteniendo la nomenclatura empleada en el ejercicio 3.1 para las etapas de apagado y

encendido de la lámpara, así como las acciones y transiciones necesarias, el diagrama
GRAFCET de la figura 3.31 debe incluir una nueva etapa inicial E2, en la que se
permita que el sistema espere hasta se conecte el circuito de encendido y apagado de la
lámpara. La única forma de que se desactive esta etapa y se active la etapa E0 que
representa la conexión del sistema cuando la lámpara está apagada, será la activación de
la transición C, que representa la conexión del sistema.
Por otro lado en cualquier momento el sistema podría ser desconectado y regresar por
tanto a la etapa inicial de espera de conexión E2. Para representar este comportamiento,
a la salida de las etapas E0 y E1 de apagado y encendido de la lámpara se debe
incorporar la posibilidad de continuar por el camino que teníamos reflejado en el
GRAFCET de la figura 3.30, o bien, regresar a la etapa inicial E2, franqueando para ello
la transición C , que representa la desconexión del sistema. Esta configuración incorpora
a la salida de estas dos etapas una estructura de divergencia en <<O>>, lo que implica la
necesidad de dos estructuras de convergencia en <<O>> en el diagrama para que éste
quede cerrado. Dichas estructuras, tal y como se muestra en la figura se dan a la entrada
de las etapas E2 y E0, respectivamente.
Las condiciones lógicas para cada etapa y acción del diagrama GRAFCET de la figura
3.31 son las siguientes:
_
E 0 = E 2C + E1 I + E1 E 2 E 0 E1 = E 0 I + E0 E 2 E1
__ __
E 2 = E 0 C + E1 C + E0 E 2 + ∑E
∀n
n
L = E1
Las condiciones lógicas de cada una de las etapas tienen las mismas dependencias que
hemos comentado en el ejercicio 3.1, tan sólo considerar que la etapa E0 se ve afectada
a la entrada por una estructura de convergencia en <<O>> y a la salida por otra de
divergencia en <<O>>. La etapa E1 se ve afectada a la salida por una estructura de
divergencia en <<O>> y la etapa E2 representa la etapa inicial y a su entrada se ve
afectada por una estructura de convergencia en <<O>>. Todas estas estructuras se han
reflejado en las ecuaciones lógicas que describen cada una de las etapas del diagrama
GRAFCET mostrado en la figura 3.31.
Se puede observar que de las ecuaciones lógicas se concluye que la etapa E0 se activa,
es decir, la lámpara estará en su posición de apagado cuando se conecte el sistema y,
una vez conectado cuando estando encendida previamente se pulse el interruptor en la
dirección de apagado. En todo momento el hecho de que la lámpara esté apagada debe
garantizar que no está encendida y que el sistema está conectado y funcionando. La
ecuación de la etapa E1, que representa la lámpara encendida estará activa cuando
habiendo estado la lámpara previamente apagada se pulse el interruptor en la dirección
de apagado y se garantice que la lámpara está apagada y que el sistema está conectando
y funcionando adecuadamente. La última etapa, etapa E2 que representa la desconexión
del sistema estará activa cuando se pide la desconexión del mismo desde cualquiera de
131
las otras dos etapas, cuando comience a funcionar el diagrama dado que es la etapa
inicial y al igual que ocurría en las otras etapas, el estar en esta situación significa que la
lámpara está desconectada es decir ni en posición de apagado ni en posición de
encendido.
EJERCICIO 3.3
Construir el diagrama GRAFCET, así como las condiciones lógicas de activación de

sus etapas, para un proceso que modele el comportamiento de un semáforo. Supóngase
que inicialmente el semáforo está en verde y de forma temporizada pasa a ámbar y de
ahí a rojo, cerrando el ciclo de colores y regresando de nuevo al verde.
El comportamiento del sistema que queremos es muy similar al del ejercicio anterior. El
sistema necesita tres etapas que son: verde – ámbar – rojo. Cada una de ellas provoca
una acción que es la de colorear la luz del semáforo con el color adecuado. De nuevo el
diagrama GRAFCET solución de este problema tendrá una relación directa con la RdP
que se ha dado como solución para este mismo problema en el tema 2 (ver figura 2.19).
V
E0 CV
TV
A
E1
CA
TA
R
E2
CR
TR
De esta forma, el GRAFCET (ver figura 3.32) comenzará en la etapa E0 que representa
el verde del semáforo (y por lo tanto lleva consigo la acción V) y permanece en esa
etapa, hasta que se cumple el tiempo que debe permanecer el semáforo en verde. La
etapa lleva asociada un contador cuya función es establecer el tiempo que el semáforo
debe permanecer en ella. De este modo la primera etapa del GRAFCET lleva asociadas
dos acciones la (V) que hace que el color del semáforo sea verde y la (CV) que pone en
marcha el contador del tiempo que debe permanecer en esa etapa. Cuando se cumple el
tiempo que el semáforo debe estar en verde se franquea la transición TV, el semáforo
cambia a ámbar, se activa la etapa E1 del GRAFCET y se desactiva la E0. La etapa E1
representa el semáforo en ámbar y realiza igual que la anterior dos acciones. Una
primera acción A que lo que hace es poner la luz del semáforo en ámbar y una segunda
132
acción CA que establece igualmente mediante un contador el tiempo que el semáforo ha

de permanecer en esta etapa. Cuando se cumple el tiempo que el semáforo debe
permanecer en ámbar, se activa la etapa E2, se franquea la transición TA y se desactiva
la etapa E1. La etapa E2 representa el semáforo en rojo, e igual que las anteriores etapas
del GRAFCET realiza dos acciones. Una primera acción R que lo que hace es poner la
luz del semáforo en rojo y una segunda acción CR que establece el tiempo que el
semáforo ha de permanecer en esta etapa. Cuando se cumple el tiempo que el semáforo
debe permanecer en rojo, se activa la etapa E0, se franquea la transición TR y se
desactiva la etapa E2. Con este último paso se cierra el ciclo de colores del semáforo,
volviendo éste a estar de nuevo en la posición de verde.
Las ecuaciones lógicas asociadas al diagrama GRAFCET de la figura 3.32 son las
siguientes:
E 0 = E 2 TR + E1 E 0 + ∑E
∀n
n E1 = E 0 TV + E 2 E1
E 2 = E1 TA + E 0 E 2
V = E0 A = E1 R = E2
CV = E 0 CA = E1 CR = E 2
De las ecuaciones se puede interpretar que el semáforo estará en verde (etapa E0)
cuando comience a funcionar el diagrama (etapa inicial del mismo) o después de haber
permanecido en rojo el tiempo correspondiente a ese color. Del mismo modo se debe
garantizar que mientras está en verde no se pasa al siguiente color que representa el
ámbar. En cuanto a la permanencia del semáforo en ámbar (etapa E1) se produce
después de haber permanecido en verde el tiempo correspondiente a ese color, y del
mismo modo que antes se debe garantizar que mientras está en ámbar no se pasa al
siguiente color que representa el rojo. Por último, en cuanto a la permanencia del
semáforo en rojo (etapa E2) se produce después de haber permanecido en ámbar el
tiempo correspondiente a ese color, y del mismo modo que antes se debe garantizar que
mientras está en rojo no se pasa al siguiente color que representa el verde.
EJERCICIO 3.4
Construir el diagrama GRAFCET y las ecuaciones lógicas asociadas de un proceso que

modele el comportamiento de un cruce con dos semáforos. Se ha de tener en cuenta que
cuando uno de ellos esté abierto el otro debe de estar cerrado y a la inversa.
Supongamos que inicialmente el semáforo 1 está en verde y el semáforo 2 está en rojo.
Evidentemente en la resolución de este problema se han de conjugar dos ciclos de

colores de un semáforo convencional como el representado en el ejercicio 3.3. Por tanto,
un ciclo de colores para cada uno de los dos semáforos que componen el cruce. Las
etapas del ciclo de colores del primer semáforo se corresponden con E0, E1 y E2 y las
133
etapas del ciclo de colores del segundo semáforo con E5, E6 y E7 En ambos las
secuencias son verde-ámbar-rojo.
Se debe considerar que en un cruce real durante un periodo de tiempo breve los dos
semáforos estarán en rojo al mismo tiempo para no permitir un choque entre los coches
que están cruzándose. La estructura del GRAFCET solución de este ejercicio (ver figura
3.33) es muy similar a la RdP mostrada como solución de este mismo ejercicio en el
tema 2 (ver figura 2.21), por lo que se necesita una etapa de permanencia en rojo para el
segundo semáforo cuando el primero realiza el ciclo de colores (etapa representada en el
diagrama por E3) y otra etapa de permanencia en rojo del primer semáforo para cuando
el segundo realiza el ciclo de colores (etapa representada en el diagrama por E4).
La primera vez que se da esta situación en el cruce es cuando el primer semáforo acaba
de realizar su ciclo de colores y el segundo está en rojo. En este momento los dos
semáforos están en rojo y transcurrido el tiempo de permanencia del primer semáforo en
rojo, se valida la transición TR (permanencia en rojo de un semáforo), pero en lugar de
poner de nuevo el primer semáforo en verde como ocurría en el ejercicio anterior, se
deja en rojo y se activa el ciclo de colores del semáforo 2. De cara a la construcción del
diagrama esto conlleva a colocar en la transición TR una estructura de convergencia en
<<Y>> y una estructura de divergencia en <<Y>>.
La parte inferior del GRAFCET de la figura 3.33 se comporta igual que la superior, sólo
que ahora el ciclo de colores en el semáforo se da en el segundo semáforo y la
permanencia en rojo es para el primer semáforo. Para cerrar el diagrama de nuevo hay
una estructura de convergencia en <<Y>> y otra de divergencia en <<Y>> entorno a la
transición TR, que regresan el GRAFCET a su posición inicial.
Aparte de etapas y transiciones, en el GRAFCET de la figura 3.33 se han considerado

las distintas acciones que generan las etapas que lo componen. Al igual que ocurría en el
GRAFCET de la figura 3.32, las etapas implícitas en los ciclos de colores son las
mismas que teníamos para el caso de un único semáforo, es decir, el color con el que
iluminan el foco del semáforo (V1, A1, R1, para el primer semáforo y V2, A2, R2, para
el segundo semáforo) y el tiempo de permanencia en cada una de esas etapas, que viene
determinado por la salida del contador que las implementa (CV, CA, CR, estos tiempos
son independientes del semáforo).
En el caso de las etapas de permanencia en rojo E3 y E4 no es necesario utilizar un

circuito contador para generarlas, sino que es suficiente con una memoria. De este modo
en ambas etapas la única acción que se genera es la de poner el foco del semáforo en
rojo (R2 y R1 respectivamente).
134
V1 R2
E0 CV E3
TV
A1
E1
CA
TA
R1
E2
CR
TR
V2
R1 E5
E4 CV
CA
A2
E6
CA
CR
R2
E7
CR
TR
Las ecuaciones lógicas asociadas al GRAFCET de la figura 3.33 son las siguientes:
135
E 0 = E 4 E 7 TR + E1 E 0 + ∑E
∀n
n E1 = E 0 TV + E 2 E1
E 2 = E1 TA + ( E 4 + E 5 ) E 2 E 3 = E 4 E 7 TR + ( E 4 + E5 ) E 3 + ∑E
∀n
n
E 4 = E 2 E 3 TR + ( E 0 + E3 ) E 4 E 5 = E 2 E 3 TR + E 6 E 5
E 6 = E 5 TV + E 7 E 6 E 7 = E 6 TA + ( E 0 + E3 ) E 7
V1 = E 0 A1 = E1 R 1 = E2 + E4 V2 = E 5 A2 = E 6 R2 = E 7 + E 3
CV = E 0 + E 5 CA = E1 + E 6 CR = E 2 + E 7
De ellas, al igual que siempre se puede interpretar el significado del diagrama.

Inicialmente se tiene la situación de que el primer semáforo está en verde y el segundo
en rojo, por eso las ecuaciones de E0 y E3 reflejan que ambas son etapas iniciales del
diagrama. De la ecuación E0 se deduce que el primer semáforo estará en verde cuando
se garantice que no está en ámbar y cuando los dos semáforos hayan estado previamente
en rojo y segundo haya sido el que más recientemente ha realizado el ciclo de colores.
De la ecuación E1 se deduce que el primer semáforo permanecerá en ámbar mientras no
pase a rojo, y siempre y cuando previamente el semáforo haya estado en verde y haya
transcurrido el tiempo que debía permanecer en ese color. De la ecuación E2 se deduce
que el primer semáforo permanecerá en rojo mientras no pase a rojo permanente (es
decir, al estado en el cual el segundo semáforo del cruce realizará su ciclo de colores
comenzando por el verde), y siempre y cuando previamente el semáforo haya estado en
ámbar y haya transcurrido el tiempo que debía permanecer en ese color.
De la ecuación E3, relativa al segundo semáforo, se deduce que éste permanecerá en el

estado que hemos llamado de rojo permanente mientras el primer semáforo realiza su
ciclo de colores y hasta que se entre en su estado de rojo permanente, lo que implicará
que transcurrido el tiempo necesario el segundo semáforo pasará a verde. Por otro lado
aparte de por se estado inicial a esta situación se llega cuando se ha cerrado el ciclo de
colores del segundo semáforo y se va a realizar un nuevo ciclo para el primero.
Las ecuaciones relativas a E4, E5, y E6 tienen la misma interpretación que las de E0, E1
y E2 pero referidas al segundo semáforo.
EJERCICIO 3.5
Construir el diagrama GRAFCET que modele el comportamiento de un montacargas

utilizado en la reparación de un edificio para trasladar cosas entre el suelo de la calle
y el tejado. Supóngase que el montacargas siempre está operando externamente y que
no tiene parada en las distintas plantas del edificio.
136
Para modelar el diagrama supondremos que inicialmente el montacargas está a pie de

calle, y parado, hasta que se le ordene comenzar a subir. De forma que cuando se pulse
el botón correspondiente, el montacargas comenzará a subir hasta que llegue al tejado.
Llegado al tejado el montacargas parará, hasta que se le una orden de bajada. Las
peticiones de bajada y subida sólo serán atendidas en las plantas en las que para y
después de que el montacargas haya descargado o cargado. Todas estas consideraciones
ya se tuvieron en cuenta en la RdP que se mostró como solución a este mismo problema
en el tema 2 (ver figura 2.26), por lo que la estructura del diagrama GRAFCET
resultante será muy similar (ver figura 3.34).
E0 E1
CS
E2 S
E3 C
PB
E4 E5
E5
CB
E6 B
PC
E7 C
PS
El diagrama de la figura 3.34 funciona de la siguiente manera, inicialmente se tienen

dos etapas E0 y E1 que hasta que no estén activas el sistema no comenzará a funcionar.
La primera indica que el montacargas está en planta calle y la segunda que el operador
ha pulsado el botón de iniciar la subida de dicho montacargas. Cuando esto sucede, el
137
montacargas comenzará a ascender para la cual debe franquear la transición CS

(comenzar a subir). En este momento se desactivan las etapas E0 y E1, activándose la
etapa E2 que representa la acción de subida que lleva asociada (acción S). El
montacargas permanecerá en esta etapa hasta que llegue al tejado, lo cual se representa
en el diagrama GRAFCET con la transición T. Una vez que se franquea esa transición
se desactiva la etapa E2 y se activa la etapa E3 que representa la carga o descarga del
montacargas y lleva asociada la acción C de carga o descarga del montacargas. En esta
etapa en la que se permanece hasta que se finaliza este proceso y por lo tanto se habilita
la transición PB, que indica que el montacargas está preparado para bajar. Una vez que
se franquea la transición PB, se desactiva la etapa E3 y se activa la E4 que representa la
espera del montacargas en el tejado a que el operador pulse la tecla de bajada al mismo.
La pulsación por parte del operador de la tecla de bajada representa la etapa E5 y

constituye otra etapa inicial del GRAFCET, que puede ser activada en cualquier
momento pero que sólo podrá ser atendida cuando el montacargas esté en la etapa que
representa la espera en el tejado. Cuando las etapas E4 y E5 están activas el GRAFCET
está preparado para franquear la transición CB que representa que el montacargas
comienza a bajar. De esta forma se desactivan las etapas E4 y E5 y se activa la etapa E6
que lleva asociada la acción B que representa la bajada. Una vez en este punto el
proceso es el mismo que en la subida. El GRAFCET permanece en la etapa E6 hasta
que llega a la planta de calle, representada por la transición PC. Franqueada está
transición se desactiva la etapa E6 de partida y se activa la E7 que representa la carga o
descarga del montacargas al nivel de planta calle, que lleva asociada de nuevo la acción
la acción C. Por último, cuando el montacargas ha sido cargado o descargado, según sea
necesario en cada caso, el GRAFCET franqueará la transición PS, que representa la
preparación por parte del montacargas para comenzar de nuevo a subir, desactivará ña
etapa E7 y activará de nuevo la etapa E0.
Teniendo presente el comportamiento del diagrama, las ecuaciones lógicas asociadas a

las distintas etapas del GRAFCET de la figura 3.34 son las siguientes:
E 0 = E 7 PS + E 2 E 0 + ∑E
∀n
n E1 = E 2 E1 + ∑E
∀n
n
E 2 = E 0 E1 CS + E3 E 2 E3 = E 2 T + E4 E3
E 4 = E 3 PB + E 6 E 4 E 5 = E6 E 5 + ∑E
∀n
n
E 6 = E 4 E 5 CB + E 7 E 6 E 7 = E 6 PC + E 0 E 7
S = E2 C = E3 + E7 B = E6
138
EJERCICIO 3.6
Modelar el siguiente sistema de producción mediante un diagrama GRAFCET. El

sistema consta de dos máquinas (M1 y M2), dos cintas transportadoras con un palet en
cada una de ellas (C1 y C2) y dos tipos de piezas (a y b) para ser procesadas. La
secuencia de operaciones posibles, ha de respetar las siguientes restricciones:
1. Para una pieza del tipo a, el proceso comienza en la máquina M1.

Finalizada la operación, se emplea C1 para transportar la pieza a M2 y tras
ser procesada sale del sistema.
2. Para una pieza del tipo b el proceso es el mismo que para la pieza tipo a
pero empleando C2 en el transporte.
3. Las máquinas no pueden realizar operaciones consecutivas sobre el mismo
tipo de pieza.
4. Para que M1 quede libre una vez finalizado el proceso de una pieza tipo a es
5. Para que M1 quede libre una vez finalizado el proceso de una pieza tipo b es
La resolución de este problema considera que el almacén es infinito y por lo tanto

siempre hay piezas del tipo a y del tipo b que en un momento determinado, que
necesitan ser procesadas. Por otro lado, los palets C1 y C2 tendrán dos posiciones,
superior e inferior.
Con estas consideraciones vamos a ver cómo se formaliza el diagrama GRACFET

solución a este problema, así como las ecuaciones lógicas que lo describen. Recuerde
que estas consideraciones ya se tuvieron en cuenta cuando para este mismo sistema se
analizó la RdP asociada (ver figura 2.32).
El diagrama GRAFCET que se muestra en la figura 3.35 realiza las siguientes acciones.
Se consideran dos etapas iniciales que son E0 y E1. La primera representa el
procesamiento por parte de M1 de una pieza de tipo a (por tanto esta etapa lleva
asociada la acción M1_a), y la segunda el posicionamiento por parte del palet C1 en la
parte superior, esperando a transportar una pieza de tipo a desde M1 a M2 (por tanto
esta etapa lleva asociada la acción C1_S). Cuando M1 finaliza el proceso de la pieza de
tipo a y siempre y cuando C1 esté a la espera para transportar esa pieza, se franquea la
transición M1a_TC1a. Esta transición representa exactamente el fin del procesamiento
de una pieza del tipo a por parte de M1 y el transporte desde M1 a M2 de esa pieza por
parte del palet C1. El franqueo de esta transición conlleva desactivar las etapas E0 y E1
y activar las etapas E2 y E3. La etapa E2 representa el procesamiento por parte de M1
de una pieza de tipo b (por tanto esta etapa lleva asociada la acción M1_b), y la etapa
E3 el posicionamiento por parte del palet C1 en la parte inferior, esperando a poder
cargar la pieza a transportada en la máquina M2 para su procesamiento (esta etapa lleva
asociada la acción C1_Ia).
Para poder continuar procesando, mientras M1 esté procesando una pieza de tipo b
(etapa E2 activa), el palet C2 debe colocarse en posición superior a la espera de poder
transportar esa pieza cuando finalice su proceso por parte de M1. Esto se representa en
el diagrama mediante la etapa E4, que lleva asociada la acción C2_S. Cuando tanto E2
como E4 están activas es el momento de franquear la transición M1b_TC2b, una vez
139
que M1 finalice con el proceso de la pieza de tipo b. El franqueo de dicha transición

conlleva la desactivación de esas dos etapas, el transporte de la pieza de tipo b
procesada por parte de C2 desde M1 a M2. De esta forma se activará de nuevo la etapa
E0 permitiendo que M1 procese otra pieza tipo a y se posiciona el palet C2 en la
posición inferior con una pieza de tipo b, esperando a poder cargarla en M2 para que sea
procesada. Esto se representa en el GRAFCET con la etapa E6, que lleva asociada la
acción C2_Ib.
En la otra rama del diagrama, teníamos el palet C1 en la posición inferior con una pieza
de tipo a, a la espera de ser procesada por la máquina M2 (etapa E3 activa tras el
franqueo de M1a_TC1a). Por tanto, para poder llevar acabo este proceso se necesita de
una nueva etapa E5, que represente el procesamiento en M2 de una pieza del tipo b (esta
etapa llevará asociada la acción M2_b), que cuando finalice y libere esta pieza pasará a
procesar la pieza de tipo a que tiene el palet C1. Cuando tanto E3 como E5 están activas
es el momento de franquear la transición M2b_TC1, una vez que M2 finalice con el
proceso de la pieza de tipo b que la ocupa. El franqueo de dicha transición conlleva la
desactivación de esas dos etapas, el comienzo del procesamiento de una pieza de tipo a
por parte de M2 (etapa E7 que lleva asociada la acción M2_a) y el regreso de C1 a la
posición superior pero sin pieza, es decir, vacío (activación de nuevo de la etapa E1).
M1_a E0 E1 C1_S
M1a_TC1a
C2_S M1_b E2 E3 C1_Ia E5 M2_b

E4
M1b_TC2b M2b_TC1
C2_Ib E6 E7 M2_a
M2a_TC2
140
Por último cuando las etapas E6 y E7 están activas, significa que M2 está procesando
una pieza de tipo a que ya ha sido procesada por M1 y que el palet C2 está cargado con
una pieza de tipo b que espera ser procesada por M2 pero que ya lo ha sido por M1.
Cuando M2 finaliza el procesamiento de la pieza de tipo a que la mantiene ocupada es
el momento de franquear la transición M2a_TC2, que representa el fin del
procesamiento de M2 de la pieza de tipo a, la carga de la pieza de tipo b a la espera en
M2 y el transporte de C2 hacia la posición superior pero ahora sin pieza alguna. Por
tanto, el franqueo de la transición conlleva la desactivación de las etapas E6 y E7 del
GRAFCET y la activación de nuevo de E4 (palet C2 en posición superior y sin pieza) y
E5 (máquina M2 procesando una pieza de tipo b).
Las ecuaciones asociadas a las etapas y acciones del GRAFCET de la figura 3.35 se
muestran a continuación:
E 0 = E 6 E 7 M2a_TC2 + (E 2 + E3 ) E 0 + ∑E
∀n
n
E1 = E 6 E 7 M2a_TC2 + (E 2 + E3 ) E1 + ∑E
∀n
n
E 2 = E 0 E1 M1a_TC1a + (E 0 + E 6 ) E 2
E 3 = E 0 E1 M1a_TC1a + (E1 + E 7 ) E 3
E 4 = E 6 E 7 M2a_TC2 + (E 0 + E 6 ) E 4 + ∑E
∀n
n
E 5 = E 6 E 7 M2a_TC2 + (E1 + E 7 ) E 5 + ∑E
∀n
n
E 6 = E 2 E 4 M1b_TC2b + (E 4 + E5 ) E 6
E 7 = E 3 E 5 M2b_TC1 + (E 4 + E5 ) E 7
M1_a = E 0 M1_b = E 2 M2_a = E 7 M2_b = E 5
C1_S = E1 C1_Ia = E 3 C2_S = E 4 C2_Ib = E 6
141
142
TEMA 4
Formalismo DEVS (Discrete EVents

dynamic Systems)
El formalismo DEVS (Zeigler y col., 2000) es una teoría de sistemas que va más allá
del modelado de sistemas de eventos discretos, considera que cualquier sistema está en
todo momento en un estado, s ∈ S. Pero que puede cambiar a otro estado s’ ∈ S como
consecuencia de que el tiempo de permanencia en el estado s ya se ha consumido
(cambio de estado que se conoce como transición interna), o como consecuencia de que
se ha producido un evento (cambio de estado que se conoce como transición externa).
También considera que el sistema recibe información de su entorno o de otros sistemas
a través de sus entradas, en forma de eventos. Mientras que genera información para su
entorno o eventos para otros sistemas a través de sus salidas. La llegada de eventos
puede ocurrir en cualquier instante de tiempo, mientras que la generación de salidas sólo
se produce como consecuencia de haber agotado el tiempo de permanencia en un
estado.
4.1 MODELOS ATÓMICOS
Un modelo atómico es una especificación del formalismo DEVS para un modelo

comportamental (caja negra) de un sistema con varias entradas y varias salidas pero que
también puede carecer de algunas de ellas. Todo modelo atómico se especifica como
una estructura matemática de la siguiente forma:
M = < X, Y, S, δext, δint, λ, ta >

donde
X es el conjunto de nombres y valores de las entradas
Y es el conjunto de nombres y valores de las salidas
S es el conjunto de estados
δext : Q x X → S, es la función de transición externa, donde
Q = {(s,e)|s ∈ S, 0 ≤ e ≤ ta(s)} es el conjunto total de estados
e es el tiempo transcurrido desde la última transición (interna o externa) de
estados
143
Formalismo DEVS (Discrete EVents dynamic Systems)
δint : S → S, es la función de transición interna

λ : S → Y, es la función de salida
ta : S → R+0,∞, es la función de avance de tiempo, determina el tiempo que el
sistema permanecerá en todos y cada uno de los estados si no se presenta ningún
evento externo, estos tiempos pueden tomar valores reales positivos (incluidos el
valor 0 y el ∞)
Si el sistema está en el estado s ∈ S y no tiene lugar ningún evento externo, el sistema

permanecerá en ese estado s por un tiempo ta(s). Es decir, cada estado del sistema tiene
asociado un tiempo ta de permanencia máxima que puede ser diferente al de cualquier
otro. Cuando el tiempo ta asociado a un estado tiene el valor 0 se dice que el estado es
transitorio, pues nunca podrá permanecer en él. En cambio si el tiempo ta asociado a un
estado toma el valor infinito se dice que el estado es pasivo, en ausencia de evento, el
sistema permanecería indefinidamente en este tipo de estado. En el resto de los casos,
cuando el tiempo ta asociado a un estado tiene un valor finito, después de transcurrido el
tiempo de permanencia se enviará a la salida el valor determinado por la función de
salida λ(s), y el sistema cambiará de estado, concretamente al estado que determine la
función de transición interna δint(s). Es decir, el cambio de estado producido por una
transición interna depende únicamente del estado actual.
En cambio, si el sistema está en el estado s ∈ S y tiene lugar un evento externo x ∈ X

antes de que se agote el tiempo de permanencia en el estado, se producirá un cambio de
estado, concretamente al estado que determine la función de transición externa
δext(s,e,x). Es decir, el cambio de estado producido por una transición externa dependerá
del estado actual, del tipo de evento y del tiempo transcurrido desde que se produjo la
última transición (interna o externa).
En definitiva, la función de transición interna δint(s) determina el cambio de estado en el

sistema cuando no se producen eventos, mientras que la función de transición externa
δext(s,e,x) determina el cambio de estado en el sistema cuando se producen eventos.
El comportamiento de un modelo atómico se puede representar mediante un

cronograma, con el siguiente conjunto de registros temporales: los eventos de entrada, la
evolución de las variables de estado, la evolución de la variable e (tiempo transcurrido
desde la última transición de estado) y los eventos de salida. La figura 4.1 es un ejemplo
de cronograma (Wainer, 1996) de un modelo DEVS con una entrada, ocho estados y
una salida. Por la trayectoria de entrada se observa que se han producido dos eventos, de
valores x1 y x2 respectivamente, en los instantes de tiempo t1 y t2. Por la trayectoria de
los estados se observa que el sistema estaba inicialmente en el estado s1, del que ha
pasado al estado s2 como consecuencia de una transición interna, tras haber generado el
correspondiente evento y1 en la salida. Que el sistema ha permanecido en el estado s2
durante todo el tiempo de permanencia ta(s2) que tenía asignado porque no se ha
producido ningún evento en la entrada, generando el correspondiente evento y2 en la
salida y pasando al estado s3 como consecuencia de la transición interna. Algo similar
ha ocurrido en el estado s3, donde el sistema ha permanecido todo el tiempo ta(s3)
asignado, generando el evento de salida y3 y pasando al estado s4. En cambio cuando el
sistema llevaba e4 unidades de tiempo en el estado s4 ha llegado el primer evento, de
valor x1 en el instante t1, provocando una transición al estado s5. En el estado s5 el
sistema también ha permanecido todo el tiempo ta(s5) asignado, generando el evento de
salida y5 y pasando al estado s6. Pero cuando el sistema llevaba e6 unidades de tiempo
144
en el estado s6 ha llegado el segundo evento, de valor x2 en el instante t2, provocando

una transición al estado s7. En el estado s7 ha permanecido todo el tiempo ta(s7)
asignado, generando el evento de salida y7 y pasando al estado s8. Se observa que la
trayectoria de la variable e “tiempo transcurrido” es un diente de sierra con las sucesivas
puesta a cero como consecuencia de las transiciones internas o externas.
x2
Eventos de
entrada
x1
t1 t2 t
s4
s7
s2
s5
Variable de
estado s1 s6
s3 s8
Tiempo
transcurrido
Eventos de y7
salida ta(s7)
ta(s1) y2 y5 e6
ta(s5)
ta(s2) y3 e4
y1 ta(s3)
Figura 4.1 Ejemplo de cronograma en un sistema con ocho estados.
Por facilitar el ejemplo se han considerado los ocho estados tabulados mediante valores
reales, como muestra la tabla 4.1, con los correspondientes tiempos de permanencia y
una función de salida igual a la identidad, de manera que el sistema genera como evento
de salida el valor real asociado al estado en el que estaba anteriormente. Además se ha
considerado que todas las transiciones ya sean internas o externas son cíclicas, de
manera que del estado s1 siempre se pasa al s2 y así sucesivamente, hasta el estado s8
que se utiliza para volver al estado s1.
Estado Valor asociado Tiempo de permanencia

(en segundos)
s1 0.3 1
s2 0.6 2
s3 0.2 3
s4 0.8 4
s5 0.5 2.5
s6 0.3 3.5
s7 0.7 2.5
s8 0.2 3
Tabla 4.1 Estados considerados en el ejemplo de la figura 1.
En la figura 4.2 se muestra el grafo reducido o diagrama de transición de estados del

modelo DEVS que ha permitido generar el cronograma de la figura 4.1. En este
145
diagrama se ha representado cada uno de los ocho estados con un círculo y su

correspondiente nombre si, se han representado con flecha continua las transiciones de
estado provocados por los eventos de entrada, es decir las transiciones externas, y con
flecha discontinua los eventos de salida asociados a las transiciones internas. Se observa
que del estado s3 se puede pasar al s4 de dos formas; por la llegada de un evento a la
entrada del modelo (transición externa) o por que se ha agotado el tiempo de
permanencia en el estado s3 (transición interna). Algo similar ocurre con los otros
estados, luego en ausencia de eventos este modelo estaría pasando cíclicamente por
todos los estados y generando eventos de salida para todos y cada uno de los estados por
los que va pasando. La llegada de un evento de entrada provoca que el cambio de estado
previsto se adelante y tenga lugar sin generar el correspondiente evento de salida.
s2 s3
s1 s4
s8 s5
s7 s6
Figura 4.2 Grafo reducido del sistema considerado en la figura 4.1.
En la figura 4.3 se muestran las cinco transiciones internas y las dos transiciones
externas que se han disparado en el modelo en las condiciones presentadas por el
cronograma de la figura 4.1. En color gris se ha marcado el estado inicial s1.
s2 s3
s1 s4
s8 s5
s7 s6
Figura 4.3 Transiciones de estados que han ocurrido en el cronograma de la figura 4.1.
146
4.2 EJEMPLOS DE MODELOS ATÓMICOS
En los siguientes apartados se describen varios ejemplos de modelos atómicos. Todos

ellos parametrizados y acompañados del correspondiente símbolo de bloque funcional,
que nos vendrá bien cuando un modelo atómico se tenga que combinar con otros para
formar un modelo más complejo.
4.2.1 Generador de eventos
En todos los modelos programados en ARENA, véanse los ejercicios del Anexo, se ha
utilizado al menos un bloque del tipo Create encargado de generar los eventos externos
(llegada de entidades) que nos permite analizar el comportamiento del sistema que se
está modelando. Por tanto ese bloque, denominado Generador en la mayoría de los
modelos, juega un papel auxiliar pero muy importante. A continuación vamos a ver que
un generador de eventos es en sí mismo un sistema de eventos discretos y que se puede
modelar con el formalismo DEVS.
El generador de eventos es un caso particular de sistema sin entrada, luego se puede

modelar sin función de transición externa. Además basta considerar un único estado, tal
que cada cierto tiempo se produzca una transición interna, generando siempre un evento
de salida del mismo valor pero sin cambiar de estado. El grafo reducido de este bloque
es tan simple como el de la figura 4.4.
activo
Figura 4.4 Grafo reducido del generador.
El intervalo de tiempo entre las transiciones puede tener un valor fijo, el periodo del
generador, y tendríamos así un generador de eventos periódico. Pero también puede
variable, por ejemplo siguiendo una determinada distribución estadística, si queremos
que la generación de eventos sea aleatoria (aperiódica).
En la figura 4.5 se puede observar el cronograma de un generador de eventos periódico,

donde están representadas, por este orden:
- La variable e (tiempo transcurrido), con la forma típica de un diente de sierra
periódico de periodo igual al del generador
- La trayectoria de salida, con los eventos de salida sincronizados con cada transición
interna
147
Tiempo
transcurrido
periodo
Salida
amplitud
Figura 4.5 Cronograma de un generador de eventos periódico.
El bloque generador así definido se puede modelar con una variable de estado, de
nombre “estado”, y dos parámetros, su periodo y la amplitud (el valor) del evento de
salida, de ahí que lo representemos como muestra la figura 4.6.
Generador periódico
salida
estado
periodo amplitud
Figura 4.6 Bloque generador de eventos periódico.
De acuerdo con el formalismo DEVS, una posible descripción del bloque generador de
eventos periódico podría ser la siguiente.
MODELO DEVS: Generador de eventos periódico

1 salida: {“salida”}, y = R /* de valor real */
1 variable de estado: estado = {“activo”} /* con un único valor */
2 parámetros: periodo = R+ , amplitud = R+ /* de valores reales positivos */
estado inicial: estado = “activo”
Transición externa: Como no tiene entrada, el generador no necesita de función de

transición externa.
Transición interna: Aunque el generador permanece siempre en el mismo estado, es

preciso incluir una transición interna periódica con el objetivo de poder generar el
evento de salida.
δint(“activo”) = (“activo”) /* permanece generando */
Salida: Genera evento de salida del mismo valor que la amplitud.

λ (“activo”) = amplitud
Avance de tiempo: Asigna un tiempo de permanencia, igual al periodo de

generador, al único estado posible.
ta(“activo”) = periodo
148
En este modelo formal, que tendrá que ser interpretado por el correspondiente lenguaje
de simulación, se han distinguido varias partes bien diferenciadas:
• El nombre del bloque
• El número y tipo de entrada y de salida
• La variable de estado con su único valor posible
• Los parámetros del bloque por su nombre y por su tipo (ambos números reales
positivos)
• El estado en el que se encontrará el generador cuando se arranque la simulación
(estado inicial)
• Las acciones propias de las funciones de transición externa e interna, y las
asignaciones propias de la función de salida y de la función de avance de tiempo.
También se han incluido una serie de comentarios para facilitar la comprensión del
modelo. Por el contrario, algo bastante normal en el formalismo DEVS, no se ha
incluido nada respecto a cómo avanza el tiempo en la simulación puesto que el avance
del tiempo dependerá de la secuencia de eventos que tengan lugar.
Una variante del bloque generador periódico es el bloque, representado en la figura 4.7,
con una sola entrada pero con una doble función; poner al generador en marcha si
estaba parado y pararlo si estaba generando señal. En ese caso sí que es obligatorio
considerar dos valores “parado” y “activo” para la variable de estado, el primero con
tiempo de permanencia infinito y el segundo con tiempo de permanencia igual al
periodo del generador, y se necesita una función de transición externa que dependiendo
del estado “parado” o “activo” del generador desencadene que esté se ponga a generar
en las mismas condiciones del ejemplo anterior o se detenga hasta recibir una nueva
orden (evento) de puesta en marcha. La figura 4.8 muestra su grafo reducido, con las
dos transiciones externas y la misma transición interna del generador anterior. La figura
4.9 muestra un cronograma representativo de este tipo de bloque. El generador, que
estaba parado, se ha puesto en marcha en el instante t1 y se ha parado en el instante t2,
como consecuencia de sendos eventos de entrada. Entre esos dos instantes de tiempo el
bloque ha generado los eventos de salida con la misma periodicidad del bloque anterior.
Generador periódico con

arranque/parada
entrada salida
estado
periodo amplitud
Figura 4.7 Bloque generador de eventos periódico con entrada de arranque/parada.
parado activo
Figura 4.8 Grafo reducido del generador con arranque/parada.
149
Entrada
“activo”
Variable de
estado
“parado” “parado”
t1 t2 t
Tiempo
transcurrido
periodo
Salida
Figura 4.9 Cronograma de un generador de eventos periódico con entrada de arranque/parada.
De acuerdo con el formalismo DEVS, un posible modelo del bloque generador de

eventos periódico con entrada de arranque/parada podría ser el siguiente.
MODELO DEVS: Generador de eventos periódico con arranque/parada

1 entrada: {“entrada”}, x = R
1 salida: {“salida”}, y = R
1 variable de estado: estado = {“parado”, “activo”}
2 parámetros: periodo = R+ , amplitud = R+
estado inicial: estado = “parado”
Transición externa: La llegada de un evento de entrada provoca siempre un cambio

de estado, independientemente del tiempo transcurrido y del estado en que estuviera.
δext(“parado”,e,x) = (“activo”) /* si estaba parado pasa a generación */
δext(“activo”,e,x) = (“parado”) /* si estaba en generación se para */
Transición interna: Cuando se produce una transición interna permanece en el

estado que estaba, el “activo” el único estado en el que se van a producir las
transiciones internas.
δint(“activo”) = (“activo”) /* si estaba en generación permanece generando */
Salida: Genera evento de salida si y sólo si está en generación.

λ (“activo”) = amplitud
Avance de tiempo: Cada estado tiene su propio tiempo de permanencia.

ta(“parado”) = ∞
ta(“activo”) = periodo
150
En un lenguaje de programación estructurado la función de transición externa se

expresaría de la siguiente forma:
if estado == “parado”
estado = “activo”
else
estado = “parado”
end
4.2.2 Transmisor o procesador
Si estamos pensando en un bloque elemental que recibe entidades por su entrada y las
deja pasar tal cual a su salida (hace la función de transmisor) o como resultado de un
procesamiento (es un procesador). Podemos suponer que el bloque va a introducir un
retraso en la transmisión o va a emplear un tiempo en el procesado y considerar a este
retraso o tiempo de procesamiento como un parámetro del bloque, con la ventaja en ese
caso de considerarlo fijo.
Lo más parecido a este tipo de bloque en ARENA es el bloque Process con la opción
Delay únicamente, que se ha utilizado con diversos fines (para la visualización de
eventos y para garantizar la permanencia del sistema en un estado concreto durante un
tiempo determinado) en los modelos del Anexo. Así por ejemplo se ha utilizado para
representar el tiempo que un carro está moviéndose hacia la derecha o hacia la izquierda
y por tanto se ha trasladado desde un punto a otro, y para representar los distintos
estados “verde”, “ámbar” y “rojo” de un semáforo. Por tanto estamos hablando de un
bloque muy importante en la descripción de sistemas de eventos discretos. A
continuación vamos a ver cómo se puede modelar con el formalismo DEVS un
transmisor o procesador.
En el ejercicio 1.5 del tema 1 ya se propuso el grafo reducido de la figura 4.10 para
describir el comportamiento de un autómata con dos estados, S1=“espera” y
S2=“ocupado”, que arranca en el estado “espera” y cambia al estado “ocupado” cada
vez que recibe un evento externo, permaneciendo en este estado un tiempo fijo después
del cual vuelve al estado “espera”. Este mismo tipo de comportamiento es el que debe
tener un transmisor o procesador, por tanto se puede modelar con el formalismo DEVS
utilizando una función de transición externa que provoca el cambio de “espera” a
“ocupado” por la transmisión o por el procesamiento y una función de transición interna
que provoca el cambio de “ocupado” a “espera”.
espera ocupado
Fig. 4.10 Grafo reducido de un transmisor.
De acuerdo con el formalismo DEVS, un posible modelo del bloque transmisor, con un
pequeño inconveniente que se subsanará más adelante y pensando más en la transmisión
de información (datos) que en la transmisión de entidades, podría ser el siguiente.
151
MODELO DEVS: Transmisor (Este modelo se mejorará más adelante)

2 variables de estado: estado = {“espera”, “ocupado”}, dato = R
1 parámetro: tiempo_transmision = R+
estado inicial: fase = “espera”, dato = 0 (o cualquier otro valor)
Transición externa: La llegada de una entidad (dato a la entrada) provoca la

ocupación del transmisor si y sólo si éste lo estaba esperando. Si estaba ocupado, el
dato se perderá.
δext(“espera”,dato,e,x) = (“ocupado”,x)
/* si estaba esperando un dato, carga el dato y pasa a ocupación durante */
/* el tiempo previsto */
Transición interna: El transmisor se pondrá a la espera cuando haya estado ocupado

el tiempo previsto en la transmisión.
δint(“ocupado”,dato) = (“espera”, dato)
/* si estaba ocupado pasa a la espera */
Salida: Transmite el dato (tal como se recibió) a la salida después de haber estado
ocupado el tiempo necesario para su transmisión.
λ (“ocupado”,dato) = dato
Avance de tiempo: Cada estado tiene su propio tiempo de permanencia.

ta(“parado”) = ∞
ta(“ocupado”) = tiempo_transmision
En un lenguaje de programación estructurado la función de transición externa se

expresaría de la siguiente forma:
if estado == “espera”
estado = “ocupado”
dato = x
end
Observación: con la descripción anterior se ha incluido una variable de estado dato de

valor real, adicional al estado del transmisor con el fin de poder memorizar el dato que
llega por la entrada y se debe transmitir por la salida después de un cierto tiempo. Pero
la citada descripción conseguirá la funcionalidad deseada si no llegan datos (eventos de
entrada) durante el tiempo que el transmisor está ocupado en la transmisión. Si no es
así, habrá datos que no sólo no se transmiten sino que además retrasarán algo más de lo
normal la transmisión de los que les preceden. A continuación se da la justificación y la
solución al segundo de los problemas, el primero de los problemas se solucionará en el
apartado 4.2.3 cuando introduzcamos los bloques de almacenamiento tipo “cola”.
En la descripción mediante el formalismo DEVS del autómata cíclico de la figura 4.3 y

del generador de la figura 4.8, la llegada de cualquier evento externo provoca, además
de la puesta a cero genérica de la variable “tiempo transcurrido”, un cambio de estado
152
mediante la correspondiente función de transición externa, y la consiguiente asignación

del tiempo de permanencia en el estado mediante la función de avance de tiempo. Sin
embargo, en el transmisor la llegada de un evento externo sólo debe provocar un cambio
de estado (de “espera” a “ocupado”) si éste estaba esperando el evento. Pero si estaba
“ocupado” debe permanecer así hasta completar el tiempo de transmisión que se le
había asignado. Este efecto no se consigue utilizando la función avance de tiempo ta
(“ocupado”)=tiempo_transmision, que asigna al estado “ocupado” un tiempo de
permanencia fijo, ya que la puesta a cero de la variable “tiempo transcurrido” provocará
que al tiempo de transmisión asignado se sume el tiempo que ya llevaba el sistema
ocupado en la transmisión.
Este problema no sólo se presenta en el transmisor, se presenta en cualquier modelo

DEVS cuando la llegada de un evento externo no debe producir una transición de
estados inmediata. La forma habitual de evitarlo es considerar una variable de estado
adicional en el modelo, que denominaremos sigma, cuyo valor se modificará a través de
las funciones de transición interna y externa, y se transmitirá tal cual a la función
avance de tiempo. En definitiva, el tiempo de permanencia en cada estado del
transmisor vendrá determinado en todo momento por el valor de sigma; igual a ∞ si el
estado es el de espera, igual al tiempo_transmision si el estado es el de transmisión y no
se espera ningún evento externo mientras se efectúe la transmisión, y se irá recalculando
(restando al tiempo de permanencia el que ya llevaba en el estado) si se presenta algún
evento externo durante la transmisión.
La descripción mejorada es pues la siguiente, donde hay que prestar especial atención a
la segunda sentencia de la función de transición externa:
MODELO DEVS: Transmisor

3 variables de estado: estado = {“espera”, “ocupado”}, sigma= R+∞, dato = R
1 parámetro: tiempo_transmision = R+
estado inicial: fase = “espera”, sigma = ∞, dato = 0 (o cualquier otro valor)
Transición externa: La llegada de una entidad (dato a la entrada) provoca la

ocupación del transmisor si y sólo si éste lo estaba esperando. Si estaba ocupado, el
dato se perderá.
δext(“espera”,sigma,dato,e,x) = (“ocupado”,tiempo_ transmision,x)
/* si estaba esperando un dato, carga el dato y pasa a ocupación durante */
/* el tiempo previsto */
δext(“ocupado”,sigma,dato,e,x) = (“ocupado”,sigma-e,dato)
/* si estaba ocupado, lo sigue estando, pero descuenta del tiempo de */
/ * permanencia lo que ya lleva en el estado ocupado */
Transición interna: El transmisor se pondrá a la espera cuando haya estado ocupado

el tiempo previsto en la transmisión.
δint(“ocupado”,sigma,dato) = (“espera”, ∞,dato)
/* si estaba ocupado pasa a la espera */
Salida: Transmite el dato (tal como se recibió) a la salida después de haber estado
ocupado el tiempo necesario para su transmisión.
153
λ (“ocupado”,sigma,dato) = dato
Avance de tiempo: el tiempo de permanencia en el estado vendrá determinado en

todo momento por el valor de sigma; igual a ∞ si el estado es el de espera, igual al
tiempo_transmision si el estado es el de transmisión y no se espera ningún evento
externo mientras se efectúe la transmisión, se irá recalculando si se presenta algún
evento externo durante la transmisión.
ta(estado,sigma,dato) = sigma
En la figura 4.11 se muestra el símbolo que utilizaremos para el transmisor.
Transmisor
entrada salida
estado sigma dato
tiempo_transmision
Figura 4.11 Bloque transmisor.
La figura 4.12 muestra el cronograma para un transmisor de esas características, donde

se observa claramente el retraso en la transmisión y donde además ha habido una
pérdida de información en la transmisión, concretamente el dato que llegó a la entrada
en cuarto lugar nunca llegó a la salida debido a que cuando llegó se estaba aún
transmitiendo el dato anterior.
Entrada
Dato no transmitido
t
“ocupado”
estado
“espera”
Tiempo
transcurrido
tiempo_transmision
Salida
t
Figura 4.12 Cronograma de un transmisor, donde se observa el retraso en la transmisión y que uno de los
datos recibidos no se ha transmitido.
154
Un posible modelo del bloque procesador sólo diferirá del modelo transmisor en la
función de salida; en lugar de transmitir el dato tal como se recibió, transmitirá el
resultado de operar con él. La operación a realizar por el procesador se podría incluir en
la función de salida o definirla como un parámetro del bloque.
4.2.3 Bloques de almacenamiento
A continuación se van a presentar tres tipos de bloques de almacenamiento:

- Un bloque “almacén expendedor” para poder simular situaciones en las que una
sección solicita sólo aquello que puede procesar.
- Un bloque “almacén receptor” para poder simular situaciones en las que una
sección entrega todo aquello que va procesando.
- Un bloque de almacenamiento tipo “cola” para poder simular situaciones en las
que una sección entrega todo aquello que va procesando y otra sección solicita
sólo aquello que puede procesar, y en la que la secuencia de llegada marca el
orden de salida.
El bloque “almacén expendedor” tiene una entrada “petición” y una salida “entrega”, tal
que la entrega se produce como consecuencia de una petición, siempre y cuando haya
algún elemento en el almacén, y consume un tiempo fijo “tiempo de preparación”.
En la figura 4.13 se muestra el símbolo que servirá para representarlo y en la figura 4.14
se muestra un posible grafo reducido. En el símbolo se observan los dos parámetros
representativos del bloque; la “capacidad” para indicar el número máximo de elementos
que caben en el almacén, y el “tiempo de preparación”, medido como el tiempo medio
que el almacén tarda en localizar y servir el elemento. Otro parámetro podría ser la
política de entrega, aunque en general supondremos que se entrega siempre el elemento
que más tiempo lleva en el almacén.
En el grafo reducido se distinguen dos estados por cada número de elementos en el

almacén. El estado “espera” para indicar que el almacén está esperando una petición, y
el estado “ocupado” para indicar que el almacén está preparando la entrega. Se observa
que la transición externa de “espera” a “ocupado” debido a una petición siempre
provoca la disminución instantánea en una unidad del número de elementos en el
almacén, pues aunque todavía falte un tiempo para servirlo se contabiliza el
compromiso adquirido. La transición de “ocupado” a “espera” es una transición interna
que irá precedida de la entrega de uno de los elementos almacenados en la salida del
almacén. Cualquier petición que se reciba cuando el bloque está preparando una entrega
o cuando no hay elementos en el almacén no será atendida.
Almacén expendedor
petición entrega
estado nº elementos elementos sigma elemento
tiempo_preparacion capacidad
Figura 4.13 Bloque de almacenamiento tipo expendedor.
155
ocupado
espera
0 1 2 3 Elementos en el almacén
Figura 4.14 Grafo reducido de un almacén expendedor.
El bloque “almacén receptor” tiene una entrada “recepción” y un contador interno del
número de elementos en el almacén. Se puede suponer que la colocación de éstos en el
almacén requiere un tiempo fijo “tiempo de colocación”. En la figura 4.15 se muestra el
símbolo que servirá para representarlo y en la figura 4.16 se muestra un posible grafo
reducido. En el símbolo se observan los dos parámetros representativos del bloque; la
“capacidad” que indica el número máximo de elementos que caben en el almacén, y el
“tiempo de colocación”, medido como el tiempo medio que se tarda en localizar un
hueco y depositar el elemento.
En el grafo reducido se distinguen dos estados por cada número de elementos en el

almacén. El estado “espera” para indicar que el almacén está esperando la llegada de un
elemento, y el estado “ocupado” para indicar que el almacén está colocando al último
elemento que ha llegado. Se observa que la llegada de cualquier elemento a la recepción
sólo provoca una transición externa, de “espera” a “ocupado”, si el almacén aún tiene
capacidad y estaba esperando al elemento. En el momento de transición se contabiliza al
nuevo elemento como parte del almacén, en el sentido de reservarle sitio aunque todavía
falta un tiempo para colocarlo. Si el almacén está ocupado colocando al elemento que
llegó con antelación, continúa realizando su tarea y no recibe al elemento que acaba de
llegar. La transición de “ocupado” a “espera” es una transición interna que se produce
cuando el último elemento en llegar ha quedado almacenado y el almacén está en
disposición de recibir a un nuevo elemento.
Almacén receptor
recepción
estado nº elementos elementos sigma
tiempo_colocacion capacidad
Figura 4.15 Bloque de almacenamiento tipo receptor.
156
ocupado
espera
Figura 4.16 Grafo reducido de un almacén receptor.
El bloque “almacén de tipo cola” tiene dos entradas; la primera “entrada” para recibir a
los elementos y la segunda “petición” para atender peticiones de elementos. Además
tiene una salida “entrega”. En la figura 4.17 se muestra el símbolo que servirá para
representarlo y en la figura 4.18 se muestra un posible grafo reducido, fusión de los dos
grafos anteriores. En el símbolo se observan los dos parámetros representativos del
bloque; la “capacidad” que indica el número máximo de elementos que puede
almacenar la cola, y el “tiempo de preparación”, medido como el tiempo medio que
tarda la “cola” en colocar un elemento recibido o en entregar un elemento solicitado.
Otro parámetro adicional podría ser el tipo de cola: FIFO (el dato que llega en primer
lugar es el primero en salir, y así sucesivamente) o LIFO (el último dato en llegar es el
primero en salir). Aunque lo habitual es que la cola sea de tipo FIFO.
En el grafo se distinguen dos estados por cada número de elementos en la cola. El

estado “espera” para indicar que la cola está esperando la llegada o la petición de un
elemento, y el estado “ocupado” para indicar que la cola está colocando o sirviendo un
elemento. Se observa que la llegada de cualquier elemento a la cola provoca que éste
sea aceptado y se incremente el contador de la cola, siempre y cuando todavía quede
capacidad y el almacén lo estuviera esperando. Si el almacén está ocupado colocando al
elemento que llegó con antelación o sirviendo un elemento, continúa realizando su tarea
y no recibe al elemento que acaba de llegar. También se observa que a una petición
provoca la disminución instantánea en una unidad del número de elementos en el
almacén, siempre y cuando exista algún elemento en el almacén y que estuviera
esperando la petición. Cualquier petición que se reciba cuando el bloque está
preparando una entrega o cuando está colocando un elemento no será atendida. La
transición de “ocupado” a “espera” es una transición interna que se produce cuando el
último elemento en llegar ha quedado almacenado o el almacén acaba de entregar un
elemento y se está en disposición de recibir o de servir un nuevo elemento.
157
Almacén tipo cola

recepción
entrega
petición
tiempo_preparacion capacidad
Figura 4.17 Bloque de almacenamiento tipo cola.
ocupado

espera
Figura 4.18 Grafo reducido de un almacén tipo cola.
A continuación se muestran una posible descripción con el formalismo DEVS de una

cola tipo FIFO. Descripción bastante explícita por los comentarios que la acompañan y
donde con los subíndices 1 y 2 acompañando a la letra “x” hemos distinguido la
procedencia (primera o segunda entrada) del evento externo.
MODELO DEVS: Almacén tipo cola

2 entradas: {“recepción”,“petición”}, x1 = R, x2 = R
1 salida: {“entrega”}, y = R
5 variables de estado: estado = {“espera”, “ocupado”}, numero_elementos,
vector_de_elementos, sigma= R+∞, elemento = R
2 parámetros: tiempo_preparacion = R+ , capacidad de la cola = Z+
estado inicial: estado = “espera”, cola de elementos en cualquier situación, sigma =
∞, elemento=0
Transición externa: La llegada de un evento por la entrada 1 (recepción de

elementos) provoca su colocación en el almacén si se estaba esperando y hay hueco
para ello. En los demás casos, el elemento se perderá. La llegada de un evento por la
entrada 2 (petición de elemento) provoca que el bloque se prepare para entregar el
primer elemento del almacén (el más antiguo de los almacenados), pero si no hay
ningún elemento almacenado o el almacén está ocupado en otra tarea, la petición no
se atenderá.
δext(“espera”,nelementos<capacidad,velementos,sigma,elemento,e,x1) =
(“ocupado”,nelementos+1,carga(velementos,x1),tiempo_preparacion,elemento)
/* si está en “espera”, llega un elemento y hay sitio, */
158
/* se prepara para cargar el elemento que ha llegado */
δext(“espera”,capacidad,velementos,sigma,elemento,e,x1) =
(“espera”,capacidad,velementos,sigma-e,elemento)
/* si está en “espera”, llega un elemento y no hay sitio, */
/* no puede recibirlo */
δext(“espera”,nelementos>0,velementos,sigma,elemento,e,x2) =
(“ocupado”,nelementos-1,descarga(velementos,
velementos(1)),tiempo_preparacion,velemento(1))
/* si está en “espera”, se le solicita un elemento y hay disponibilidad, */
/* saca el primer elemento de la cola y se prepara para entregarlo */
δext(“espera”,0,velementos,sigma,elemento,e,x2) =
(“ocupado”,0,velementos,sigma-e,elemento)
/* si está en “espera”, se le solicita un elemento y no hay disponibilidad, */
/* no se atiende la petición */
δext(“ocupado”,nelementos,velementos,sigma,elemento,e,x1) =
(“ocupado”,nelementos,velementos,sigma-e,elemento)
/* si está “ocupado” y llega un elemento, éste no se recepciona */
δext(“ocupado”,nelementos,velementos,sigma,elemento,e,x2) =
/* si está “ocupado” y se le solicita un elemento, no se atiende la petición */
Transición interna: La transición interna está asociada a la transmisión de un

elemento, el primero de la cola, o a la colocación del elemento que acaba de llegar, y
provoca siempre el cambio a “espera” ya sea para recibir al siguiente elemento o para
atender la próxima petición.
δint(“ocupado”,nelementos,velementos,sigma,elemento) =
(“espera”,nelementos,velementos,∞,elemento)
/* si ha transmitido o recibido un elemento, se prepara para */
/* recibir el siguiente o para atender la próxima petición */
Salida: Entrega el primer elemento de la cola a la salida después de haber estado

ocupado el tiempo necesario para prepararlo.
λ (“ocupado”,nelementos,velementos,sigma,elemento) = elemento
Avance de tiempo: El tiempo de permanencia en el estado viene determinado en

todo momento por el valor de sigma; igual ∞ si es el estado de espera, igual al
tiempo_preparación si es el estado ocupado y no se espera ningún evento externo
mientras se efectúe la recepción o la entrega, se irá recalculando si se presenta algún
evento externo durante la recepción o la entrega.
ta(estado,nelementos,velementos,sigma,elemento) = sigma
La figura 4.19 muestra el cronograma de un almacén tipo cola con capacidad igual o
superior a tres elementos, que inicialmente estaba vacío y ha recibido 5 elementos
(etiquetados con las letras E1 a E5) y 4 peticiones (todas del mismo valor, aunque éste
159
no influye para nada en el comportamiento del almacén) con las secuencias

representadas en las dos gráficas superiores. En la tercera gráfica se observan los nueve
pasos por el estado de “ocupado” durante el tiempo de preparación cada vez que ha
recibido un elemento o se le ha solicitado un dato, porque en las cinco recepciones había
espacio en el almacén y porque en las 4 peticiones siempre ha habido algún elemento
para atender la petición. El resto del tiempo, el almacén ha estado en el estado de
“espera”. La cuarta gráfica muestra cómo ha evolucionado el número de elementos en la
cola, desde 0 (estado inicial del almacén vacío) hasta 1 (diferencia entre el número de
peticiones y el número de elementos que han llegado a la cola), pasando por todos los
valores entre 0 a 3. Y en la quinta gráfica se observan los instantes en los que se han
entregado los primeros cuatro elementos (E1 a E4) que llegaron al almacén.
E5
Recepción E1
E3
E2
E4
Petición
Estado
3 t
tiempo_preparacion
2
Nº de
elementos 1 1
E1
E3
Entrega E2
E4
t
Figura 4.19 Ejemplo de cronograma en un almacén tipo cola que ha recibido 5 elementos y ha atendido 4
peticiones.
La figura 4.20 muestra el cronograma de la misma cola, también inicialmente vacía y

que ha recibido la misma secuencia de 5 elementos pero distintas peticiones, en
concreto 6 peticiones en lugar de 4, con la secuencia presentada en la segunda gráfica.
Se observa que la primera petición ha llegado cuando se estaba colocando el primer
elemento en el almacén y la tercera petición ha llegado con el almacén vacío,
provocando que ambas peticiones no se hayan atendido. El resto del tiempo se observa
la misma evolución que en el caso anterior.
160
E5
E1
Recepción E3
E2
E4
peticiones no
Petición atendidas
Estado
3 t
tiempo_preparacion
2
Nº de
elementos 1 1
E1
E3
Entrega E2
E4
t
Figura 4.20 Ejemplo de cronograma en un almacén tipo cola que ha recibido 5 elementos y 6 peticiones,
pero sólo ha atendido 4 peticiones.
El bloque almacén tipo cola descrito anteriormente puede venir muy bien para modelar
cualquier almacén de productos en el que la recepción o la entrega de elementos
consume un tiempo considerable en el proceso que se desea simular. Incluso podría
servir cuando el tiempo de recepción y el tiempo de entrega son distintos, bastaría con
sustituir el parámetro “tiempo_preparacion” por dos parámetros “tiempo_recepcion” y
“tiempo_entrega” y asignar adecuadamente el que corresponda en la transición interna.
Pero se puede simplificar si lo que se desea modelar es una cola de elementos, por
ejemplo la cola de clientes en una oficina de atención al público, donde la entrada en la
cola y la salida de ella se producen en un tiempo infinitesimal o despreciable frente a
otros eventos en el sistema. La primera simplificación es que el parámetro
“tiempo_preparacion” desaparece del símbolo de la figura 4.17, dando lugar al bloque
de la figura 4.21. Otras simplificaciones y modificaciones funcionales, que se pueden
observar comparando el grafo reducido de la figura 4.22 con el de la figura 4.18, son las
siguientes:
• Se mantiene una transición interna para poder generar el evento de salida (el
acto de salida de la cola).
• El estado “ocupado” ha pasado a ser un estado transitorio de “entrega” pues le
asignaremos un tiempo de permanencia igual a cero.
• La transición externa asociada a la recepción tiene un efecto inmediato en la cola
(aumenta el número de elementos en una unidad).
• Se ha considerado oportuno que la transición externa asociada a la petición no
tenga el efecto inmediato en la cola (descuenta una unidad en el número de
elementos) sino que este efecto tenga lugar cuando se produce la entrega
efectiva a la salida del bloque.
• Se han incorporado dos transiciones externas más cuando la cola esta vacía, con
ello se pretende conseguir que cuando llega una petición, estando la cola vacía,
ésta pase al estado “entrega” por un tiempo indefinido, para que cuando llegue
161
un elemento a la cola, éste no se almacene, sino que se entregue inmediatamente

en la salida.
Cola de elementos
recepción
entrega
petición
capacidad
Figura 4.21 Bloque cola de elementos.
recepción
entrega

espera
0 1 2 3 Elementos en cola
Figura 4.22 Grafo reducido de una cola de elementos.
La posible descripción con el formalismo DEVS sería entonces la siguiente.
MODELO DEVS: Cola de elementos

2 entradas: {“recepción”,“petición”}, x1 = R, x2 = R
5 variables de estado: estado = {“espera”, “entrega”}, numero_elementos,
1 parámetro: capacidad de la cola = Z+
estado inicial: estado = “recepción”, cola de elementos en cualquier situación, sigma
= ∞, elemento=0
Transición externa: La llegada de un evento por la entrada 1 (recepción de

elementos) provoca su colocación en la cola si se estaba esperando y hay hueco para
ello. Si había una petición pendiente de atender, el elemento se entrega
inmediatamente, sin pasarlo por la cola. En los demás casos, el elemento se perderá.
La llegada de un evento por la entrada 2 (petición de elemento) provoca que el
bloque se prepare para entregar el primer elemento de la cola (el más antiguo de los
almacenados), pero si no hay ningún dato en la cola, la petición se memoriza y se
atenderá cuando sea posible.
δext(“espera”,nelementos<capacidad,velementos,sigma,elemento,e,x1) =
162
(“espera”,nelementos+1,carga(velementos,x1),sigma,elemento)
/* si está en “espera”, llega un elemento y hay sitio en la cola, */
/* lo carga inmediatamente */
δext(“espera”,capacidad,velementos,sigma,elemento,e,x1) =
(“espera”,capacidad,velementos,sigma,elemento)
/* si está en “espera”, llega un elemento y no hay sitio en la cola, */
/* no lo puede recibir */
δext(“entrega”,0,velementos,sigma,elemento,e,x1) =
(“entrega”,1,velementos,0,x1)
/* si está en “entrega” porque tiene pendiente una petición, y llega */
/* un elemento, se prepara para entregarlo inmediatamente */
δext(“espera”,nelementos>0,velementos,sigma,elemento,e,x2) =
(“ocupado”,nelementos,descarga(velementos, velementos(1)),0,velemento(1))
/* si está en “espera”, se le solicita un elemento y hay disponibilidad */
/* en la cola, saca el primer elemento de la cola y se prepara para */
/* entregarlo inmediatamente*/
δext(“espera”,0,velementos,sigma,elemento,e,x2) =
(“entrega”,0,velementos,∞,elemento)
/* si está en “espera”, se le solicita un elemento y no hay elementos */
/* en la cola, se prepara para que cuando llegue el elemento */
/* lo pueda entregar inmediatamente*/
Transición interna: La transición interna está asociada a la entrega de un elemento,

provoca siempre el cambio a “espera” ya sea para recibir el siguiente elemento o para
atender la próxima petición.
δint(“entrega”,nelementos,velementos,sigma,elemento) =
(“espera”,nelementos-1,velementos,∞,elemento)
/* si ha entregado un elemento, se prepara para recibir otros */
/* o para atender la próxima petición */
Salida: Entrega el primer elemento de la cola a la salida inmediatamente después de

habérselo solicitado.
λ (“entrega”,nelementos,velementos,elemento) = elemento

todo momento por el valor de sigma; igual ∞ si es el estado de espera o el de entrega
porque hay una petición pendiente, igual al cero cuando hay elementos en la cola y
se prepara para hacer una entrega inmediata.
La figura 4.23 muestra el cronograma de una cola con capacidad para 5 elementos, que
inicialmente estaba vacía y ha recibido 5 elementos (etiquetados con las letras E1 a E5)
y 5 peticiones. En la tercera gráfica se observa como el paso por el estado “entrega” ha
sido fugaz en cuatro ocasiones, las que corresponden a cuatro entregas inmediatas
porque había elementos en la cola, mientras que en la segunda petición no había
163
elementos en la cola y ha permanecido en “entrega” hasta que ha llegado un elemento,

concretamente el E2. La cuarta gráfica muestra cómo ha evolucionado el número de
elementos en la cola y en la quinta gráfica se observan los instantes en los que se han
entregado los cinco elementos que ha pasado por la cola.
E5
E1
Recepción E3
E2
E4
Petición
“entrega” t
Estado
“espera”
2 t
Nº de 1 1
elementos
t
E5
E1
Entrega E3
E2
E4
t
Figura 4.23 Ejemplo de cronograma en la cola de elementos como consecuencia de 5 llegadas y 5
peticiones.
Basándonos en las descripciones de los apartados anteriores, es correcto conectar un

bloque “generador con entrada de arranque/parada”, un bloque “cola de elementos” y un
bloque “procesador” tal como se muestra en la figura 4.24. Si el generador está
inicialmente parado, la cola está vacía y el procesador en espera, así permanecerán
indefinidamente. Pero si el generador está inicialmente arrancado, la cola está en el
estado de “entrega” con algún elemento almacenado, y el procesador está en espera,
inmediatamente la cola presentará a su salida el elemento que más tiempo lleva en la
cola. El elemento será aceptado por el procesador, que pasará a procesarlo, esta tarea lo
mantendrá ocupado durante el “tiempo_procesamiento”. Al finalizar el procesamiento,
el procesador presentará el elemento procesado a su salida y este evento será
interpretado por la cola como la petición de un nuevo elemento. Con lo cual se repetirá
un nuevo ciclo. Durante el tiempo que el procesador ha estado procesando, la cola habrá
seguido atendiendo la llegada de elementos procedentes del generador.
arranque/parada Cola de elementos Procesador
Arranque elemento
estado entrega salida
estado nº elementos elementos sigma elemento estado sigma dato
periodo amplitud petición
capacidad tiempo_procesamiento
Figura 4.24 Ejemplo de conexión: Generador, Cola de elementos y Procesador.
164
4.2.4 Bloques repartidores
En este apartado se aborda el tema de canalización de eventos con el formalismo DEVS.

El primer componente que vamos a modelar es un bloque repartidor de tareas entre dos
procesadores, la tarea (evento) que reciba la enviará al procesador libre en ese
momento, de ahí que necesite:
• Tres entradas; la primera para recibir las tareas, la segunda y la tercera para tener
conocimiento de cuando los procesadores han finalizado sus tareas.
• Dos salidas; para entregar las respectivas tareas al procesador principal (por la
primera salida) y al procesador de respaldo (por la segunda salida).
• Un parámetro; el tiempo_reparto, medido como el tiempo que necesita el bloque
para encaminar una tarea desde que la recibe en su entrada hasta que la coloca
en una de las dos salidas.
A continuación se muestran la posible representación del repartidor de tareas y su

descripción, esta última bastante explícita por los comentarios que la acompañan, con el
formalismo DEVS.
Repartidor de tareas
tarea tarea para p1
salida p1 estado p1
estado sigma tarea
estado p2 tarea para p2
salida p2
tiempo_reparto
Figura 4.25 Bloque repartidor.
MODELO DEVS: Repartidor de tareas

3 entradas: {tarea,“salida p1”,“salida p2”}, x1 = R, x2 = R, x3 = R
2 salidas: {“tarea para p1”,“tarea para p2”} , y1 = R, y2 = R
5 variables de estado: estado = {“recepción”, “transmisión”}, estado p1 = {“libre”,
“ocupado”}, estado p2 = {“libre”, “ocupado”}, sigma= R+∞, tarea = R
parámetro: tiempo_reparto = R+
estado inicial: estado = “recepción”, estado p1 = “libre”, estado p2 = “libre”, sigma=
R+∞, tarea = 0
Transición externa: La llegada de un evento por la entrada 1 (entrada de tareas)

provoca que el bloque se prepare para encaminarla al procesador 1 si éste esta libre o
al procesador 2 si el primero está ocupado. Cuando ambos procesadores están
ocupados o cuando el bloque aún está transmitiendo la tarea anterior, la llegada de
una nueva tarea hará que está no se transmita. La llegada de eventos por las entradas
2 y 3 se utilizará para conocer que el correspondiente procesador ha finalizado su
trabajo y por tanto vuelve a quedar libre.
δext(“recepción”,“libre”,estado p2,sigma,tarea,e,x1) =
(“transmisión”,“libre”,estado p2,tiempo_reparto, x1)
/* si estaba en “recepción” esperando una tarea y el procesador p1 */
/* está libre, se prepara para la transmisión */
165
δext(“recepción”,“ocupado”,“libre”,sigma,tarea,e,x1) =
(“transmisión”,“ocupado”,“libre”,tiempo_reparto, x1)
/* si estaba en “recepción” esperando una tarea y el procesador p1 */
/* está ocupado pero el p2 está libre, se prepara para la transmisión */
δext(“recepción”,“ocupado”,“ocupado”,sigma,tarea,e,x1) =
(“transmisión”,“ocupado”,“ocupado”,sigma-e, x1)
/* si estaba en “recepción” esperando una tarea y los procesadores */
/* están ocupados, la tarea que ha llegado no se transmite*/
δext(“transmisión”,estado p1, estado p2,sigma,tarea,e,x1) =

(“transmisión”,estado p1, estado p2,sigma-e,tarea)
/* si estaba en “transmisión” la tarea que ha llegado no se transmite */
δext(estado,“ocupado”,estado p2,sigma,tarea,e,x2) =
(estado,“libre”,estado p2, sigma-e,tarea)
/* si el bloque sabía que el procesador p1 estaba “ocupado” y recibe */
/* un evento por la segunda entrada, interpreta que éste ha quedado “libre” */
δext(estado,estado p1,“ocupado”,sigma,tarea,e,x3) =
(estado,estado p1,“libre”, sigma-e,tarea)
/* si el bloque sabía que el procesador p2 estaba “ocupado” y recibe */
/* un evento por la tercera entrada, interpreta que éste ha quedado “libre” */
Transición interna: La transición interna está asociada a la transmisión de la tarea al

procesador principal o al procesador de respaldo, provoca la ocupación del
procesador correspondiente y el cambio a “recepción” para quedar en condiciones de
recibir la siguiente tarea.
δint(“transmisión”,“libre”,estado p2,sigma,tarea) =
(“recepción”,“ocupado”,estado p2,∞,tarea)
/* si ha transmitido la tarea al procesador 1, coloca su status en ocupado */
/* y se prepara para recibir la siguiente tarea */
δint(“transmisión”,“ocupado”,“libre”,sigma,tarea) =
(“recepción”,“ocupado”, “ocupado”,∞,tarea)
/* si ha transmitido la tarea al procesador 2, coloca su status en ocupado */
/* y se prepara para recibir la siguiente tarea */
Salida: Encamina la tarea al procesador principal si está libre y si no al procesador

de respaldo.
λ (“transmisión”,“libre”,estado p2,sigma,tarea) = (tarea,0)
λ (“transmisión”,“ocupado”,“libre”,sigma,tarea) = (0,tarea)
Tiempo de permanencia: El tiempo de permanencia en el estado viene determinado

en todo momento por el valor de sigma; igual ∞ si es el estado de recepción e igual al
tiempo_reparto o a lo que resta de la transmisión si está encaminando una tarea a uno
de los procesadores.
166
ta(estado,estado p1,estado p2,sigma,tarea) = sigma
La figura 4.26 el conjunto “repartidor de tareas y dos procesadores” como un único

bloque, con 1 entrada y 1 salida, el resto con conexiones internas. Esto es lo que se
denomina un modelo acoplado en el formalismo DEVS.
Procesador
estado sigma dato salida p1

Repartidor de tareas
tarea
tiempo_procesamiento
salida p1 estado p1 tarea para p1 salida
fase sigma tarea
estado p2
salida p2 tarea para p2 Procesador
tiempo_reparto
estado sigma dato salida p2
tiempo_procesamiento
Figura 4.26 Ejemplo de modelo acoplado: Repartidor de tareas con dos procesadores.
4.3 MODELOS ACOPLADOS
En varios ejemplos anteriores hemos visto como los modelos atómicos se pueden
conectar para formar un modelo funcionalmente más complejo, a continuación vamos a
ver como contempla estas conexiones el formalismo DEVS. Se habla de modelo
acoplado o multicomponente como aquel modelo obtenido de conectar varios modelos
atómicos, y se especifica como una estructura matemática de la siguiente forma:
N = ( X, Y, D, {Md | d ∈ D}, CE, CS, CI, Selección)

donde
D es el conjunto de nombres de los componentes
Md son las descripciones DEVS de todos y cada uno de los componentes
CE es el conjunto de conexiones entre las entradas externas y las entradas de los
componentes
CS es el conjunto de conexiones entre las salidas de los componentes y las salidas
externas
CI es el conjunto de conexiones internas, es decir, las conexiones entre las salidas
de los componentes y las entradas de los componentes que no salen al exterior del
modelo
Selección es la función de secuencialización o prioridad, contiene las reglas que
se utilizarán cuando haya que elegir cuál de los componentes inminentes (los que
tiene menor tiempo al próximo evento) ejecutará su próximo evento. En la
mayoría de los casos basta con indicar el orden de prioridad entre los
componentes.
167
Observación: En estos modelos no se admite realimentación directa, es decir, no se

admite la conexión de una salida de un bloque con una de sus entradas.
Por ejemplo, el conjunto de tres bloques de la figura 4.24, resultante de la conexión de

un generador, una cola y un procesador, se puede describir como un modelo acoplado
con una entrada y una salida. Su posible descripción en el formalismo DEVS es la
siguiente:
MODELO DEVS ACOPLADO: Generador, cola y procesador

1 entrada: {“arranque”}, x = R
/* Tres componentes con sus correspondientes modelos DEVS */

D = {generador periódico con arranque/parada, cola de elementos, procesador}
/* Una conexión de entrada externa */

CE = { ( (generador, cola y procesador,“arranque”) , (generador,“arranque”) ) }
/* Una conexión de salida externa */

CS = { ( (procesador,“salida”) , (generador, cola y procesador,“salida”) ) }
/* Tres conexiones internas */

CI = { ( (generador,“salida”) , (cola,“recepción”) ),
( (cola,“entrega”) , (procesador,“entrada”) ),
( (procesador,“salida”) , (cola,“petición”) ) }
Función de selección: el orden de prioridad debería ser (procesador, cola,

generador). Pues así garantizamos que se resuelve adecuadamente la siguiente
situación: está previsto que al mismo tiempo que el procesador acaba de procesar un
elemento, el generador está presentando a la cola otro elemento. De acuerdo con el
orden de prioridad, se atendería primero el fin del procesamiento, a continuación se
haría el envío de un nuevo elemento desde la cola al procesador para que éste no se
quede parado y después se atendería la llegada del elemento procedente del
generador.
El modelo acoplado de la figura 4.26, resultante de la conexión de un repartidor de

tareas y dos procesadores, tiene una entrada y una salida. Su posible descripción en el
formalismo DEVS es la siguiente:
MODELO DEVS ACOPLADO: Repartidor y procesadores

/* Tres componentes con sus correspondientes modelos DEVS */

D = {repartidor , procesador 1, procesador 2}

CE = { ( (repartidor y procesadores,“tarea”) , (repartidor, tarea”) ) }
168
/* Dos conexiones de salida externa */

CS = { ( (procesador 1,“salida”) , (repartidor y procesadores,“salida”) ),
( (procesador 2,“salida”) , (repartidor y procesadores,“salida”) ) }
/* Cuatro conexiones internas */

CI = { ( (repartidor,“tarea para p1”) , (procesador 1,“entrada”) ),
( (repartidor,“tarea para p2”) , (procesador 2,“entrada”) ),
( (procesador 1,“salida”) , (repartidor,“salida p1”) ),
( (procesador 2,“salida”) , (repartidor,“salida p2”) ) }
Función de selección: El orden de prioridad de los procesadores está implícito en el

bloque repartidor a la hora de dirigir el trabajo, pero en la función de selección es
preciso indicar que en el caso de que ambos procesadores vayan a acabar su
procesamiento en el mismo instante de tiempo, la primera petición que se debe
transmitir al bloque repartidor sea la del procesador 1 para que sea éste el que reciba
la próxima tarea. El orden de prioridad adecuado sería (procesador 1, repartidor,
procesador 2).
En definitiva un modelo acoplado en el formalismo DEVS nos dice como se conectan

varios componentes para formar un modelo multicomponente. Y como los componentes
pueden ser modelos básicos (atómicos) o modelos acoplados, quiere decir que el
formalismo DEVS contempla la construcción jerárquica sin ningún tipo de límite.
4.4 MODELOS EN PARALELO
El formalismo DEVS Paralelo difiere del formalismo estándar en que permite que
cualquier número de componentes pueda tener una transición simultánea y por tanto los
componentes receptores deben estar preparados para recibir eventos simultáneos en
varias de sus entradas e interpretarlos adecuadamente. En la conexión de modelos
paralelos se sigue el mismo procedimiento que en los modelos acoplados, pero no se
necesita la función de selección. El medio de intercambio de información en el
formalismo DEVS Paralelo son los mensajes, compuestos básicamente de pares de
entrada y valor, es decir el valor de la variable y el nombre de la entrada a la que va
dirigido. Todo modelo atómico paralelo se especifica como una estructura matemática
de la siguiente forma:
M = < X, Y, S, δext, δint, δcon, λ, ta >

donde
S es el conjunto de estados
δext : Q x X → S, es una función de transición externa, donde
Q = {(s,e)|s ∈ S, 0 ≤ e ≤ ta(s)} es el conjunto total de estados
e es el tiempo transcurrido desde la última transición (interna o externa) de
estados
δint : S → S, es una función de transición interna
169
δcon : Q x X → S, es una función de transición confluente, que se utiliza para

decidir el próximo estado si se produce una colisión entre eventos externos y
eventos internos.
λ : S → Y, es la función de salida
ta : S → R+0,∞, es la función de avance de tiempo, determina el tiempo de
permanencia en todos y cada uno de los estados, estos tiempos pueden tomar
valores reales positivos (incluidos el valor 0 y el ∞).
A continuación se comentan dos ejemplos donde se pone de manifiesto esta necesidad:
• La cola de elementos de la figura 4.21 tiene una sola entrada de petición, pues está
pensada para servir a un procesador en la configuración mostrada en la figura
4.24. ¿Qué ocurre si esta cola de elementos la ponemos al servicio de dos o más
procesadores independientes o conectados en paralelo? Pues que, conectando la
salida de la cola a los procesadores y las salidas de los procesadores a la entrada
“petición” de la cola, podríamos llegar a tener funcionalidad sin necesidad de
utilizar un repartidor de tareas entre la cola y los procesadores, bastaría con
indicar el orden de prioridad de los procesadores. No obstante la funcionalidad no
está garantizada, porque si por cualquier motivo dos o más procesadores quedarán
libres en el mismo instante de tiempo, la cola de elementos recibiría por su
entrada “petición” dos eventos y sólo atendería uno de ellos. Definiendo la cola
de elementos como un modelo paralelo se resuelve este problema, pues sería
capaz de atender cualquier número de peticiones simultáneas por su entrada
“petición” siempre que hubiera elementos disponibles y también sería capaz de
recibir cualquier número de elementos simultáneamente por su entrada
“recepción”.
• Al describir el modelo atómico del transmisor o procesador dijimos que si un dato

llegaba a su entrada cuando estaba ocupado (procesando el dato anterior), el dato
se perdía. Por tanto, si tenemos dos procesadores (el procesador 1 y el procesador
2) conectados en serie tendremos que asegurarnos que el procesador 2 es más
rápido que el procesador 1 para que todos los datos que lleguen al primero puedan
pasar siempre por el segundo. Pero imaginemos que por alguna circunstancia los
dos procesadores van a acabar de procesar en el mismo instante de tiempo,
entonces en el procesador 2 se presentarían simultáneamente una transición
interna asociada a que debe entregar el dato que acaba de procesar y una
transición externa asociada a la llegada del dato que el procesador 1 le acaba de
pasar. En un modelo acoplado esta situación se resuelve dando prioridad al
procesador 2, para que entregue el dato procesado antes que el otro procesador
haga lo mismo con el suyo. En un modelo paralelo no es necesario marcar la
prioridad, es la función de transición confluente la que se encarga de que tenga
lugar la transición interna, sin liberar al procesador 2, y que inmediatamente se
ponga a procesar el elemento que le ha pasado el otro procesador.
170
EJERCICIO 4.1
Dado el mismo sistema de ocho estados representados en la tabla 4.1, y tomando el

estado s8 como estado de partida.
a) Utilizar el diagrama de la figura 4.2 para, mostrar las transiciones que se habrán
disparado si han llegado dos eventos de entrada, en los instantes de tiempo 5 y 10,
durante los 15 segundos que ha durado la simulación.
b) Construir el correspondiente cronograma, con la misma información que el ejemplo
de la figura 4.1.
a) El estado de partida s8 tiene asociado, según la tabla 4.1, un tiempo de permanencia

de 3 segundos, por tanto como el primer evento de entrada llega a los 5 segundos habrá
dado tiempo a que se dispare la transición interna de s8 a s1. El estado s1 tiene asociado,
según la tabla 4.1, un tiempo de permanencia de 1 segundos y como aún quedaban 2
segundos para que llegará el primer evento de entrada, habrá dado tiempo a que se
dispare la transición interna de s1 a s2. El estado s2 tiene asociado, según la tabla 4.1, un
tiempo de permanencia de 3 segundos y como sólo quedaba 1 segundo para que llegará
el primer evento de entrada, éste habrá provocado una transición externa de s2 a s3 a los
5 segundos. El estado s3 tiene asociado, según la tabla 4.1, un tiempo de permanencia
de 3 segundos y como aún quedaban 5 segundos para que llegará el segundo evento de
entrada, habrá dado tiempo a que se dispare la transición interna de s3 a s4. El estado s4
tiene asociado, según la tabla 4.1, un tiempo de permanencia de 2.5 segundos y como
sólo quedaban 2 segundos para que llegará el segundo evento de entrada, éste habrá
provocado una transición externa de s4 a s5 a los 10 segundos. El estado s5 tiene
asociado, según la tabla 4.1, un tiempo de permanencia de 2.5 segundos y como sólo
quedaban 5 segundos para que acabará la simulación, ha dado tiempo a que se produzca
otra transición interna s5 a s6 a los 12.5 segundos. Pero no ha dado tiempo a que se
dispare la transición interna de s6 a s7 ya que el estado s6 tiene asociado, según la tabla
4.1, un tiempo de permanencia de 3.5 segundos y sólo quedaban 2.5 segundos para que
acabará la simulación Esta secuencia de transiciones está representada en la figura 4.27.
s2 s3
s1 s4
s8 s5
s7 s6
Figura 4.27 Transiciones de estados que han ocurrido en el sistema como consecuencia de los dos
eventos de entrada.
171
b) En la figura 4.28 se muestra el correspondiente cronograma. Donde se aprecian

claramente las seis transiciones (4 internas y dos externas), los instantes de tiempo en
los que han tenido lugar y los eventos de salida, que han provocado las cuatro
transiciones externas, de valores 0.2, 0.3, 0.2 y 0.5 como corresponden, según la tabla
4.1, a los estados s8, s1, s3 y s5.
x2
Eventos de
x1
entrada
0 5 10 15
t2 t
t1
s4
s2
s5
Variable de
estado s1 s6
s8 s3
0 5 10 15
t
Tiempo
transcurrido
0 5 10 15
t
Eventos de
salida ta(s5) = 2.5 y5 = 0.5
y8 = 0.2 y1 = 0.3
ta(s8) = 3 ta(s3) = 3 y3 = 0.2
0 ta(s1) = 1 5 10 15
t
Figura 4.28 Cronograma para el sistema con ocho estados de la Tabla 4.1.
EJERCICIO 4.2
¿Cómo sería el símbolo y el grafo reducido de un generador de eventos periódico con

arranque y parada independientes? Describirlo mediante el formalismo DEVS.
Si se considera que el arranque y la parada son independientes, el bloque generador

debe poseer dos entradas, una para arrancarlo y otra para pararlo, como se muestra en la
figura 4.29. Su grafo reducido es similar al de la figura 4.8, pero ahora es necesario
precisar a qué entrada está asociada cada una de las dos transiciones externas. La
transición externa de “parado” a “activo” está asociada al evento que llegue por la
entrada “arranque” y la transición externa de “activo” a “parado” está asociada al evento
que llegue por la entrada “parada”.
172

arranque y parada
arranque
salida
estado
parada
periodo amplitud
Figura 4.29 Bloque generador de eventos periódico con entradas de arranque y de parada.
arranque
parado activo
parada
Figura 4.30 Grafo reducido del generador con arranque y parada.
Para describirlo con el formalismo DEVS nos vamos a fijar en la descripción del
“generador con arranque/parada” (el bloque que tiene la funcionalidad más parecida) y
la descripción del “almacén tipo cola” (porque ha sido el primer componente descrito
con formalismo DEVS que tiene dos entradas). El resultado es la siguiente descripción,
donde los comentarios son suficientemente aclaratorios: observe que ha sido necesario
incluir la variable de estado sigma, por las mismas razones que en el bloque
“Transmisor”.
MODELO DEVS: Generador de eventos periódico con arranque y parada

2 entradas: {“arranque”,“parada”}, x1 = R, x2 = R
1 variable de estado: estado = {“parado”, “activo”}
2 parámetros: periodo = R+ , amplitud = R+
estado inicial: estado = “parado”
Transición externa: La llegada de un evento de entrada no siempre provoca un

cambio de estado, pues si el generador ya está arrancado no debe obedecer a un
nuevo evento por la entrada de “arranque” sino sólo a un nuevo evento por la entrada
de “parada” y viceversa.
δext(“parado”,sigma,e,x1) = (“activo”,periodo) /* si estaba parado y llega */
/* una orden de arranque, pasa a generación */
δext(“activo”,sigma,e,x1) = (“activo”,sigma-e) /* si estaba activo y llega */
/* una orden de arranque, permanece activo */
δext(“activo”,sigma,e,x2) = (“parado”, ∞) /* si estaba activo y llega */
/* una orden de parada, se para */
δext(“parado”,sigma,e,x2) = (“parado”, sigma-e) /* si estaba parado y llega */
/* una orden de parada, permanece parado*/
Transición interna: Cuando se produce una transición interna permanece en el

estado que estaba, el “activo” el único estado en el que se van a producir las
transiciones internas.
173
δint(“activo”,sigma) = (“activo”,periodo) /* si estaba en generación */

/* permanece generando */
Salida: Genera evento de salida si y sólo si está en generación.

λ (“activo”,sigma) = amplitud

todo momento por el valor de sigma; igual a ∞ si el estado es “parado”, igual al
periodo si el estado es “activo”, y se irá recalculando si se presenta algún evento
externo de arranque cuando el generador está arrancado o viceversa (cuando el
generador está parado).
ta(estado,sigma) = sigma
EJERCICIO 4.3
Basándose en las descripciones de los apartados anteriores, justifique que es correcto

conectar un bloque “generador con entrada de arranque/parada” y un bloque
“procesador” tal como se muestra en la figura 4.31. ¿Qué estados iniciales deben tener
los dos bloques para que el conjunto tenga algún tipo de funcionalidad?
Generador periódico con Procesador

arranque/parada
Arranque entrada salida

estado estado sigma dato
periodo amplitud tiempo_procesamiento
Figura 4.31 Ejemplo de conexión: Generador y Procesador.
La conexión de la figura 4.31 es correcta, pues la salida del generador es un valor real,
igual que la entrada del procesador, y la salida del procesador también toma valores
reales como la entrada del generador.
Si el generador se inicializa en el estado “parado” y el procesador en el estado “espera”,

éste último no recibirá ningún evento del generador y por tanto no podrá generar el
evento que ponga en marcha al generador. Por tanto, con esta inicialización no es
posible conseguir ningún tipo de funcionalidad.
Si el generador se inicializa en el estado “activo” y el procesador en el estado “espera”,

transcurrido un periodo de tiempo, el generador habrá colocado un evento a la entrada
del procesador, haciéndolo pasar al estado de “ocupado”. Cuando el evento haya sido
procesado, la salida del procesador provocará que el generador se pare. Por tanto, con
esta inicialización es posible conseguir una funcionalidad parcial: el procesador
completa un procesamiento, el primero que le solicitó el generador. Aunque el
generador haya generado más eventos mientras que el procesador estaba “ocupado”,
éstos no habrán sido atendidos por el procesador.
174
Si el generador se inicializa en el estado “parado” y el procesador en el estado

“ocupado”, cuando haya transcurrido el tiempo de procesamiento, el procesador
provocará un evento a su salida que pondrá en marcha al generador y, transcurrido un
periodo de tiempo, aparecerá un nuevo evento a la entrada del procesador. Cuando el
nuevo evento haya sido procesado, la salida del procesador provocará que el generador
se pare. Por tanto, con esta inicialización es posible conseguir una funcionalidad parcial:
el procesador completa dos procesamientos, el que estaba realizando al inicializar la
simulación y el primero que le solicitó el generador.
Si el generador se inicializa en el estado “activo” y el procesador en el estado

“ocupado”, cuando haya transcurrido el tiempo de procesamiento, el procesador
provocará un evento a su salida que parará al generador. Por tanto, con esta
inicialización es posible conseguir una funcionalidad parcial: el procesador completa un
procesamiento, el que estaba realizando al inicializar la simulación. Aunque el
generador haya generado más eventos mientras que el procesador estaba “ocupado”,
éstos no habrán sido atendidos por el procesador.
EJERCICIO 4.4
Describir mediante el formalismo DEVS los bloques de almacenamiento tipo

“expendedor” y “receptor”.
Los bloques “almacén expendedor” y “almacén receptor” se pueden considerar como

casos particulares del bloque “almacén tipo cola”, por tanto para sus descripciones
tomaremos como punto de partida la de éste último. El resultado son las siguientes
descripciones, donde los comentarios son suficientemente aclaratorios.
MODELO DEVS: Almacén expendedor

1 entrada: {“petición”}, x = R
1 salida: {“entrega”}, y = R
2 parámetros: tiempo_preparacion = R+ , capacidad de la cola = Z+
estado inicial: estado = “espera”, cola con bastantes elementos, sigma = ∞,
elemento=0
Transición externa: La llegada de un evento a la entrada provoca que el bloque se

prepare para entregar el primer elemento del almacén (el más antiguo de los
almacenados), pero si no hay ningún elemento almacenado o el almacén está
ocupado en otra tarea, la petición no se atenderá.
δext(“espera”,nelementos>0,velementos,sigma,elemento,e,x) =
(“ocupado”,nelementos-1,descarga(velementos,
velementos(1)),tiempo_preparacion,velemento(1))
/* si está en “espera”, se le solicita un elemento y hay disponibilidad, */
/* saca el primer elemento de la cola y se prepara para entregarlo */
δext(“espera”,0,velementos,sigma,elemento,e,x) =
(“espera”,0,velementos,sigma-e,elemento)
175
/* si está en “espera”, se le solicita un elemento y no hay disponibilidad, */

/* no se atiende la petición*/
δext(“ocupado”,nelementos,velementos,sigma,elemento,e,x) =
/* si está “ocupado” y se le solicita un elemento, no se atiende la petición */
Transición interna: La transición interna está asociada a la transmisión de un

elemento, el primero de la cola, y provoca siempre el cambio a “espera” para atender
la próxima petición.
/* si ha entregado un elemento, se prepara para */
/* atender la próxima petición */
Salida: Entrega el primer elemento de la cola a la salida después de haber estado

ocupado el tiempo necesario para prepararlo.
λ (“ocupado”,nelementos,velementos,sigma,elemento) = elemento

todo momento por el valor de sigma; igual ∞ si es el estado es “espera”, igual al
tiempo_preparación si el estado es “ocupado” y no se espera ningún evento externo
mientras se efectúe la entrega, se irá recalculando si se presenta algún evento externo
durante la entrega.
MODELO DEVS: Almacén receptor

1 entradas: {“recepción”}, x = R
0 salidas
2 parámetros: tiempo_colocacion = R+ , capacidad de la cola = Z+
estado inicial: estado = “espera”, cola de elementos sin llenar, sigma = ∞,
elemento=0
Transición externa: La llegada de un evento a la entrada provoca su colocación en

el almacén si y sólo si se estaba esperando y hay hueco para ello. En los demás casos,
el elemento se perderá.
δext(“espera”,nelementos<capacidad,velementos,sigma,elemento,e,x) =
(“ocupado”,nelementos+1,carga(velementos,x1),tiempo_colocacion,0)
/* si está en “espera”, llega un elemento y hay sitio en el almacén, */
/* se prepara para colocar el elemento que ha llegado */
δext(“espera”,capacidad,velementos,sigma,elemento,e,x) =
(“espera”,capacidad,velementos,sigma-e,elemento)
/* si está en “espera”, llega un elemento y no hay sitio en el almacén, */
/* éste no se recepciona */
176
δext(“ocupado”,nelementos,velementos,sigma,elemento,e,x) =
/* si está “ocupado” y llega un elemento, éste no se recepciona */
Transición interna: La transición interna está asociada a la colocación del elemento

que acaba de llegar, y provoca siempre el cambio a “espera” para recibir al siguiente
elemento.
/* si ha recibido un elemento, se prepara para recibir el siguiente */
Salida: No tiene función de salida.

todo momento por el valor de sigma; igual ∞ si es el estado es “espera”, igual al
tiempo_colocación si el estado es “ocupado” y no se espera ningún evento externo
mientras se efectúe la recepción, se irá recalculando si se presenta algún evento
externo durante la recepción.
EJERCICIO 4.5
Proponer un símbolo y una descripción para un modelo atómico DEVS del “carro que
va y viene” analizado en el tema 1.
El comportamiento del “carro que va y viene” fue presentado y analizado en el apartado

1.5.4. Recuerde que era un sistema donde podían ocurrir dos tipos de transiciones, una
transición externa asociada a la pulsación del botón y dos transiciones internas
asociadas a que el carro ha alcanzado uno de los extremos. Las acciones a tomar
dependían del estado del botón y del carro. El símbolo del modelo atómico y su
descripción con el formalismo DEVS pueden quedar como sigue, donde hemos
supuesto creído conveniente, pero no sería totalmente imprescindible, considerar que el
modelo tiene dos salidas A y B para indicar la llegada del carro a los extremos izquierdo
y derecho del raíl. También, con el fin de dar mayor generalidad se ha considerado
conveniente parametrizar el modelo utilizando la longitud del raíl y velocidades
distintas a derecha e izquierda.
Carro que va y viene

A
pulsación
botón carro sigma
B
tamaño_raíl vel_D vel_I
Figura 4.32 Símbolo para el carro que va y viene.
MODELO DEVS: Carro que va y viene

1 entrada: {“pulsación”}, x = R
177
2 salidas: {“A”,“B”}, y1 = {0,1}, y2 = {0,1}

3 variables de estado: botón = {0,1}, carro = {“R”,“D”,“I”}, sigma= R+∞
3 parámetros: tamaño_raíl = R+, vel_D = R+, vel_I = R+
estado inicial: botón = 0, carro=“R”, sigma = ∞
Transición externa: Todas las pulsaciones provocan un cambio de estado inmediato

en el botón y además que el carro se ponga en marcha (si estaba parado en el extremo
A).
δext(0,“R”,sigma,e,x) = (1,“D”,tamaño_raíl/vel_D)
/* si el botón no está pulsado pasa a estarlo y si el carro está en*/
/* reposo, se pone en movimiento hacia la derecha */
δext(0,carro<> “R”,sigma,e,x) = (1,carro,sigma-e)

/* si el botón no está pulsado pasa a estarlo y si el carro está en*/
/* movimiento, sigue estándolo */
δext(1,carro,sigma,e,x) = (0,carro,sigma-e)
/* si el botón está pulsado deja de estarlo con independencia de */
/* cual sea el estado del carro */
Transición interna: El carro deja de moverse hacia la derecha para hacerlo hacia la
izquierda cuando alcanza el extremo B con independencia del estado del botón. El
carro cambia de sentido (cambio de I a D) cuando alcanza el extremo A si el botón
está pulsado, en caso contrario se para.
δint(botón,“D”,sigma) = (botón,“I”, tamaño_raíl/vel_I)

/* provoca el cambio de sentido en el extremo B */
δint(1,“I”,sigma) = (1,“D”, tamaño_raíl/vel_D)

/* provoca el cambio de sentido en el extremo A */
/* si el botón está pulsado */
δint(0,“I”,sigma) = (0,“R”,∞)
/* provoca la parada en el extremo A si el botón no está pulsado */
Salida: Indica la presencia del carro en el extremo correspondiente.

λ (botón,“D”,sigma) = (0,1)
/* moviéndose a la derecha alcanza el extremo B */
λ (botón,“I”,sigma) = (1,0)
/* moviéndose a la izquierda alcanza el extremo A */

todo momento por el valor de sigma; igual ∞ si el carro está en reposo, igual al
tiempo que le llevará alcanzar un extremo cuando el carro comienza a moverse en
cualquiera de los sentidos, y se recalcula si llega alguna pulsación mientras el carro
está en movimiento.
ta(botón,carro,sigma) = sigma
178
Observación. La descripción anterior guarda un total paralelismo con el grafo reducido

de la figura 1.6 (a). La primera sentencia de la función de transición externa recoge el
paso del estado R al D cuando el botón M es pulsado. Las otras dos sentencias de la
función de transición externa no están recogidas en el grafo reducido pero son
necesarias para atender las pulsaciones del botón. La primera sentencia de la función de
transición interna recoge el paso del estado D al I. La segunda y tercera sentencias de la
función de transición interna recoge las dos posibles transiciones que se pueden
producir desde el estado I, la primera cuando el botón está pulsado y la segunda cuando
no lo está. Nos encontramos pues ante un estado de uno de los componentes del sistema,
el estado del “carro moviéndose hacia la izquierda”, que tiene un tiempo de
permanencia conocido (el necesario para llegar al extremo A) pero cuyo destino “carro
en reposo” o “carro moviéndose hacia la derecha” depende del estado del otro
componente del sistema, el botón.
EJERCICIO 4.6
Describir mediante un modelo atómico DEVS la “taquilla del cine” analizada en el

tema 1. Si tuviera que describirla mediante un modelo acoplado DEVS, ¿qué bloques
de los presentados en el tema utilizaría y como sería la descripción?
El comportamiento de la “taquilla del cine” fue presentado y analizado en el apartado

1.5.1. Recuerde que era un sistema donde podían ocurrir dos tipos de transiciones, véase
el grafo reducido de la figura 1.8, una transición externa asociada a la llegada de una
persona al cine y una transición interna asociada a cuando la persona abandona la
taquilla. Las acciones a tomar dependían del estado de la taquilla y del estado de la cola,
véanse los diagramas de flujo de la figura 1.2. No se imponía ninguna condición al
tamaño de la cola, por lo que podemos suponer que su capacidad es infinita, y toda
persona requería un tiempo de atención (parámetro) en la taquilla. La descripción
mediante un modelo atómico con el formalismo DEVS puede quedar como sigue.
MODELO DEVS: Taquilla del cine

1 entrada: {“llegada”}, x = R
5 variables de estado: taquilla = {“libre”, “ocupada”}, numero_personas,
vector_de_personas, sigma= R+∞, persona = R
1 parámetro: tiempo_atencion = R+
estado inicial: taquilla = “libre”, cola en cualquier situación, sigma = ∞, persona=0
Transición externa: La llegada de una persona provoca su paso a la taquilla si ésta

está libre. En caso contrario la persona pasa a la cola.
δext(“libre”,0,vpersonas,sigma,persona,e,x) =
(“ocupada”,0,vpersonas,tiempo_atencion,x)
/* si la taquilla está “libre”, llega una persona, */
/* ésta pasa a ocupar la taquilla */
δext(“ocupada”,npersonas,vpersonas,sigma,persona,e,x) =
(“ocupada”,npersonas+1,carga(vpersonas,x),sigma-e,persona)
/* si la taquilla está “ocupada”, llega una persona, */
179
/* ésta pasa al último lugar de la cola */
Transición interna: La salida de una persona, provoca que la siguiente de la cola

pase a ser atendida o que la taquilla quede libre si ya no hay nadie en la cola.
δint(“ocupada”,npersonas>0,vpersonas,sigma,persona) =
(“ocupada”,npersonas-1,descarga(vpersonas,vpersonas(1)),
tiempo_atencion,vpersona(1))
/* si quedan personas en la cola, la salida de una persona, */
/* provoca que la primera de la cola pase a la taquilla */
δint(“ocupada”,0,vpersonas,sigma,persona) =
(“libre”,0,vpersonas,vpersonas,∞,persona)
/* si no quedan personas en la cola, la salida de una persona, */
/* provoca que la taquilla quede libre*/
Salida: Coloca en la salida a la persona que acaba de ser atendida.

λ (“ocupada”,npersonas,vpersonas,sigma,persona) = persona

todo momento por el valor de sigma; igual ∞ si la taquilla ha quedado libre, igual al
tiempo_atencion cuando hay elementos en la cola, y se recalcula si llega alguna
persona mientras otra está siendo atendida.
ta(taquilla, npersonas,vpersonas,sigma,persona) = sigma
La “taquilla de un cine” se puede construir como modelo acoplado conectando dos

bloques, una “cola de elementos” y un “procesador”, como muestra la figura 4.33. La
capacidad de la cola se debe elegir con valor infinito y el tiempo de procesamiento del
procesador se debe fijar al tiempo de atención que requiere una persona en la taquilla.
Para conseguir la funcionalidad deseada es imprescindible que el procesador arranque
en el estado de “espera”, mientras que la cola puede estar en cualquier situación. Si la
cola arranca vacía, la llegada de la primera persona al cine provocará que la cola la pase
directamente a la taquilla. Y si la cola arranca con algún elemento, ésta enviará a la
taquilla a la persona que más tiempo lleva en ella, provocando sucesivos ciclos de
“ocupado” y “espera” en el procesador y los correspondientes abandonos de personas
que ya han sido atendidas.
Taquilla de un cine
Cola de elementos Procesador
llegada recepción
entrega salida salida
estado nº elementos elementos sigma elemento estado sigma dato
petición
capacidad tiempo_procesamiento
Figura 4.33 Modelo acoplado para la taquilla de un cine.
Su descripción mediante modelo acoplado quedaría como sigue:
180
MODELO DEVS ACOPLADO: Taquilla de un cine

1 entrada de valor real: {“llegada”}, x = R
1 salida de valor real: {“salida”}, y = R
/* Dos componentes con sus respectivos modelos DEVS */

D = {cola de elementos, procesador}

CE = { ( (taquilla de un cine,“llegada”) , (cola de elementos,“recepción”) ) }
/* Una conexión de salida externa */

CS = { ( (procesador,“salida”) , (taquilla de un cine,“salida”) ) }
/* Dos conexiones internas */

CI = {( (cola de elementos,“entrega”) , (procesador,“entrada”) ),
( (procesador,“salida”) , (cola de elementos,“petición”) ) }
Función de selección: No es necesaria en este caso pues la cola de elementos está

siempre al servicio del procesador.
EJERCICIO 4.7
Describir mediante un modelo atómico DEVS los “carros que van y vienen
sincronizados en los extremos” analizados en el tema 1. Si tuviera que describirlos
mediante un modelo acoplado DEVS ¿cómo modificaría el bloque propuesto en el
ejercicio 4.5 para el “carro que va y viene”, cómo serían las conexiones y la
descripción?
El comportamiento de los “carros que van y vienen” fue presentado y analizado en el

apartado 1.6.3.1. Recuerde que era un sistema donde podían ocurrir dos tipos de
transiciones, una transición externa asociada a la pulsación del botón y ocho
transiciones internas asociadas a que uno de los carros ha alcanzado uno de los
extremos, véase el grafo reducido de la figura 1.9. Las acciones a tomar dependían del
estado del botón y de los carros. Recuerde que el conjunto de los dos carros sólo podía
estar en siete estados posibles, como se justificó en el apartado 1.6.3.1. El símbolo del
modelo atómico y su descripción con el formalismo DEVS pueden quedar como sigue.
Carros que van y vienen

A
pulsación botón carros sigma B

C
tamaño_raíl1 vel_D1 vel_I1
D
Figura 4.34 Símbolo para los carros que van y vienen.
181
MODELO DEVS: Carros que van y vienen

4 salidas: {“A”,“B”, “C”,“D”}, y1 = {0,1}, y2 = {0,1}, y3 = {0,1}, y4 = {0,1}
3 variables de estado: botón = {0,1}, carros = {“RI1 RI2”,“RI1 I2”,“D1 D2”,
“D1 RD2”, “RD1 D2”, “I1 RI2”, “I1 I2”}, sigma= R+∞
6 parámetros: tamaño_raíl1 = R+, vel_D1= R+, vel_I1 = R+,
tamaño_raíl2 = R+, vel_D2= R+, vel_I2 = R+
estado inicial: botón = 0, carros =“RI1 RI2” , sigma = ∞

en el botón y además que lo carros se ponga en marcha (si estaban parados en sus
respectivos extremos izquierdos).
δext(0,“RI1 RI2”,sigma,e,x) = (1, “D1 D2”,

min(tamaño_raíl1/vel_D1,tamaño_raíl2/vel_D2)
/* si el botón no está pulsado pasa a estarlo y si los carros están en*/
/* reposo en los extremos izquierdos, se ponen en */
/* movimiento hacia la derecha */
δext(0,carros<>“RI1 RI2”,sigma,e,x) = (1,carros,sigma-e)

/* si el botón no está pulsado pasa a estarlo y si algún carro está en*/
/* movimiento, sigue estándolo */
δext(1,carros,sigma,e,x) = (0,carros,sigma-e)
/* cuales sean los estados de los carros */
Transición interna: El carro 1 deja de moverse hacia la derecha para hacerlo hacia
la izquierda cuando alcanza el extremo B si el carro 2 ya había alcanzado el extremo
D, pero si no es así el carro 1 se tiene que parar en el extremo B. Algo similar ocurre
cuando el carro 2 alcanza el extremo D. El carro 1 cambia de sentido (cambio de I a
D) cuando alcanza el extremo A si el botón está pulsado y el carro2 ya había
alcanzado el extremo C, en caso contrario se para. Algo similar ocurre cuando el
carro 2 alcanza el extremo I.
if tamaño_raíl1/vel_D1 <= tamaño_raíl2/vel_D2

δint(botón,“D1 D2”,sigma) = (botón,“RD1 D2”,tamaño_raíl1/vel_D1)
/* provoca la parada del carro 1 en el extremo B porque */
/* el carro 2 aún no ha llegado a D */
else
δint(botón,“D1 D2”,sigma) = (botón,“D1 RD2”,tamaño_raíl2/vel_D2)
/* provoca la parada del carro 2 en el extremo D porque */
/* el carro 1 aún no ha llegado a B */
end
δint(botón,“RD1 D2”,sigma) = (botón,“I1 I2”,

tamaño_raíl2/vel_D2-tamaño_raíl1/vel_D1)
/* provoca que ambos carros vayan hacia la izquierda porque */
182
/* el carro 1 estaba en B y el carro 2 ya ha llegado a D */
δint(botón,“D1 RD2”,sigma) = (botón,“I1 I2”,

tamaño_raíl1/vel_D1-tamaño_raíl2/vel_D2)
/* provoca que ambos carros vayan hacia la izquierda porque */
/* el carro 2 estaba en D y el carro 1 ya ha llegado a B */

δint(botón,“I1 I2”,sigma) = (botón,“RI1 I2”,tamaño_raíl1/vel_I1)
/* provoca la parada del carro 1 en el extremo A porque */
/* el carro 2 aún no ha llegado a C */
else
δint(botón,“I1 I2”,sigma) = (botón,“I1 RI2”,tamaño_raíl2/vel_I2)
/* provoca la parada del carro 2 en el extremo C porque */
/* el carro 1 aún no ha llegado a A */
end
δint(0,“RI1 I2”,sigma) = (0,“RI1 RI2”,∞)

/* provoca que ambos carros se paren porque el carro 1 estaba en A, */
/* el carro 2 ya ha llegado a C y el botón no está pulsado*/
δint(0,“I1 RI2”,sigma) = (0,“RI1 RI2”,∞)

/* provoca que ambos carros se paren porque el carro 2 estaba en C, */
/* el carro 1 ya ha llegado a A y el botón no está pulsado*/
δint(1,“RI1 I2”,sigma) = (1,“RI1 RI2”,0)

/* provoca que ambos no se paren porque el carro 1 estaba en A, */
/* el carro 2 ya ha llegado a C y el botón está pulsado*/
δint(1,“I1 RI2”,sigma) = (1,“RI1 RI2”,0)

/* provoca que ambos carros no se paren porque el carro 2 estaba en C, */
/* el carro 1 ya ha llegado a A y el botón está pulsado*/
Salida: Indica la presencia de los carros en los extremos correspondientes.

λ (botón,“D1 D2”,sigma) = (0,1,0,0)
/* moviéndose a la derecha el carro 1 ha alcanzado el extremo B */
else
λ (botón,“D1 D2”,sigma) = (0,0,0,1)
/* moviéndose a la derecha el carro 2 ha alcanzado el extremo D */
end
λ (botón,“RD1 D2”,sigma) = (0,1,0,1)

/* moviéndose a la derecha el carro 2 ha alcanzado el extremo D */
λ (botón,“D1 RD2”,sigma) = (0,1,0,1)
/* moviéndose a la derecha el carro 1 ha alcanzado el extremo B */
183
λ (botón,“I1 I2”,sigma) = (1,0,0,0)

/* moviéndose a la izquierda el carro 1 ha alcanzado el extremo A */
else
λ (botón,“I1 I2”,sigma) = (0,0,1,0)
/* moviéndose a la izquierda el carro 2 ha alcanzado el extremo C */
end
λ (botón,“RI1 I2”,sigma) = (1,0,1,0)

/* moviéndose a la izquierda el carro 2 ha alcanzado el extremo C */
λ (botón,“I1 RI2”,sigma) = (1,0,1,0)
/* moviéndose a la izquierda el carro 1 ha alcanzado el extremo A */
Avance de tiempo: Los tiempos de permanencia en los siete posibles estados del
conjunto vienen determinado en todo momento por el valor de sigma; igual ∞ si los
carros están en reposo, calculado en función de los parámetros del sistema si el
conjunto de carros está en cualquier otro estado del sistema y no se esperan
pulsaciones, y se recalcula si llega alguna pulsación mientras haya algún carro en
movimiento.
ta(botón,carros,sigma) = sigma
Aclaraciones: La complejidad del ejemplo nos recomienda hacer algunas aclaraciones a

las funciones descritas anteriormente.
1) En la primera sentencia de la función de transición externa nos hemos
encontrado con el primer problema. ¿Cuál es el tiempo de permanencia en el
estado “D1 D2”? El tiempo de permanencia depende de la parametrización que
se haya hecho del sistema, en concreto de las velocidades a derecha de ambos
carros y de los tamaños de los raíles, pues dependiendo de estos parámetros el
carro 1 alcanzará el extremo B antes de que el carro 2 alcance el extremo D o
viceversa.
2) En la función de transición interna nos hemos encontrado con el siguiente
problema. Por el mismo razonamiento hecho en la aclaración anterior, la
transición interna que se producirá desde el estado “D1 D2” tendrá un estado
destinatario diferente “RD1 D2” o “D1 RD2”, que depende de la
parametrización que se haya hecho del sistema. Lo hemos resuelto combinando
dos sentencias de la función de transición interna en una estructura condicional
“if then else”. Una solución similar se ha empleado en las dos posibles
transiciones cuando ambos carros están moviéndose hacia la izquierda.
3) Los tiempos de permanencia en los siete estados del conjunto de ambos carros se
han ido asignado en base a los seis parámetros del sistema. Por ejemplo, el
tiempo de permanencia en el estado “RD1 D2” es el tiempo que falta para que el
carro 2 alcance el extremo D medido desde el instante que el carro 1 ha
alcanzado el extremo B. Luego se puede expresar como el tiempo total que
necesita el carro 2 para ir desde el extremo izquierdo C al extremo derecho D,
menos el tiempo que ha empleado el carro 1 en llegar de A a B.
4) El querer disponer de eventos de salida cada vez que los carros van alcanzando
los respectivos extremos ha complicado la función de salida, en la que se ha
vuelto a hacer uso de estructuras condicionales en función de los seis parámetros
del sistema.
184
El bloque elemental descrito en el ejercicio 4.5 no nos vale para describir el conjunto de
los dos carros pues mientras “el carro que va y viene” sólo presenta tres posibles estados
(“R”, “D” e “I”), cada uno de los carros que van y vienen puede presentar cuatro
posibles estados (“RI”, “D”, “RD” e “I”). Pero no basta con ampliar en un estado más,
el de reposo en el extremo derecho, sino que también hay que ampliar la información
que el carro recibe de su entorno, pues antes sólo recibía eventos asociados con el botón
y ahora debe recibir eventos asociados con el otro carro. El bloque resultante debe
quedar como muestra la figura 4.35. Y su descripción va a continuación.
pulsación Carro que va y viene combinado

A
llegada A
botón otro carro carro sigma
B
llegada B
tamaño_raíl vel_D vel_I
Figura 4.35 Símbolo para el carro que va y viene combinado con otro carro.
MODELO DEVS: Carro que va y viene combinado con otro carro

3 entradas: {“pulsación”,“llegada A”,“llegada B”}, x1 = R, x2 = {0,1}, x3 = {0,1}
2 salidas: {“A”,“B”}, y1 = {0,1}, y2 = {0,1}
3 variables de estado: botón = {0,1}, otro carro = {“RI”,“D”,“RD”,“I”},
carro = {“RI”,“D”,“RD”,“I”}, sigma= R+∞
3 parámetros: tamaño_raíl = R+, vel_D = R+, vel_I = R+
estado inicial: botón = 0,otro carro=“RI”, carro=“RI”, sigma = ∞

en el botón y además que el carro se ponga en marcha (si los dos carros estaba
parados en los extremos izquierdos). La llegada del otro carro a uno de los extremos
(el izquierdo A o el derecho B) se atiende inmediatamente para tener siempre
información de la situación del otro carro y provoca distintas acciones, dependiendo
del estado del carro y del botón.
δext(0,“RI”,“RI”,sigma,e,x1) = (1,“D”,“D”,tamaño_raíl/vel_D)
/* si el botón no está pulsado pasa a estarlo y si los carros están en*/
/* reposo, el carro se pone en movimiento hacia la derecha */
/* y considera que el otro carro también */
δext(0,{otro carro,carro}<> {“RI”,“RI”},sigma,e,x) = (1,otro carro,carro,sigma-e)

/* si el botón no está pulsado pasa a estarlo y si alguno de los carros */
/* está en movimiento, el carro sigue en el estado que estuviera */
/* y considera que el otro carro también */
δext(1,otro carro,carro,sigma,e,x) = (0,carro,sigma-e)

/* cuales sean los estados de los carros */
185
δext(boton,“D”,“D”,sigma,e,x3) = (boton,“RD”,“D”,sigma-e)
/* toma nota de que el otro carro ha llegado antes al extremo derecho */
δext(boton,“D”,“RD”,sigma,e,x3) = (boton,“I”,“I”,tamaño_raíl/vel_I)
/* como estaba esperando la llegada del otro carro al extremo derecho */
/* se pone en marcha hacia la izquierda y considera que el otro también */
δext(boton,“I”,“I”,sigma,e,x2) = (boton,“RI”,“I”,sigma-e)
/* toma nota de que el otro carro ha llegado antes al extremo izquierdo */
δext(0,“I”,“RI”,sigma,e,x2) = (boton,“RI”,“RI”,∞)
/* como estaba esperando la llegada del otro carro al extremo izquierdo */
/* pero el botón no está pulsado, se queda parado */
/* y considera que el otro también */
δext(1,“I”,“RI”,sigma,e,x2) = (1,“D”,“D”,tamaño_raíl/vel_D)
/* como estaba esperando la llegada del otro carro al extremo izquierdo */
/* y el botón está pulsado, se pone en marcha hacia la derecha */
/* y considera que el otro también */
Transición interna: El carro deja de moverse hacia la derecha para pararse o para
moverse hacia la izquierda cuando alcanza el extremo B, dependiendo del estado del
otro carro pero con independencia del estado del botón. El carro cambia de sentido
(cambio de I a D) cuando alcanza el extremo A si el botón está pulsado y el otro
carro lo estaba esperando, en cualquier otro caso se para.
δint(botón,“D”,“D”,sigma) = (botón, “D”,“RD”,∞)

/* provoca la parada del carro en el extremo B */
δint(botón,“RD”,“D”,sigma) = (botón, “I”,“I”, tamaño_raíl/vel_I)

/* provoca el cambio de sentido en el extremo B */
/* y considera que el otro carro se ha puesto en marcha */
δint(botón,“I”,“I”,sigma) = (botón, “I”,“RI”,∞)

/* provoca la parada del carro en el extremo A */
δint(0,“RI”,“I”,sigma) = (botón, “RI”,“RI”,∞)

/* provoca la parada del carro en el extremo A */
δint(1,“RI”,“I”,sigma) = (1, “D”,“D”, tamaño_raíl/vel_D)

/* provoca el cambio de sentido en el extremo A */
/* y considera que el otro carro se ha puesto en marcha */
Salida: Indica la presencia del carro en el extremo correspondiente.
λ (botón,“D”,“D”,sigma) = (0,1)
/* moviéndose a la derecha ha alcanzado el extremo B */
/* antes que el otro carro el suyo */
186
λ (botón,“I”,“I”,sigma) = (1,0)
/* moviéndose a la izquierda ha alcanzado el extremo A */
/* antes que el otro carro el suyo */
λ (0,“RI”,“I”,sigma) = (1,0)
/* moviéndose a la izquierda ha alcanzado el extremo A */
/* después que el otro carro el suyo */

todo momento por el valor de sigma; igual ∞ si el carro está en reposo, igual al
tiempo que le llevará alcanzar un extremo cuando el carro comienza a moverse en
cualquiera de los sentidos, y se recalcula si llega alguna pulsación o evento del otro
carro mientras el carro está en movimiento.
ta(botón,otro carro,carro,sigma) = sigma
Conectando dos bloques como el descrito anteriormente, véase figura 4.36, se consigue
la funcionalidad deseada. La descripción del modelo acoplado va a continuación.
pulsación pulsación 1 carro1 que va y viene combinado

A1 A
llegada A2
B1 B
llegada B2
pulsación 2 carro2 que va y viene combinado

A2 C
llegada A1
B2 D
llegada B1
Figura 4.36 Modelo acoplado para los carros que van y vienen.
MODELO DEVS ACOPLADO: Carros que van y vienen

4 salidas: {“A”,“B”,“C”,“D”}, y1 = {0,1}, y2 = {0,1}, y3 = {0,1}, y4 = {0,1}
/* Dos componentes del mismo tipo y por tanto el mismo modelo DEVS */
187
D = {carro1 que va y viene combinado, carro2 que va y viene combinado}
/* Dos conexiones de entrada externa */

CE = { ( (carros que van y vienen,“pulsación”) , (carro1,“pulsación”) ),
( (carros que van y vienen,“pulsación”) , (carro2,“pulsación”) ) }
/* Cuatro conexiones de salidas externas */

CS = { ( (carro1,“A1”), (carros que van y vienen,“A”) ),
( (carro1,“B1”), (carros que van y vienen,“B”) ),
( (carro2,“A2”), (carros que van y vienen,“C”) ),
( (carro2,“B2”), (carros que van y vienen,“D”) )}
/* Cuatro conexiones internas */

CI = { ( (carro1,“A1”), (carro2,“llegada A1”) ),
( (carro1,“B1”), (carro2,“llegada B1”) ),
( (carro2,“A2”), (carro1,“llegada A2”) ),
( (carro2,“B2”), (carro1,“llegada B2”) ) }
Función de selección: el orden de prioridad puede ser cualquiera.
188
ANEXO
Ejercicios para programar en ARENA
A continuación se incluye una serie de ejercicios con el objetivo de que el alumno

practique el modelado de sistemas de eventos discretos (SED) en el entorno de
programación ARENA. Todos los ejercicios (algunos resueltos, otros propuestos) se
acompañan del correspondiente archivo “*.doe” para que el alumno pueda reproducir
los resultados o experimentar con situaciones totalmente diferente a la comentada en la
resolución del ejercicio.
Los ejercicios están clasificados en tres categorías:
Modelos de autómatas de estado

Modelos con estructura de Red de Petri
Modelos sobre automatismos
En casi todos los ejercicios el alumno se verá necesitado de la generación de eventos,

para ello se le recomienda utilizar un bloque Create (denominado Generador en la
figura A.1), y de algún procedimiento para que los eventos (una vez procesados)
abandonen el modelo, un bloque Dispose (denominado Receptor en la figura A.1) le
servirá en esta tarea, véase el archivo “ej_basico.doe”.
Figura A.1 Modelo “generación y recepción de eventos”.
Pero si además se desea tener una visualización gráfica de los instantes en que se
producen los eventos, se recomienda utilizar un bloque Process con la opción Delay
únicamente (denominado Visualizador en la figura A.2) y elegir un valor del retardo
muy pequeño en relación con el intervalo entre eventos. De esta forma se consigue que
los eventos ocupen un tiempo despreciable del procesador y por tanto que la evolución
189
de la variable Retardo.WIP tenga el aspecto de la representación gráfica incluida en la

figura A.2. Véase el archivo “ej_v_eventos.doe”.
Figura A.2 Modelo “generación y visualización de eventos”.
Se recomienda al alumno que haga uso de la ayuda del entorno de ARENA así como de
los manuales que le acompañan, en especial el capítulo “Getting Started” de la guía
“Arena Standard Edition. User’s Guide”. También se le recomienda que consulte el
Tema 6 de Simulación (Urquía, 2003) y la solución a los problemas de este tema.
190
A.1 MODELOS DE AUTÓMATAS DE ESTADO
A continuación se proponen varios ejercicios sobre autómatas de estado con el objetivo

de que el alumno se familiarice con el entorno de programación ARENA.
A.1.1 Ejercicio 1: “Autómata cíclico con dos estados”
Programar un autómata con dos estados (“S1” y “S2”) que cambie de estado de forma
cíclica cada vez que reciba un evento.
Solución: Véase el archivo “ej_automata.doe”. Entre el Generador y el Receptor se

ha incorporado un bloque Assign (denominado Automata en la figura A.3). Dicho
bloque hace uso del operador matemático “= =” que permite realizar una negación
lógica cuando se utiliza con una variable binaria de la forma siguiente:
Estado = Estado = = 0
Además a la variable Estado se le ha asignado un objeto circular que cambia de color

(azul y rojo) en función de su valor, que también se muestra en un campo de texto. Las
figuras A.3 (a) y (b) muestran dos momentos concretos de la simulación: a) al llegar el
segundo evento, b) al llegar el tercer evento.
Figura A.3 (a) Estado del autómata al llegar el segundo evento.
Figura A.3 (b) Estado del autómata al llegar el tercer evento.
En el modelo anterior se puede incluir visualización gráfica de los instantes en los que
se han generado los eventos y del estado instantáneo en que se encuentra el autómata.
191
También se ha aprovechado la ocasión para agrupar la visualización numérica e

iconográfica de la variable Estado en un solo elemento con la apariencia mostrada en la
figura A.4, véase archivo “ej_automata_v.doe”.
Figura A.4 Modelo del autómata con visualización gráfica del estado y de los eventos.
Observe que el modelo anterior arranca siempre en el Estado=0, pasa al Estado=1

cuando llega el primer evento y alterna entre estados con la llegada de los sucesivos
eventos. En definitiva, el modelo funciona como un contador módulo 2, porque pasa al
estado “1” cada vez que se recibe un evento impar y porque pasa al estado “0” cada vez
que se reciba un evento par. Si se quiere que el modelo arranque en el estado “1” basta
con cambiar el valor inicial de la variable Estado. Pero en ese caso empezará a
funcionar como contador módulo 2 con lógica inversa, pasando al estado “1” cada vez
que se recibe un evento par y al estado “0” cada vez que se reciba un evento impar. En
un apartado posterior, cuando programemos los modelos con estructura de redes de
Petri, volverá a mencionarse el tema de la inicialización del modelo por la importancia
que ésta tiene.
192
A.1.2 Variantes del ejercicio 1
1.a) El modelo de autómata cíclico con dos estados tiene una aplicación inmediata: se
propone adaptarlo para que simule el encendido y apagado de una lámpara mediante
el correspondiente pulsador. Se recomienda aprovechar este ejercicio para practicar
con un tipo de animación más compleja que la del autómata y más apropiada para el
fenómeno que se está simulando. Por ejemplo, utilizando el siguiente esquema de
circuito eléctrico con dos elementos interruptor y lámpara, cada uno con dos estados
posibles; el interruptor puede estar “abierto” o “cerrado” y la lámpara puede estar
“apagada” o “encendida”. O bien utilizando dos esquemas eléctricos diferentes.
Solución: Ver el archivo “ej_lampara.doe”.
Para su desarrollo se ha partido del archivo “ej_automata.doe”, se ha conservado la

estructura de bloques pero se ha eliminado la visualización numérica y el objeto circular
animado. Se ha incorporado el esquema eléctrico compuesto por los siguientes tres
elementos: un elemento fijo sobre el que se han superpuesto dos objetos animados el
interruptor con dos valores “abierto” y “cerrado” y la lámpara con dos valores
“apagada” y “encendida”, véase la tabla A.1. En la figura A.5 puede verse el aspecto del
esquema eléctrico cuando la lámpara está apagada y cuando la lámpara está encendida.
Elemento fijo Interruptor Lámpara
Tabla A.1 Elementos utilizados para animar el esquema eléctrico de encendido y apagado de un
lámpara.
193
Figura A.5 Aspecto del esquema eléctrico cuando la lámpara está apagada (izquierda) y cuando la
lámpara está encendida (derecha).
1.b) El modelo de autómata cíclico se puede modificar para que funcione como un
autómata de n estados (contador módulo n).
Solución: Basta definir una variable n y utilizarla como parámetro en la función

matemática AMOD para asignarle, en el bloque Assign, al estado del autómata el resto
de la división entre el número asociado al evento y el módulo del contador. En concreto
basta realizar la siguiente asignación:
Estado = AMOD(Generador.NumberOut,n)
Se podría utilizar el mismo objeto animado pero con tantos colores como valores pueda
tomar la variable de estado.
Véase como ejemplo el archivo “ej_contador.doe”, que aunque valdría para cualquier
contador, contiene animación y visualización dimensionada para un contador de módulo
menor o igual que 5.
Para su desarrollo se ha partido del archivo “ej_autómata_v.doe”, se ha incluido la

sentencia
Estado = AMOD(Generador.NumberOut,n)
en el bloque Automata, se han incorporado cinco valores (‘0’, ‘1’, ‘2’, ‘3’ y ‘4’) con los
correspondientes colores en el objeto circular animado, se ha ampliado a [-1 5] el
escalado de la gráfica de la derecha para dar cabida a los cinco valores del Estado, y se
ha asignado el valor 5 a la variable n para que el autómata esté en concordancia con la
animación.
La figura A.6 muestra el resultado de la simulación; después de 12 eventos generados

aleatoriamente se observa como el contador, que partió del estado inicial “0” ha pasado
de forma cíclica por los cinco estados, acabando en el estado “2”.
194
Figura A.6 Estructura en Arena de un contador módulo 5 y resultados de la simulación después de 12

eventos generados aleatoriamente.
1.c) Modelar el comportamiento básico de un semáforo de tráfico con un autómata

cíclico con tres estados en los que cada estado tiene asignado un tiempo de
permanencia distinto; por ejemplo 1 minuto en el estado “verde”, 10 segundos en el
estado “ámbar” y 1 minuto en el estado “rojo”.
Solución: El cambio cualitativo respecto a los modelos anteriores es que se trata de un

ciclo regular, que se repite indefinidamente. Se ha optado pues por utilizar un bloque
Create en el que se haya elegido la opción de generar eventos a intervalos regulares de
tiempo, y un bloque Assign que asigne, en función de cada estado del semáforo, el
estado siguiente y modifique el tiempo entre eventos del bloque Create para que el
siguiente evento se produzca en el plazo correspondiente. El modelo, ver el archivo
“ej_semaforo.doe”, incluye además la animación propia del semáforo haciendo uso de
los siguientes tres iconos, uno por cada estado.
Para su desarrollo se ha partido del archivo “ej_autómata_v.doe”, se ha conservado la

estructura de bloques pero se ha eliminado la visualización de eventos (bloque
195
Visualizador y gráfica de eventos generados). En el bloque Generador se ha

seleccionado una generación periódica con tiempo entre eventos igual al valor de la
variable tpermanencia. En el bloque Assign, denominado antes Automata y ahora
Semaforo, se han incluido las sentencias
Estado=AMOD(Generador.NumberOut,3)
tpermanencia=10*(Estado==0)+60*(Estado==1)+60*(Estado==2)
con la primera sentencia se lleva la cuenta del estado (con valores ‘0’, ‘1’ y ‘2’), y con
la segunda sentencia se consigue asignar a la variable tiempo de permanencia el valor
que corresponde al siguiente estado. Es decir, que después del estado en “verde”
representado por el valor ‘0’, el tiempo de permanencia debe valer 10 segundos (el
tiempo que debe permanecer en el próximo estado, que es el “ámbar”. La animación se
ha realizado a través de un único objeto con valor igual al Estado, que tiene asociado
los tres iconos mencionados anteriormente.
La figura A.7 muestra el resultado de la simulación; después de 600 segundos se

observa como el semáforo, que partió del estado inicial “verde” ha pasado de forma
cíclica por los tres estados posibles, completando cinco ciclos y acabando en el estado
“verde”.
Figura A.7 Modelo en Arena del semáforo y resultados de la simulación después de 600 segundos.
1.d) Utilizar la experiencia del ejercicio anterior para modelar el comportamiento

básico de los “semáforos de tráfico encargados de regular un cruce” analizado en el
ejercicio 1.6.
Solución: En el ejercicio 1.6 se justificó que el comportamiento de los “semáforos de

tráfico encargados de regular un cruce” se podía modelar como un autómata cíclico con
seis estados, los recogidos en la tabla 1.3. Por tanto para su programación en Arena,
196
véase el archivo “ej_semaforos.doe”, se ha partido del archivo “ej_semaforo.doe”

correspondiente al ejercicio anterior, en el bloque Semaforo se han incluido las
sentencias:
Estado=AMOD(Generador.NumberOut,6)
Estado_S1=2*(Estado==0)+0*(Estado==1)+1*(Estado==2)+2*(Estado=
=3)+2*(Estado==4)+2*(Estado==5)
Estado_S2=2*(Estado==0)+2*(Estado==1)+2*(Estado==2)+2*(Estado=
=3)+0*(Estado==4)+1*(Estado==5)
tpermanencia= 60*(Estado==0)+10*(Estado==1)+10*(Estado==2)+
60*(Estado==3)+10*(Estado==4)+10*(Estado==5)
Con la primera sentencia se lleva la cuenta de los seis estados (con valores ‘0’, ‘1’, ‘2’,
‘3’, ‘4’ y ‘5’) que intervienen en el ciclo, en el mismo orden de la tabla 1.3, y con la
cuarta sentencia se consigue asignar a la variable tiempo de permanencia el valor que
corresponde al siguiente estado. Es decir, que después del estado (“rojo” y “rojo”)
representado por el valor ‘0’, el tiempo de permanencia debe valer 60 segundos (el
tiempo que debe permanecer en el próximo estado, que es el (“verde” y “rojo”). La
animación se ha realizado con dos objetos idénticos al ejercicio anterior, con valores
iguales al Estado_S1 y al Estado_S2. De ahí la segunda y la tercera sentencia, que se
han incluido en el bloque Semaforo con el objetivo de discriminar el estado individual
de cada uno de los semáforos al partir del Estado del conjunto.

observa como el conjunto de semáforos, que partió del estado inicial (“verde” y “rojo”)
ha pasado de forma cíclica por los seis estados posibles, completando tres ciclos y
acabando en el estado (“rojo” y “verde”). Para facilitar la interpretación de la
simulación se han incluido también las gráficas de evolución del estado de cada uno de
los semáforos.
Figura A.8 Modelo en Arena de dos semáforos que regulan un cruce y resultados de la simulación
después de 600 segundos.
197
A.1.3 Ejercicio 2: Autómata con estados de “espera” y “ocupado”
Programar un autómata con dos estados, S1=“espera” y S2=“ocupado”, que arranca

en el estado “espera” y cambia al estado “ocupado” cada vez que recibe un evento,
permaneciendo en este estado un tiempo fijo (tpermanencia) después del cual vuelve al
estado “espera”. En definitiva se trata de programar un bloque Transmisor o
Procesador con tiempo de transmisión o de procesamiento fijo. Se recomienda incluir
una animación gráfica sobre el siguiente grafo reducido, que ya fue justificado en el
ejercicio 1.5.
espera ocupado
Solución: Véase el archivo “ej_automata_S1S2.doe”. El bloque Automata de la figura

A.4 se ha sustituido por un conjunto de tres bloques, el primero (denominado Cambio
al estado S2 en la figura A.9) y el tercero (denominado Cambio al estado S1 en la
figura A.9) son dos bloques de tipo Assign que realizan respectivamente la siguientes
operaciones:
Estado = 1 y Estado = 0
provocando por tanto un cambio de valor lógico en la variable Estado, mientras que el
segundo (denominado Permanencia en el estado S2 en la figura A.9) es un bloque
Process con la opción Delay únicamente, con un valor del retardo igual al tiempo de
permanencia en el estado S2. El primer cambio de estado, de “espera” a “ocupado” se
produce cuando llega un evento y el segundo cambio de estado, de “ocupado” a
“espera” se produce cuando el evento ha permanecido el tiempo correspondiente en el
estado S2.
La animación sobre el correspondiente diagrama de transición de estados se ha resuelto

combinando dos arcos de flecha con dos iconos circulares, uno para cada estado, pero
sus animaciones están particularizadas de distinta forma. El objeto “S1” tiene asignado
el color rojo cuando Estado=0 y el color azul cuando Estado=1, mientras que el objeto
“S2” tiene asignado el color rojo cuando Estado=1 y el color azul cuando Estado=0.
Figura A.9 Modelo de un autómata con visualización gráfica y animación del diagrama de transición de
estados.
198
En la visualización gráfica de la figura A.9 se observa que el bloque Generador ha

generado tres eventos, distanciados entre sí 4 unidades de tiempo y que el autómata ha
pasado las tres veces por el estado S2 (valor lógico “1”) permaneciendo en él 1 unidad
de tiempo (el valor que se ha fijado para la variable tpermanencia). Para que la
solución anterior sea válida hay que tener la precaución de dimensionar adecuadamente
el bloque Generador. Este debe generar los eventos con un intervalo de tiempo inferior
al tiempo de permanencia en el estado S2, puesto que de no ser así todos los eventos
progresarán en el modelo produciendo transiciones de estado no deseadas.
Hay una forma de evitar el problema anterior, véase el archivo

“ej_automata_S1S2m.doe”, consiste en que cada vez que llega un evento se chequea si
el autómata está en el estado S2=“ocupado”. Si no lo está se procede como en la figura
A.10, pero si el autómata está ocupado en la transmisión del evento anterior, el evento
que acaba de llegar no se manda al autómata sino que se desvía hacia otro Receptor
alternativo para que abandone el modelo sin ser atendido. El bloque encargado de
tomar la decisión (denominado Ocupado en la figura A.10) es un bloque del tipo
Decide que utiliza la variable Estado para enviar o no el evento al autómata.
Figura A.10 Ampliación del modelo de autómata de dos estados para que no reciba eventos cuando está
ocupado.
En la visualización gráfica de la figura A.10 se observa que el bloque Generador ha

generado aleatoriamente siete eventos, que sólo cinco de esos eventos han sido
transmitidos por el autómata, que le han llevado a permanecer cinco veces en el estado
S2 (valor lógico “1”) durante 1 unidad de tiempo, y que los otros dos eventos han sido
desviados al receptor alternativo.
El modelo anterior se puede simplificar más, véase el archivo

“ej_automata_S1S2s.doe”, eliminando los dos bloques Assign y aprovechando el
atributo WIP del bloque Process tanto para tomar la decisión como para representar el
estado del autómata. El diagrama resultante se muestra en la figura A.11, donde se ha
utilizado el nombre “Automata” para el bloque Process.
199
Figura A.11 Estructura simple del modelo de autómata de dos estados.
A.1.4 Variantes del ejercicio 2
2.a) Basándose en el autómata anterior y en la experiencia previa con el

comportamiento básico del semáforo de tráfico, se propone desarrollar un modelo que
simule el comportamiento de un semáforo que atiende un paso de peatones con
pulsador manual. Se recomienda incluir en el modelo una animación gráfica sobre el
correspondiente grafo reducido además de la animación propia del semáforo.
Solución: Véase el archivo “ej_semaforo_peatones.doe”.
El autómata que modela el comportamiento de este tipo de semáforo se puede concebir

con cuatro estados, que fueron analizados en el ejercicio 1.5, los habituales “verde”,
“ámbar” y “rojo” cada uno con su correspondiente tiempo de permanencia (1 minuto en
“verde”, 10 segundos en “ámbar” y 1 minuto en “rojo”) y un cuarto estado “espera”,
con tiempo de permanencia ilimitado, pues si no existe petición de ningún peatón, el
semáforo permanecerá en este estado indefinidamente, en el que también luce la
lámpara verde.
Para su desarrollo se ha partido del archivo “ej_automata_S1S2m.doe” que modelaba

el autómata con dos estados (“espera” y “ocupado”), se ha sustituido la secuencia de dos
estados por una secuencia de cuatro estados utilizando siete bloques, cuatro del tipo
Assign y tres del tipo Process son la opción Delay únicamente, véase el archivo
“ej_semaforo_peatones.doe” y la figura A.12, conformando la siguiente secuencia
Comienza el ciclo básico

Permanece en verde
Cambia a ámbar
Permanece en ámbar
Cambia a rojo
Permanece en rojo
Cambia a espera
En los cuatro bloques Assign simplemente se asigna el valor correspondiente a la

variable Estado, para la que se ha utilizado la siguiente codificación (0=“espera”,
1=“verde”, 2=“ámbar” y 3=“rojo”), y en los bloques Process se utiliza como retardo la
variable correspondiente (tverde, tambar y trojo) que han sido previamente inicializadas
200
a sus respectivos valores (60, 10 y 60 segundos). El modelo se ha completado utilizando

el mismo objeto animado que en la variante 1.c pero con cuatro posibles valores,
repitiendo el mismo icono “semáforo en verde” en los dos estados: “espera” y “verde”.
La animación gráfica sobre el correspondiente grafo reducido se ha resuelto de forma

similar al caso anterior de dos estados, cada uno de los cuatro estados tiene asociado la
misma variable Estado y cuatro iconos circulares pero sus animaciones están
particularizadas de distinta forma, en función de su valor. Así por ejemplo, el objeto
“Espera” tiene asignado el color rojo cuando Estado=0 y el color azul en los demás
casos Estado=1, 2 ó 3, mientras que el objeto “Verde” tiene asignado el color rojo
cuando Estado=1 y el color azul en los demás casos Estado=0, 2 ó 3.

observa como el semáforo, que estaba en el estado de “espera” ha pasado de forma
cíclica por los cuatro estados posibles, completando dos ciclos y acabando en el estado
“espera”, debido a dos peticiones de los peatones representadas por la gráfica de eventos
generados. Para facilitar la interpretación de la simulación se han incluido también la
gráfica de evolución del estado del semáforo.
Figura A.12 Modelo en Arena de un semáforo con pulsador de peatones y resultados de la simulación
después de 600 segundos.
2.b) ¿Cómo modelaría el comportamiento de un montacargas utilizado en la

reparación de un edificio para trasladar cosas entre el suelo de la calle y el tejado?
Suponga que el montacargas siempre está operado externamente (por operarios que se
encuentran en el tejado o en la calle) y no tiene parada en las plantas del edificio.
Solución: Véase el archivo “ej_montacargas.doe”.
Los posibles estados del montacargas son: “parado en la calle”, “parado en el tejado”,
“subiendo” al tejado, “bajando” a la calle. Para su operación se necesitan dos botones;
un botón de subir, al que hará caso si el montacargas está en ese momento en la calle, y
201
un botón de bajar, al que hará caso si el montacargas está en ese momento en el tejado.
Además se puede suponer que siempre tarda lo mismo en realizar el recorrido de subida
y de bajada. Por tanto el grafo reducido es el siguiente, donde se observan dos
transiciones externas (provocadas por las peticiones “subir” y “bajar”) y dos
transiciones internas (provocadas por el propio montacargas cuando llega al tejado o a
la calle):
subir
parado en la
calle subiendo
parado en el
tejado
bajando
bajar
Figura A.13 Grafo reducido para modelar el montacargas.
Para su desarrollo se han reproducido en paralelo dos diagramas de bloques muy

parecidos al del archivo “ej_automata_S1S2m.doe”, que modelaba el autómata con
dos estados (“espera” y “ocupado”). El diagrama de bloques superior es un autómata
secuencial de dos estados (“el montacargas está subiendo” y “el montacargas está
parado en el tejado”) que sólo atiende las peticiones de subida (preguntando si el
“montacargas está parado en la calle”) y el diagrama de bloques inferior es un autómata
secuencial de dos estados (“el montacargas está bajando” y “el montacargas está parado
en la calle”) que sólo atiende las peticiones de bajada (preguntando si el “montacargas
está parado en el tejado”).
El montacargas puede estar en cualquiera de los cuatro estados, anteriormente

comentados, que se van asignando a la variable Estado en los correspondientes bloques
Assign, utilizando la siguiente codificación (1=“parado en la calle”, 2=“subiendo”,
3=“parado en el tejado” y 4=“bajando”). La visualización de esta variable nos permite
saber dónde está el montacargas en todo momento. También se han incluido dos
bloques visualizadores de los eventos generados, en definitiva de las peticiones de
subida y de bajada.
La figura A.14 muestra el resultado de una simulación con tiempo de recorrido igual a 5
minutos tanto en la subida como en la bajada; después de 30 minutos se observa como
el montacargas, que estaba inicialmente en el estado de “parado en la calle” ha
completado un ciclo debido a una primera petición de subida (que se produjo a los 2
minutos) y a una primera petición de bajada (que se produjo a los 10 minutos). Después,
a los 12 minutos cuando estaba “bajando” se produjo la segunda petición de subida, que
no fue atendida. Sí fue atendida la tercera petición de subida que se produjo a los 22
minutos. Y tampoco se atendió la segunda petición de bajada que se produjo a los 25
minutos. En los bloques receptores se puede confirmar que de las 5 peticiones
generadas, se han atendido 2 peticiones de subida (las que han llegado al Receptor 1),
se ha desatendido 1 petición de subida (la que ha llegado al Receptor2), se ha atendido
1 petición de bajada (la que ha llegado al Receptor3) y se ha desatendido una petición
de bajada (la que ha llegado al Receptor4).
202
Figura A.14 Modelo en Arena de un montacargas y resultados de la simulación después de 30 minutos.
203
A.2 MODELOS CON ESTRUCTURA DE RED DE PETRI

A continuación se proponen varios ejercicios para practicar con las redes de Petri.
A.2.1 Ejercicio 3: Encendido y apagado de una lámpara
Se propone programar un nuevo modelo para simular el encendido y apagado de una

lámpara mediante el correspondiente pulsador, con la funcionalidad que se comentó en
la variante 1.a del ejercicio A.1, pero que tenga estructura de Red de Petri. Se aconseja
acompañar el modelo de una animación sobre la red además del icono utilizado en la
variante 1.a.
Solución: El encendido y apagado de una lámpara se puede modelar con la Red de Petri
comentada en el apartado (a) del ejercicio 2.1.
Este modelo se puede reproducir en Arena mediante la estructura de bloques de la figura

A.15, ver el archivo “ej_lamparaRP.doe”. Donde se ha utilizado:
- Un bloque Create, denominado Generador de pulsaciones en la figura A.15,

para simular el apagado y encendido mediante el interruptor. Este bloque
representa en la estructura de la Red de Petri el disparo de la transición T1 o de la
transición T2 según proceda.
- Un bloque Decide, denominado Apagada en la figura A.15, que desvía los

eventos generados por el interruptor (o pulsador) en función del estado de la
lámpara (“encendida” o “apagada”), representado por una variable binaria Estado.
Este bloque, que no está representado en la estructura de la Red de Petri, es
necesario para que los eventos generados por un mismo bloque se puedan
interpretar alternativamente como disparo de la transición T1 o de la transición
T2.
- Un bloque Match, denominado Match 1 en la figura A.15, para modelar que la

lámpara pasará a estar “apagada” siempre y cuando estuviera “encendida” y se
haya pulsado el interruptor. Este bloque corresponde en la estructura de la Red de
Petri al lugar P2 pero también lleva implícito el disparo de la transición T2.
- Un bloque Assign, denominado Apaga en la figura A.15, que provoca que la

lámpara cambie de estado, de “encendida” a “apagada”, en el que permanecerá
hasta la próxima pulsación. Este bloque corresponde en la estructura de la Red de
Petri a la materialización de la transición T2.
- Un bloque Match, denominado Match 2 en la figura A.15, para modelar que la

lámpara pasará a estar “encendida” siempre y cuando estuviera “apagada” y se
haya pulsado el interruptor. Este bloque corresponde en la estructura de la Red de
Petri al lugar P1 pero también lleva implícito el disparo de la transición T1.
- Un bloque Assign, denominado Enciende en la figura A.15, que provoca que la

lámpara cambie de estado, de “apagada” a “encendida”, en el que permanecerá
hasta la próxima pulsación. Este bloque corresponde en la estructura de la Red de
Petri a la materialización de la transición T1.
204
- Dos bloques Create, denominados Permite el primer apagado y Permite el

primer encendido en la figura A.15, necesarios para poder arrancar la simulación
en cualquiera de los dos estados posibles (la lámpara está “encendida” o la
lámpara está “apagada”) y que el primer evento provocado por el Generador de
pulsaciones se pueda interpretar respectivamente como el primer apagado o el
primer encendido. Estos bloques sirven en la estructura de la Red de Petri para
elegir un marcado inicial, los dos posibles marcados son: [1 0] ⇔ la lámpara está
“apagada” y [0 1] ⇔ la lámpara está “encendida”.
- Dos bloques Dispose, denominados Receptor 1 y Receptor 2 en la figura A.15,

para que los eventos puedan abandonar el modelo. Por tanto no forman parte de la
estructura de la Red de Petri.
- Un registro gráfico para visualización del estado “0” = “apagada” o “1”=

“encendida” de la lámpara.
- El esquema eléctrico con los dos objetos animados (interruptor y lámpara) para
acompañar al modelo con la misma animación en la variante 1.a.
- Con el fin de animar la red de Petri se han incluido las dos variables binarias (P1 y
P2) que representan el estado “no marcado” o “marcado” de los dos lugares de la
Red de Petri, y se han añadido más sentencias en los bloques de asignación
(combinadas con el cambio de estado) para realizar el desmarcado y el marcado
oportuno. Por ejemplo, el bloque Apaga realiza las siguientes asignaciones:
Estado=0 Para indicar el paso a lámpara “apagada”
P1=1 Para marcar el lugar P1
P2=0 Para desmarcar el lugar P2
- La animación se ha hecho sobre un gráfico fijo en el que sólo cambian las dos
marcas, una por cada lugar, de la forma siguiente: ausencia de objeto cuando la
variable P1 ó P2 que tiene asociada toma el valor cero y objeto circular de color
rojo cuando la variable P1 ó P2 que tiene asociada toma el valor uno.
205
Figura A.15 Modelo sobre el encendido y apagado de una lámpara con estructura de Red de Petri.
206
En la visualización gráfica de la figura A.15 se observa que el estado de la lámpara ha

ido cambiando como consecuencia de los once eventos generados aleatoriamente por el
bloque Generador de pulsaciones a partir del instante 2 unidades de tiempo. En el estado
inicial la lámpara estaba apagada, marca en P1, y ha acabado de la misma forma.
A.2.2 Ejercicio 4 : Carro que va y viene de derecha a izquierda
La red de Petri representada en la figura A.15 puede servir para modelar el

movimiento de un carro que situado sobre un tramo de raíl no circular, va y viene, en
continuo movimiento de derecha a izquierda, cambiando de dirección cada vez que
alcanza el extremo correspondiente. Bastaría con asignarle la siguiente interpretación:
P1: Carro moviéndose hacia la derecha

T1 : El carro ha alcanzado el extremo derecho
P2: Carro moviéndose hacia la izquierda
T2 : El carro ha alcanzado el extremo izquierdo
Sin embargo los dos fenómenos tienen otros rasgos diferenciales que no están
reflejados en la red de Petri. Mientras el encendido y apagado de la lámpara
(transiciones T1 y T2 de la red) están asociados a un pulsador y por tanto el paso de
“encendida” a “apagada” o viceversa es totalmente aleatorio, el cambio de dirección
en el movimiento del carro se produce periódicamente (bajo condiciones ideales del
raíl y suponiendo velocidades iguales y constantes en ambos sentidos) cada vez que éste
alcanza el extremo correspondiente. Tales rasgos diferenciales sí tienen influencia al
implementar el modelo en Arena. ¿Qué estructura de bloques propondría para modelar
el movimiento del carro?
Solución: Véase el modelo “ej_carroRP1.doe”, que presenta la estructura de bloques

de la figura A.16. Donde se ha utilizado:
- Un bloque Assign, denominado Cambia a derecha en la figura A.16, para

informar que el carro ha pasado de “moverse hacia la izquierda” a “moverse hacia
la derecha”. Este bloque corresponde en la estructura de la Red de Petri a la
materialización de que la transición T2 se ha disparado.
- Un bloque Process, denominado Derecha en la figura A.16, con la opción Delay

de manera que el carro permanezca moviéndose hacia la derecha el tiempo
necesario para que alcance el extremo derecho. Este bloque corresponde en la
estructura de la Red de Petri al lugar P1 pero también tiene implícito el disparo de
la transición T1.
- Un bloque Assign, denominado Cambia a izquierda en la figura A.16, para

informar que el carro ha pasado de “moverse hacia la derecha” a “moverse hacia
la izquierda”. Este bloque corresponde en la estructura de la Red de Petri a la
materialización de que la transición T1 se ha disparado.
- Un bloque Process, denominado Izquierda en la figura A.16, con la opción Delay

de manera que el carro permanezca moviéndose hacia la izquierda el tiempo
necesario para que alcance el extremo izquierdo. Este bloque corresponde en la
207
estructura de la Red de Petri al lugar P2 y también tiene implícito el disparo de la

transición T2.
- Un bloque Create, denominado Permite el primer movimiento en la figura A.16,

necesario para poder conseguir que el carro comience a “moverse hacia la
derecha” bajo el supuesto de que está en el extremo izquierdo. Este bloque sirve
en la estructura de la Red de Petri para elegir el marcado inicial: [1 0] ⇔ el carro
está “moviéndose hacia la derecha”.
- Un registro gráfico para visualización del estado del carro, representado por la
variable Estado con los valores: “1” = “moviéndose hacia la derecha” o “2”=
“moviéndose hacia la izquierda”.
- La red de Petri animada; con este fin se han incluido las dos variables binarias (P1
y P2) que representan el estado “no marcado” o “marcado” de los dos lugares de
la Red de Petri, y se han añadido más sentencias en los bloques de asignación
(combinadas con el cambio de estado) para realizar el desmarcado y el marcado
oportuno. Por ejemplo, en el bloque Cambia a derecha
Estado=1 Para indicar el paso a carro “moviéndose hacia la derecha”

P1=1 Para marcar el lugar P1
P2=0 Para desmarcar el lugar P2
Figura A.16 Modelo sobre el carro que va y viene de derecha a izquierda con estructura de Red de Petri.
208
En la visualización gráfica de la figura A.16 se observa que el carro ha ido cambiando

periódicamente de dirección como consecuencia de haber permitido su primer
movimiento hacia la derecha. Cuando ha acabado la simulación, estaba moviéndose
hacia la derecha, marca en el lugar P1 de la red.
Una comparación entre los diagramas de bloque de la figura A.15 y de la figura A.16
permite comprobar que es difícil, por no decir imposible, establecer una traducción
directa de una red de Petri a ARENA o cualquier otro lenguaje de modelado.
A.2.3 Ejercicio 5 : Semáforo de peatones
Se propone repetir una experiencia similar a los dos ejercicios anteriores,

programando un modelo con estructura de Red de Petri que simule el comportamiento
del semáforo de peatones, con pulsador manual. Se aconseja acompañar el modelo de
una animación sobre la red además de los iconos utilizados en la variante 2.a.
Solución: Véase el modelo “ej_semáforo_peatonesRP.doe”.
En la figura A.17 se puede observar la red de Petri animada, similar a la propuesta en el

ejercicio 2.5 pero donde no se ha incluido la conexión y desconexión por el operador
externo. La red tiene forma cíclica con cuatro lugares (uno para cada estado, los mismos
que se comentaron en la solución de la variante 2.a) y cuatro transiciones. Luego,
respecto a la red de los ejercicios 2.3 y 2.4, se ha ampliado el número de lugares y de
transiciones, pero no se ha introducido ninguna dificultad adicional. Las transiciones y
los lugares tienen la siguiente interpretación:
P1: Estado de espera (semáforo en verde) pulsación

T1 : Pulsación
P2 : Semáforo en verde
T2 : Cambio a ámbar por tiempo
P3 : Semáforo en ámbar
T3 : Cambio a rojo por tiempo
P4 : Semáforo en rojo
T4 : Cambio a espera por tiempo
El diagrama de bloques es muy parecido al utilizado en la figura A.15, pero incluye un

subconjunto cíclico como el del ejercicio 4 de este anexo (propio del fenómeno que se
está representando y de la red de Petri elegida), que no era necesario en la figura A.15.
Este subconjunto tiene como objetivo repetir la misma secuencia que se comentó en la
variante 2.a. En dicha secuencia hay un estado de “espera”, lugar P1 de la red, que no se
abandona en un tiempo determinado sino como consecuencia de una pulsación de los
peatones, transición T1. Esta función de sincronización la realiza el bloque Match 1
como ocurría en el ejercicio 3 de este anexo sobre la lámpara.
Tras 600 segundos de simulación se observa como el semáforo, que estaba en el estado
de “espera” ha pasado de forma cíclica por los cuatro estados posibles, completando tres
ciclos y acabando en el estado “rojo”, debido a las tres peticiones de los peatones. Por
tanto con la red marcada en P4.
209
Figura A.17 Modelo en Arena con estructura de Red de Petri para el semáforo con pulsador de peatones y resultados de la simulación después de 600 segundos.
210
A.2.4 Ejercicio 6 : Carro que va y viene, con botón de parada
Se propone ampliar la red de Petri y el modelo del ejercicio 4 de este anexo para
contemplar que el movimiento del carro está controlado por un botón en el extremo
izquierdo del raíl, véase figura 1.1. Con dicho botón se consigue: a) que el carro no
empiece a moverse hacia la derecha hasta que el botón esté “pulsado”, y b) que
cuando el carro, moviéndose hacia la izquierda, alcance el extremo izquierdo cambiará
de dirección si y sólo si el botón está “pulsado”, pues en caso contrario se parará
hasta que se pulse el botón, evento que dará lugar a un nuevo movimiento de ida y
vuelta.
Solución: Véase el archivo “ej_carroRP2.doe”.
En la figura A.18 se puede observar la red de Petri que modela el comportamiento del
carro que va y viene de derecha a izquierda controlado por un pulsador. Respecto a la
red de Petri representada en la figura A.16 ha habido que cambiar la interpretación de la
transición T2, añadir un lugar más y dos transiciones con la siguiente interpretación:
T2 : El carro ha alcanzado el extremo izquierdo, estando el botón pulsado

T3 : El carro ha alcanzado el extremo izquierdo, estando el botón sin pulsar
P3 : Carro parado en el extremo izquierdo, esperando pulsación
T4 : Se ha pulsado el botón
Una característica de la red, que no está presente en los ejercicios anteriores, es que
presenta un punto de toma de decisión, ya que el disparo de T2 implica la desactivación
de T3 y viceversa (a través del lugar P2). Esta toma de decisión hace la función de
control del botón comentada como (b) en el enunciado, es decir, cuando el carro llega al
extremo izquierdo se producirá el disparo de T2 (cambio de dirección de izquierda a
derecha) si el botón está “pulsado” y en caso contrario se producirá el disparo de T3
(que provoca la parada del carro). La otra función de control del botón, comentada
como (a) en el enunciado, se logra con la transición T4 que pone en marcha el carro si
éste estaba parado, marca en el lugar P3, cuando se pulsa el botón.
Observación: esta red de Petri ya se utilizó como ejemplo de generación de un árbol de

cobertura en el tema 2, véase figura 2.4, pero entonces no se comentó nada sobre el
fenómeno o sistema que podía representar. Y también se utilizó en el apartado 2.5.1 del
tema 2 para presentar las redes de Petri interpretadas, donde sí se analizó con detalle el
comportamiento dinámico del sistema que estaba representando.
Otra característica de la red es que integra dos secuencias cíclicas, que también se
detectaron en el tema 2 al hacer su árbol de cobertura, la que ya teníamos de dos
estados, representada por los lugares P1 y P2, y la nueva de tres estados, representada
por los lugares P1, P2 y P3. Pero sólo puede estar activa una de ellas, dependiendo del
estado del botón. Ambas secuencias aparecen anidadas en el diagrama de bloques de la
figura A.18, siendo el bloque Decide denominado Debe esperar el que realiza la toma
de decisión en función del estado del botón.
211
Para guardar información del estado del botón se ha utilizado un bloque Assign,
denominado Atiende el pulsador en la figura A.18, de forma similar a como se hizo el
autómata cíclico de dos estados (véase el ejercicio 1 de este anexo). Y para encaminar la
pulsación se ha utilizado otro bloque Decide, denominado Esta en reposo, de manera
que la pulsación sólo se envía al bloque Match1 que lleva implícita la transición T3 si el
carro está esperando en el extremo izquierdo.
En el modelo se ha incorporado visualización gráfica tanto del estado del carro como
del botón, en la figura A.18 se puede ver el resultado de una simulación de 600
segundos. Se observa como el carro, que inicialmente estaba parado (Estado=’0’) ha
arrancado cuando el botón ha pasado del valor ‘0’ al valor ‘1’, ha repetido cuatro veces
el ciclo de movimiento a derecha e izquierda, ha vuelto a parar porque se encontró que
el botón estaba a ‘0’ cuando llegó al extremo izquierdo y ha vuelto a arrancar repitiendo
de nuevo el ciclo hasta llegar al estado ‘moviéndose hacia la derecha’ reflejado por la
marca en P1 cuando acabo la simulación.
212
Figura A.18 Modelo en Arena con estructura de Red de Petri para el carro que va y viene con botón y resultados de la simulación después de
600 segundos.
213
A.2.5 Ejercicio 7 : Montacargas
Se propone programar un nuevo modelo con estructura de Red de Petri para simular el
funcionamiento del montacargas, que ya se planteó en la variante 2.b del ejercicio 2 de
este anexo.
Solución: Para modelar el funcionamiento del montacargas se ha elegido la red

representada en la figura A.19, que ya fue propuesta en el ejercicio 2.6. La red recoge
claramente la secuencia de los cuatro estados en los que puede estar el montacargas
(representados por P1 a P4, en el mismo orden que se consideraron en la variante 2.b),
pero además hace explícita las dos posibles peticiones (petición de subida o petición de
bajada) que pueden hacer los operarios del montacargas. Tanto es así que las peticiones,
independientemente del instante en el que se produzcan, serán memorizadas a través del
marcado de P5 y P6 para ser atendidas cuando corresponda. La petición de subida
cuando el montacargas esté “parado en la calle”, disparando la transición T1, y la
petición de bajada cuando el montacargas esté “parado en el tejado”, disparando la
transición T3. Las otras dos transiciones, T2 y T4, son temporizadas y se disparan
respectivamente en los instantes que el montacargas llega al tejado y llega a la calle.
Para la programación de esta red en ARENA, véase el modelo

“ej_montacargasRP.doe”, se ha utilizado una estructura de bloques similar a la
empleada en los dos ejercicios anteriores. Compuesta de:
- Cuatro bloques Assign, denominados Comienza a subir, Espera arriba,

Comienza a bajar, Espera abajo en la figura A.19, para atender los cambios de
estado y de marcado relativos al montacargas. Representan las acciones
inmediatas producidas por el disparo de las cuatro transiciones de la red.
- Dos bloques Assign, denominados Memoriza petición de subida y Memoriza

petición de bajada en la figura A.19, para atender los cambios de estado y de
marcado producidos por las peticiones de los operarios.
- Dos bloques Process, denominados Sube y Baja en la figura A.19, con la opción
Delay de manera que el montacargas permanezca subiendo (lugar P2) o bajando
(lugar P4) el tiempo necesario (representado por la variable trecorrido) para que
alcance el tejado o el suelo.
- Tres bloques Create, denominados Pulsador de subida, Pulsador de bajada y

Permite la primera subida en la figura A.19. Los dos primeros son necesarios
para simular las peticiones de los operarios y el tercero está para poder conseguir
que el montacargas comience a “subir” bajo el supuesto de que está parado en el
suelo.
- Dos bloques Match, denominados Match 1 y Match 2 en la figura A.19. El

primero para modelar que el montacargas comenzará a subir si “había o ha llegado
una petición de subida y el montacargas acaba de llegar al suelo o ya lo estaba”.
El segundo para modelar el caso similar antes de comenzar a bajar. Estos bloques
también realizan la función de guardar en una cola las respectivas peticiones de
subida y de bajada.
214
- Dos bloques Dispose, denominados Receptor1 y Receptor2 en la figura A.19 que

retiran del modelo las peticiones de subida y de bajada respectivamente cuando se
han atendido.
- Tres registros gráficos. Uno para visualización del estado del montacargas,
representado por la variable Estado con los valores: “1” = “parado en la
calle”=“esperando a subir”, “2”= “subiendo”, “3” = “parado en
tejado”=“esperando a bajar”, “4”= “bajando”.
La figura A.19 muestra el resultado de una simulación con tiempo de recorrido igual a 5
minutos tanto en la subida como en la bajada; después de 30 minutos se observa como
el montacargas, que estaba inicialmente en el estado de “parado en la calle”, ha
completado un ciclo debido a una primera petición de subida (que se produjo a los 2
minutos) y a una primera petición de bajada (que se produjo a los 10 minutos). Entre
ambas peticiones el montacargas ha tenido tiempo para hacer el recorrido de subida y
esperar a que se produjera la petición de bajada. Después, a los 12 minutos cuando
estaba “bajando” se produjo la segunda petición de subida, que no fue atendida en ese
momento pero quedó memorizada y fue atendida inmediatamente después de que el
montacargas alcanzó el suelo. El montacargas tuvo tiempo para llegar al tejado, donde
estuvo parado un cierto tiempo hasta que se recibió la petición de bajada (segunda
petición en la gráfica, a los 25 minutos), comenzó a bajar y acabó la simulación cuando
estaba bajando (marca en P4). La marca en P5 se debe a que antes de que llegara la
segunda petición de bajada, cuando el montacargas estaba parado en el tejado, se recibió
la tercera petición de subida, que aún no se ha podido atender.
Existe una diferencia importante entre el modelo con estructura de autómata, presentado
en la variante 2.b, y el modelo con estructura de red de Petri. En el autómata no se
atendían todas las peticiones mientras que en la red de Petri se atienden todas las
peticiones y las que no ha dado tiempo a atender, por la duración limitada de la
simulación, están guardadas en una cola.
En la simulación realizada en la figura A.19 también se ha puesto de manifiesto un

fenómeno que en otros casos (por ejemplo en un ascensor) no tiene mucho sentido; se
trata de que ha quedado en cola de espera la tercera petición de subida cuando el
montacargas en ese momento estaba parado en el tejado. No obstante, si los operarios
están coordinados o sólo existe un operario sí que tiene sentido dejarlo así, pues antes
de pedir que el montacargas suba le tendrá o tendrán que haber pedido que baje.
La solución alternativa hubiera sido generar una petición “ficticia” de bajada para hacer
que el montacargas llegará al suelo y pudiera atender la petición “real” de subida. Pero
esto será posible si la red de Petri se acompaña de un gestor de peticiones.
215
Figura A.19 Modelo del montacargas con estructura de Red de Petri.
216
A.2.6 Ejercicio 8 : Carros que van y vienen
Se propone modelar con una red de Petri el comportamiento de dos carros que van y
vienen de derecha a izquierda por dos tramos rectos independientes, véase figura 1.9.
Entre los carros existe la política de que el primero que llegue a un extremo (izquierdo
o derecho) deberá esperar a que llegue el otro carro para reanudar simultáneamente la
marcha en dirección contraria. Además existe un botón, que afecta por igual a los dos
carros, permitiendo que éstos se pongan en marcha hacia la derecha o puedan
reanudar este tipo de marcha después de que ambos hubieran alcanzado el extremo
izquierdo.
Solución: Véase el archivo “ej_carrosRP1.doe”.
En la figura A.20 se puede observar la red de Petri que modela el comportamiento de

los dos carros que van y vienen de derecha a izquierda, sincronizados en los extremos, y
controlados por un botón común. Cuya interpretación es la siguiente:
P1 : Carro 1 moviéndose hacia la derecha.

P3 : Carro 1 parado en el extremo derecho.
P5 : Carro 1 moviéndose hacia la izquierda.
P7 : Carro 1 parado en el extremo izquierdo.
P2 : Carro 2 moviéndose hacia la derecha.
P4 : Carro 2 parado en el extremo derecho.
P6 : Carro 2 moviéndose hacia la izquierda.
P8 : Carro 2 parado en el extremo izquierdo.
T1 : El carro 1 ha alcanzado el extremo derecho.
T2 : El carro 2 ha alcanzado el extremo derecho.
T3 : Los dos carros ya han alcanzado el extremo derecho.
T4 : El carro 1 ha alcanzado el extremo izquierdo.
T5 : El carro 2 ha alcanzado el extremo izquierdo.
T6 : Los dos carros ya han alcanzado el extremo izquierdo y el botón está pulsado.
La red es una combinación de dos redes muy similares a la del ejercicio 6 del anexo,
véase la figura A.18, donde:
- A los tres lugares que permiten modelar el movimiento de cada carro ha habido
que añadir dos lugares más, para representar que los dos carros pueden llegar a
parar en el extremo derecho debido a que el otro carro aún no ha llegado.
- A las cuatro transiciones temporizadas de final de recorrido (dos por cada carro)
se han sumado las transiciones que realizan las labores de sincronización cuando
los dos carros han alcanzado el mismo extremo y se encuentran en disposición
de reanudar la marcha en sentido contrario o, como están en el extremo
izquierdo, la reanudación de la marcha está afectada por el estado del botón.
Luego en ella se pueden observar claramente los ejemplos de concurrencia y
sincronización analizados en el apartado 2.4 del tema 2, basta comparar con las
figuras 2.10 y 2.11.
En el diagrama de bloques, véase figura A.20, se ha intentado mantener una estructura,

similar al ejercicio anterior, con dos bucles por cada carro, condicionados por el estado
217
del pulsador y sincronizados a través de los tres bloques de tipo Match. La disposición
de estos bloques hace que un bucle no pueda evolucionar si el otro no ha avanzado lo
suficiente.
En el modelo se ha incorporado visualización gráfica del estado del botón y del estado
de los carros, empleando dos variables Estado1 y Estado2 (con la misma codificación:
0= “carro parado en el extremo izquierdo”, 1= “carro moviéndose hacia la derecha”,
2=“carro parado en el extremo derecho” y 3=“carro moviéndose hacia la izquierda”).
En la figura A.20 se puede ver el resultado de una simulación de 600 segundos, bajo el
supuesto de que ambos carros tiene tiempos de recorrido fijos pero distintos
(trecorrido1 = 30 segundos y trecorrido2 = 20 segundos). Se observa como los dos
carros, que inicialmente estaban parados han arrancado hacia la derecha cuando el
pulsador ha pasado del valor ‘0’ al valor ‘1’. Repitiendo cuatro veces el ciclo de
movimiento a derecha e izquierda, con una diferencia muy manifiesta en la evolución
de los dos estados, pues como se ha supuesto que el carro 2 es más rápido, siempre tiene
que esperar en los extremos al carro 1, que ha estado moviéndose continuamente. Los
dos carros han parado porque se encontraron que el pulsador estaba a ‘0’ cuando
coincidieron después de cuatro ciclos en el extremo izquierdo y ha vuelto a arrancar
repitiendo de nuevo el ciclo hasta llegar al estado ‘moviéndose hacia la derecha’
reflejado por la marcas en P1 y P2 cuando se agotó el tiempo de simulación.
Observación: Si imponemos la condición de que un carro sólo espera al otro en el

extremo izquierdo la red de Petri se simplificaría dando lugar a una red análoga a la
analizada en el apartado 2.3.2 como ejemplo de red de Petri ordinaria no marcada, véase
figura 2.9, y posteriormente como marcada. Pero en ambos análisis no se hizo ningún
tipo de alusión al tipo de fenómeno que podía representar. Véase el archivo
“ej_carrosRP2.doe”, donde han desaparecido los lugares P3 y P4 y la transición T3.
En la figura A.21 se puede ver el resultado de una simulación de 600 segundos en las
mismas condiciones del modelo anterior. De nuevo se repite cuatro veces el ciclo de
movimiento a derecha e izquierda en ambos carros, pero ahora se observa como el carro
2, que es más rápido, siempre espera en el extremo izquierdo al carro 1, que ha estado
moviéndose continuamente.
218
Figura A.20 Modelo en Arena con estructura de Red de Petri para los dos carros que van y vienen con pulsador común y resultados de la simulación después de 600
segundos.
219
Figura A.21 Modelo en Arena con estructura de Red de Petri para los dos carros que van y vienen con sincronización y pulsador común en el extremo izquierdo.
220
A.2.7 Ejercicio 9: Sistema de producción con dos robots, dos máquinas y dos
almacenes
Se propone modelar en Arena el sistema de producción analizado en el ejercicio 2.8.
Solución: Véase el archivo “ej_produccion1.doe”. Para programar en ARENA la red

propuesta en el ejercicio 2.8, se ha utilizado una estructura de bloques compuesta de:
- Cinco bloques Create, denominados Genera pieza, Genera R1, Genera M1,
Genera R2 y Genera M2 en la figura A.22. Los últimos cuatro bloques para dar
entrada en el sistema, desde el instante inicial, a los cuatro elementos activos (los
dos robots y las dos máquinas) que participan en él. Estos elementos son
realmente recursos, pero por ahora los vamos a considerar como otras entidades
que también fluyen por el sistema. El primero para generar la primera de las
entidades “pieza” que va a fluir por el sistema.
- Un bloque Separate, denominado Separate 1 en la figura A.22, para duplicar la

única pieza que circula por el sistema cuando ésta ya ha sido recogida del
almacén, se consigue así el efecto de que el almacén tiene capacidad infinita. Por
tanto siempre hay “piezas” en el almacén A1.
- Cinco bloques Process, denominados R1 transportando, M1 procesando, R2

transportando desde M1 a M2, M2 procesando y R2 transportando desde M1
al almacén en la figura A.22, con la opción Delay para representar las actividades
que realizan los elementos del sistema, es decir, los nodos P4, P5, P9, P10 y P12
de la red propuesta en el ejercicio 2.8. Cada actividad y por tanto cada bloque
tiene asociado su correspondiente parámetro (el tiempo que requiere la actividad
concreta).
- Siete bloques Match, denominados Match 1 a Match 7 en la figura A.22. El

primero para sincronizar el disparo de la transición t1 y provocar la acción
oportuna, recuerde que para que una pieza pase a ser procesada tiene que haber
piezas en el almacén A1, que la máquina M1 y el robot R1 estén libres. El bloque
Match 2 sincroniza el disparo de la transición t2 y provoca que la pieza comience
a procesarse en la máquina M1 y que el robot R1 quede libre. Y así sucesivamente
pues el resto de los bloques Match están asociados a las transiciones 3 a 7, en el
mismo orden.
- Un bloque Dispose, denominado almacen en la figura A.22 que representa al

almacén A2, donde se reciben las piezas procesadas.
Para no complicar excesivamente el diagrama de bloques, no se ha incluido ni la RdP

ni los bloques auxiliares para hacer su animación. Sin embargo sí se han incluido tres
registros gráficos y sus correspondientes bloques auxiliares para la visualización de los
siguientes eventos: “la recogida de piezas por el robot R1 en el almacén A1”, “la
entrada de piezas en el segundo subsistema por medio del robot R2” y “la entrega de
piezas por el robot R2 en el almacén A2”.
Con el fin de probar el modelo se han elegido los siguientes parámetros en minutos
221
Tiempo que necesita el robot R1 para transportar la pieza desde el almacén A1 a la

máquina M1: tiempo_TR1 = 2
Tiempo de procesamiento de la pieza en la máquina M1: tiempo_TPM1 = 10
Tiempo que necesita el robot R2 para transportar la pieza desde la máquina M1 a la

máquina M2: tiempo_TR2_M1aM2 = 1
Tiempo de procesamiento de la pieza en la máquina M2: tiempo_TPM2 = 15
Tiempo que necesita el robot R2 para transportar la pieza desde la máquina M2 al

almacén 2: tiempo_TR2_M2aA = 5
En la figura A.22 se puede ver el resultado de una simulación de 120 minutos. Trate de
reproducirlo paso a paso, observando cómo fluyen los recursos (R1, R2, M1 y M2) y las
piezas por las colas de los bloques Match (de forma similar al marcado de la red de
Petri) y poniendo especial atención a cómo avanza el reloj de la simulación, asociado a
los siguientes eventos:
- La primera pieza se crea a los 5 minutos y es recogida inmediatamente por el

robot R1 para llevarla a la máquina M1, que la recibe a los 5+2=7 minutos,
liberándose el robot R1.
- A los 7+10=17 minutos la máquina M1 ya ha procesado la primera pieza y se

produce la primera entrada de piezas en el segundo subsistema por medio del
robot R2. En ese mismo instante como la máquina M1 ha quedado libre, el robot
R1 recoge una nueva pieza (la segunda).
- A los 17+1=18 minutos la primera pieza ha llegado a la máquina M2.
- A los 17+2=19 minutos la segunda pieza llega a la máquina M1.
- A los 19+10=29 minutos la máquina M1 ha acabado de procesar la segunda pieza

pero ésta no puede avanzar al segundo subsistema porque la máquina M2 está
ocupada.
- A los 18+15=33 minutos la máquina M2 queda libre pues ha acabado de procesar

la primera pieza e inmediatamente es recogida por el robot R2, que está libre para
llevarla al almacén A2.
- A los 33+5=38 minutos la primera pieza es entregada en el almacén A2,

liberándose el robot R2 para recoger la segunda pieza que está esperando en la
máquina M1. En ese mismo instante como la máquina M1 ha quedado libre, el
robot R1 recoge una nueva pieza (la tercera). Por tanto, hay simultaneidad en las
siguientes tres acciones: entrega en el almacén A2, recogida de nueva pieza por el
robot R2 y recogida de nueva pieza por el robot R1.
- A partir de aquí comienza a repetirse un ciclo, de longitud 21 minutos que se pone

de manifiesto tanto en la recogida de piezas, pues 38 (instante de la tercera
222
recogida) -17 (instante de la segunda recogida) = 21 minutos, como en las otras

dos señales visualizadas “la entrada de piezas en el segundo subsistema” y “la
entrega de piezas en el almacén A2” ya que todos. Pues como se ha comentado
anteriormente se da simultaneidad en las tres acciones que estamos visualizando.
Estos 21 minutos se van a repetir en todas la piezas, representa el tiempo que una
pieza tarda en pasar del almacén A1 al almacén A2 tras haber sido transportadas
por los robots (R1 y R2) y procesadas por las máquinas (M1 y M2). Es el
resultado de sumar los tiempos parciales del subsistema más lento, que en este
caso resulta ser el segundo.
tiempo_TR2_M1aM2+tiempo_PM2+tiempo_TR2_M2aA = 1+15+5 = 21 minutos
223
Figura A.22 Modelo en Arena del sistema de producción con dos robots, dos máquinas y dos almacenes.
224
A.3 MODELOS SOBRE AUTOMATISMOS
Los siguientes ejercicios, que versan sobre la implementación en ARENA de

automatismos diseñados con GRAFCET, presentan una característica común; la
perfecta integración de dos sistemas en un mismo modelo: el “sistema físico que se va a
controlar” y “el automatismo o sistema automático que lo controla”. Habrá pues un
doble flujo de información, las medidas (de variables físicas o de estados del sistema)
fluyen desde el sistema físico al automatismo a través de los sensores y las actuaciones
fluyen desde el automatismo al sistema físico a través de los actuadores. En general
supondremos que los sensores y actuadores están integrados en el sistema físico que se
va a controlar.
Entre los sistemas físicos hay algunos que son muy simples de modelar pues generan
poca información. Por ejemplo “la lámpara y su sistema eléctrico” deben generar
peticiones de apagado o de encendido pero no necesitan informar sobre el estado de la
lámpara, puesto que el sistema de encendido/apagado conoce siempre el estado en el
que ésta se encuentra. Sin embargo otros sistemas físicos requieren un modelado más
preciso. Por ejemplo en “el carro que va y viene” intervienen leyes físicas de
movimiento y la presencia de otros elementos (el botón en el extremo izquierdo del raíl
y los posicionadores en ambos extremos) que suministran información al automatismo
para que éste pueda tomar las acciones oportunas.
En otros sistemas nos veremos obligados a programar nuestros propios contadores de

tiempo para programar eventos temporizados, pues ARENA no los tiene incorporados
como bloque genérico. Por ejemplo, al modelar los semáforos, donde conviven las
correspondientes lámparas (verde, ámbar y roja), los sistemas eléctricos y el sistema
electrónico encargado de realizar la secuencia de colores adecuada para regular el
tráfico y de atender las peticiones que correspondan (por ejemplo la solicitud de paso de
peatones).
A.3.1 Ejercicio 10: Automatismo para encendido y apagado de una lámpara
Se propone programar y comprobar el automatismo para el encendido y apagado de

una lámpara mediante el correspondiente pulsador, con la funcionalidad que se
comentó en la variante 1.a del ejercicio 1 de este anexo. Se aconseja acompañar el
modelo de una animación sobre el GRAFCET utilizado para el diseño del automatismo.
Solución: El GRAFCET que modela el encendido y apagado de una lámpara está

descrito en la resolución del ejercicio 3.1, donde también se describen las ecuaciones
lógicas que debe incorporar el automatismo encargado del encendido y apagado de la
lámpara. Este modelo se puede reproducir en ARENA mediante la estructura de bloques
de la figura A.23, ver el archivo “ej_auto_lampara.doe”. Los tres bloques de la parte
superior representan al sistema físico mientras que los tres bloques de la parte inferior
representan al automatismo. Aunque aparentemente entre ellos no existe ningún flujo de
información sí lo hay, este flujo se produce a través de la siguiente variable del sistema:
VI , variable lógica para conocer el estado del interruptor
225
En el sistema físico se ha incorporado el único elemento, “el interruptor”, que genera

información para el automatismo. Este interruptor tiene características de autómata
cíclico con dos estados, y se ha programado como el autómata del ejercicio 1 del anexo,
utilizando un bloque Assign con la sentencia
VI = VI = = 0
La lógica de control es otro bloque Assign que reproduce las ecuaciones lógicas (véase
la justificación en la resolución del ejercicio 3.1)
_
E 0 = E 1 I + E1 E 0 + E 0 + E 1 E1 = E 0 I + E 0 E1
L = E1
mediante las sentencias
VIN=VI==0
E0N=E0==0
E1N=E1==0
E0=( E1 && VIN ) || ( E1N && E0) || ((E0 || E1) == 0)
E0N=E0==0
E1=( E0 && VI ) || ( E0N && E1 )
E1N=E1==0
L=E1
Donde se han utilizado variables lógicas auxiliares VIN, E0N y E1N para representar la
negación del estado del interruptor (VI) y de las dos etapas (E0 y E1) del GRAFCET. Y
donde es importante recalcar la secuencialidad en la activación de las etapas; el valor
lógico de E1 no se actualiza con el valor de E0 del ciclo anterior sino con el valor de E0
previamente calculado en el mismo ciclo.
Además se han utilizado:
- Dos bloques Create, denominados Generador de pulsaciones y Reloj de la

lógica de control en la figura A.23. El primero tiene la misión de generar
aleatoriamente eventos para conseguir que el interruptor vaya alternando entre sus
dos estados (abierto y cerrado). El otro bloque genera eventos periódicos para que
las ecuaciones que constituyen la lógica de control se actualicen regularmente,
cada intervalo de tiempo, con independencia de que el estado del interruptor no
haya cambiado y por tanto tampoco cambiará el estado de la lámpara.
- Dos bloques Dispose, denominados Receptor 1 y Receptor 2 en la figura A.23.

Que sirven para retirar del sistema los eventos generados por las pulsaciones del
interruptor y por el reloj de la lógica de control.
- Un gráfico fijo, representando el GRAFCET del sistema completo, acompañado

de tres campos numéricos, que muestran los valores instantáneos del estado del
interruptor y de las dos etapas del GRAFCET, y un círculo coloreado para animar
el estado de la lámpara (el azul representa que la lámpara está apagada y el rojo
que está encendida).
226
- Tres registros gráficos para mostrar la evolución temporal del estado del
interruptor y de las dos etapas del GRAFCET.
Figura A.23 Automatismo para encendido y apagado de una lámpara.
Los registros gráficos de la figura A.23 muestran los resultados producidos en 10

minutos de simulación, en las siguientes condiciones: el reloj de la lógica de control
tiene un periodo de 1 segundo, representado en el modelo por la variable delta_t, la
lámpara estaba inicialmente apagada y se han producido diez pulsaciones de forma
aleatoria a partir del minuto 2. Lógicamente después de un número par de pulsaciones,
la lámpara ha terminado en el mismo estado “apagada” que tenía inicialmente.
A.3.2 Ejercicio 11: Automatismo para el control del carro que va y viene
Se propone programar y comprobar el automatismo para el carro que va y viene por un

raíl, con pulsador de arranque/parada en el extremo izquierdo.
Solución: El GRAFCET que modela el comportamiento del carro que va y viene por un
raíl, con botón de parada en el extremo izquierdo, se presentó en la figura 3.13 del tema
3, y las ecuaciones lógicas que debe incorporar el automatismo encargado de su control
se presentaron en el ejemplo 3.2.3.2. Este modelo se puede reproducir en ARENA
mediante la estructura de bloques de la figura A.25, ver el archivo
“ej_auto_carro.doe”. Los tres bloques de la parte superior representan una parte del
sistema físico, la relacionada con el pulsador, los tres bloques de en medio representan
la otra parte del sistema físico, la relacionada con el movimiento del carro y los tres
bloques de la parte inferior representan al automatismo. El flujo de información entre
los elementos físicos del sistema y el automatismo, véase la figura A.24, se produce a
través de las siguientes variables del sistema:
VP , variable lógica para conocer el estado del pulsador

VA , variable lógica para conocer la presencia del carro en el extremo izquierdo A
VB , variable lógica para conocer la presencia del carro en el extremo derecho B
VD , variable lógica para indicar que el carro debe moverse hacia la derecha
227
VI , variable lógica para indicar que el carro debe moverse hacia la izquierda
Pulsador Carro
VP VA VB VD VI
Automatismo
Figura A.24 Flujo de información entre las tres partes del sistema “carro que va y viene”.
El bloque Pulsador de la figura A.25 tiene características de autómata cíclico con dos
estados, como el interruptor del ejercicio anterior, y se ha programado utilizando un
bloque Assign con la sentencia
VP = VP = = 0
El bloque Carro de la figura A.25 incluye la dinámica que describe el movimiento del
carro y la detección de su presencia en los extremos del raíl. En su modelado se ha
buscado generalidad, por lo que se ha supuesto que el carro se puede mover a distintas
velocidades constantes (vel_D y vel_I) a derecha y a izquierda, debido a dos motores
independientes (activados por la variables lógicas respectivas VD y VI), luego la
velocidad neta del carro viene dada en todo momento por la expresión
d x(t)
= vel_D VD - vel_I VI
dt
donde x(t) representa la posición relativa del carro respecto al extremo izquierdo del
raíl. Y aproximando la derivada por Euler, se llega a la siguiente expresión discretizada,
que nos da la posición instantánea del carro en t+∆t conocida su posición en el instante t
x(t+∆t) = x(t) + (vel_D VD – vel_I VI) ∆t
Como además se ha supuesto que el raíl tiene una longitud finita L y que se necesitan
variables lógicas que informen de la presencia o no del carro en los extremos, el modelo
dinámico se debería completar con las siguientes sentencias:
Si x ≤ 0
x=0
VA = 1
VB = 0
Si 0 < x < L
VA = 0
VB = 0
Si x ≥ L
x=L
VA = 0
228
VB = 1
Todo lo relativo al movimiento del carro se ha programado en ARENA utilizando un

bloque Assign mediante las sentencias
posicion=posicion+delta_t*(vel_D*VD-vel_I*VI)
VA=posicion <= 0
VB=posicion >= L
posicion=(VA==1)*0+(VA==0)*(VB==0)*posicion+(VB==1)*L
La Lógica de control de la figura A.25 es otro bloque Assign que reproduce las
ecuaciones lógicas (véase la justificación en el ejemplo 3.2.3.2)
E 0 = E 2 A P + E1 E 0 + E 0 + E1 + E 2
E1 = E 0 P + E 2 AP + E 2 E1 E 2 = E1 B + E0 E1 E 2
D = E1 I = E2
VPN=VP==0
E0N=E0==0
E1N=E1==0
E2N=E2==0
E0=( E2 && VA && VPN ) || ( E1N && E0) || ((E0 || E1 || E2) == 0)
EON=E0==0
E1=( E0 && VP ) || ( E2 && VA && VP) || ( E2N && E1 )
E1N=E1==0
E2=( E1 && VB ) || ( E0N && E1N && E2 )
VD=E1
VI=E2
En el modelo de la figura A.25 se han utilizado además:
- Tres bloques Create, denominados Generador de pulsaciones, Reloj del carro y

Reloj de la lógica de control. El primero y el tercero tienen las mismas
funcionalidades que en el ejercicio anterior. El segundo genera eventos periódicos
para que la posición del carro se actualice regularmente, cada intervalo de tiempo,
con independencia de que el estado de los motores no haya cambiado.
- Tres bloques Dispose, denominados Receptor 1 , Receptor 2 y Receptor 3. Que

sirven para retirar del sistema los eventos generados durante la simulación.
- Nueve campos numéricos, que muestran los valores instantáneos: de la posición

del carro, sobre su presencia o no en cada uno de los extremos, y el estado del
pulsador, de las tres etapas del GRAFCET y de los dos motores.
- Un objeto animado, estándar de ARENA, en forma de barra horizontal que se

colorea en rojo según evolucione la posición del carro en el raíl. La barra
totalmente en blanco indica que el carro está en el extremo izquierdo y la barra
229
totalmente en rojo indica que el carro está en el extremo izquierdo, las otras
posibilidades representan posiciones intermedias del carro en el raíl.
- Cuatro registros gráficos para mostrar la evolución temporal de la posición del

carro y de las tres etapas del GRAFCET.

minutos de simulación, en las siguientes condiciones: el reloj del carro y de la lógica de
control tiene el mismo periodo de 1 segundo, representado en el modelo por la variable
delta_t, las velocidades del carro hacia la derecha y hacia la izquierda tienen el mismo
valor de 0.05 m/s, el raíl mide 5 metros. El carro, que estaba inicialmente parado en el
extremo izquierdo, se ha puesto en marcha (hacia la derecha) como consecuencia de la
primera pulsación en el minuto 1. Con posterioridad se han producido siete pulsaciones
que han ido cambiando el estado del pulsador, pero que sólo han tenido efecto sobre el
movimiento del carro (mandándolo parar) cuando éste ha llegado al extremo izquierdo.
En la evolución de E0 se observa que esa situación se ha producido una sola vez. La
posición del carro ha descrito el típico diente de sierra, truncado cuando ha estado
parado en el extremo izquierdo, y simétrico porque hemos supuesto que el carro se
mueve con la misma velocidad a derecha que a izquierda. La posición final del carro,
4.9 m a la derecha se pone claramente de manifiesto en la barra horizontal, que está casi
totalmente coloreada de rojo.
230
Figura A.25 Automatismo para el control del carro que va y viene.
231
A.3.3 Ejercicio 12: Automatismo para el control de los dos carros que van y vienen,
sincronizados en el extremo izquierdo
Se propone programar y comprobar el automatismo para los dos carros que van y
vienen por un raíl, con pulsador de arranque/parada y sincronización en el extremo
izquierdo.
Solución: El GRAFCET que modela el comportamiento de los carros que van y vienen
por un raíl, con botón de parada en el extremo izquierdo y sincronización (un carro
espera al otro) en ese mismo extremo, se presentó en la figura 3.14 del tema 3, y las
ecuaciones lógicas que debe incorporar el automatismo encargado de su control se
presentaron en el ejemplo 3.2.3.3. Este modelo se puede reproducir en ARENA
mediante la estructura de bloques de la figura A.26, ver el archivo
“ej_auto_carros.doe”. La principal novedad respecto al de la figura A.25 es la
reutilización de los tres bloques del carro para modelar tanto al carro 1 como al carro 2,
cada uno con sus propios parámetros. Respecto al flujo de información entre los
elementos físicos del sistema y el automatismo, es similar al representado en la figura
A.24, donde en lugar de un carro aparecen dos, pero éstos no intercambian información
entre sí sino a través del automatismo lógico.
La Lógica de control de la figura A.26 es otro bloque Assign que reproduce las
ecuaciones lógicas (véase la justificación en el ejemplo 3.2.3.3)
E 0 = E 5 E 6 A1 A 2 P + ( E1 + E 2 ) E 0 + E 0 + E1 + E 2 + E 3 + E 4 + E 5 + E 6
E 1 = E 0 P + E 5 E 6 A1 A 2 P + E 3 E 1 E 2 = E 0 P + E 5 E 6 A1 A 2 P + E 4 E 2
E 3 = E1 B1 + E 5 E 3 E 4 = E 2 B2 + E 6 E 4
E 5 = E 3 A1 + E 0 (E1 + E 2 ) E 5 E 6 = E 4 A 2 + E 0 (E1 + E 2 ) E 6
D1 = E1 D2 = E2 I1 = E 3 I2 = E 4
VPN=VP==0
E0N=E0==0
E1N=E1==0
E2N=E2==0
E3N=E3==0
E4N=E4==0
E5N=E5==0
E6N=E6==0
E0=( E5 && E6 && VA1 && VA2 && VPN ) || ( (E1N || E2N) && E0)
|| ((E0 || E1 || E2 || E3 || E4 || E5 || E6) == 0)
EON=E0==0
E1=( E0 && VP ) || ( E5 && E6 && VA1 && VA2 && VP)
|| ( E3N && E1 )
E1N=E1==0
232
E2=( E0 && VP ) || ( E5 && E6 && VA1 && VA2 && VP)

|| ( E4N && E2 )
E2N=E2==0
E3=( E1 && VB1) || ( E5N && E3 )
E3N=E3==0
E4=( E2 && VB2) || ( E6N && E4 )
E4N=E4==0
E5=( E3 && VA1) || ( E0N && ( E1N || E2N ) && E5 )
E5N=E5==0
E6=( E4 && VA2) || ( E0N && ( E1N || E2N ) && E6 )
VD1=E1
VD2=E2
VI1=E3
VI2=E4

minutos de simulación, en las siguientes condiciones:
Los relojes de los carros y de la lógica de control tiene el mismo periodo de 1
segundo.
Las velocidades del carro 1 hacia la derecha y hacia la izquierda tienen el mismo
valor de 0.05 m/s.
Las velocidades del carro 2 hacia la derecha y hacia la izquierda tienen el mismo
valor de 0.1 m/s.
Los raíles ambos carros mide lo mismo 5 metros.
Los carros, que estaban inicialmente parados en los extremos izquierdos, se han puesto
en marcha (hacia la derecha) como consecuencia de la primera pulsación en el minuto 1.
Con posterioridad se han producido siete pulsaciones que han ido cambiando el estado
del pulsador, pero que sólo han tenido efecto sobre los movimientos de los carros
(mandándolos parar) cuando éstos han llegado al extremo izquierdo. La posición del
carro 1, el más lento, ha descrito mismo diente de sierra del modelo anterior, pero la
posición del carro 2, el más rápido ha descrito un diente de mayor frecuencia
(concretamente el doble) y más truncado porque ha tenido que permanecer dos veces
parado en el extremo izquierdo hasta que llegará el carro 1. Las diferentes posiciones
finales de los carros se ponen claramente de manifiesto en las barras horizontales, pero
para ver el sentido del movimiento hay que consultar las variables de estado de los
motores o el valor de las etapas del GRAFCET, concretamente el carro 1 está
moviéndose hacia la derecha mientras que el carro 2 lo está haciendo hacia la izquierda,
están marcadas (a valor lógico 1) las etapas E1 y E4 del GRAFCET.
233
Figura A.26 Automatismo para el control de los carros que van y vienen.
234
A.3.4 Ejercicio 13: Automatismo para el control de tráfico en un cruce con dos
semáforos
Se propone programar y comprobar el automatismo para el control de tráfico en un

cruce con dos semáforos.
Solución: Ver la figura A.27 y el archivo “ej_auto_crucesemaforos.doe”. El sistema

físico en este ejercicio estaría constituido por las luces de los semáforos, pero no ha sido
necesario explicitarlas como tal en el modelo, pues son elementos pasivos que en todo
momento obedecen a las variables lógicas generadas por el automatismo para el
conjunto de seis luces. El automatismo tiene la misma estructura de tres bloques
utilizada en los ejercicios anteriores, pero a diferencia de ellos necesita apoyarse en tres
contadores, denominados Contador VERDE, Contador AMBAR y Contador ROJO
en la figura A.27, para poder temporizar los tiempos de permanencia en cada uno de los
tres estados “verde”, “ámbar” y “rojo” de los semáforos.
Cada bloque contador tiene un parámetro asociado, el valor de la cuenta que debe
realizar, una entrada lógica de activación y una salida lógica para indicar el final de la
cuenta. Por ejemplo, el contador encargado de temporizar el tiempo que va a estar
encendida la luz “verde” se ha programado en ARENA con un bloque Assign y las
siguientes sentencias
cuentaV=duracion_verde*(ECV==0)+(0*(cuentaV==0)+
(cuentaV>=1)*(cuentaV-1))*(ECV==1)
VTV=cuentaV == 0
La primera de las dos sentencias anteriores nos permite tener cargado el contador
cuando no está activo (ECV=“0”) y que esté dispuesto a iniciar la cuenta atrás en
cualquier momento, contar hacia atrás cuando está activado (ECV=“1”) y que nunca se
pase del cero en la cuenta atrás. La segunda de las sentencias sirve para comunicar a la
lógica de control, poniendo a “1” la variable lógica VTV, que la cuenta ha terminado.
Las dos sentencias están particularizadas para la luz verde, los otros bloques contadores
incluyen sentencias similares. Como en ningún momento se puede dar la situación de
que dos contadores estén activos a la vez, sino que se van secuenciando como muestra
el GRAFCET del ejercicio para dar lugar al ciclo completo del primer semáforo y luego
el ciclo completo del segundo semáforo, se podía haber utilizado un único contador.
Pero por simplicidad en el modelo se ha preferido utilizar tres contadores distintos, uno
por cada luz, aunque eso sí los tres se utilizan tanto para el primer semáforo como para
el segundo.
La Lógica de control de la figura A.27 reproduce las ecuaciones lógicas del ejercicio
3.4, mediante las sentencias:
E1N=E1==0
E2N=E2==0
E4N=E4==0
E5N=E5==0
E6N=E6==0
E7N=E7==0
E0=( E4 && E7 && VTR ) ||
235
( E1N && E0 ) || ((E0 || E1 || E2 || E3 || E4 || E5 || E6 || E7) == 0)

E0N=E0==0
E1=( E0 && VTV ) || ( E2N && E1 )
E1N=E1==0
E2=( E1 && VTA ) || ( (E4N || E5N) && E2 )
E2N=E2==0
E3=( E4 && E7 && VTR ) ||
( (E4N || E5N) && E3 ) || ((E0 || E1 || E2 || E3 || E4 || E5 || E6 || E7) == 0)
E3N=E3==0
E4=( E2 && E3 && VTR ) || ( (E0N || E3N) && E4 )
E4N=E4==0
E5=( E2 && E3 && VTR ) || ( E6N && E5 )
E5N=E5==0
E6=( E5 && VTV ) || ( E7N && E6 )
E6N=E6==0
E7=( E6 && VTA ) || ( (E0N || E3N) && E7 )
LV1=E0
LA1=E1
LR1=E2 || E4
LV2=E5
LA2=E6
LR2=E3 || E7
ECV=E0 || E5
ECA=E1 || E6
ECR=E2 || E7
En el modelo de la figura A.27 también se ha incluido la animación de los semáforos,

pero algo más simple que la de la figura A.7. El semáforo 1 es el de la izquierda y el
semáforo es el de la derecha, cada luz desaparece (color transparente) cuando está
apagada y aparece con su color (el ámbar se ha sustituido por el color amarillo) cuando
está encendida. Para parametrizar el modelo se ha supuesto que todos los relojes van al
mismo periodo de 1 segundo que la lógica de control, que los tiempos de permanencia
en el ciclo normal del semáforo son 60 segundos para el verde, 10 segundos para el
ámbar y 5 segundos para el rojo. Este último valor garantiza el tiempo que los dos
semáforos van a coincidir en rojo, pero el tiempo total que un semáforo estará en rojo
será de 80 (5 + 60 + 10 + 5) segundos pues a los intervalos de 5 segundos en los que
ambos semáforos coinciden en rojo hay que sumar los tiempos en que el otro semáforo
está en verde y en ámbar.
En el modelo de la figura A.27 no se incluye ningún registro gráfico, lo importante es

ver al modelo en ejecución y observar que efectivamente los dos semáforos ejecutan los
ciclos previstos de forma adecuada. Después de 10 minutos (600 segundos) de
simulación, los dos semáforos vuelven a estar en la misma situación de partida; el
semáforo 1 en verde y el semáforo en rojo.
236
Figura A.27 Automatismo para el control de tráfico en un cruce con dos semáforos.
A.3.5 Ejercicio 14: Automatismo para el control de un semáforo de peatones
Se propone programar y comprobar el automatismo para el control de un semáforo de

peatones.
Solución: El automatismo que controle el semáforo de peatones estará basado en un

GRAFCET de mayor o menor número de etapas, en función del tipo de semáforo que
consideremos. En el tema 1 se consideró el más simple, con sólo dos luces (roja y
verde), véase la figura 1.4. Pero en los temas 2 y 3 y en el apartado A.1 de este anexo se
consideró el más completo, con tres luces (roja, ámbar y verde) y garantizando un
tiempo mínimo de permanencia en verde.
La novedad de este ejercicio es que el GRAFCET y el automatismo resultante deben

incorporar la funcionalidad del botón del semáforo. A diferencia del simple interruptor
(utilizado en el encendido y apagado de la lámpara, y en los carros) que conmuta
instantáneamente cada vez que atiende una petición, y se limita a informar al
automatismo de su estado “pulsado” o “no pulsado”. El botón del semáforo debe
atender la petición del primer peatón, desatender las peticiones de los peatones que
vayan llegando si aún o se ha atendido la petición del primero y desatender cualquier
otra petición que se reciba cuando el semáforo está en rojo (dando paso a los peatones).
Esta funcionalidad se ha incorporado en el GRAFCET de la figura A.28 de forma
similar a como se han incorporado en el ejercicio 3.5 las peticiones de subida y bajada
para el montacargas.
La etapa E0 representa que el semáforo está en verde, esperando a que se produzca

alguna petición de un peatón, a través de la etapa E4. Las etapas E1, E2 y E3
constituyen el ciclo básico (verde, ámbar, rojo) del semáforo, con características
similares a las comentadas en el ejercicio 3.3. Las acciones LV1, LA1, LR1, representan
el encendido de la luz correspondiente (verde, ámbar o roja), y aunque sólo hay un
semáforo ha habido que utilizar esos nombres de variables pues otros nombres como LR
están reservados por el lenguado de modelado de ARENA. Las acciones ECV, ECA y
237
ECR representan el comienzo de la cuenta en los contadores respectivos, de forma

similar al ejercicio anterior de los dos semáforos. La acción EBP se incluye para
representa que el sistema queda a la espera de alguna pulsación a través del botón de
peatones. La transición VP está asociada a la petición aleatoria del peatón, mientras que
VTV, VTA y VTR son transiciones temporizadas por los respectivos contadores.
LV1
E0 E4
EBP
VP
LV1
E1
ECV
VTV
LA1
E2
ECA
VTA
LR1
E3
ECR
VTR
Figura A.28 GRAFCET del semáforo de peatones.
Por tanto las ecuaciones lógicas que debe incorporar el automatismo son las siguientes:
E 0 = E 3 VTR + E1 E 0 + E 0 + E 1 + E 2 + E 3 + E 4
E 4 = E1 E 4 + E 0 + E 1 + E 2 + E 3 + E 4
E 1 = E 0 E 4 VP + E 2 E 1
E 2 = E 1 VTV + E 3 E 2
E 3 = E 2 VTA + E 0 E 3
LV1 = E 0 + E 1 EBP = E 0 ECV = E 1
LA1 = E 2 ECA = E 2 LR1 = E 3 ECR = E 3
Que están programadas en el bloque Lógica de control de la figura A.29, véase el

archivo “ej_auto_semaforopeatones.doe”, mediante las sentencias
E1N=E1==0
E0=( E3 && VTR ) || ( E1N && E0) || ((E0 || E1 || E2 || E3) == 0)
238
E4=( E1N && E4) || ((E0 || E1 || E2 || E3) == 0)

E2N=E2==0
E1=( E0 && E4 && VP ) || ( E2N && E1 )
E3N=E3==0
E2=( E1 && VTV ) || ( E3N && E2 )
E0N=E0==0
E3=( E2 && VTA ) || ( E0N && E3 )
LV1=E0 || E1
EBP=E0
ECV=E1
LA1=E2
ECA=E2
LR1=E3
ECR=E3
El automatismo se apoya, como en el modelo del ejercicio anterior, en tres contadores

para poder temporizar los tiempos de permanencia en cada uno de los tres estados
“verde”, “ámbar” y “rojo” del semáforo. El modelo se completa con la lógica asociada
al botón de peatones, para la que se ha utilizado un bloque Decide, denominado
Atiende en la figura A.29, que desvía las peticiones recibidas al bloque Atiende
peticion si y sólo si la variable EBP está al valor lógico “1”, es decir el semáforo ha
llegado a la etapa E0 y está esperando la petición de algún peatón. Al atender la petición
se ponen las variables E4 y VP al valor lógico “1”, es decir, se activa la etapa E4 para
indicar que ha llegado una petición y se permite la transición VP para que el semáforo
comience su ciclo de colores. En cualquier otra situación, EBP estará al valor lógico “0”
y las peticiones de los peatones no se atenderán. Algo similar se hizo en el caso del
carro que va y viene con botón de arranque/parada, véase la figura A.18.
239
Figura A.29 Automatismo para control del semáforo de peatones.
Como parámetros del modelo se ha supuesto que todos los relojes van al mismo periodo
de 1 segundo que la lógica de control, que los tiempos de permanencia en el ciclo
normal del semáforo son 60 segundos para el verde, 10 segundos para el ámbar y 60
segundos para el rojo. En el modelo “ej_auto_semaforopeatones.doe” se incluyen
también seis registros temporales (no recogidos en figura A.29) para poder analizar las
peticiones de los peatones, generadas aleatoriamente por el bloque Generador de
peticiones, y la evolución temporal de las cinco etapas del GRAFCET. En la figura
A.30 se muestra un ejemplo de resultados, donde se observa (comparando la llegada de
las peticiones con la evolución de la etapa E1) que en los 10 minutos que ha durado la
simulación se recibieron un total de 7 peticiones, pero sólo se atendieron tres. Que
provocaron tres ciclos (E1=“verde”, E2=“ámbar” y E3 =“rojo”), de los cuales se
completaron los dos primeros y estaba a punto de completarse el tercero (semáforo en
rojo, véase figura A.29) cuando acabó la simulación.
240
Figura A.30 Resultados de simulación con el automatismo para control del semáforo de peatones.
241
242
BIBLIOGRAFÍA
J. ARACIL, F. GORDILLO: Dinámica de sistemas. Alianza Editorial, 1997.
J. BALCELLS, J. L. ROMERAL: Automátas Programables, Marcombo Boixareu

Editores, 1997.
J. P. DESCHAMPS, J. M. ÁNGULO: Diseño de sistemas digitales: Metodología

moderna, Paraninfo, 1989.
S. DORMIDO, M. A. CANTO, J. MIRA, A. E. DELGADO: Estructura y tecnología de

computadores, Sanz y Torres, 2002.
A. GUASCH, M. A. PIERA, J. CASANOVAS, J. FIGUERAS: Modelado y simulación:

Aplicación a procesos logísticos de fabricación y servicios. Edicions UPC, 2002.
W. D. KELTON, R. P. SADOWSKI, D. T. STURROCK: Simulation with Arena, Third

edition, McGraw-Hill, 2004.
R. J. PAUL: “Activity Cycle Diagrams and the Three Phase Approach”. Proceedings of
the 1993 Winter Simulation Conference, 1993.
L. SCHRUBEN: “Simulation Modeling with Event Graphs”. Communications od the

ACM, 26 (11), pp. 957-963, November 1983.
M. SILVA: Redes de Petri en la Automática y la Informática. Editorial AC, 1985.
A. URQUÍA: SIMULACIÓN: Texto Base de Teoría, Curso 2003-04. Departamento de

Informática y Automática, UNED.
A. URQUÍA: SIMULACIÓN: Solución a una selección de problemas y enunciado del

Proyecto, Curso 2003-04. Departamento de Informática y Automática, UNED.
F. VÁZQUEZ: Modelado y Simulación de Sistemas Dinámicos. Departamento de

Informática y Análisis Numérico. Universidad de Córdoba, 2002.
G. A. WAINER: Introducción a la Simulación de Eventos Discretos. Informe técnico.

Departamento de Computación. Facultad de Ciencias Exactas y Naturales. Universidad
de Buenos Aires, 1996. http://www.dc.uba.ar/people/proyinv/tr.html.
243
Bibliografía
B. P. ZEIGLER, H. PRAEHOFER, T. G. KIM: Theory of Modeling and Simulation:

Integrating Discrete Event and Continuous Complex Dynamic Systems. Second Edition.
Academic Press, 2000.
http://ttt.upv.es/jldiez/curso_aui. Plataforma Multimedia para Automatización

Industrial. Desarrollada por profesores del Departamento de Ingeniería de Sistemas y
Automática de la Universidad Politécnica de Valencia. 2002.
244

Matemática Discreta (UNED) - Modelado de Sistemas de Eventos Discretos

Diunggah oleh

Informasi Dokumen

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

Matemática Discreta (UNED) - Modelado de Sistemas de Eventos Discretos

Diunggah oleh

Hak Cipta:

Format Tersedia

MODELADO DE SISTEMAS

petición petición petición petición

recepción recepción recepción recepción

Fernando Morilla García Natividad Duro Carralero

Departamento de Informática y Automática

E.T.S. de Ingeniería Informática, UNED

Tema 1 : Introducción al modelado de sistemas discretos

1.1 Sistemas y experimentos ………………………………………………………… 1

1.2 Modelado y simulación ………………………………………………………….. 2

1.3 Modelado de sistemas de eventos discretos……………………………………… 6

1.4 Metodología de modelado…………………………………………………….....13

1.5 Ejemplos de sistemas de eventos discretos …………………………………… 17

1.6 Técnicas de descripción funcional……………………………………………… 22

1.7 Ejercicios resueltos ……………………………………………………………...35

Tema 2 : Redes de Petri

2.1 Definición formal de las Redes de Petri ……………………………………… 49

2.2 Reglas del comportamiento dinámico de una Red de Petri…………………… 51

2.3 Configuraciones y propiedades básicas de las Redes de Petri………………... 57

2.4 Concurrencia y sincronización.……………………………………………….. 64

2.5 Extensiones de las Redes de Petri…..………………………………………… 65

2.6 Ejercicios resueltos …………………………………………………………… 70

Tema 3 : Diseño e implementación de automatismos

3.1 Diseño de automatismos con GRAFCET.…………………………………..… 97

3.2 Implementación de automatismos con GRAFCET………………………….. 112

3.3 Diseño estructurado………………………………………………………….. 118

3.4 Ejercicios resueltos ………………………………………………………….. 129

Tema 4 : Formalismo DEVS (Discrete EVents dynamic Systems)

4.1 Modelos atómicos.…………………………………………………………… 143

4.2 Ejemplos de modelos atómicos……………………………………………… 147

4.3 Modelos acoplados…………………………………………………………... 167

4.4 Modelos en Paralelo…………………………………………………………. 169

4.5 Ejercicios resueltos ………………………………………………………….. 171

Anexo : Ejercicios para programar en ARENA

A.1 Modelos de autómatas de estado.………………………………….………… 191

A.2 Modelos con estructura de red de Petri……………………………………… 204

A.3 Modelos sobre automatismos………………………………………………... 225

Bibliografía ………………………………………..……………………………….... 243

Introducción al modelado de sistemas

Al comienzo del tema se da un repaso a los principales conceptos de modelado y

1.1 SISTEMAS Y EXPERIMENTOS

En el sentido amplio del término, un sistema S es un objeto formado por un conjunto de

• Un sistema ecológico formado por diferentes poblaciones entre las que se

Un procedimiento para conocer el comportamiento de los sistemas es la

Cuando es posible trabajar directamente con el sistema real, el método experimental

En ciertas ocasiones es imposible experimentar con el sistema real, porque el sistema

1.2 MODELADO Y SIMULACIÓN

Llamaremos modelo M a un objeto artificial construido para representar de forma

Nótese que la complejidad de un sistema (Guasch y col. 2002) no debería medirse en

Así la simulación es considerada como el arte y la ciencia de experimentar con modelos.

El modelado representa el proceso de organizar y estructurar el conocimiento acerca de

1.2.1 Modelos matemáticos

Existen diferentes clasificaciones de los modelos matemáticos, atendiendo a diferentes

Un modelo matemático es determinista cuando su nuevo estado queda completamente

Por el contrario, un modelo es estocástico cuando alguna de sus variables de entrada

Las dificultades asociadas a la simulación de modelos estocásticos pueden invitarnos en

Un modelo estático es una representación de un sistema en un instante de tiempo

De tiempo continuo, De tiempo discreto o Híbrido

En un modelo de tiempo discreto los cambios pueden ocurrir únicamente en instantes

Tal como se ha indicado al comienzo de la sección, la decisión de realizar un modelo

Los modelos de tiempo discreto se utilizan frecuentemente en ingeniería para diseñar

en el instante tk, con un intervalo de discretización ∆t, se obtiene el siguiente modelo de

De variables continuas, De variables discretas o Mixtos

En este punto es conveniente realizar una consideración acerca de los modelos de

1.3 MODELADO DE SISTEMAS DE EVENTOS DISCRETOS