See discussions, stats, and author profiles for this publication at: https://www.researchgate.

net/publication/317413579

Modelo y simulación de Redes de Petri con el formalismo DEVS

Conference Paper · August 2010

CITATIONS READS

0 94

3 authors:

Taihú Pire Federico Bergero

National Scientific and Technical Research Council Rosario National University
16 PUBLICATIONS   49 CITATIONS    22 PUBLICATIONS   155 CITATIONS   

SEE PROFILE SEE PROFILE

Ernesto Kofman
National Scientific and Technical Research Council
106 PUBLICATIONS   1,702 CITATIONS   

SEE PROFILE

Some of the authors of this publication are also working on these related projects:

MPC for applications View project

S-PTAM View project

All content following this page was uploaded by Taihú Pire on 08 June 2017.

The user has requested enhancement of the downloaded file.

 AADECA 2010 - Semana del Control Automático - XXII◦ Congreso Argentino de Control Automático
31 de Agosto al 2 de Septiembre de 2010 - Buenos Aires, Argentina.

MODELADO Y SIMULACIÓN DE REDES DE PETRI

CON EL FORMALISMO DEVS

Taihú Piré 1 Federico Bergero 2 Ernesto Kofman 3

Departamento de Ciencias de la Computación. FCEIA - UNR.

Laboratorio de Sistemas Dinámicos. FCEIA - UNR.
CIFASIS–CONICET. Riobamba 245 bis - (2000) Rosario

Resumen: En este trabajo se presenta el desarrollo de una librerı́a de Redes de Petri

implementada completamente bajo un simulador de eventos discretos (DEVS) llamado
PowerDEVS. Se describe la metodologı́a utilizada para sortear los problemas que
surgen de las diferencias entre estos formalismos (modularidad vs. no-modularidad,
cambios locales vs. cambios globales, prioridades vs. no determinismo) con el objetivo
de mantener la apariencia gráfica de las Redes de Petri.
Esta nueva librerı́a permite el modelado y simulación de modelos hı́bridos inter–
formalismos (DEVS y Redes de Petri) tomando ventajas de cada uno de ellos y
utilizando cada uno donde es más apropiado. Se presentan también dos ejemplos
de uso de la librerı́a donde se ilustran algunas de sus caracterı́sticas.

Palabras Claves: Redes de Petri, DEVS, PowerDEVS, Sistemas Hı́bridos

1. INTRODUCCIÓN Pese a su generalidad, DEVS no es un lenguaje

La rápida evolución tecnológica de las últimas
décadas emergió junto con nuevos sistemas dinámi-
cos entre los cuales encontramos, por ejemplo,
redes de computadoras, sistemas de producción
automatizados, sistemas de control supervisorio,
etc. En estos sistemas los cambios se deben a la
ocurrencia asincrónica de eventos, lo que motivó la
formulación del término Sistemas de Eventos
Discretos (DES) y la definición de formalismos
que permitan modelar, analizar y simular dichos
sistemas.
Entre los formalismos más populares para estos
sistemas se encuentran las Redes de Petri (Petri
Nets o PN) (Cassandras and Lafortune, 2008;
Cohen, 2001), que proveen una representación
gráfica muy conveniente para modelizar y analizar
distintos tipos de problemas. Por otra parte, orien-
tado a los problemas de modelado y simulación
más generales, se desarrolló el formalismo DEVS
(Discrete EVent System specification) (Zeigler et
al., 2000). DEVS es un formalismo universal que
permite expresar todos los modelos que pueden
ser representados por cualquier otro formalismo
DES (como las PN por ejemplo).
1 taihup@gmail.com
2 bergero@cifasis-conicet.gov.ar
3 kofman@fceia.unr.edu.ar
gráfico, y en gran cantidad de casos es mucho
más simple obtener un modelo en Redes de Petri
que hacerlo directamente en DEVS. Por otro lado,
hay muchos modelos que no pueden representarse
con Redes de Petri (aproximaciones de sistemas
continuos, por ejemplo, o modelos hı́bridos en
general), y que el formalismo DEVS puede simular
de manera muy eficiente.
Esto sugiere la conveniencia de utilizar ambos
formalismos en conjunción. De hecho, hay un
antecedente del uso de PN en un simulador
DEVS (Jacques and Wainer, 2002). Sin embargo,
debido a las caracterı́sticas del simulador utilizado
(CD++) (Wainer, 2002), en dicho trabajo los
modelos tienen muchas restricciones y en el
modelado se deben agregar puertos y conexiones
que no existen en la Red de Petri original.
En el presente trabajo se desarrolla e implementa
una metodologı́a que permite utilizar Redes de
Petri dentro de una herramienta de modelado
y simulación de DEVS denominada PowerDEVS
(Bergero and Kofman, 2010). A diferencia de
lo desarrollado en CD++, esta implementación
respecta la apariencia gráfica de las Redes de Petri
y no tiene restricciones, incluyendo temporización,
asignación de prioridades e interconexión con
otros modelos DEVS (incluyendo aproximaciones
de modelos continuos). Además de describir la im-
plementación, se muestran ejemplos de aplicación
que utilizan la librerı́a desarrollada.
 AADECA 2010 - Semana del Control Automático - XXII◦ Congreso Argentino de Control Automático
