Está en la página 1de 13

Proceedings de las JII 2005.

34º JAIIO. Rosario, Argentina. Agosto de 2005.

Modelado de Celdas de Producción Flexible con


Redes de Petri y Raise

Sergio Gallina Flavio Fama


Departamento de Electrónica Departamento de Electrónica
Facultad de Tecnología y Ciencias Aplicadas Facultad de Tecnología y Ciencias Aplicadas
Universidad Nacional de Catamarca Universidad Nacional de Catamarca
Maximio Victoria 55, 4700 Catamarca, Argentina Maximio Victoria 55, 4700 Catamarca, Argentina
sgallina@tecno.unca.edu.ar ffama@tecno.unca.edu.ar

Resumen – En este trabajo se presenta el modelado de una celda de producción flexible utilizando los
métodos formales orientados al modelo tal como Redes de Petri (RdP), y los métodos formales axiomáticos
como RAISE (Rigurous Approach to Industrial Software Engineering). La combinación de estos métodos
constituye una poderosa herramienta para el diseño y simulación de las celdas de producción flexible.
Existen situaciones en las que el modelado a través de las RdP clásicas no es suficiente. En estos casos la
industria utiliza frecuentemente las Redes de Petri Coloreadas aprovechando su mayor nivel de abstracción.
No obstante el propósito de nuestro trabajo es demostrar que no es la única solución al modelado. Para los
casos en que las RdP clásicas no alcanzan para la especificación del modelo, se pueden utilizar los métodos
formales axiomáticos como RAISE.
El trabajo se organiza en cuatro apartados. En el primero, se presenta una introducción describiendo las
celdas de manufactura y la necesidad de contar con herramientas que se adapten a las necesidades cambiantes
del mercado. En el segundo apartado se efectúan consideraciones de los principales métodos de especificación
para sistemas de tiempo real, en al apartado tres se presenta un caso de estudio el que se modela utilizando
RdP y RAISE. Finalmente en el cuarto apartado se exponen las conclusiones.
En el trabajo demostramos que es posible la combinación de ambas metodologías, complementándose y
aprovechando las ventajas que cada una de ellas ofrecen.

Palabras Clave – Redes de Petri, RAISE, Métodos Formales, Celdas de Producción Flexible Ingrese las
palabras clave, el número no debe ser superior a 5.

I. INTRODUCCIÓN
En los últimos años las industrias han tenido que adaptarse a las demandas cambiantes del
mercado. Ante este hecho los sistemas de producción deben ser lo suficientemente flexibles como para
poder dar satisfacción a la demanda de nuevos productos manteniendo calidad y competitividad en los
costos. Es así que nace en la industria el concepto de sistemas de manufactura flexible.
Los Sistemas de Manufactura Flexible, FMS según sus siglas en inglés (Flexible Manufacturing System),
se componen de una red de estaciones de trabajo generalmente con un alto grado de automatización,
integrado por máquinas enlazadas mediante un sistema de manejo de materiales automatizado operado por
un CNC (control numérico por computador). Como se ha descripto, se compone de varias máquinas

14
Proceedings de las JII 2005.
34º JAIIO. Rosario, Argentina. Agosto de 2005.

controladas por computador con la característica de poder realizar distintas operaciones debido a la
versatilidad de las máquinas-herramientas. [1]
Dentro de este contexto, una celda de producción flexible, FMC (Flexible Manufacturing Cell), es un
grupo de máquinas relacionadas que realizan un trabajo particular o un paso de un proceso de fabricación
más general, es decir producen una parte o producto.
La necesidad de contar con sistemas de producción que se adapten rápidamente a las demandas
(flexibilidad), obligo a desarrollar sistemas de organización y planificación igualmente flexibles.
Una forma de planificación de la producción, en donde se pueda modelar el comportamiento de un sistema
de producción flexible es mediante el uso de las Redes de Petri, que permiten modelar las distintas
alternativas que se puedan diseñar para lograr un manejo adecuado de los recursos y las máquinas para
adaptarlas a una demanda cambiante.
RAISE es un método formal que incluye un lenguaje de especificaciones de amplio espectro llamado RSL
(RAISE Specification Language) que a partir de especificaciones y por medio de decisiones de diseño,
permite llegar a un nivel que se puede traducir a código.
Este artículo se propone demostrar que las Redes de Petri y los métodos formales axiomáticos como
RAISE constituyen un complemento adecuado para el diseño y simulación de sistemas de producción
flexible, basándose en la capacidad gráfica del primer método y en la rigurosidad del formalismo
matemático para el segundo caso.