31 de Agosto al 2 de Septiembre de 2010 - Buenos Aires, Argentina.
El trabajo está estructurado de la siguiente
manera: en la sección 2 se presentan los con-
ceptos y herramientas utilizados en el resto del
trabajo. En la sección 3 se describe el trabajo
desarrollado y en la sección 4 se exponen distintos
ejemplos y aplicaciones que manifiestan distintas
caracterı́sticas de la implementación. Finalmente,
en la sección 5 se comentan algunas conclusiones
y posibles trabajos futuros.
2. CONCEPTOS PREVIOS
2.1 Redes de Petri
Las Redes de Petri (PN) (Cassandras and Lafor-
tune, 2008; Cohen, 2001) son una herramienta
gráfica, creada por Carl Adam Petri, que se
utilizan para representar fenómenos tales como
la dinámica de eventos, la evolución en paralelo,
la dependencia condicional (sincronización), la
competencia de recursos, etc. Estos fenómenos se
manifiestan frecuentemente en sistemas de pro-
ducción, protocolos de comunicaciones, compu-
tadoras y redes de datos, software de tiempo real,
sistemas de transporte, etc.
Desde el punto de vista de la teorı́a de grafos
las redes de Petri son un par dirigido (ϑ, M )
compuesto por un grafo dirigido bipartito ϑ =
(E, V ) y una marca inicial M. El conjunto
de vértices está dividido en dos subconjuntos
disjuntos P (lugares) y T (transiciones). Los
lugares serán representados por: Pi , i = 1, ..., |P |
y las transiciones por: Tj , j = 1, ..., |T |. Los arcos
de E van de los lugares a las transiciones o bien
de las transiciones a los lugares. Gráficamente los
lugares serán representados mediante cı́rculos y
las transiciones mediante arcos. A los arcos se les
asigna un peso el cual está dado por un número
entero (en ausencia de dicho número se considera
que el peso es 1). La marca inicial asigna un entero
no negativo Mi a cada lugar Pi . Gráficamente,
Mi puntos o marcas serán colocados en el cı́rculo
que representa a Pi . El vector columna M , cuyas
componentes son las Mi , recibe el nombre de
marca inicial de la red de Petri. Diremos que un
lugar Pi es anterior a una transición Tj , si hay un
arco que va de Pi a Tj . Análogamente, diremos
que un lugar Pi es posterior a la transición Tj , si
hay un arco que va de Tj a Pi . Una representación
gráfica de una Red de Petri puede verse en la
Fig. 1.
2 2
T1 P1 T2 P3 T1 P1
2 2
P2 T3 T3 P2
(a)
P4 T1 P4
Figura 1. Evolución de una Red de Petri
Las transiciones que no poseen lugares anteriores
reciben el nombre de transiciones de entrada (o
fuentes). Los disparos de las mismas se deben a
decisiones externas (son “controladas” desde el
exterior). Las transiciones que no poseen lugares
posteriores se llaman transiciones de salida (o
sumideros). Los disparos de las mismas nos
indican cuando se producen marcas desde la red
hacia el exterior.
Las mismas definiciones pueden hacerse para los
lugares (los lugares de entrada deben ser provistos
de marcas desde el exterior).
Los cambios de estados ocurren según las siguien-
tes reglas de evolución:
una transición Ti puede dispararse o activar-
se, si cada lugar anterior a Ti contiene al
menos tantas marcas como el peso del arco
que los une.
cuando una transición Ti es disparada o
activada, se elimina de cada lugar anterior a
dicha transición tantas marcas como el peso
del arco que los une. También se agrega a
cada lugar posterior a Ti tantas marcas como
el peso del arco que los une (ver Fig. 1).
En lugar de asociar pesos a los arcos, se puede
suponer que todos los arcos tienen peso uno y
permitir varios arcos “paralelos” entre lugares y
transiciones.
Las Redes de Petri permiten también incorporar
temporización, añadiendo un parámetro a los
lugares y/o transiciones que denota:
lugares: el tiempo mı́nimo que las marcas
deben permanecer antes de contribuir a ha-
bilitar el disparo de una transición posterior.
Se denomina tiempo de espera.
transiciones: el tiempo que separa el comien-
zo (el consumo de marcas de los lugares
anteriores) y la finalización (la producción
de marcas hacia los lugares posteriores)
del disparo de una transición. Se denomina
tiempo de disparo.
2.2 Simuladores de Redes de Petri
Dado que las Redes de Petri son muy utilizadas,
se han desarrollado numerosas herramientas para
su modelado, simulación y análisis:
Hay un conjunto de herramientas de código
T2 P3 abierto desarrolladas en Java, que permiten
editar, simular y analizar redes de Petri
T3
(b)
de manera gráfica. Entre ellas encontramos
Pipe2 (Bonet et al., 2007), Tapaal (Byg
et al., 2009) y HPSim. Cada una de estas
herramientas ofrece distintas opciones de
temporización, análisis, etc.
 AADECA 2010 - Semana del Control Automático - XXII◦ Congreso Argentino de Control Automático
31 de Agosto al 2 de Septiembre de 2010 - Buenos Aires, Argentina.
Matlab posee un toolbox para diseñar, ana-
lizar y simular redes de Petri (Zdenk et al.,
2001),.
Modelica cuenta con una librerı́a de Redes
de Petri (Mosterman et al., 1998), que
permite modelar y simular Redes de Petri
en las distintas herramientas de software que
implementan este lenguaje. Estos modelos
pueden interactuar con modelos más gene-
rales representados en Modelica.
2.3 Formalismo DEVS
DEVS(Zeigler et al., 2000) es un formalismo
para modelar y analizar sistemas de eventos
discretos(es decir, sistemas en los cuales en un
lapso finito de tiempo, ocurren una cantidad finita
de cambios).
Un modelo DEVS puede ser visto como un
autómata que procesa una secuencia de eventos
de entrada y genera una secuencia de eventos de
salida.
Formalmente un modelo DEVS está descripto por
dos clases de componentes, modelos atómicos y
modelos acoplados.
Un modelo atómico representa la unidad “mole-
cular” de procesamiento, en el sentido que es la
pieza fundamental y más básica. Formalmente un
modelo atómico esta conformado por la 7-upla
(X, Y, S, δint , δext , λ, ta) donde:
Cada posible estado s (s ∈ S) tiene asociado
un Avance de Tiempo calculado por la Función
de Avance de Tiempo ta(s). Luego, si el estado
toma el valor s1 en el tiempo t1 , tras ta(s1 )
unidades de tiempo (o sea, en tiempo ta(s1 )+t1 ) el
sistema realiza una transición interna yendo a un
nuevo estado s2 . El nuevo estado se calcula como
s2 = δint (s1 ). La función δint se llama Función de
Transición Interna.
Cuando el estado va de s1 a s2 se produce también
un evento de salida con valor y1 = λ(s1 ). La
función λ (λ : S → Y ) se llama Función de
Salida. Ası́, las funciones ta, δint y λ definen el
comportamiento autónomo de un modelo DEVS.
Cuando llega un evento de entrada el estado
cambia instantáneamente. El nuevo valor del
estado depende no sólo del valor del evento
de entrada sino también del valor anterior de
estado y del tiempo transcurrido desde la última
transición. Si el sistema llega al estado s3 en el
instante t3 y luego llega un evento de entrada
en el instante t3 + e con un valor x1 , el nuevo
estado se calcula como s4 = δext (s3 , e, x1 ) (notar
que ta(s3 ) > e). En este caso se dice que el
sistema realiza una transición externa. La función
δext se llama Función de Transición Externa.
Durante una transición externa no se produce
ningún evento de salida.
Los modelos DEVS pueden acoplarse de forma
equivalente a los diagramas de bloques, a través
de puertos de entrada y salida. Los modelos
acoplados constituyen modelos DEVS válidos, que
pueden acoplarse a su vez con otros modelos
DEVS atómicos o acoplados.
2.4 Redes de Petri y DEVS
Como se mencionó en la introducción, el formalis-
mo DEVS permite representar cualquier sistema
de eventos discretos y existe un antecedente de la
utilización de Redes de Petri en una herramienta
de simulación DEVS (Jacques and Wainer, 2002).
En dicha implementación, se desarrollan dos
modelos DEVS atómicos: uno para los lugares y
otro para las transiciones.
La Fig. 2 ilustra el modelo DEVS que describe el
lugar. Éste tiene un único puerto de entrada y un
único puerto de salida.
IN PLACE OUT
Figura 2. Modelo conceptual de un lugar
El puerto de entrada (IN ) es usado para recibir
eventos desde las transiciones que indican que hay
que sumar o restar marcas.
El puerto de salida (OU T ) es usado para enviar
eventos notificando a las transiciones posteriores
el número de marcas. De esta manera las tran-
siciones pueden determinar si están activas. Este
proceso es ejecutado cada vez que el número de
marcas en el lugar es modificado y cuando el
modelo es inicializado.
La Fig. 3 ilustra el modelo DEVS que describe la
transición.
IN0 OUT1
TRANSITION
IN1 OUT2
IN2 OUT3
IN3 OUT4
IN4 FIRED
Figura 3. Modelo conceptual de una transición
Este modelo posee cinco puertos de entrada y
cinco puertos de salida. Por el puerto de entrada
IN 1 llegan eventos de los lugares anteriores
notificando la cantidad de marcas que tienen los
mismos. Los puertos de entrada IN 2, IN 3, e
IN 4 tienen la misma función que el puerto IN 1
excepto que los arcos representan una conexión
doble, triple y cuádruple respectivamente.
El puerto de entrada IN 0 cumple la misma
función que el puerto IN 1 con la excepción de
 AADECA 2010 - Semana del Control Automático - XXII◦ Congreso Argentino de Control Automático