II. CONSIDERACIONES
La especificación es el proceso de describir un sistema y sus propiedades deseadas. Las
propiedades del sistema deben incluir: comportamiento funcional, comportamiento en el tiempo y
características de desempeño o estructura interna. La especificación es un dispositivo de comunicación útil
entre el consumidor y el diseñador, entre el diseñador y el implementador, y entre el implementador y el
probador. Sirve como un documento compañero del código fuente del sistema, pero con un alto nivel de
descripción [2].
La especificación formal se usa como un lenguaje con una sintaxis y semántica definidas
matemáticamente. Una forma en que la notación matemática puede ayudar a alcanzar éstas metas, es a
través del uso de tipos de datos matemáticos para modelar los datos en un sistema. Estos tipos de datos no
están orientados hacia la representación de las computadoras, pero obedecen a una rica colección de leyes
matemáticas que hacen posible razonar efectivamente, acerca de la forma en que un sistema será
especificado. Se usa la notación de predicado lógico para describir en forma abstracta el efecto de cada
operación de nuestro sistema, contrariamente a lo que nos permite razonar acerca de su comportamiento
[3].

15
Proceedings de las JII 2005.
34º JAIIO. Rosario, Argentina. Agosto de 2005.

Actualmente las metodologías de desarrollo para la mayoría de los sistemas utilizan grandes sistemas de
inspección (prueba) que, aunque eliminan gran cantidad de errores, pueden resultar insuficientes para las
áreas críticas del sistema desarrollado. Es allí en donde se ve la necesidad de utilizar métodos formales en
el desarrollo e implementación de los sistemas.
Podemos decir que los métodos formales tienen las siguientes ventajas:
 Aumentan la confianza en la validación de los requerimientos.
 Permiten definir que actividades implican mayor o menor esfuerzo, así como cuáles de éstos
aportarán mayores beneficios.
 Permiten visualizar qué métodos y herramientas se usarán por cuáles tareas.
En algunos casos complejos, se puede ver la necesidad de contar con un sistema seguro y que fuese en
tiempo real, resulta claro que de no contar con un sistema con las características antes mencionadas,.se
tendría una gran cantidad de problemas, la mayoría de ellos de graves consecuencias [4].
La especificación formal es una parte de una colección de técnicas más generales que son conocidos como
Métodos Formales. Todas estas están basadas en la representación y el análisis matemático del software.
Dentro de los métodos de formalización podemos distinguir diferentes enfoques, los cuales se grafican en
la Figura 1.

Figura 1
A. Métodos Formales basados en la propiedad (Axiomáticos)
En los métodos axiomáticos las operaciones son especificadas por sus equivalencias algebraicas a
menudo en términos de otras operaciones. Los axiomas son usados para especificar las propiedades del
sistema, pero están restringidas a ecuaciones. Lenguajes con la habilidad para definir especificaciones
algebraicamente incluyen Larch, LOTOS, y RAISE entre otros.

16
Proceedings de las JII 2005.
34º JAIIO. Rosario, Argentina. Agosto de 2005.