31 de Agosto al 2 de Septiembre de 2010 - Buenos Aires, Argentina.
que las conexiones consisten en un arco inhibidor.
Es decir, los lugares de entrada deben contener
cero marcas para que la transición esté activa y
cuando esta se dispara ninguna marca es removida
del lugar.
Por el puerto de salida OU T 1 se envı́an eventos
a los lugares posteriores indicando que deben
incrementar su estado en una marca. Los puertos
de salida OU T 2, OU T 3 y OU T 4 cumplen con el
mismo propósito que el puerto OU T 1, excepto que
los arcos representan una conexión doble, triple y
cuádruple respectivamente. Finalmente, F IRED
es un puerto de salida que se utiliza para indicar a
los lugares anteriores que deben remover marcas.
Este último puerto (y sus conexiones hacia los
lugares anteriores) no existen en la representación
gráfica original de la red, sino que son un requisito
de esta implementación. En consecuencia, los
modelos de Redes de Petri representados en
CD++ no lucen como la red original y obligan
al usuario a agregar muchos puertos y conexiones
adicionales.
2.5 PowerDEVS
PowerDEVS (Bergero and Kofman, 2010) es un
entorno de simulación multi-plataforma de mode-
los DEVS de propósito general. Fue desarrollado
y es mantenido por el Laboratorio de Sistemas
Dinámicos de la Facultad de Ciencias Exactas,
Ingenierı́a y Agrimensura de la Universidad Na-
cional de Rosario.
Una de las caracterı́sticas salientes de Power-
DEVS es que contiene una librerı́a completa de
implementación de los métodos de QSS (Cellier
and Kofman, 2006), los cuales realizan una apro-
ximación DEVS de sistemas continuos. De esta
manera, PowerDEVS permite simular sistemas
continuos y discretos (es decir, sistemas hı́bridos)
de una manera muy simple y eficiente.
Esta herramienta permite acoplar modelos gráfi-
camente a través de una interfaz sencilla e
intuitiva (ver Fig. 5) lo que la hace apropiada
para el modelado con formalismos gráficos como
las Redes de Petri .
El motor de simulación de PowerDEVS, imple-
mentado completamente en C++, mapea cada
modelo DEVS atómico a un clase. Al ejecutarse
la simulación, habrá tantas instancias de esta
clase como modelos atómicos hubiere en el modelo
DEVS. Esto permite referenciar a través de
punteros a los modelos atómicos en tiempo de
ejecución. Esta caracterı́stica, como se verá más
adelante, será crucial para evitar el agregado
de las conexiones y puertos inexistentes que
aparecı́an en (Jacques and Wainer, 2002).
Por otra parte, los eventos que procesan los
modelos atómicos también son instancias de una
clase llamada Event. Como vimos en la sección
2.3 tanto los eventos de entrada como los de
salida de un modelo DEVS pueden pertenecer
a cualquier conjunto definido por el modelador.
Para representar esto en el motor de simulación,
el valor que contiene la clase Event es del tipo
void *, o sea un puntero sin tipo. C++ hace
posible que cualquier tipo sea convertido desde y
hacia void * dejando ası́ que los eventos tomen
valores de cualquier tipo.
Esta caracterı́stica también será explotada para
evitar conexiones inexistentes transmitiendo pun-
teros a los distintos modelos como parte del valor
del evento.
3. TRABAJO DESARROLLADO
En esta sección se describe la metodologı́a desa-
rrollada y la implementación de Redes de Petri en
el entorno PowerDEVS.
3.1 Dificultades Básicas
La principal dificultad para representar Redes
de Petri en DEVS está asociada a la dinámica
del disparo de una transición. En ese momento
todos los lugares anteriores deben decrementar su
número de marcas y (de no haber temporización)
todos los lugares posteriores deben incrementarlo.
Esto a su vez, puede modificar el estado activo o
inactivo de otras transiciones.
Debido a la modularidad de DEVS (un modelo
no puede ver ni modificar directamente el estado
de otro), estos cambios implican la necesidad
de conexiones desde las transiciones hacia los
lugares anteriores y posteriores. En las Redes
de Petri, en cambio, sólo hay arcos desde las
transiciones hacia los lugares posteriores. Esta
diferencia provocará que, de no utilizarse algún
truco para romper la modularidad, el modelo
DEVS de la Red de Petri contendrá puertos
y conexiones inexistentes, tal como ocurre en
(Jacques and Wainer, 2002).
Otro problema es que todos los cambios de marcas
y de activación asociados a un disparo deben
realizarse simultáneamente. Este comportamiento
no es trivial de representar en DEVS, ya que
los modelos DEVS cambian su estado de a uno
por vez, es decir no puede haber cambio en dos
modelos al mismo tiempo.
Finalmente, hay una dificultad adicional asociada
al no determinismo de las Redes de Petri. Cuando
dos transiciones están activas, el formalismo no
especifica cuál es la que debe dispararse. En
 AADECA 2010 - Semana del Control Automático - XXII◦ Congreso Argentino de Control Automático