Todos los métodos de especificación, ya sean formales o no, tienen como objetivo realizar
especificaciones que tengan las siguientes propiedades: no ambigüedad, consistencia y completitud. Con
el uso de métodos axiomáticos es más probable que logremos estos propósitos. Por un lado, la sintaxis del
lenguaje permite interpretar de una sola forma la especificación, eliminando la ambigüedad que surge con
el uso de un lenguaje natural o de una notación gráfica que también puede ser interpretada de formas
distintas. Además, la potencia expresiva de la teoría de conjuntos y de la lógica permite representar de
forma clara los requisitos.
No podemos dejar de mencionar que uno de los inconvenientes de las especificaciones formales es que
son más difíciles de usar y de entender. Por estos motivos, el uso de especificaciones formales se ha
venido reservando a aplicaciones muy concretas del software, en las que la seguridad y fiabilidad sean un
componente fundamental.
El uso de una metodología formal (basado en principios matemáticos) permite el refinamiento progresivo
de una especificación abstracta en una especificación concreta usando reglas bien definidas. Esto lleva a la
posibilidad de generar programas automáticamente desde las especificaciones formales.

B. El método RAISE
RAISE es un acrónimo de Rigurous Approach to Industrial Software Engineering. Este fue el
nombre que se le dio a un lenguaje de especificación formal llamado RSL por “RAISE Specification
Lenguaje”. Este lenguaje tiene un método asociado llamado justamente RAISE. También se desarrollaron
herramientas de soporte a la metodología.
RSL es un lenguaje de amplio espectro que puede ser usado para formular tanto las especificaciones
iniciales abstractas como para expresar diseños de bajo nivel aceptable para la traducción al lenguaje de
programación [5]
El IIST (Internacional Institute of Software Technology) de la UNU (United Nations University) ha
desarrollado herramientas de verificación para el RSL. Estas herramientas, para plataformas Unix y PC
están disponibles gratuitamente en la WEB. [6].
Las herramientas fueron desarrolladas con aportes de investigadores argentinos como: Arístides Dasso y
Ana Funes de la Universidad Nacional de San Luis.
El proyecto LaCoS ESPIRIT (1990-1995) ha refinado la tecnología RAISE. Un importante aspecto del
proyecto es una serie de aplicaciones industriales de tiempo real [7].

17
Proceedings de las JII 2005.
34º JAIIO. Rosario, Argentina. Agosto de 2005.

B.1. Conceptos básicos de RSL


Es conveniente expresar algunos conceptos básicos del lenguaje RSL [7], lo que permitirá una
mejor comprensión de la propuesta efectuada en el presente trabajo.
Class : Una expresión de clase representa esencialmente un conjunto de modelos. Cada modelo asocia
una entidad con un identificador definido dentro de la expresión de clase. Ejemplo:
class
value i: int // define a i como un entero
axiom i = 1 ∨ i = 2 // asigna a i los valores 1 o 2
end
Scheme : Una expresión de clase con nombre se llama scheme. De esta forma, cada ocurrencia del
nombre, llamado instanciacion del esquema puede reemplazarse con la expresión de la clase. Ejemplo:
scheme S =
class
value i: int // define a i como un entero
axiom i = 1 ∨ i = 2 // asigna a i los valores 1 o 2
end
Ahora se podrán definir objetos como diferentes instancias de S
object
O1 = S, // instancia de S
O2 = S // instancia de S

Type: Colección de valores relacionados lógicamente. Algunos tipos vienen definidos por el lenguaje RSL
(a modo de ejemplo mencionamos: Nat: todos los numero naturales, Int: números enteros, Bool: variables
binarias). Además se pueden definir tipos propios. Ejemplo:
type
raw, // define a “raw” como una pieza
buffer = raw–set // define a buffer como un conjunto de piezas
Value: Declaración de valor. Ejemplo:
Value
put_buffer : raw x buffer  buffer // La function “put_buffer” se define como
// el producto cartesiano de “raw” por
// “buffer” y devuelve “buffer”. Se agrega una
// pieza al buffer de piezas.

18
Proceedings de las JII 2005.
34º JAIIO. Rosario, Argentina. Agosto de 2005.

Axiom: Los axiomas expresan propiedades de nombres de ‘values’. Para cada identificador de valor los
axiomas establecen exactamente que valor dentro de su tipo representa cada identificador. Ejemplo:
Axiom
forall r : raw, b : buffer • // Para todo par de elementos r (raw) y
put_buffer (r,b) ≡ b1 ∪ {r1} // b (buffer), agregar una pieza al buffer
// es la unión del buffer con la pieza.

C. Métodos Formales Basados En El Modelo


En una representación orientada al modelo, el sistema es especificado en términos de un modelo
de estado que se forma usando construcciones matemáticas tales como conjuntos y secuencias. Las
operaciones son definidas por modificaciones hechas al estado del sistema.
En este tipo de especificaciones las mismas representan un modelo del sistema, construido a partir de las
primitivas del lenguaje dentro de una determinada disciplina formal (grafos, conjuntos, etc.), como es el
caso de las Redes de Petri.
El modelado con Redes de Petri (figura 2) permite la representación grafica y simulación de situaciones
tales como: concurrencia, sincronización, paralelismo, secuencialidad, con el respaldo de un formalismo
matemático que permite una representación del estado de la red en una matriz de incidencia C = (cij)nxm
[8].

Figura 2: Red de Petri

C = Pos - Pre
C(pi , tj)  Pos(tj , pi) - Pre(pi , tj)
19
Proceedings de las JII 2005.
34º JAIIO. Rosario, Argentina. Agosto de 2005.

Considerando la red de la figura 2, ella puede ser definida algebraicamente de la siguiente manera
P = (p1, p2, p3, p4, p5, p6, p7, p8) (Lugares de la red)
T = (t1, t2, t3, t4, t5, t6) (Transiciones)
Matricialmente :

Matriz de pre condiciones Matriz de post condiciones


t1 t2 t3 t4 t5 t6 t1 t2 t3 t4 t5 t6
1 0 0 0 0 0 p1 0 0 0 0 0 0 p1
0 1 0 0 0 0 p2 1 0 0 0 0 0 p2
0 0 1 0 0 0 p3 0 1 0 0 0 0 p3
Pre(pi, tj) = 0 0 0 0 0 1 p4 Pos(pi, tj) = 0 0 1 0 0 0 p4
0 0 0 1 0 0 p5 1 0 0 0 0 0 p5
0 0 0 0 1 0 p6 0 0 0 1 0 0 p6
0 0 0 0 0 1 p7 0 0 0 0 1 0 p7
0 0 0 0 0 0 p8 0 0 0 0 0 1 p8

Matriz de incidencia
T
t2 t3 t4 t5 t6
1
-1 0 0 0 0 0 p1
1 -1 0 0 0 0 p2
0 1 -1 0 0 0 p3
C(pi, tj) =
0 0 1 0 0 0 p4
1 0 0 -1 0 0 p5
0 0 0 1 -1 0 p6
0 0 0 0 1 -1 p7
0 0 0 0 0 1 p8

Teniendo en cuenta los marcados y las secuencias de disparo, podemos asumir que una marcación Mn es
alcanzable desde una marcación M, toda vez que exista una secuencia S de transiciones disparadas que
llevan el marcado de M a Mn.
El de la alcanzabilidad es quizás el problema de análisis básico de las RdP, muchos otros problemas
pueden ser establecidos en términos de problemas de alcanzabilidad. Gracias a su formalismo matemático
podemos determinar a partir de una marcación inicial y una secuencia de disparo, si es posible llegar a una
marcación Mn, de la misma manera, podemos determinar que secuencia es necesaria para llegar a una
marcación Mn. [9].

20
Proceedings de las JII 2005.
34º JAIIO. Rosario, Argentina. Agosto de 2005.

III. CASO DE ESTUDIO


A. Presentación del modelo:
Supongamos el siguiente modelo que se expone en la figura 3, en donde una celda de producción
flexible esta conformada por dos maquinas (M1 y M2), una cinta transportadora y un sistema robotizado
de carga de materia prima. La celda produce una pieza terminada. La materia prima puede ser de dos tipos
diferente, llamémosla materia prima ‘A’ y materia prima ‘B’ que corresponde a piezas terminadas por la
máquina M1.