31 de Agosto al 2 de Septiembre de 2010 - Buenos Aires, Argentina.
la presente implementación se optó por asignar
prioridades estáticas (asignadas por el usuario)
a los modelos DEVS que representan las tran-
siciones, modificando la semántica de ejecución,
disparando la transición de mayor prioridad,
cuando hay múltiples transiciones activas.
3.2 Implementación
Siguiendo la idea de (Jacques and Wainer, 2002),
la transición y el lugar serán representados por
modelos DEVS atómicos, mientras que los arcos
serán conexiones DEVS entre los puertos corres-
pondientes. En este trabajo se implementarán
tanto lugares como transiciones temporizadas.
Los eventos transmitidos entre las transiciones y
lugares tienen la siguiente estructura:
typedef struct msg{
double y[10];
Simulator *src;
int tokens;
}Message;
El campo double y[10] está ubicado prime-
ro para tener compatibilidad con los demás
bloques de PowerDEVS. Cuando un evento
es emitido por un lugar, y[0] contiene el
número de marcas del mismo. Cuando es
emitido por una transición, tiene valor 0. El
resto de los componentes es siempre 0.
Simulator *src es un puntero que hace
referencia al objeto que emitió el evento.
Este puntero es utilizado por el receptor del
evento para acceder y modificar el estado
del atómico que envió el mensaje. Esto es
lo que permite quebrar la modularidad de
DEVS para evitar las conexiones adicionales
ya mencionadas.
int tokens indica la cantidad de marcas
que contiene un lugar y en el caso de una
transición siempre tiene el valor 0.
3.3 Modelo del lugar
El modelo DEVS del lugar tendrá un puerto
de entrada por cada transición anterior y un
único puerto de salida que podrá ser conectado a
múltiples transiciones posteriores. Los valores de
los eventos de entrada y de salida, serán instancias
de la clase Message.
El modelo DEVS del lugar tendrá las siguientes
caracterı́sticas:
El estado es s = (tokens ∈ N0+ , Sigma ∈
R+ , T imeF lag ∈ {0, 1, 2}, T okenT imes ∈
List(R+ )). El entero tokens mantiene la
cantidad de marcas “activas” que contiene el
lugar. Sigma mantiene el tiempo de avance.
T imeF lag indica en que estado está el
lugar: 0 cuando no hay marcas nuevas, 1
cuando hay marcas que están cumpliendo el
tiempo de espera del lugar y 2 cuando hay
marcas nuevas que han cumplido el tiempo
de espera. La lista T okenT imes mantiene
el tiempo de espera actual de cada marca
contenida en el lugar.
δint : Si el lugar estaba esperando que alguna
marca se active (T imeF lag = 1), al cum-
plirse el tiempo correspondiente, una marca
es agregada a tokens, se asigna Sigma = 0
para notificar a las transiciones posteriores
que hay una nueva marca activa y se va
a un estado en el cual hay marcas activas
(T imeF lag = 2). Si el lugar ya tenı́a
marcas activas al momento de cumplirse
el tiempo de espera (T imeF lag = 2), se
debe corroborar si quedan marcas en la
lista. En caso afirmativo se toma como
tiempo de avance el tiempo en que la
próxima marca va a estar activa (Sigma =
min(T okenT imes); T imeF lag = 1), en caso
contrario se transiciona a un estado pasivo
(Sigma = ∞; T imeF lag = 0).
δext : Se actualiza la lista de T okenT imes
teniendo en cuenta el tiempo transcurrido. Se
agrega una nueva marca a la lista con tiempo
de espera igual al del lugar. Luego se asigna
a Sigma el tiempo en el cual se va a activar
la próxima marca.
Cuando una transición cambia la cantidad de
marcas en un lugar, el lugar debe ser notificado.
Esto se realiza utilizando un mecanismo provisto
por el motor de simulación de PowerDEVS,
el cual permite simular la ocurrencia de una
transición externa aún sin haber recibido un
evento. Cuando el lugar recibe un aviso de este
tipo (una transición externa simulada), emite un
evento instantáneamente haciendo Sigma = 0
para notificar a las transiciones posteriores su
nuevo número de marcas.
3.4 Modelo de la Transición
El modelo DEVS de la transición tendrá un
puerto de entrada por cada lugar anterior y un
único puerto de salida que podrá ser conectado
a múltiples lugares posteriores. Si la transición
no tiene ningún puerto de entrada (es decir no
tiene lugares anteriores), se comportará como una
fuente periódica de marcas teniendo como perı́odo
el tiempo de disparo.
El modelo DEVS de la transición tiene las
siguientes caracterı́sticas:
el estado es s = (Sigma ∈ R+ , enabled ∈
bool, portsinit ∈ bool, dataBase ∈ N →
(N × N )) donde Sigma representa el tiempo
 AADECA 2010 - Semana del Control Automático - XXII◦ Congreso Argentino de Control Automático