Figura N° 3: Celda de producción

B. Funcionamiento de la Celda de Producción Flexible.


El robot es el encargado de extraer materia prima e ingresarla a la máquina M1 o M2 según el tipo
de materia prima. Si el robot reconoce que la materia prima es del tipo ‘A’ la deber cargar en la maquina
M1 y se procesa secuencialmente primero en M1 y luego en M2 para quedar terminada. En cambio si el
robot reconoce a la materia prima como del tipo ‘B’, la carga en la maquina M2 y solo requiere de esta
maquina para quedar terminada.

Figura 4: Ruta de productos

21
Proceedings de las JII 2005.
34º JAIIO. Rosario, Argentina. Agosto de 2005.

En un FMS no hay rutas predefinidas para el movimiento de las materias primas en el sistema. Esta
propiedad asegura la flexibilidad y versatilidad del sistema de manufactura [10]. La ruta de los dos
productos que se producen se muestra en la figura 4.

Figura 5: Red de Petri del modelo

C. Modelado de la CPF con Redes de Petri:


El modelado con Red de Petri que se muestra en la figura 5, nos permite describir el
funcionamiento del modelo. Las maquinas en su fase inicial se encuentran disponibles (libres) y los
representamos con una marca en M1 Libre y en M2 Libre, simultáneamente el robot se encuentra
habilitado pudiendo tomar una pieza del repositorio de materia prima.
Esta red puede presentarse como un conjunto de tres subredes que modelan el funcionamiento de M1, M2
y el robot como se muestra en el agrupamiento de la figura 5.
Si la materia prima reconocida por el robot es del tipo ‘A’ será colocada en la maquina M1. Al cargar la
pieza la maquina se ocupa por lo que se quita la marca de M1 Libre y termina el proceso de carga

22
Proceedings de las JII 2005.
34º JAIIO. Rosario, Argentina. Agosto de 2005.

(comienzo del maquinado), la pieza es maquinada por M1 y se guarda en un buffer y de allí se transfiere al
repositorio de materia prima de la maquina M2.
Si la materia prima es del tipo ‘B’ el robot la carga en la maquina M2, y al terminar el maquinado la pieza
se descarga de la maquina como producto terminado.
Obsérvese que una vez que el robot carga una maquina, y esta comienza el maquinado, queda disponible
para la carga de la otra máquina. Con esta configuración, el robot carga alternativamente a M1 y M2.
Durante la descripción se ha mencionado situaciones que pueden ser resueltas de un modo satisfactorio
por las Redes de Petri, tales como:
• Secuencialidad: las tareas se realizan una después de otra carga – maquinado – terminado – descarga
• Paralelismo: Las dos maquina pueden funcionar simultáneamente
• Concurrencia: La carga de la pieza requiere que exista la materia prima, que el robot listo (disponible)
y maquina lista (libre)
Vemos claramente que las RdP son una herramienta gráfica apropiada para el diseño y simulación de una
celda de producción flexible.
Un aspecto que se debe tener en cuenta es la situación de conflicto que se presenta en la elección de la
pieza para que ingrese a la línea de maquinado, en la que el robot solo puede tomar una y debe colocarla
en la maquina que corresponda. Cuando existe el problema de compartir recursos como maquinas o robots
existen dos tipos de exclusión conocidos como exclusión mutua secuencial y exclusión mutua paralela
[11]. Esta situación aparece con mucha frecuencia en los ambientes de manufactura. En la figuras 6a y 6b
se representan estas situaciones.

Figura 6a Figura 6b

En la industria, generalmente el tratamiento de este tipo de situaciones se modelan utilizando las


Redes de Petri Coloreadas, en las que tanto las transiciones, lugares y arcos pueden contener funciones
que permiten agregar poder semántico al modelo [10], [12], [13], [14].

23
Proceedings de las JII 2005.
34º JAIIO. Rosario, Argentina. Agosto de 2005.

En el presente trabajo proponemos especificar el modelo de conflicto usando RAISE (Rigurous Approach
to Industrial Software Engineering)

D. Especificación del robot y el buffer de materia prima con RAISE:


En nuestro caso de estudio el robot debe decidir que materia prima seleccionar para hacer que el proceso
de carga sea interactivo. Para ello es necesario modelar el repositorio de materia prima (buffer)
conjuntamente con el funcionamiento del robot, para lo cual efectuamos las siguientes consideraciones:
• Las materias primas A y B, pueden ser agregadas y extraídas del Buffer
• Si se extrae materia prima “A” se coloca en M1, si es “B” se coloca en M2.
• Las maquinas procesan un producto por vez.
• El ordenamiento de las piezas es aleatorio
• El buffer tiene una capacidad limitada por lo que se considera como un set de recursos finitos
La siguiente es una especificación utilizando el lenguaje RSL desarrollado por la metodología RAISE.

scheme ROBOT_MANAGER =
class
type
raw , //definimos la materia prima como tipo abstracto
machine = {“M1”,”M2”}, //definimos la lista de maquinas
buffer = raw-set //definimos el buffer como una bolsa de materia
//prima
value
extract_buffer : buffer → buffer X raw //Función para extraer una pieza del buffer
put_buffer : raw X buffer → buffer, //Función para colocar una pieza del buffer
put_machine : raw X machine → machine, //Función para colocar una pieza en una maquina
release_machine : machine → machine X raw, //Función para extraer piezas de la maquina
empty_m : machine, //maquina vacía
empty_b : buffer, //buffer vacio

axiom
forall r: raw, b : buffer • //Ámbito de la function “extract_buffer”
extract_buffer (b) as (b1,r1) //Valor de la función con definición de
post r1 ∈ b ∧ b1 = b \ { r1} //post condiciones (situaciòn del buffer
pre b ≠ {}, //despues de extraer la pieza) y pre condiciones
put_buffer (r,b) ≡ b1 ∪ { r1}, // (que el buffer no este vacio).
empty_b ≡ {} //

forall r: raw, m : machine • // La function put_machine coloca una pieza en


put_machine (r,m) ≡ // la maquina M1 si es “A” o en M2 si es “B”. Si
if r = “A” ∧ m = “M1” then m ∧ ¢r² // las piezas no son “A” o “B”, la maquina queda
else if r = “B” ∧ m = “M2” then m ∧ ¢r² // vacia (function “empty_m”)
else empty_m //
end

24
Proceedings de las JII 2005.
34º JAIIO. Rosario, Argentina. Agosto de 2005.

pre m = ¢ ², // La pre condicion es que la maquina este vacia


// antes de ejecutar la funcion “put_machine”

get_machine (m) ≡ (tl m, hd m) // especificaciòn de la function “get_machine”


pre m ≠ ¢ ² // para quitar una pieza de una máquina.
post m = ¢ ²,
empty_m ≡ ¢ ²

end

En ROBOT _ MANAGER se definió a la materia prima como una lista de dos elementos (“A” y “B”), la
máquina como lista con dos elementos (“M1” y “M2”) y al buffer como una bolsa (“set”) de materias
primas (“raw”).
Tanto para el buffer como para las máquinas se modelaron las funciones de ingreso (“put_”), extracción
(“get_”) y dispositivos vacíos (“empty_”). A continuación se efectuó la especificación algebraica
(axiomas) para cada una de las situaciones teniendo en cuenta las consideraciones de funcionamiento.
Puede verse claramente que es posible el modelado de partes de una celda de producción flexible
utilizando los métodos formales algebraicos de los cuales aprovechamos su rigurosidad y poder de
especificación.
El código presentado constituye una “especificación inicial” que define el comportamiento del sistema
más que ocuparse de detalles de implementaciòn. A partir de esta se podrá refinar y obener una
especificación final que este lista para la traducción a código ejecutable.