31 de Agosto al 2 de Septiembre de 2010 - Buenos Aires, Argentina.
de avance y enabled indica cuando la tran-
sición está activada. La variable portsinit
indica si todos los lugares anteriores ya han
notificado cuantas marcas tienen y quienes
son estos lugares (a través del puntero). El
arreglo dataBase indica cuantas marcas tiene
cada lugar anterior y que peso tiene el arco
que lo conecta.
δint : Si la transición está activa (enabled =
true), se vuelve a verificar si todos los lugares
anteriores contienen las marcas suficientes
para el disparo. Esto debe realizarse ya que
otra transición pudo haber realizado un dis-
paro en ese instante quitando alguna marca
necesaria. Si todos los lugares anteriores
contienen la cantidad de marcas necesarias,
la transición se dispara quitando las marcas
correspondientes de los lugares anteriores.
Esto se realiza de manera no modular,
accediendo directamente al estado de los
lugares a través de los punteros recibidos
en los eventos. Luego, se hace Sigma = 0
produciendo un evento que notifica a los
lugares posteriores que deben agregar una
marca y además se notifica a los lugares
anteriores que se les han quitados marcas (a
través de una transición externa simulada.
Si en los lugares anteriores no habı́a
suficientes marcas para que la transición se
dispare, esta vuelve a desactivarse y tran-
siciona hacia un estado pasivo (enabled =
f alse; Sigma = ∞).
δext Cuando la transición recibe un mensaje
de un lugar, debe ver si todos los lugares
anteriores tienen la cantidad de marcas
necesarias para activarse. Si es ası́, y la
transición no estaba activa, la transición
se activa y espera su tiempo de disparo
(enabled = true; Sigma = time). Si la
transición ya estaba activa, sigue esperando
su tiempo de disparo tomando en cuenta el
tiempo ya transcurrido.
Se realizó también un modelo de una transición
especial que se dispara instantáneamente cuando
recibe un evento por su único puerto de entrada.
Esta transición tiene el fin de hacer de interfaz
entre partes del modelo que estén expresadas en
Redes de Petri y partes que estén expresadas
utilizando los bloques DEVS convencionales.
3.5 Librerı́a de PowerDEVS
Los tres modelos atómicos desarrollados fueron
incluidos en una nueva librerı́a de PowerDEVS
(Fig. 4) dando la posibilidad al usuario de modelar
Redes de Petri arrastrando y conectando bloques.
El bloque que representa el lugar posee los
siguientes parámetros:
Figura 4. Libreria de Redes de Petri de Power-
DEVS
tokens es un valor entero define la cantidad de
marcas iniciales del lugar.
time es un valor flotante que especifica el tiempo
de espera del lugar.
inputs permite cambiar la cantidad de puertos
de entrada (igual al número de transiciones
anteriores).
El bloque que representa la transición tiene los
siguientes parámetros:
time es un valor flotante que especifica el tiempo
de disparo de la transición.
inputs permite cambiar la cantidad de puertos
de entrada (igual al número de lugares anterio-
res).
Finalmente, la transición especial disparada por
eventos no tiene ningún parámetro ya que se
dispara instantáneamente frente a la recepción de
cualquier evento de entrada.
Al haberse mantenido la convención utilizada
por los bloques de la librerı́a de PowerDEVS en
los valores de los eventos emitidos, la salida de
los lugares y transiciones pueden conectarse a
cualquier otro bloque. Esto permitirá el modelado
hı́brido utilizando Redes de Petri, aproximaciones
de sistemas continuos, y bloques DEVS conven-
cionales dentro de un mismo modelo.
4. EJEMPLOS
En esta sección analizaremos dos ejemplos que
ilustran el uso de la librerı́a desarrollada.
4.1 Cola-Procesador
El modelo Cola-Procesador representa un sistema
en el cual un procesador recibe un trabajo, lo
ejecuta durante un lapso de tiempo y luego
está libre para recibir otro trabajo. Se introduce
también una cola (o buffer), para recordar (o
encolar) los trabajos que surgen mientras el
procesador está ocupado. La Fig. 5 muestra el
modelo de la Red de Petri correspondiente usando
la librerı́a de PowerDEVS desarrollada.
En el estado inicial, el sistema tiene asignada
una marca en el lugar Processor Free indicando
 AADECA 2010 - Semana del Control Automático - XXII◦ Congreso Argentino de Control Automático
31 de Agosto al 2 de Septiembre de 2010 - Buenos Aires, Argentina.
Figura 5. Sistema Cola-Procesador
Figura 6. Evolución del sistema Cola-Procesador
que el procesador está desocupado, y por lo
tanto puede procesar un pedido. El resto de los
lugares (Buffer y Processor ) se encuentran sin
marcas. Además, Processor tiene un tiempo de
espera de dos unidades, representando el tiempo
de procesamiento.
Las transiciones, en tanto, son instantáneas (ti-
me=0), a excepción de la Transition1 que genera
los trabajos. Esta tiene un tiempo de disparo de
1,3.
En la Fig. 6 se puede ver la evolución de
la cantidad de trabajos en cola (lı́nea sólida
ascendente) y, graficados como eventos (lı́nea de
puntos), los avisos del procesador al terminar cada
trabajo y tomar otro.
En este ejemplo puede verse el uso conjunto de
Redes de Petri y diagramas de bloques continuos
e hı́brido, aprovechando las ventajas que los for-
malismos ofrecen para modelar cada subsistema.
4.2 Control Supervisor de un Robot
La Figura 7 muestra un modelo PowerDEVS
que consta de tres subsistemas. El de la derecha
representa la dinámica continua de un robot móvil
con ruedas y su sistema de control de posición. El
subsistema de la izquierda modela un sistema de
control de alto nivel que define las tareas que debe
realizar dicho robot. Finalmente, el subsistema
Figura 7. Modelo PowerDEVS del Robot y su
Control
Figura 8. Subsistema continuo de control de
posición
del centro calcula las señales de referencias para
la posición del robot en función de las tareas
correspondientes. Los restantes bloques calculan
la distancia hasta la referencia para determinar si
el robot llegó a destino.
El modelo del robot y su control de posición
fueron tomados de (Oriolo et al., 2002), siguiendo
el método de linealización por realimentación
dinámica. La Figura 8 muestra una parte de
este control modelado en PowerDEVS utilizando
bloques de la librerı́a de sistemas continuos.
Para el control de alto nivel, se consideró que
hay una mesa con objetos de dos clases en la
posición (0,0) y el robot debe tomarlos de a uno
y llevarlos a dos mesas (según el tipo de objeto)
en las posiciones (1,1) y (1,-1). Tras llevar un
objeto, debe volver al origen a buscar uno nuevo,
preferentemente alternando el tipo de objeto. La
Figura 9 muestra el modelo en Redes de Petri del
control de alto nivel.
El modelo completo se simuló considerando que
inicialmente hay cuatro paquetes de un tipo y dos
del otro en la mesa y que el robot está en el origen.
La Figura 10 muestra la evolución de la posición
del robot en el tiempo.
En este ejemplo puede verse el uso combinado
de las Redes de Petri y de los bloques continuos
e hı́bridos explotando las ventajas que ofrece
cada formalismo para el modelado de los distintos
sistemas.
 AADECA 2010 - Semana del Control Automático - XXII◦ Congreso Argentino de Control Automático
31 de Agosto al 2 de Septiembre de 2010 - Buenos Aires, Argentina.

sólo pueden graficarse resultados como los de la

Fig.6.
La nueva librerı́a (con varios ejemplos de apli-
cación) está incluida en la distribución de Po-
werDEVS. Su uso y distribución es libre (bajo
licencia GPL). Para más información https://
sourceforge.net/projects/powerdevs/.

REFERENCIAS
Bergero, F. and E. Kofman (2010). PowerDEVS.
A Tool for Hybrid System Modeling and Real
Time Simulation. Simulation: Transactions
of the Society for Modeling and Simulation
Figura 9. Control de Alto Nivel en PowerDEVS International. in Press.
Bonet, P., C.M. Llado, R. Puijaner and W.J.
Knottenbelt (2007). PIPE v2.5: A Petri Net
1.2 Tool for Performance Modelling. In: Proc. 23rd
1.0 Latin American Conference on Informatics
0.8 (CLEI 2007). San Jose, Costa Rica.
Byg, J., K.Y. Joergensen and J. Srba (2009).
Pos X

0.6

0.4
TAPAAL: Editor, simulator and verifier of
0.2
timed-arc Petri nets. In: Proceedings of the
0.0
7th International Symposium on Automated
−0.2
0 20 40 60 80 100 120 Technology for Verification and Analysis (AT-
VA’09). Macao, China. pp. 84–89.
1.5
Cassandras, C. and S. Lafortune (2008). Introduc-
1.0
tion to Discrete Event Systems. Second Edition.
0.5
Springer. New York.
Pos Y

0.0
−0.5
−1.0
−1.5
0 20 40 60 80 100
Tiempo (s)
Figura 10. Resultado de Simulación del Robot
5. CONCLUSIONES Y TRABAJO A FUTURO
Se desarrolló una nueva librerı́a para modelado y
simulación de Redes de Petri dentro del simulador
PowerDEVS, habiéndose resuelto los principales
problemas de incompatibilidad de los formalis-
mos. De esta forma, se logró una implementación
que, para el usuario, conserva la apariencia gráfica
de las Redes de Petri (esta caracterı́stica no habı́a
sido lograda nunca en simuladores basados en
DEVS).
Otra caracterı́stica saliente de la librerı́a es
que puede ser utilizada para realizar modelos
que combinen las Redes de Petri con otros
formalismos.
Mediante dos ejemplos de aplicación, se verificó el
funcionamiento de la librerı́a y se ilustró su uso
en casos hı́bridos de relativa complejidad.
Como trabajo futuro, queda pendiente desarrollar
alguna herramienta de visualización especı́fica
para mostrar la evolución de las Redes de Petri
modeladas en PowerDEVS, ya que actualmente
Cellier, F. E. and E. Kofman (2006). Continuous
System Simulation. Springer. New York.
Cohen, G. (2001). Análisis y Control de Sistemas
120
de Eventos Discretos: De Redes Temporizadas
al Álgebra. Cuadernos del Instituto de Ma-
temática Beppo Levi. FCEIA - Universidad
Nacional de Rosario.
Jacques, C. and G. Wainer (2002). Using the
CD++ DEVS Tookit to Develop Petri Nets.
In: Proceedings of the Summer Computer
Simulation Conference.
Mosterman, P., M. Otter and H. Elmqvist
(1998). Modeling petri nets as local constraint
equations for hybrid systems using modelica.
In: Proceedings of the Summer Computer
Simulation Conference. pp. 314–319.
Oriolo, G., A. De Luca and M. Vendittelli
(2002). WMR Control Via Dynamic Feedback
Linearization: Design, Implementation, and
Experimental Validation. IEEE Transactions
on Control Systems Technology 10(6), 835–852.
Wainer, G. (2002). CD++: a toolkit to develop
DEVS models. Software: Practice and Expe-
rience 32(13), 1261–1306.
Zdenk, M. S., M. Svádová and Z. Hanzálek
(2001). Matlab toolbox for petri nets. In:
22nd International Conference ICATPN 2001.
pp. 32–36.
Zeigler, B., T. G. Kim and H. Praehofer (2000).
Theory of Modeling and Simulation. Second
edition. Academic Press. New York.

View publication stats