IV. CONCLUSIONES
Las Redes de Petri constituyen una poderosa herramienta para la especificación de Sistemas de
Producción Flexible. Cuando el sistema se va haciendo cada vez más complejo debido a los
requerimientos se encuentran situaciones en los que modelar con las RdP clásicas se hace complicado. Se
mencionó que para resolver este problema frecuentemente se utilizan otros modelos de RdP avanzados
como las RdP coloreadas (CPN).
Si bien las CPN son una opción frecuentemente utilizada en la industria, la combinación de las RdP
clásicas con métodos de especificación formal algebraica constituye una opción a tener en cuenta. En
nuestro caso se utilizó RAISE que provee el lenguaje RSL de especificación y entendemos que esta
combinación mejora y simplifica la especificación del modelo.
La mejora deviene de la posibilidad de especificar rigurosamente con RAISE lo que con RdP clásicas no
fuera posible. La simplificación se demuestra en la utilización de RdP para simular el modelo y RAISE

25
Proceedings de las JII 2005.
34º JAIIO. Rosario, Argentina. Agosto de 2005.

para especificar el robot, de este modo el funcionamiento queda perfectamente definido y puede ser
traducido al programa que sirve para su operación de acuerdo a los requerimientos.
Una de las actividades que pueden ser desarrolladas a partir de la presente propuesta sería la de comparar
el esfuerzo necesario para especificar y modelar situaciones complejas, utilizando CPN y RAISE.

REFERENCIAS
[1]. Abdón Sánchez Sosa, Universidad Nacional de Colombia, 2000
[2]. Clarke, E. and Wing, J. .”Formal Methods”. State of the art and future directions. Carnegie Melon
University. 1997
[3]. Spivey, J. M. . “The Z notation. A reference manual”. Ed. Prentice-Hall. Oxford , England, 1998
[4]. Lynch, N. and Tuttle, M. “Hierarchical correctness proofs for distributed algorithms”. Technical
report, MIT Laboratory for Computer Science, Cambridge, MA. April, 1987
[5]. German Antonio Montejano, “Especificación Formal en RSL del Balanced Scorecard”, Tesis de
Maestría en Ingeniería de Software. San Luis, 2005.
[6]. www.iist.unu.edu
[7]. Chris George, P. Haff, K. Havelund,A. Haxthausen “The RAISE Specification Language” Prentice
Hall 1992
[8]. Reynaldo Chile Palomino, “Uma Abordagem para Modelagem, Análise e Controle de Sistemas de
Produção Utilizando Redes de Petri”, (Tesis de Maestría – www.eps.ufsc.br/sisserta/palomino). 1998
[9]. Flavio S. Fama, Sergio H. Gallina, “Uso De Las Redes De Petri Para La Planificación Y Control De
Un Proyecto De Software”, II Jornadas Universitarias de Ingeniería JUI, Septiembre, 2002.
[10]. Armis Zimmermann, “A Modeling Method for Flexible Manufacturing Systems base don Colored
Petri Nets”, Institut fur Technische Informatik, Technische Universit Aat Berlin, 1994.
[11]. Zhou, M., McDermott, K., Patel, P.A. “Petri Net Synthesis and Analysis of a Flexible Manufacturing
System Cell”. IEEE Trans. On Systems, Man, and Cybernetics. 1993
[12]. Kazuhiro Saitou, Samir Malpathk, “Robust design flexible manufacturing systems using colored petri
net and genetic algorithm”, Department of Mechanical Engineering, University of Michigan, 2000.
[13]. Tomaz Barros, Jorge de Figueiredo, “A fault tolerant colored petri net model for flexible
manufacturing systems”, Departamento de electrónica e sistemas, Universidad Nacional de Pernambuco,
November 1997.
[14]. L.A. Riascos, L.A. Moscazo, “Detection and Treatment of fault in manufacturing systems base don
Petri Nets”, Escola Politécnica da Universidade de Sao Paulo, Departamento de Ingeniaría Mecatronica e
de Sistemas Mecánicos, 1998.

26