FACULTAD DE INGENIERÍA ELÉCTRICA
ESPECIALIDAD AUTOMÁTICA
Título: Desarrollo de Modelos de Automatizaciones en
OPN de Instalaciones de Laboratorio.
Diplomantes: Ksenia Arias Granda
Yanexis Estrada Figueredo
Tutores: Dr. Israel Benítez Pina
Msc. Luisa Villafruela Loperena
Curso 2001 – 2002
" Año de los Héroes Prisioneros del Imperio "
FACULTAD DE INGENIERÍA ELÉCTRICA
ESPECIALIDAD AUTOMÁTICA
Ksenia Arias Granda
Yanexis Estrada Figueredo
Santiago de Cuba, Junio 2002
"Año de los Héroes Prisioneros del Imperio"
Resumen
RESUMEN
La comunidad científica y académica internacional está enfrascada en la búsqueda de métodos
formales para el modelado y diseño de sistemas de automatización que permitan garantizar la
calidad de las redes de automatización con PLC’s. Este trabajo presenta un estudio sobre
implementación de modelos de automatizaciones sobre redes de Petri (PN’s), en específico Redes
de Petri Ordinarias (OPN’s) y su traducción a programas en lenguajes de PLC’s IEC1131
compatibles.
Este trabajo tiene como objetivo desarrollar modelos en OPN de automatización de instalaciones
del laboratorio de control de procesos gobernadas por PLC’s, mediante el uso del Visual Object
Net utilizando la metodología de diseño de GHeNESys para en un futuro integrar la fase de diseño
al Sistema Docente de Automatización Industrial (SDAI) en desarrollo sobre estas instalaciones.
Se definen los pasos para implementar programas desde modelos validados. La metodología
propone el diseño, verificación y validación de automatizaciones con PLC’s con el objetivo de
orientar a los especialistas en la forma de lograr la evaluación de sus diseños desde la etapa inicial
mediante métodos formales en PN’s. Se dan sus bases teóricas y se crean los modelos en OPN de
las instalaciones del Panel Gaseoso (control de presión) y Panel de Control de Nivel del
Laboratorio de Control de Procesos, así como su programa traducido a lenguajes de PLC’s.
Los resultados obtenidos en este trabajo se utilizarán a partir del curso 2002-2003 en la asignatura
de Sistemas Automatizados de 5to año de Automática. Además, mediante los proyectos MES de
Laboratorios Virtuales y proyectos de colaboración internacional, se irán extendiendo estos
resultados al pre y postgrado del resto de las universidades cubanas e iberoamericanas que
participan en los mismos.
Summary
SUMMARY
The international scientific and academic community is work in the search of formal methods to
modeling and design of automation systems that allow to guarantee the quality in PLC’s
automation networks. This work presents a study on implementation of models of automations it
has more than enough Petri Nets (PN’s), in specific Ordinary Petri Nets (OPN’s) and its
translation to programs in PLC’s languages compatible IEC1131.
This work has as purpose to develop models in OPN of automation laboratory of process control
governed by PLC’s, by means of the use of the Visual Object Net using design methodology of
Ghenesys to integrate in a future the design phase to the Educational System of Industrial
Automation (SDAI) in development on these laboratories.
They are defined the steps to implement programs from validated models. The methodology
proposes the design, verification and validation of PLC’s automations with the purpose of guiding
the specialists in the form to obtain evaluations of theirs designs from the initial stage using
formal methods in PN’s. It include theoretical bases and the OPN models are given of the
laboratories of the Gassy Panel (control of pressure) and Panel of Level Control of Processes
Control Laboratory, as well as their program translated to PLC’s languages.
The results obtained in this work will be used starting from the course 2002-2003 in Automated
Systems subject in 5to course of Automatic. Also, by means of the MES projects of Virtual
Laboratories and international collaboration projects, these results will go extending to all courses
of the rest of the Cuban and Ibero-American universities that participate in this project.
Indice
INDICE
INTRODUCCIÓN ...........................................................................................................................................1
CAPÍTULO 1. MODELADO EN REDES DE PETRI PARA AUTOMATIZACIONES CON PLC’s ..............5
1.1 PN’s clásicas y su uso en modelado para automatizaciones con PLC’s. ................................................ 6
1.1.1 Propiedades de las PN’s. .................................................................................................................... 14
1.1.2 Métodos de análisis de las PN’s. ........................................................................................................ 16
1.1.3 Subclases de PN’s. .............................................................................................................................. 17
1.2 Red Jerárquica Extendida GHENeSys. .................................................................................................. 19
1.2.1 Metodología propuesta. ...................................................................................................................... 23
1.3 Metodología de implementación de los modelos formales en OPN a lenguajes de PLC’s IEC1131
compatibles y su reinterpretación, utilizando GHENeSys. ........................................................................... 24
1.3.1 Analogías entre GHENeSys y los lenguajes IEC1131 compatibles. ................................................... 26
CAPÍTULO 2. DISEÑO, VERIFICACIÓN Y VALIDACIÓN SOBRE GHENESYS. .................................33
2.1 Actualidad en diseño, verificación y validación de automatizaciones con PLC’s................................. 35
2.2 Diseño sobre GHENeSys......................................................................................................................... 38
2.3.1 Reglas de Reducción Simple. ............................................................................................................... 48
2.3.2 Teorema del Rango. ............................................................................................................................. 51
2.4 Validación sobre GHENeSys. ................................................................................................................. 56
2.4.1 Herramienta de diseño sobre GHENeSys e implementación automática. ........................................... 59
CAPÍTULO 3. APLICACIÓN DE LA METODOLOGÍA PRESENTADA EN LA AUTOMATIZACIÓN
DE DOS INSTALACIONES DE LABORATORIO........................................................................................61
3.1 Panel de nivel ......................................................................................................................................... 61
3.1.1 Funcionamiento de la instalación. ....................................................................................................... 62
3.1.2 Diseño del sistema de control del Panel de Nivel utilizando GHENeSys. ........................................... 63
Luego de la implementación se realiza la validación final del funcionamiento del sistema controlado con
ayuda de las facilidades que brinda el ISaGRAF 3.3 para esto. .................................................................. 74
3.2 Panel Gaseoso........................................................................................................................................ 74
3.2.1 Funcionamiento de la instalación. ....................................................................................................... 75
3.2.2 Diseño del sistema de control del Panel Gaseoso utilizando GHENeSys............................................ 76
3.3 Ventajas del método formal de diseño en OPN’s.................................................................................... 83
VALORACIÓN ECONÓMICA. .....................................................................................................................85
Indice
CONCLUSIONES .........................................................................................................................................88
RECOMENDACIONES.................................................................................................................................90
BIBLIOGRAFÍA ............................................................................................................................................91
ANEXOS........................................................................................................................................................94
Anexo 1. Modelo en Redes de Petri del Panel de Nivel. ............................................................................... 94
Anexo 2. Programación en FBD/LD y Simulación en ISaGRAF 3.3 del Panel de Nivel.............................. 97
Anexo 3. Modelo en Redes de Petri del Panel Gaseoso.............................................................................. 100
Anexo 4. Programación en FBD/LD y Simulación en ISaGRAF 3.3 del Panel Gaseoso. .......................... 101
Introducción
INTRODUCCIÓN
Desde los años 70’s hasta la fecha los Controladores Lógicos Programables (PLC’s) han sido los
dispositivos mayormente utilizados en la solución de problemas de automatización y control. Su
uso se extiende a soluciones muy diversas, que van desde máquinas herramientas hasta plantas
industriales, desde juguetes hasta el confort de hoteles y edificios, desde elevadores hasta
sistemas telefónicos, desde sistemas de seguridad crítica hasta sistemas de generación de
electricidad, entre otros.
Los PLC’s no son más que computadoras adaptadas al ambiente de control de procesos, los que
cuentan tanto con parte electrónica (hardware) como de programación (software). Estos
dispositivos se encargan de garantizar el comportamiento deseado de un proceso determinado,
utilizando para ello el conjunto de señales de entrada y salida asociadas a éste, así como del
programa elaborado para ello. Por lo anterior, se deduce que las aplicaciones con PLC’s
comprenden típicamente varias partes, tales como: el proceso a controlar (ej: una planta), el PLC,
conexiones entre el PLC y el entorno, el programa del PLC, conexiones entre el PLC y una PC
(opcional), etc. Por ello, una aplicación con PLC trabajará correctamente solo si todas las partes,
que están relacionadas entre sí, trabajan adecuadamente.
Por sus características y exigencias, este campo generó sus propios métodos de diseño y
lenguajes de programación, desarrollándose varios de estos últimos debido al rápido auge de los
PLC’s en los años 80’s. Con el objetivo de estandarizar estos lenguajes en 1993, la International
Electrotechnical Commission (IEC) presentó la norma IEC1131 creada basándose en la
experiencia de varios fabricantes líderes en esta rama, unificando de esta forma los esfuerzos de
fabricantes, investigadores e ingenieros que trabajan sobre esta línea. En la parte 3 de esta norma
(IEC1131-3) se define la sintaxis, y en menor parte, la semántica de cinco lenguajes de
programación, dos de ellos lenguajes de texto: Instruction List (IL) y Structured Text (ST), dos
gráficos: Ladder Diagram (LD) y Function Block Diagram (FBD), y uno estructurado:
Sequential Function Chart (SFC).
1
Introducción
Si asumimos que la parte del hardware está funcionalmente bien y garantiza la correcta
operación del controlador, entonces la aplicación con PLC estará determinada por el software
asociado a éste; es decir, por el programa de su algoritmo de control.
Al aumentar la complejidad de los sistemas de control, de las exigencias en cuanto a fiabilidad y
seguridad, así como los costos de éstos, los diseñadores se han visto en la necesidad de buscar
métodos de verificación y validación que aseguren el funcionamiento seguro y correcto de la
solución generada. Debido a ello, la programación de PLC’s que tradicionalmente se ha venido
realizando de forma directa, ha generado en los últimos años que estudiosos en esta rama,
orienten sus esfuerzos hacia la aplicación de métodos formales, ya utilizados con anterioridad en
la programación de computadoras, a este campo de la automática. Estando orientados éstos a los
lenguajes estándares ya mencionados, recogidos en la norma IEC1131-3.
Los métodos formales basan sus principios en el análisis y verificación del programa dado a
partir de la obtención de su modelo, estudiando tanto las propiedades funcionales como
estructurales de éste. La aplicación de estos métodos permite elevar la seguridad en la
concepción y aplicación del programa elaborado, la reducción de los tiempos de diseño e
implementación, así como la reusabilidad, generalidad y optimización
del algoritmo
desarrollado, entre otras ventajas, [Frey00.1] lo que hace muy atractiva su utilización.
Son sin dudas las Redes de Petri (PN’s) las de mayor aplicación en la descripción formal de
programas de PLC’s. Introducidas por Carl Adam Petri en 1962, las PN’s han tenido un
vertiginoso desarrollo desde esa fecha hasta nuestros días; constituyendo una herramienta tanto
gráfica como matemática. Resultando una opción útil para describir y estudiar sistemas que
se caracterizan por ser concurrentes, asincrónicos, distribuidos, paralelos, no determinísticos y/o
estocásticos.
2
Introducción
En el contexto de la programación de PLC’s, las PN’s poseen muchas ventajas sobre otras formas
de descripción formales, al facilitar una modelación sencilla e intuitiva, siendo generalmente los
modelos de PN’s más compactos y poderosos. En la actualidad se han desarrollado muchas
modificaciones y extensiones aplicadas a este campo, encontrándose además, un gran número de
herramientas asistidas por computadora disponibles, las que permiten la edición, simulación y
análisis de ellas. Dentro de las PN’s estudiadas, la red extendida GHENeSys [Glez&Silva01] ha
demostrado ser la más adecuada para nuestros intereses.
La utilización de las PN’s como método formal para la verificación de programas de PLC’s es
poco conocido en nuestro país, y debido a las ventajas citadas anteriormente resulta conveniente
su uso. El propósito que persigue el presente trabajo es desarrollar los modelos en PN’s,
particularizando en el procedimiento propuesto por el grupo que investiga este tema, fruto de la
colaboración Universidad de Oriente - Universidad de Sao Paulo, el que utiliza la red extendida
GHENeSys como vía de representación. Escogiendo para nuestro análisis las instalaciones del
Laboratorio de Control de Procesos, Panel de Nivel y Panel Gaseoso. Estos modelos servirán de
base para las clases prácticas y laboratorios de este tema en la asignatura Sistemas
Automatizados en 5to año de Automática que comienza su impartición en Septiembre de este
año.
El trabajo se encuentra organizado en tres capítulos. En el primero de ellos se presenta la base
teórica en la que se sustentan las Redes de Petri; se mencionan sus propiedades, así como las
clases en que se subdividen éstas. Se trata además el tema de la utilización en la representación
de la red jerárquica extendida GHENeSys, planteándose la metodología de implementación de
los modelos formales en OPN’s a lenguajes de PLC’s IEC1131 compatibles y su
reinterpretación.
En el segundo capítulo se trata el Diseño, Verificación y Validación sobre GHENeSys, dando
primeramente una panorámica sobre trabajos actuales relacionados con el tema. Se exponen los
3
Introducción
pasos de la metodología, presentando ejemplos de aplicación de métodos de validación y
verificación según sea el caso.
En el tercer capítulo se enfatiza en la aplicación de la metodología planteada a las instalaciones
de laboratorio, se presentan las características, así como la operación de ambos paneles. Se
obtiene el modelo de las subredes, su simulación en el Visual Object Net (VON), así como el
programa para su implementación traducido a lenguajes de PLC’s según la norma IEC1131.
Estos modelos se integran a la etapa de diseño de un SDAI que se encuentra en desarrollo con el
apoyo del proyecto MES de Laboratorios Virtuales y otros proyectos de colaboración
internacional con la USP (Brasil) y la UPC (Barcelona, España). En este último caso un proyecto
del Centro de Cooperación para el desarrollo (CCD) de la UPC.
4
Capítulo 1. Modelado en Redes de Petri para automatizaciones con PLCs
CAPÍTULO 1. MODELADO EN REDES DE PETRI PARA
AUTOMATIZACIONES CON PLC’s
Los PLC’s constituyen los dispositivos de automatización industrial de mayor uso en el mercado
internacional. Estudios recientes arrojan que el 74 % de los usuarios del mercado de
automatización utilizan redes de automatización con PLC’s, y los usos específicos son: 87 % en
control de máquinas, 58 % en control de procesos, 40 % en control de movimiento, 26 % en
control de sistemas batch, 18 % en diagnóstico y un 3 % en otros tipos de usos.
Se han desarrollado varias etapas de normalización de sus lenguajes de programación, hasta llegar
a la mundialmente aceptada IEC1131-3. Sin embargo, el diseño de los sistemas de automatización
con dichos equipos tradicionalmente ha seguido métodos intuitivos basados en la experiencia del
programador.
El desarrollo de las potencialidades de estos dispositivos, el incremento de la complejidad de las
aplicaciones, la necesidad de reducir el tiempo de desarrollo, y de mayores niveles de seguridad y
optimización de las automatizaciones con ellos, ha generado la necesidad de aplicar métodos
formales en el diseño de estos sistemas.
Las ventajas de los métodos formales en el proceso de diseño son por ejemplo, la facilidad para
análisis y reutilización, la repetitibidad, la facilidad para proceder al análisis de sistemas de gran
tamaño, la precisión del proceso de modelado, la facilidad de documentación. Todo esto justifica
la obtención de nuevos métodos que tornen más rápido y seguro este proceso, pero sin descuidar
el contenido formal. En este campo, las Redes de Petri (PN’s) y sus extensiones, han sido la
representación/formalismo que más ha avanzado en este sentido por su dualidad matemáticográfica, su aplicabilidad, expresividad, y una cierta adherencia a los métodos de diseño
convencionales como el Top-down o el Bottom-up.
5
Capítulo 1. Modelado en Redes de Petri para automatizaciones con PLCs
En la actualidad hay varios trabajos que demuestran que la comunidad científica internacional
trabaja en esta dirección. En todos ellos se plantea la difícil representación con la teoría de control
tradicional de los Sistemas de Eventos Discretos (DES) donde aparecen concurrencias, conflictos,
no-determinismos, para lo que las PN’s constituyen un arma efectiva. Estas proveen métodos de
validación y verificación que garantizan la calidad de los sistemas de control antes de su
implementación.
Por todo lo anterior consideramos de gran importancia el conocimiento de los métodos más
efectivos en este sentido y el desarrollo de una metodología aplicable al mayor número de
automatizaciones con PLC’s en cualquier sector económico. Para ello veremos algunos conceptos
básicos de las PN’s y concluir con una propuesta de metodología general para incorporar esta al
desarrollo de los modelos de nuestras instalaciones de laboratorio .
1.1 PN’s clásicas y su uso en modelado para automatizaciones con PLC’s.
Red de Petri (PN) es un término agrupador, que en el transcurso del tiempo ha venido a
designar un amplio número de modelos de sistemas, procedimientos, técnicas y patrones
descriptivos relacionados unos con otros en el sentido de que están todos basados en el mismo
principio específico (Teoría de las Redes de Petri).
El principal atractivo radica en que permiten la identificación de los aspectos básicos de los
sistemas distribuidos tanto conceptual como matemáticamente. Tienen la dualidad de ser una
herramienta de modelado matemática y gráfica aplicable a muchos sistemas, lo cual incluye
además, el atractivo de los sistemas visuales de simulación gráfica.
La principal clase de Red de Petri es la llamada Sistema de Red Elemental (EN Systems =
Elementary Net Systems). Una EN Systems es, dentro de la Teoría de Redes (Net Theory) aplicada
a procesos y sistemas distribuidos, un modelo simple de sistemas distribuidos.
6
Capítulo 1. Modelado en Redes de Petri para automatizaciones con PLCs
Existen dos grandes grupos de PN’s: las redes clásicas, que incluyen los Sistemas
Condición/Evento (C/E-systems), las Redes Lugar/Transición (P/T-nets) y las extensiones
derivadas de ellas y las redes de alto nivel, que abarcan fundamentalmente las Redes
Predicado/Evento (P/E-nets), Redes coloridas y Redes relacionadas. Estos grupos se diferencian
fundamentalmente por la forma en que son marcadas las redes (cantidad de tokens).
El modelo de sistema C/E los elementos S son simplemente marcados o no marcados (sólo es
posible un token).
En el modelo de sistema P/T-nets, los elementos S pueden contener un cierto número de tokens
sin diferenciación.
En el modelo de sistema P/E-nets, los elementos S son marcados por objetos individuales (hay
diferenciación entre tipos de tokens).
Las aplicaciones de automatización con PLC’s abarcan principalmente el sector de las Redes
Clásicas, por lo que sólo abundaremos sobre éstas. Todas las redes clásicas tienen, como
estructura básica, una red elemental (EN).
Un Sistema de Red Elemental (EN-system) es una cuádrupla N = (B,E;F,Cin) donde (B,E;F) es
una red llamada Red Subyacente (Underling Net) de N, und(N) y Cin ⊆ B es llamado caso
inicial (initial case) of N, inc(N) [Thiagarajan86].
Se mantiene igual terminología que en teoría de redes para la und(N):
Bn es el conjunto de condiciones de N.
En es el conjunto de eventos de N.
Fn es el conjunto de relaciones de flujo de N.
Xn es el conjunto de elementos de N.
7
Capítulo 1. Modelado en Redes de Petri para automatizaciones con PLCs
Esta EN-system como modelo abstracto de un sistema distribuido tiene dos partes:
N = (B, E, F, Cin)
\____/ \__/
Estructura Comportamiento
Estática
Dinámico
La notación gráfica de una EN-system, es la notación gráfica de la und(N) a la que se adiciona el
marcaje de Cin representado por las marcas o puntos (tokens) en los estados. La notación gráfica
de la und(N) responde a un gráfico bipartito, direccionado, ordenado y no vacío sin nodos
aislados, donde B y E (también llamados S y T) son los conjuntos de estados y transiciones de N
asociados a círculos y a cajas o cuadrados respectivamente, siendo F las relaciones de flujo en N
que son arcos con direcciones apropiadas.
Siguiendo la dinámica del marcaje se pueden encontrar los elementos que pertenecen al conjunto
de casos Cn (combinaciones de Bn) y pasos Un (combinaciones de En). De acuerdo a esto se
puede definir el espacio de estados del sistema y la clase completa de casos generadora del
mismo.
El modelo de sistema C/E [Reising82], muy utilizado, es esencialmente un EN-System que
satisface algunas restricciones adicionales. En éstas los elementos S son simplemente marcados o
no marcados (sólo es posible un token) y las reglas de disparos de las transiciones sólo obedecen a
la precondición de t(•t); o sea, el marcaje de los estados de entrada y la activación del evento
asociado a la transición. Un ejemplo a modelar con este sistema en automatizaciones con PLC’s
podría ser la atención a las botoneras locales de arranque y parada o el control de acciones
secuenciales binarias del proceso.
En el modelo P/T-net [Reising82], los elementos S (ahora llamados Lugares P) pueden contener
un cierto número de tokens sin diferenciación. Esto agrega a la dinámica anterior, el análisis de la
8
Capítulo 1. Modelado en Redes de Petri para automatizaciones con PLCs
capacidad de cada Lugar (K) y el peso asociado a los arcos (W). Por tanto, las reglas de disparo
de las transiciones también deben tener en cuenta la posibilidad de asimilación de tokens de los
lugares de destino (Postcondición de t; o sea, t•). Por ello, el movimiento de tokens en el disparo
de la transición queda determinado por el peso de los arcos que la interconectan a las entradas y a
las salidas. Un ejemplo clásico que también se presenta en automatizaciones con PLC’s es el de
compartir recursos, como el uso compartido de los sistemas de comunicación, de áreas de
almacenaje para diferentes líneas de producción, etc.
En los modelos de alto nivel (como el sistema llamado Predicate/Event nets), los elementos S
son marcados por objetos individuales (hay diferenciación entre tipos de tokens), lo cual aumenta
la potencialidad de la red pero modifica grandemente las reglas de comportamiento dinámico,
tornando más complejo su análisis y uso. Debido a esto no serán objeto de estudio en el presente
trabajo.
A partir de estos grandes tipos, hay extensiones y modificaciones que adecuan el modelo a
condiciones específicas de determinadas aplicaciones. Estos son los casos de las Redes
Temporizadas [Ajmone95, Murata89], Redes Interpretadas [David92, Frey00.2, Frey00.3], Redes
Extendidas [Murata89, Silva&Miyagi95], y otras más.
De aquí podemos resumir que de acuerdo a nuestros objetivos de trabajo con PLC’s, sólo los
modelos C/E y P/T nos interesan. Pero, ¿cuál de los dos es el más recomendable para el análisis
de éstas automatizaciones con PLC’s?. Además, ¿es necesario vincularlos a extensiones y/o
modificaciones específicas como las indicadas?.
Para responder estas preguntas tendremos en cuenta que los C/E-Systems pueden ser considerados
como un caso especial de P/T-Net con capacidades de Lugares y pesos de Arcos unitarios. Tienen
comportamientos similares, pero debe considerarse que un C/E-System está provisto de una clase
caso C, donde las P/T-Nets asumen sólo un marcaje inicial. También puede hacerse extensiva
9
Capítulo 1. Modelado en Redes de Petri para automatizaciones con PLCs
como una generalización de los C/E-Systems en las P/T-Nets, la situación de contacto en que una
transición t ∈ Tn falla porque un Lugar en t• (Postcondición) no tiene suficiente capacidad.
La posibilidad de tener en cuenta redes que consideren sólo las Precondiciones (denominadas
contact-free) y la transformación del complemento para eliminar la influencia de la Postcondición
en las reglas de disparo permite trabajar siempre con redes de capacidad infinita, con sólo las tres
reglas de transición o de disparo que se relacionan seguidamente [Murata89]:
‰
Una transición t se dice que está habilitada si cada lugar de entrada p de t está marcado con al
menos w(p,t) tokens, donde w(p,t) es el peso de los arcos desde p a t.
‰
Una transición habilitada puede o no dispararse (si los eventos de que depende tienen o no,
lugar en ese momento).
‰
Un disparo de una transición habilitada t quita w(p,t) tokens de cada lugar de entrada p de t, y
adiciona w(p,t) tokens a cada lugar de salida p de t, donde w(p,t) es el peso de los arcos desde
t a p.
De acuerdo a todo lo anterior, trabajaremos las PN’s clásicas como todo un conjunto referido en
P/T-nets, pero particularizaremos más en las Redes de Petri Ordinarias (OPN), que tienen la
restricción de que el peso de los arcos que la forman es igual a 1 [Murata89].
Utilizando la notación básica formal, podemos definir una red Lugar/Transición (P/T-net)
[Bernardinello92] como una séxtupla ∑ = (S,T, F, K,W, M0), donde:
i)
S ∩ T = ∅.
ii)
S ∪ T ≠ ∅.
iii)
F ⊆ (SxT) ∪ (TxS).
iv)
dom(F) ∪ cod(F) = S ∪ T.
v)
K: S → N+ ∪ {∞} es una función de capacidad.
vi)
W: F → N+ es una función de peso.
10
Capítulo 1. Modelado en Redes de Petri para automatizaciones con PLCs
vii)
M0: S → N es una marcación inicial que satisface: ∀s∈S: M0(s) ≤ K(s).
Dada una red Lugar/Transición ∑, tenemos que:
La aplicación M: L → N+ es llamada una marcación en ∑ si se cumple M(s) ≤ K(s) para todo
s∈S.
Sea M una marcación en ∑, podemos decir que una transición t ∈ T está habilitada si se cumple
que: ∀s ∈ S : W(s,t) ≤ M(s) ≤ K(s) – W(t,s)
Una marcación M que habilita t lleva a una marcación M’ disparando t, donde:
M’(s) = M(s) – W(s,t) + W(t,s) ; ∀s ∈ S, ∀(s,t) ∈ F, ∀(t,s) ∈ F
La ocurrencia de t lleva de una marcación M a M’, y es representado como M[t>M’.
Se denota por R(M) como el menor conjunto de las marcaciones de ∑ alcanzables a partir de M,
tal que:
1. M ∈ R(M) y
2. Si M1 ∈ R(M)
y para algún
t ∈ T, M1[a>M2] entonces M2 ∈ R(M)
Ahora podemos definir a una P/T-net como de libre contacto (contact-free) [Reising89], si para
todo M ∈ [Mn> y para todo t ∈ Tn:
Si ∀ s ∈ •t: M(s) > Wn(s,t) entonces
∀s ∈ t• : M(s) < Kn(s) – Wn(t,s)
Esto no es más que el marcaje en cada lugar de entrada debe ser mayor que el peso del arco de
salida hacia la transición, pero en la salida el marcaje debe ser menor que la capacidad permitida
menos el peso del arco de entrada desde la transición.
11
Capítulo 1. Modelado en Redes de Petri para automatizaciones con PLCs
El comportamiento dinámico de muchos de los sistemas estudiados por la ingeniería pueden ser
descritos usando ecuaciones diferenciales. En el caso de las Redes de Petri este comportamiento
dinámico es regido por su ecuación de estado. Una parte fundamental de esta ecuación de estado
es lo que se denomina como matriz de incidencia.
Definición 2.10 Matriz de Incidencia [Desel&Esparza95]
La matriz de incidencia A:(SxT)→{-1,0,1} de N será definida por:
⎧ 0
⎪
N(s,t)= ⎨ 1
⎪ −1
⎩
(s,t) ∉ F y (t, s) ∉ F o (s,t) ∈ F y (t, s) ∈ F
(s,t) ∉ F y (t, s) ∈ F
(s,t) ∈ F y (t, s) ∉ F
Como base teórica para la definición de la matriz de incidencia es bueno tener en cuenta que
para cualquier Lugar S y cualquier Transición T arbitrarios de una red, ambos están relacionados
por una de las cuatro formas siguientes con respecto a la relación de flujo F [Desel&Esparza95]:
‰
(s,t) ∉ F y (t,s) ∉ F : Completamente no relacionados.
‰
(s,t) ∈ F y (t,s) ∉ F: t solo ocurre cuando S tiene al menos un token y al ocurrir reduce
tokens en S.
‰
(s,t) ∉ F y (t,s) ∈ F: t incrementa el número de tokens en S en uno (recuerden son solo
OPN).
‰
(s,t) ∈ F y (t,s) ∈ F: t solo ocurre cuando S tiene al menos un token pero al ocurrir no
cambia tokens en S.
Es importante observar que el cambio del número de tokens en S causado por la ocurrencia de t no
depende del marcaje existente en la red, sino que esta completamente determinado por la
estructura de la red.
12
Capítulo 1. Modelado en Redes de Petri para automatizaciones con PLCs
Para una PN con n transiciones y m lugares, la matriz de incidencia A = [aij] es una matriz de
enteros de orden n x m (transiciones x lugares). Esta matriz de incidencia representa la estructura
de la red y puede ser descrita de la forma siguiente[Murata89]:
A = [aij]
con aij = aij+ - aij-
donde:
aij+ =W(i,j)
es el peso del arco que va del lugar i a la transición j.
es el peso del arco que va de la transición j a el lugar i.
aij- =W(j,i)
aij representa el numero total de tokens removidos, adicionados y cambiados en el lugar j
cuando la transición i es disparada.
La ecuación de estado en una red está dada por la siguiente ecuación:
Mk+1 = Mk + AT Vk
para k = 1, 2, …
donde:
Mk estado actual, vector columna mx1 del marcaje inicial
Mk+1 estado siguiente es un vector columna mx1 del marcaje resultante
AT es la transpuesta de la matriz de incidencia A
Vk es un vector columna nx1, llamado vector de control o de habilitación que representa el késimo disparo (donde todos sus elementos son cero menos el de la posición indicada a la
transición que se dispara en ese k-ésimo disparo.
Si consideramos que un determinado marcaje de destino Md es alcanzable desde M0 a través de
la secuencia de disparo {v1, v2, …, vd}, podríamos expresar la ecuación de estado de la siguiente
forma:
d
Md = M 0 + A T ∑ Uk para k = 1, 2,...
k =1
la cual se puede reescribir como:
ΔM = A T Χ
13
Capítulo 1. Modelado en Redes de Petri para automatizaciones con PLCs
donde:
ΔM = Md - M0
y
d
X = ∑ Uk
k =1
siendo X un vector columna nx1 de enteros no-negativos llamado vector de conteo de disparos.
La entrada I-ésima de X denota el número de veces que la transición I debe dispararse para
transformar M0 en Md.
1.1.1 Propiedades de las PN’s.
En el análisis y diseño de modelos basados en PN’s se tienen en cuenta un conjunto de
propiedades [Murata89], pudiendo clasificarse éstas como:
•
Propiedades dependientes del marcaje, o propiedades funcionales (marking-dependent or
behavioral properties): Son aquellas propiedades dependientes del marcaje inicial y reflejan el
comportamiento dinámico del sistema.
•
Propiedades estructurales (structural properties): Son aquellas propiedades independientes
del marcaje inicial de la red.
Propiedades funcionales:
1. Alcanzabilidad (Reachability)
2. Limitación (Boundedness)
3. Vivacidad (Liveness)
4. Reversibilidad y Estado particular (Reversibility and Home State)
5. Cobertura (Coverability)
6. Persistencia (Persistence)
7. Distancia sincrónica (Sinchronic distance)
8. Disparabilidad (Fairness)
14
Capítulo 1. Modelado en Redes de Petri para automatizaciones con PLCs
Propiedades estructurales:
1. Vivacidad estructural (Structural Liveness)
2. Controlabilidad (Controllability)
3. Limitación estructural (Structural Boundedness)
4. Conservabilidad (Conservativeness)
5. Repetitividad (Repetitiviness)
6. Consistencia (Consistency)
7. Invariantes S y T (S- and T-Invariants)
8. Disparabilidad limitada estructural (Structural B-Fairness)
La definición de cada una de estas propiedades se sale de los marcos de este trabajo y pueden ser
encontradas en varios textos básicos sobre PN’s como el caso de [Murata89]. Por tanto, se
trabajará con algunas de ellas por su importancia en la rama.
En el análisis de modelos PN de sistemas de automatización es muy importante la propiedad de
Alcanzabilidad de estados, pues a partir de un estado inicial muchas veces se requiere que la red
avance automáticamente hasta un estado dado, si no tiene esta capacidad, no podrá ejecutar el
comportamiento deseado. A esto está relacionada la Vivacidad de la red, si generalizamos esta
capacidad a todo el sistema, y es aquí donde pueden detectarse partes de la red que detienen su
funcionamiento (como lazos cerrados, bloqueos, deadloock), lo cual nos permite eliminar estas
situaciones anormales en el programa del PLC desde esta etapa inicial de diseño.
Aquí entran a jugar su papel propiedades estructurales como la Vivacidad Estructural, la
capacidad de Repetitividad y la Controlabilidad de la red, porque la red además de ser viva
estructuralmente tiene que garantizar su Repetitividad, ya que el trabajo de todo sistema de
control es cíclico y más en el caso de los PLC’s, pero también debe garantizar que este
comportamiento no sea aleatorio, sino que sea controlable.
15
Capítulo 1. Modelado en Redes de Petri para automatizaciones con PLCs
Las Invariantes S y T están relacionados con partes de la red donde no hay cambio en la suma
compensada de tokens durante el disparo de sus transiciones o que son capaces de volver al
marcaje inicial de esa parte del sistema. Estos invariantes pueden ser beneficiosos o perjudiciales
según los objetivos del sistema, y por tanto, también deben ser analizados durante el diseño de la
red. Además, nos dan una herramienta matemática para el análisis de otras propiedades de la red.
También los sistemas de control no pueden tener un comportamiento ilimitado en la mayoría de
sus elementos por las propias limitaciones físicas del sistema, fundamentalmente capacidad de
almacenes o recursos compartidos. Por tanto, también debe vigilarse la propiedad de Limitación
estructural o funcional de la red.
1.1.2 Métodos de análisis de las PN’s.
Los métodos de análisis de las PN’s se pueden clasificar en tres grupos:
1. Método del árbol de cobertura o de Alcanzabilidad (Coverability or Reachability Tree
Method).
2. Método de acercamiento por ecuación matricial (Matrix-Equation Approach).
3. Método de técnicas de reducción o descomposición.
El primer método involucra esencialmente la enumeración de todos los marcajes alcanzables o sus
marcajes cubribles. Este es posible aplicarlo a toda clase de redes, pero está limitado a redes
“pequeñas” por su complejidad con la explosión espacial de estados para sistemas grandes
(inmenso número de lugares).
Los otros dos métodos son prácticos y potentes, pero en muchos casos, solo son aplicables a
subclases especiales de PN’s o situaciones especiales (tiene limitaciones). Para el análisis se
deben asumir, en primer lugar, sólo PN puras (sin autolazos) o transformadas a puras (agregando
16
Capítulo 1. Modelado en Redes de Petri para automatizaciones con PLCs
un par Lugar-Transición a cada autolazo) [Murata89] para admitir la definición de las ecuaciones
matriciales. En segundo lugar, en el análisis deben considerarse OPN’s (Lugares con capacidad
mayor o igual a 1, pero el peso de arcos es unitario).
El tercero de los métodos mencionados, el de las técnicas de reducción o descomposición
[Murata89, Bilinski94, Desel&Esparza95], es el utilizado en el desarrollo de este trabajo. Este
método facilita y simplifica el análisis de sistemas “grandes” al reducir estructuralmente el
modelo obtenido a una descripción más general, denominada subred o “macro”, la cual mantiene
las propiedades originales de la red que le dio origen. Las técnicas de transformación también
pueden ser utilizadas para la síntesis de un modelo abstracto a un modelo más refinado
jerárquicamente. Existen muchas técnicas de transformación para las PN’s, las que se utilizan para
analizar vivacidad, seguridad, y limitación mediante la comprobación de buena conformación de
la red [Desel&Esparza95].
1.1.3 Subclases de PN’s.
Dentro de las OPN, donde el peso de los arcos es unitario, se han definido subclases teniendo en
cuenta las particularidades de los conjuntos de entrada y salida de transiciones y eventos (•t, t•,
•p, p•), para definir restricciones en su estructura subyacente, las que resultan útiles cuando se
detallan las propiedades de las PN’s. Se asume que las PN’s no tienen lugares ni nodos aislados
(esto es que no existe t o p tal que •t = t• = φ, •p = p• = φ).
Se debe señalar que tanto la redes ordinarias como las no-ordinarias tienen la misma potencia de
modelado, solo se diferencian en la eficiencia y conveniencia del modelado. Veamos
seguidamente las clases de OPN que existen:
1. Máquina de Estados (State Machine SM): Es una OPN tal que cada transición t tiene
exactamente un lugar de entrada y exactamente uno de salida |•t| = |t•| = 1, ∀t ∈ T. Esta clase
17
Capítulo 1. Modelado en Redes de Petri para automatizaciones con PLCs
no admite sincronizaciones, por lo que puede modelar alternativas pero no paralelismo (Ver
Figura 1.1a).
2. Gráfico marcado (Marked Graph MG): Es una OPN tal que cada lugar p tiene exactamente
una transición de entrada y exactamente una de salida |•p| = |p•| = 1, ∀p ∈ P. Permiten
modelar sincronizaciones pero no alternativas (Ver Figura 1.1b).
3. Red libre-selección (Free-choice net FC): Es una OPN tal que todo arco desde un lugar es un
arco único o es un único arco de entrada a una transición, es decir:
Para todo p ∈ P, |p•| < 1
o
•(p•) = {p}
Para todo p1, p2 ∈ P, p1• ∩ p2• ≠ φ ⇒ |p1•| = |p2•| = 1
Admiten sincronización y conflictos separados, pero no la mezcla de ambos (confusión).
4. Red libre-selección extendida (Extended free-choice net EFC): Es una OPN tal que (Ver
Figura 1.1c):
Para todo p1, p2 ∈ P, p1• ∩ p2• ≠ φ ⇒ p1• = p2•
Si hay intersección de Postcondición esta es igual.
5. Red de selección asimétrica (Asymmetric choice net AC): También llamada Red Simple, es
una OPN tal que (Ver Figura 1.1d):
Para todo p1, p2 ∈ P, p1• ∩ p2• ≠ φ ⇒ p1• ⊆ p2• o p1• ⊇ p2•
Si hay intersección de Postcondición son iguales o subconjuntas.
Figura 1.1 Subclases de PNs
18
Capítulo 1. Modelado en Redes de Petri para automatizaciones con PLCs
En resumen proponemos utilizar P/T-nets lo más cercanas posibles a los menores tipos de OPN’s
(MG, SM, FC-nets). Para lo cual utilizaremos, más adelante, el concepto de subred dentro de las
Redes Jerárquicas para analizar el sistema modularmente, de forma que podamos acercarnos lo
mayor posible a esta propuesta. Esto será desarrollado sobre la base de la Red Jerárquica
GHENeSys [Glez01].
1.2 Red Jerárquica Extendida GHENeSys.
Las aplicaciones de automatización con PLC’s han evolucionado al diseño de sistemas complejos
con varios niveles de jerarquía, fuertes interacciones, compartición de recursos y sincronización
de actividades.
En el proceso de diseño de sistemas complejos e integrados, el grado de complejidad aumenta
proporcionalmente a diferentes factores: el tamaño del sistema, el volumen y complejidad de las
tareas, el grado de integración entre las partes que lo forman, etc. Este aumento de complejidad
dificulta el proceso de diseño de diversas formas: más difícil, más lento, mayores posibilidades de
error, lo que acaba por incidir en el costo del proyecto.
El uso de un diseño jerárquico es una de las vías de solución de esta complejidad. Este diseño
jerárquico no necesariamente coincide con la estructura de implementación, pero sí con la
distribución funcional del sistema. Se busca la estructura funcional con mayor independencia para
formar módulos integrados donde se modelan todas las funciones internas. Mientras que las
interacciones con el exterior solo se presentan en su nivel jerárquico superior.
La teoría clásica de redes no trata de forma adecuada el concepto de modularidad de sistemas
complejos, que difiere de la idea de simples elementos concurrentes y distribuidos.
19
Capítulo 1. Modelado en Redes de Petri para automatizaciones con PLCs
Algunas modificaciones fueron propuestas al formalismo original de Petri, utilizando elementos
de alto nivel para tratar el problema de la explosión de estados en grandes modelos y obtener una
representación mas compacta, como las redes Predicado/Evento y las Redes Coloridas
[Murata89]. Estos casos resuelven situaciones particulares, pero no proveen mecanismos
adecuados para la composición y jerarquización de módulos (subredes).
También otra aproximación a estas ideas aparece en [Esparza&Silva90] dentro del análisis TopDown para síntesis de redes, donde se define una regla de refinamiento para L&B FC-nets, el
Macroplace, que sustituye una subred SM por un Lugar. Por su parte se habla de modularidad y
composicionalidad de PN refiriéndose a la sustitución de Lugares y Transiciones por subredes y
viceversa.
Una propuesta en este sentido fue presentada en un contexto más cercano a sistemas distribuidos
de control en la contribución de la red GHENeSys (General Hierarchical Enhanced Net System)
[Silva&Miyagi95, Ramos&Silva99] que incluye el uso de módulos de subredes denominadas
Integrons. Esta modularidad no limita la utilización de las OPN’s en los esquemas resultantes,
pero simplifica grandemente el trabajo con ellas resolviendo la explosión de estados.
Esto garantiza una solución equivalente tanto en el modelo como en el programa para aplicaciones
de sistemas de control distribuido, pero garantizando también en el modelo y el programa, cumplir
con la simplicidad interna de los submódulos integrantes. Esto es debido a que los módulos
resultantes agrupados en Integrons en el modelo, pueden ser tratados como OPN’s y en el
programa estos mismos submódulos constituyen pasos del programa SFC que pueden ser tratados
al nivel de programas en el propio SFC, o en IL, LD o ST de acuerdo a la experiencia del
programador. Por tanto, es necesario definir formalmente esta nueva red.
20
Capítulo 1. Modelado en Redes de Petri para automatizaciones con PLCs
La red GHENeSys puede ser definida como una séxtupla N=(L, A, F, K, M, Π) [Glez01] donde:
i)
L∩A = ∅
ii)
L∪A ≠ ∅
iii)
F ⊆ (LxA) ∪ (AxL)
iv)
B∪P = L
v)
K: B → N+∪{∞} para todo p∈P, K(p) = 1
vi)
M: L → N+ siendo: M(l) ≤ K(l) para todo l∈L
vii)
Π: (B∪A) → {0,1}
Los elementos del conjunto L son llamados lugares y según el item (iv), está compuesto por la
unión de los conjuntos B y P (Boxes y Pseudoboxes respectivamente). Los elementos del conjunto
A son llamados actividades. F es la relación de flujo y sus elementos son llamados arcos. K es la
función capacidad que indica la capacidad máxima permitida en cada box. M es la marcación
inicial de la red respetando las capacidades de cada lugar. Π es una función que identifica los
Macroelementos dentro de la red.
Los elementos del conjunto L tienen funciones diferentes en la ecuación de estado de la red. Los
elementos del subconjunto P representan lugares con marcación persistente y esto es considerado
en la ecuación de estado que trataremos más adelante.
Teniendo en consideración el item (iv) podemos reescribir el item (iii) de la siguiente forma:
F ⊆ (BxA) ∪ (AxB) ∪ (PxA) ∪ (AxP)
Los dos primeros términos representan los arcos que conectan los boxes con las actividades. A
través de estos arcos, las marcas “fluyen” entre los elementos de los conjuntos B y A siguiendo la
regla de disparo de la red. El tercer término representa la conexión de los Pseudoboxes con las
Actividades. Estas conexiones pueden ser de dos tipos: habilitadora (arcos de test) o
deshabilitadora (arcos inhibidores).
21
Capítulo 1. Modelado en Redes de Petri para automatizaciones con PLCs
El último término carece de sentido práctico en nuestra red, por eso el mismo puede ser removido
quedando la relación de flujo definida de la siguiente forma:
F ⊆ (BxA) ∪ (AxB) ∪ (PxA)
Siendo:
F=
⎧ − 1 para (BxA)
⎪ 1 para (AxB)
⎪
⎨
⎪ 1 para (PxA) siendo a habilitada
⎪⎩ − 1 para (PxA) siendo a inhabilita da
En principio, los elementos del conjunto P representan eventos no controlables o información
externa a la red en cuestión, pero nada impide que este elemento pertenezca al conjunto B de otra
red. La utilidad del Pseudobox es modelar la transmisión de información entre diferentes partes de
un mismo sistema (dependencia funcional), así como la influencia de la información externa.
En la red GHENeSys, así como en general en las OPN’s, un nuevo estado depende del estado en
que la red está y de las transiciones (actividades de la red) habilitadas en ese momento. Podemos
decir que el estado de la red (marcación de los lugares que conforman la red) depende linealmente
del estado inicial (marcación inicial) y de la secuencia en que fueron ejecutadas las transiciones
una vez habilitadas.
Como en la matriz de incidencia aparecen los Pseudoboxes, y estos son elementos con marcación
persistente, es necesario hacer una modificación en la ecuación de estado. Esta modificación
prevé el uso de una matriz D que es una matriz de orden (mxm), siendo m el número de lugares
de la red. Esta es una matriz diagonal, donde la diagonal principal corresponde al vector d, donde
di = 1 si li ∈ B y di = 0 si li ∈ P.
La ecuación de estado modificada es la siguiente:
M K +1 = M K + D ⋅ C ⋅ VK
22
Capítulo 1. Modelado en Redes de Petri para automatizaciones con PLCs
En el sentido de Jerarquía, definimos los elementos “macros” que son la base de la jerarquía en la
red GHENeSys, a los cuales llamamos Integrons. Estos elementos representan toda una subred.
Como la red es bipartita, los elementos “macros” pueden ser también de dos tipos: actividades o
lugares. Las macro actividades comienzan y terminan como actividades y los macro lugares
comienzan y terminan con lugares. De esa forma nuestra red puede ser constituida mezclando
elementos simples y macros permitiendo la representación en varios niveles de abstracción.
Estos elementos por definición, poseen una entrada y una salida. Si garantizamos que estos
elementos sean propios la red resultante será viva [Glez01]. Por tanto, si desarrollamos el modelo
jerárquico de nuestro sistema mediante esta red podemos utilizar todas las herramientas
disponibles para el análisis y diseño de OPN’s. De aquí que se proponga la metodología resumida
en el siguiente epígrafe.
1.2.1 Metodología propuesta.
Para la utilización de todo lo anterior en el proceso de diseño de sistemas de automatización con
PLC’s proponemos los siguientes pasos:
1. Estudio del sistema a controlar y los requerimientos funcionales del usuario.
2. Determinación de la mayor cantidad de unidades funcionales del sistema de control, sin
coincidir necesariamente con su futura implementación.
3. Definición de acciones internas e interdependencias de cada unidad funcional y el nivel
jerárquico en que deben estar de acuerdo a estas interdependencias y su función en el sistema
de control.
4. Utilización de un diseño Top-down para establecer un modelo jerárquico basado en Integrons
para cada unidad funcional, estableciendo una red GHENeSys para todo el modelo del sistema
de control.
5. Refinamiento Botton-up del modelo para detallar la estructura de cada subred del modelo,
buscando su representación en un tipo de OPN lo más sencilla posible. En casos que su
23
Capítulo 1. Modelado en Redes de Petri para automatizaciones con PLCs
simplificación sea imposible, y se requieran redes más complejas, se deben crear nuevas
subredes para atender solo a esa situación. Esto permite aplicar a la mayor parte del sistema
controlado métodos de diseño de modelos simples de OPN’s y las herramientas complejas
solo en pequeñas subredes.
6. Clasificación
de
cada
subred
y
determinación
de
sus
propiedades
funcionales
(fundamentalmente live y safe) y estructurales (fundamentalmente S- y T-Invariantes).
7. Aplicación del método de reglas de reducción simples para revisar la estructura de la red, y
lograr la mayor independencia entre selección y concurrencia de las ramas del modelo.
8. Reclasificación de cada subred modificada y redeterminación de sus propiedades, realizando
adecuaciones que permitan su cumplimiento.
9. Simulación del trabajo de cada subred y comprobación del cumplimiento de los requisitos
funcionales del usuario.
10. Reclasificación de cada subred modificada y redeterminación final de sus propiedades.
11. Estudio de las características particulares del equipamiento para su implementación y
modelado de la subred que realiza la sincronización de las comunicaciones.
12. Traducción del modelo a un programa SFC en todos los niveles, considerando el criterio del
usuario para seleccionar otro tipo de lenguajes (ST, IL, LD) para redes básicas.
1.3 Metodología de implementación de los modelos formales en OPN a lenguajes de PLC’s
IEC1131 compatibles y su reinterpretación, utilizando GHENeSys.
De acuerdo a toda la experiencia reunida por el estudio de muchos trabajos investigativos
relacionados con el tema. Consideramos que la mejor variante, para lograr un modelo sencillo
pero a la vez lo más completo en potencia de diseño, verificación y validación, permitiendo una
implementación y reinterpretación automática, es con el uso de las Redes Jerárquicas
Extendidas GHENeSys. Para ello utilizaremos la metodología descrita en el epígrafe anterior
hasta la obtención del modelo formal validado.
24
Capítulo 1. Modelado en Redes de Petri para automatizaciones con PLCs
Esto permite obtener un modelo jerárquico en varios niveles de toda la aplicación donde cada
nivel puede estar formado por tantas subredes como unidades funcionales (lo más pequeñas
posibles) tengan la suficiente independencia como para serlo. Esto garantiza una equivalencia con
la programación estructurada modular que propone la IEC1131 mediante los bloques funcionales
y subprogramas permitidos.
La restricción de que estas subredes sean propias (una entrada y una salida y todos los nodos
envueltos en caminos directos E/S) permite también subprogramas y bloques funcionales con
estas características.
La garantía de redes bien-formadas y vivas logran las estructuras requeridas para generar
automáticamente los bloques funcionales o programas libres de bloqueos, con autorrecuperación y
seguridad de funcionamiento. Para lo cual contribuyen los pasos de verificación ya efectuados.
También la validación ya realizada garantiza que el programa que se obtenga cumpla con los
requisitos funcionales demandados por el usuario, pues el modelo lo demostró. Pero además esta
en correspondencia con la solución generada a los problemas de estados prohibidos y cadenas
deseadas considerados durante todas las etapas del diseño formal hasta llegar al modelo validado
por simulación.
La concepción del diseño de cada subred integrando las estructuras típicas de Sistemas de
Eventos Discretos(DES) nos permitirá subdividir las estrategias de implementación o
reinterpretación de acuerdo a estas mismas estructuras que fueron utilizadas en el diseño. Esto nos
permitirá prever desde las primeras etapas del diseño las posibles estructuras del programa de
implementación.
Pero cada subred creada por el usuario es una nueva estructura que puede ser reutilizable, por
tanto puede ser almacenada en una biblioteca para la conformación de subredes más complejas.
De esta forma además de las estructuras típicas cada diseñador podrá ir adecuando su ambiente de
25
Capítulo 1. Modelado en Redes de Petri para automatizaciones con PLCs
trabajo para lograr la integración de subredes más complejas que ya tiene preelaboradas y
validadas para la conformación de su sistema.
De acuerdo a todo lo anterior explicaremos las bases mínimas de todo el sistema, o sea las reglas
generales de analogías entre los elementos de la red jerárquica extendida de GHENeSys y los
lenguajes de programación IEC1131 compatibles.
1.3.1 Analogías entre GHENeSys y los lenguajes IEC1131 compatibles.
Como se trabaja sobre una red GHENeSys que ya se explicó pertenece al tipo de las CrtlPN, no
pueden utilizarse las reglas establecidas por Frey [Frey98] para las SIPN, pero tampoco son
aplicables todas las analogías presentadas en el trabajo de Uzam [Uzam98 ] para su APN, por las
diferencias que existen. Por tanto se establecen nuevas analogías.
- Para los Boxes se mantiene su equivalencia a un bit interno (marca de bit o bandera) del PLC.
O sea, su estado 0 o 1 corresponderá con el estado de una variable binaria interna del PLC.
‰
Los Pseudoboxes corresponderán con diferentes tipos de señales según su uso:
Si representa mediciones desde sensores del proceso corresponderán con entradas del PLC
(lo que según la IEC1131 pueden utilizar un identificador simple o el direccionado directo del
PLC).
‰
Si representa informaciones que vienen desde otras subredes u otras partes de la propia red
corresponderán con variables binarias internas (bits internos o banderas) del PLC (lo que
según la IEC1131 también pueden utilizar un identificador simple o su direccionado directo).
‰
Si representa el bit de salida de un temporizador o contador corresponderán con variables
representadas por el identificador del temporizador o contador seguido de “.Q” como
indica la IEC1131.
26
Capítulo 1. Modelado en Redes de Petri para automatizaciones con PLCs
‰
Si representa la salida binaria de algún bloque funcional tendrán el nombre del bloque
funcional seguido de “.nombre de la salida del bloque” como reglamenta a IEC1131-3.
Los Boxes y Pseudoboxes dan las condiciones de disparo de las transiciones del modelo en
GHENeSys, por tanto corresponden con la parte condicional de las secciones de programas
resultantes de cualquier sección del programa.
Las operaciones lógicas entre estas señales estarán en dependencia de la estructura que las
entrelazan con la o las transiciones que le suceden. Es decir si todas entran a una sola transición
conforman una operación lógica AND. Si llegan a varias transiciones que después se unen en un
solo Lugar se traducen en una función lógica OR. Combinaciones de estas estructuras darían
también combinaciones de esas operaciones lógicas en el programa resultante.
La traducción de esta parte condicional a lenguajes LD e IL esta prácticamente implícita en la
definición de los lenguajes IEC1131 compatibles. En LD son contactos en serie o paralelo (ya
sea AND u OR respectivamente). En lenguaje IL serían precisamente instrucciones que
representan estas funciones binarias. En el caso de traducción a lenguaje ST estas condicionales se
convierten en las expresiones condicionantes de alternativas IF.
Consideramos que estas PN’s a traducir serán FC (contact-free), o sino deben ser transformadas a
contact-free utilizando la transformación del complemento antes de su traducción. Por tanto
eliminamos la necesidad de incorporar a las traducciones la parte del chequeo de los estados de
los Lugares de salida de las transiciones propuesta por Frey [Frey00]. Lo que también favorece el
proceso inverso de reinterpretación.
El resultado del disparo de una transición conformaría la parte de acción que sigue a toda parte
condicional de una red de programación elemental en cualquier lenguaje de PLC’s (ejemplo IL,
LD). Pero esa acción obligatoriamente implica el reseteo de todos los bits internos asociados a
los lugares de entrada y el seteo de los bits internos asociados a los lugares de salida. Esto
27
Capítulo 1. Modelado en Redes de Petri para automatizaciones con PLCs
corresponde con una técnica también empleada en programación directa de PLC’s que consiste en
representar mediante banderas (bits internos o marcas) el estado de activación de la secuencia del
programa para luego poder utilizarlas en cualquier otra parte del programa que requiera sensar
este estado, o para saltos u otras acciones auxiliares. Esto puede extender algo mas el programa
resultante (sobre todo en IL) pero daría mas seguridad a la aplicación. No obstante puede tomarse
la convención de que el usuario asigne sobre el modelo las variables a los Lugares y la traducción
solo utilizaría nuevos bits internos si ese estado no tiene asignada ninguna otra variable y de esta
forma se evita la redundancia de estados en la traducción automática del modelo a el programa.
Luego esta parte de acción resultante de la traducción del disparo de esa transición será
aumentada con las acciones de impulso asociadas a la misma, es decir, el seteo o reseteo (según
sea 1 o –1 el valor de la función Q de asociación en la definición de GHENeSys) de las salidas al
proceso requeridas para ejecutar el cambio de estado que representa esta transición en el proceso
real.
Esta claro que en LD esta parte de acción son las representadas en bobinas de distintos tipos
(normal, negada, S, R). En IL conforma el conjunto de instrucciones de asignación, seteo y
reseteo. Para el lenguaje ST sería el cuerpo de la parte THEN de una alternativa IF.
Detrás de cada transición existe al menos un Lugar (solo Boxes). Como los Boxes pueden tener
acciones de nivel sobre salidas al proceso asociadas a su estado mediante la función Q, se
consultará por el estado del bit interno asociado a ese Lugar y luego se ejecutan las asignaciones
directas o negadas (según sea 1 o –1 el valor de la función Q de asociación) sobre las salidas hacia
el proceso.
Esta claro que todas estas salidas pueden estar nombradas por el direccionamiento directo en el
PLC o por un identificador que luego se asocia a esa dirección como lo reglamenta la IEC1131.
28
Capítulo 1. Modelado en Redes de Petri para automatizaciones con PLCs
Para la traducción a lenguajes IL, LD y ST de la consulta por el bit interno del Lugar y luego las
acciones de nivel que tiene asociadas siguen las mismas reglas expresadas anteriormente para
cualquier condicional y acción.
Si estas acciones de asignación, seteo o reseteo se ejecutan sobre entradas de un bloque
temporizador, contador u otro bloque funcional cualquiera, el nombre de la variable entonces
corresponde con el identificador del bloque funcional seguido de “.nombre_de la_entrada”.
Pero cualquier tipo de bloque funcional no recibe solo entradas binarias, ni tiene solo salidas
binarias. Generalizando para cualquier bloque funcional, es necesario una etapa de carga de
señales de diversos tipos (a veces ninguna binaria), luego el procesamiento de estas señales, y al
final la transferencia de los resultados a las variables asociadas a las salidas del bloque (algunos
casos ninguna binaria). Para esto la IEC1131 da una solución normalizada a su inclusión en la
programación LD que es el uso de las entradas EN y ENO para la asociación de bloques
funcionales a estos diagramas de escalera.
Para nuestro modelo aprovecharemos esta regla tan común entre los programadores de PLC’s para
el tratamiento de señales analógicas dentro de una OPN. Lo cual mantiene la potencialidad
gráfico-analítica de las OPN para el proceso de verificación y validación sin afectar la
representatividad del modelo frente al proceso real, pero sin complicarlo.
Para ello también aprovechamos otro elemento del sistema GHENeSys fundamental para no
perder formalidad en este modelo, los Macroelementos. Las redes en GHENeSys permiten la
existencia de MacroLugares y MacroTransiciones, que significan subredes propias que se
representan en el modelo por un solo elemento de mayor tamaño, pero que implican la ejecución
de varias acciones que pueden ser complejas pero que no afectan la interrelación con los demás
elementos del modelo, aparte de las entradas y salidas de ese Macroelemento representadas en el
esquema.
29
Capítulo 1. Modelado en Redes de Petri para automatizaciones con PLCs
Por tanto cualquier bloque funcional podrá representarse por tres tipos de Macroelementos:
1. MacroLugar de entrada: Representa una subred que realiza la carga de todas las variables
del proceso a las señales de entrada al bloque funcional.
2. MacroLugar de salida: Representa una subred que realiza la transferencia de todas las
señales de salida del bloque funcional a las variables del proceso.
3. MacroTransición o MacroLugar de ejecución: Representa la subred que realiza la
ejecución de las operaciones internas del bloque funcional. Aquí hay dos tipos fundamentales
de operaciones normalizadas en todos los lenguajes de PLC’s IEC1131 compatibles: las
operaciones estándares por un lado y los bloques funcionales y funciones estándares por el
otro. En el primer caso estarán representados por MacroTransiciones y en el segundo por
MacroLugares, ya que en el segundo caso la complejidad es mayor al requerir la llamada al
bloque funcional o función y muchos de ellos necesitan de una transición resultante
generalmente activada por un bit de salida resultado de esa operación. Por ejemplo el bit de
salida de temporizadores.
Esto además de simplificar grandemente la representación de temporizadores y contadores en el
modelo en OPN (no es necesario utilizar transiciones temporizadas, ni peso de arcos como en las
APN de Uzam [Uzam98]), permite además realizar operaciones con bytes o words sobre modelos
con OPN, pues estas acciones quedan encapsuladas en las subredes de los Macroelementos y no
requieren ser modeladas al nivel de esta red.
O sea que en esta metodología no es requerido salir de las OPN’s para representar funciones de
temporización, conteo, ni analógicas como propone Uzam [Uzam98]. Tampoco es necesario
asociar operaciones lógicas entre señales a las transiciones como propone Frey [Frey00]
oscureciendo la representación gráfica y matemática del modelo.
Esta variante de modelado aprovecha la normalización aprobada en la IEC1131 para integrar
bloques funcionales y operaciones estándares a la programación LD, es decir el uso de las
entradas EN y salidas ENO si dicho bloque no dispone de entradas y salidas booleanas, lo que le
30
Capítulo 1. Modelado en Redes de Petri para automatizaciones con PLCs
da fuerte compatibilidad con dicha norma aprobada por todos los fabricantes y usuarios de PLC’s
desde 1993.
Además la metodología permite modelar el comportamiento de los tres tipos de temporizadores
(TON, TOF, TP) y los tres tipos de contadores (CU, CD y CUD) de dicha norma internacional.
El modelo de la aplicación no requiere de que sea anexada el modelado del comportamiento de
estos tipos de temporizadores y contadores (porque esta encapsulada en los Macroelementos), así
como de ningún otro tipo de bloque funcional, al igual que sucede con los programas en lenguajes
de PLC’s que solo programan entradas y salidas del bloque. Esto coincide con la metodología de
PLC’s que rige la IEC1131 en la cual el usuario no necesita actuar sobre la programación interna
del temporizador, contador o cualquier otro bloque funcional, sino anexar a su programa una
instanciación de este. De igual forma el modelo solo anexa una instanciación de este bloque
(Macroelemento) utilizando sus entradas y salidas, el resto es modelado interno propio del
ambiente de modelado o de programación.
En el caso que se utilice un ambiente de modelado estándar solo se requerirá esta anexión
(modelado interno del Macroelemento) para el caso que se desee una simulación automática
completa del funcionamiento de todo el sistema controlado, pero en este caso además de anexar
estos bloque deben anexarse los modelos que simulan el comportamiento del proceso a controlar
(igual que se realiza en los ambientes de programación IEC1131 compatibles). De esta forma el
modelo de la red a verificar es solo la que representa el programa de control (o sea el controlador)
y por tanto aquí es donde se aseguran las propiedades para tener un diseño eficiente y por tanto un
programa resultante también más eficiente que es el objetivo central de la introducción de los
métodos formales en la programación de PLC’s.
En todo bloque funcional que se representa en un modelo sobre GHENeSys se utilizan los
Pseudoboxes para condicionar el momento de disparo de la transición de salida del modelo del
bloque a la ejecución verdadera del resultado de la acción del bloque funcional (por ejemplo bit de
31
Capítulo 1. Modelado en Redes de Petri para automatizaciones con PLCs
salida de temporizadores y contadores). Cuando no hay bit de salida de la ejecución del bloque
esta transición se ejecuta automáticamente luego de activado el Macroelemento de ejecución
interna del bloque funcional.
De esta forma queda resuelto el gran problema de representar mediante OPN’s las operaciones no
binarias combinadas con binarias tan comunes en múltiples aplicaciones de PLC’s, sin necesidad
de utilizar redes coloridas u otro tipo de redes de alto nivel. Así mantenemos la potencialidad de
verificación gráfico-analítica del modelo sin dejar de representar cualquier aplicación sobre
PLC’s.
Además se mantiene una correspondencia mas directa entre la estructura de un programa IEC1131
compatible con su modelo en PN’s, pues los bloques funcionales están previstos desde la etapa de
diseño.
En el uso de GHENeSys se recomienda como principal, y siempre que lo permita la herramienta
de programación de PLC’s desarrollada por cada fabricante en particular (determinada por el
equipamiento escogido en la aplicación).
Por todo lo recogido anteriormente, se puede apreciar la posibilidad de utilización de modelos en
la red jerárquica extendida GHENeSys para el diseño, verificación y validación de
automatizaciones, que luego pueden ser implementadas en programación modular estructurada
compatible con la norma IEC1131.
32
Capítulo 2. Diseño, Verificación y Validación sobre Ghenesys
CAPÍTULO 2. DISEÑO, VERIFICACIÓN Y VALIDACIÓN SOBRE
GHENESYS.
En el proceso de diseño de sistemas de automatización con PLC’s, juegan un papel fundamental
la formalización, la verificación y la validación, por lo que es necesario tener en cuenta su
diferenciación.
La Formalización consiste en la creación de los modelos formales de las especificaciones
deseadas, del proceso no-controlado y del controlador resultante del diseño. Puede ser completa o
parcial en dependencia de si los tres elementos se formalizan o no, lo cual depende de la
metodología de diseño a seguir. Esta tiene gran importancia porque crea las bases para el estudio
formal del sistema, que lo resumen las dos etapas explicadas seguidamente.
Existen diferentes enfoques en el sentido de la formalización, uno de ellos es el caso de las reglas
Token Passing Marking (TPM) [Uzam98] para la formalización de especificaciones de control
dentro del diseño de supervisores de DES modelados en PN, que permiten comparar el modelo
controlado con los problemas de estados prohibidos y de cadenas deseadas, especificados para el
diseño en la Teoría de Autómatas de Wonham [Ramadge&Wonham89].
Verificación es la prueba de que la semántica interna del modelo es correcta independientemente
del sistema modelado. Las propiedades buscadas del modelo son: vivacidad, seguridad,
limitabilidad, alcanzabilidaa, etc. Estas son propiedades estándares, y por tanto, ya están
formalizadas, existiendo métodos gráficos (ej: análisis de RG o gráficos de alcanzabilidad,
técnicas de reducción o descomposición, etc.) y analíticos (ej: cálculo de invariantes S y T
mediante la matriz de incidencia, etc.).
Validación es la prueba que determina si el modelo concuerda con los propósitos del diseñador.
Investiga propiedades específicas del controlador, por lo que pueden o no estar formalizadas. Por
tanto, varía según el grado de formalización del método de diseño empleado.
33
Capítulo 2. Diseño, Verificación y Validación sobre Ghenesys
Los enfoques utilizados tanto en Validación como en Verificación se clasifican en los basados en
modelos (los que no los utilizan), y los que no utilizan modelos pero sí restricciones específicas
[Frey98, Frey00.1, Frey00.2, Mader00].
Los formalismos pueden ser PN, C/E-System, Autómata, Lógica de alto nivel, Lenguajes
sincrónicos, Sistemas de transición general y Ecuaciones algebraicas. Los métodos los clasifica
en: Simulación, Análisis de alcanzabilidad, Chequeo de modelo y Prueba de teoremas.
En este capítulo se proponen los enfoques basados en modelos que utilizan el formalismo de las
redes de Petri (PN) utilizando los métodos de chequeo gráfico y analítico de las propiedades del
modelo y la simulación. Las ventajas del formalismo PN ha sido tratado en muchos trabajos
[Holloway89, DiCesare93, Desrochers95, Uzam98]. Por tanto, solo nos concentraremos en los
métodos cuyos detalles presentaremos más adelante.
La mejor variante es la formalización de las especificaciones informales mediante un modelo al
que puedan verificarse sus propiedades estándares para luego validarlo. Entonces, con el diseño
verificado y validado se puede realizar su implementación con los niveles requeridos de
seguridad y optimización de las automatizaciones con PLC’s, y que garantice estar al nivel de la
complejidad de las aplicaciones actuales y de la necesidad de reducir el tiempo de desarrollo de
los proyectos.
Solo una metodología práctica y una herramienta visual que la respalde pueden permitir la
popularidad requerida a los métodos formales para terminar de absorber el mercado de diseño de
automatizaciones con PLC’s.
En el presente capítulo se profundiza en los métodos de diseño, verificación y validación que
pueden ser empleados dentro de esa metodología para garantizar las propiedades estándares en
los modelos de este tipo de automatizaciones. Así como, para validar el cumplimiento de los
requerimientos del usuario en el diseño del controlador resultante.
34
Capítulo 2. Diseño, Verificación y Validación sobre Ghenesys
2.1 Actualidad en diseño, verificación y validación de automatizaciones con PLC’s.
En la actualidad existen muchos trabajos relacionados con la aplicación de métodos formales en
la verificación y validación de diseños de Automatización en procesos de Manufactura flexible,
procesos Batch, Supervisorios de DES, etc. Muchos de estos sistemas utilizan PLC’s en su
implementación. Por lo cual varias de estas líneas incluyen el desarrollo de modelos de
automatizaciones con PLC’s sobre PN’s [David92, DiCesare93, Zhou95, Desrochers95,
Holloway97, Uzam98]. Pero los métodos de análisis y diseño difieren de acuerdo a las
particularidades de cada modelo y de las líneas que siguen sus investigaciones.
El estudio formal sobre diseño de controladores de eventos discretos, tiene cuatro técnicas
fundamentales: Autómata, PN’s, Minimax y otras álgebras, Redes utilizando Pilas (queuing
networks). Dentro de ellas nos interesan los trabajos sobre PN’s por sus ventajas de sencillez
gráfica y matemática frente a los restantes métodos.
En el tutorial de Dr. Holloway [Holloway97] se resumen las principales líneas actuales de diseño
de controladores de eventos discretos sobre PN’s:
1. Enfoque al comportamiento controlado (Controlled behaviour approach) En este el
modelo incluye el comportamiento de la planta y el controlador juntos. Cuando se obtiene el
comportamiento deseado del sistema controlado, se debe extraer la lógica de control para su
implementación [Zhou & DiCesare93].
2. Enfoque al controlador lógico (Logic controller approach): Consiste en el diseño directo e
implementación del controlador del Sistema de Evento Discreto (DES) basado en definir el
comportamiento de E/S del controlador requerido para lograr el comportamiento deseado del
controlador del sistema. Aquí es necesario dar señales de entrada al controlador para que
ejecute las acciones requeridas, por tanto, es necesario validarlo por simulación [David92].
3. Enfoque teórico al control (Control theoretic approach) Usa el marco de control
supervisorio clásico de Ramadge y Wonham [Ramadge&Wonham89], dando un modelo del
35
Capítulo 2. Diseño, Verificación y Validación sobre Ghenesys
sistema sin control y de acuerdo a este y a las especificaciones del comportamiento
controlado deseado, se sintetiza el controlador [Holloway97, Uzam98].
En los trabajos de Giua [Giua96] se discuten varias técnicas de PN’s para control supervisorio de
DES. De aquí extraemos los dos grupos importantes de Supervisorios basados en PN’s:
‰
Supervisorio Relacional (Mapping supervisor): La política de control es eficientemente
computada por un controlador en línea como función realimentada del marcaje del
sistema.
‰
Supervisorio compilado (Compiled supervisor): La política de control es representada
como una estructura de red.
La segunda es la mejor por ser más rápida al no tener el cómputo del controlador en línea, ambos
(sistema no-controlado y controlado) usan PN’s y pueden usarse construcciones basadas en la
composición de bloques estándares de redes para la creación del sistema a lazo cerrado.
Es importante destacar que en la teoría de Autómata están muy bien expresadas las
especificaciones del sistema de control relacionadas con dos categorías de clases de
especificaciones relacionadas en la literatura de control supervisorio [Ramadge&Wonham89]:
‰
Problema de Estados Prohibidos (Forbidden State Problem): Aquí las especificaciones
de control son expresadas como condiciones prohibidas que deben ser evitadas.
‰
Problema de cadenas prohibidas (o deseadas) (Forbidden (desired) String Problem):
Aquí las especificaciones de control son expresadas como una secuencia de actividades
que debe ser suministrada para que no permita la ocurrencia de secuencias de actividades
no deseadas.
La síntesis del supervisor se realiza teniendo en cuenta esto, es decir, los eventos que no creen
situaciones prohibidas son los que pueden ocurrir.
36
Capítulo 2. Diseño, Verificación y Validación sobre Ghenesys
En PN’s ese mismo modelo puede ser usado para el análisis de las propiedades funcionales, la
evaluación del comportamiento, así como la construcción sistemática del controlador de eventos
discretos.
Existen varios enfoques para atacar los problemas de estados prohibidos y cadenas deseadas
sobre PN, empezando por el que los agrupa en una sola clase “Generalised Mutual Exclusions
Constrains” (GMEC) [Giua&DiCesare&Silva93], hasta el que trabaja en el uso de una clase
extendida general de CtrlPN [Holloway96].
Según Holloway, la síntesis de controladores de plantas modelados por PN’s que usan el último
acercamiento (Control teoretic approach), tienen dos líneas principales:
‰
Control de realimentación de estados (State Feebback Control) que se basa en la
adición de lugares de control a la PN’s creando las CtlPN (Controlled PN).
‰
Control de realimentación de eventos (Event Feeback Control) que se basa en la
asignación de eventos a las transiciones creando las LabPN (Labeled PN).
CtlPN (Controlled PN) es una tripleta Nc=(N,C,B) donde N = (P,T,F) es una OPN, C es un
conjunto finito de Lugares de control disjunto de P y T, mientras que B ⊆ (C x T) es el conjunto
de arcos desde los Lugares de control a las transiciones
LabPN (Labeled PN o PN Generator) es una quíntupla G = (N,Σ, l, M0, F) donde N = (P,T,F)
sigue siendo OPN, Σ es un conjunto (alfabeto) finito de eventos, l: Σ → T es una función que
asigna eventos a las transiciones, M0 es el marcaje inicial y F un conjunto finito de marcajes
finales.
37
Capítulo 2. Diseño, Verificación y Validación sobre Ghenesys
2.2 Diseño sobre GHENeSys.
Inicialmente se realiza el estudio del proceso a controlar y los requisitos funcionales del sistema
controlado, para poder subdividir todo el sistema en la mayor cantidad de unidades funcionales
posibles, que podrán constituir módulos a los distintos niveles jerárquicos, permitiendo el mayor
grado posible de independencia, estando presentes sus interacciones en el módulo jerárquico
superior que los contiene.
Esta propuesta se corresponde con los métodos de modelado propuestos por varios autores, como
es el caso de Zhou [Zhou95], el que propone los siguientes pasos:
‰
Identificación de operaciones y recursos.
‰
Identificación de relaciones.
‰
Diseño de PN’s, el que comprende a su vez:
‰
‰
Diseñar Lugares y/o Transiciones asociados a eventos, operaciones y/o procesos.
‰
Arreglarlos de acuerdo a las relaciones identificadas en el paso precedente.
‰
Insertar lugares y transiciones necesarios para las interconexiones.
‰
Enlazar con arcos de entradas las transiciones con sus lugares condicionantes.
‰
Dibujar arcos de salida de transiciones hacia sus lugares resultantes de su disparo.
‰
Determinar el número inicial de tokens.
Modificación de PN’s: Chequear si el modelo refleja la operación del sistema y modificar la
red hasta que ella modele el sistema.
Las unidades funcionales propuestas en la metodología, agrupan operaciones y recursos que se
destinan a una función específica del sistema. Para éstas es necesario definir sus relaciones, con
el objetivo de establecer cuáles son relaciones internas que quedan dentro de ese módulo, y
cuáles son interrelaciones con otros módulos que serán modeladas en un nivel jerárquico
superior. Luego, se siguen los otros dos pasos de diseño y modificación para cada subred.
38
Capítulo 2. Diseño, Verificación y Validación sobre Ghenesys
La utilización del diseño jerárquico que permite GHENeSys concuerda con el enfoque al
modelado (modeling approach) propuesto por Luca Ferrarini [Zhou95], donde incorpora las
técnicas Botton-up y Top-down en el modelado en PN’s. En este trabajo se plantea que la técnica
Botton-up brinda la posibilidad de definir tareas elementales, modeladas cuidadosamente, para
definir bloques elementales, llamadas ECT (Tareas de Control Elemental), que se interconectan
adecuadamente para formar la red, en su caso solo admite redes Máquinas de Estado (SM)
fuertemente conectadas. Esto coincide con la propuesta de GHENeSys, pero en éstas puede ser
cualquier tipo de OPN, solo cumpliendo las condiciones requeridas para sistemas propios
[Glez&Silva01] (una entrada una salida y caminos directos E/S que enlacen todos los nodos).
Además, Ferrarini plantea solo tres tipos genéricos de interconexión: autolazos (función similar a
arcos de prueba o habilitadores de los Pseudoboxes de GHENeSys), arcos inhibidores (también
considerados en los Pseudoboxes de GHENeSys), sincronización (generalizada) para compartir
recursos (considerada además en GHENeSys, solo que utilizando los Pseudoboxes únicamente
para compartir información [Glez&Silva01]).
La técnica Top-down de Ferrarini [Zhou95] se basa en la representación multinivel (jerárquica)
como la propuesta para enfrentar sistemas complejos por muchos otros autores (ej.
[Zhou&DiCesare&Desrochers89]), y que también se aplica sobre GHENeSys. Ferrarini defiende
el uso cuidadoso del intercambio de señales entre las subredes del sistema, estén o no en
diferentes niveles, para no dañar la sincronización. Eso también se tiene en cuenta en GHENeSys,
donde los Pseudoboxes facilitan enormemente este diseño, solo exceptuando el caso de compartir
recursos.
El estudio del proceso y de los requisitos funcionales del usuario pueden ser formalizados desde
esta etapa para garantizar un modelo jerárquico modular del proceso no-controlado en PN’s. Esto
coincide con la propuesta inicial de los seis métodos de diseño presentados en la tesis doctoral de
Uzam (Método del arco inhibidor, del arco habilitador, del Lugar intermedio, APN-SM, U-TPM,
C-TPM) [Uzam98T]. Pero en los primeros 4 métodos las APN que modelan el proceso nocontrolado y el supervisor están representadas de forma independiente, siendo enlazadas por
39
Capítulo 2. Diseño, Verificación y Validación sobre Ghenesys
elementos auxiliares (arcos inhibidores, arcos habilitadores, lugares auxiliares y combinaciones
de los dos primeros) lo que aumenta el tamaño de la estructura final del sistema. Con los dos
últimos métodos se obtienen supervisores más compactos porque trabajan modificando el propio
modelo no-controlado. De estos últimos, el caso del C-TPM no requiere de la construcción del
RG del modelo no-controlado para crear el supervisor, y las especificaciones de estados
prohibidos son formalizadas independientes del modelo no-controlado. Estas son ventajas que se
aprovechan de la propuesta sobre GHENeSys, ya que preparan las condiciones para el uso de
métodos de análisis gráficos o matemáticos, según las posibilidades y necesidades del diseñador.
El método C-TPM [Uzam98] es una técnica de síntesis Bottom-up que utiliza el modelo nocontrolado y las reglas TPM basadas en las especificaciones de estados prohibidos para el diseño
del modelo controlador del supervisor. La implementación de estas reglas utiliza una mezcla de
arcos habilitadores e inhibidores. Después de esto debe ser verificada su corrección a través del
análisis RG. Se denomina Método C-TPM porque usa el Controlled model y las TPM rules, que
fueron extraídas directamente de las especificaciones de estados prohibidos. En estas últimas, si
la parte if de la regla contiene combinaciones AND u OR deben definirse en el modelo (para el
caso OR, duplicando la transición tantas veces como lugares de entrada existan, que luego entran
al mismo lugar siguiente).
Pasos del método C-TPM [Uzam98T]:
1. Diseño del modelo no-controlado del sistema usando APN.
2. Convertir las especificaciones de estados prohibidos dados en reglas TPM relacionadas.
3. Construir el modelo controlado del sistema por unión del modelo no-controlado con las reglas
TPM obtenidas en el paso anterior.
4. Generar el RG del modelo controlado.
5. Chequear el modelo controlado de acuerdo a las especificaciones por análisis de RG. Si no se
cumple volver al paso 2 a corregir y repetir la secuencia de pasos.
40
Capítulo 2. Diseño, Verificación y Validación sobre Ghenesys
6. Implementar el supervisorio (modelo controlado) en el PLC utilizando el lenguaje de
programación Diagramas de Escalera (LD) o cualquiera de los lenguajes de la norma
IEC1131, según la preferencia del programador.
Para el trabajo sobre GHENeSys se aprovechan los tres primeros pasos del método adaptados
convenientemente.
El modelo del proceso no-controlado puede crearse utilizando la combinación de módulos
estándares sobre PN’s que representen las distintas funciones del modelo. Esto es conocido en
algunos trabajos como Modelado Modular.
Para crear facilidades de estructuración del programa resultante, estas estructuras deben ser
propias (solo una entrada y una salida y que para cada nodo existe un camino E/S que pasa por él)
[Glez01]. Esto coincide con las definiciones de PN’s bien formadas [Desel&Esparza95]. Al final,
tanto en los modelos PN’s como en los programas se garantiza vivacidad (evitando deadlocks) y
funcionamiento sin bloqueos respectivamente.
Las estructuras básicas para construcción de redes pueden ser divididas en dos grandes grupos
[Glez01]: las equivalentes a las estructuras de lenguajes de programación (que son propias) y las
básicas de sistemas de producción, que pueden ser trasformadas a propias mediante el uso de los
Pseudoboxes de GHENeSys (excepto el caso de compartición de recursos).
Primer grupo:
‰
Secuencial. Una acción detrás de otra.
‰
Condicional: Alternativas donde la solución del conflicto la resuelven los Pseudoboxes.
41
Capítulo 2. Diseño, Verificación y Validación sobre Ghenesys
‰
Iteración. Repetición de acciones hasta obtener el resultado deseado.
‰
Paralela: Actividades que pueden realizarse al mismo tiempo o en cualquier orden de forma
paralela.
Segundo Grupo:
‰
Compartición de recursos o información: Se tienen dos procesos paralelos que comparten
el uso de un equipamiento o información.
‰
Sincronización:
Dos
secuencias
paralelas
sincronizadas
por
una
relación
de
pedido/reconocimiento.
42
Capítulo 2. Diseño, Verificación y Validación sobre Ghenesys
‰
Relación productor-consumidor: Dos procesos paralelos donde la ejecución de una es
condición para la otra y viceversa.
Las que no se pueden transformar a propias, entonces se propone modelarlas en un bloque aparte
de una entrada y una salida para aislar la “fuente de bloqueos” y prever un algoritmo de control
para resolver este problema.
Además, hay otras estructuras para DES presentadas en Uzam98:
‰
Buffer: Almacenaje limitado de una producción intermedia, donde la capacidad el buffer (k)
es la capacidad del lugar de retorno inicializado a ese valor k.
‰
Pila FIFO: Secuencia de Buffers como en el caso de una banda transportadora.
‰
Máquina: Puede alternar entre dos estados (en espera o trabajando), pero puede además de
éstos dos estar descompuesta si el proceso no es fiable.
‰
Motor y actuador: Puede estar apagado o encendido, pero además puede ser que tenga doble
sentido de giro y entonces tiene 3 estados.
43
Capítulo 2. Diseño, Verificación y Validación sobre Ghenesys
Ambos tienen igual gráfico en PN’s:
Estas estructuras son representadas de forma diferente al crear el Supervisor, pues no es necesario
presentar la rotación de los dos o tres estados posibles, sino como dos o tres condiciones, que
luego activan las acciones sobre el sistema asociadas a los lugares. Para esto se usan los
Pseudoboxes simplificando las PN’s creadas.
Todas estas estructuras son utilizadas para conformar las distintas subredes que integran los
diferentes niveles de la jerarquía del modelo GHENeSys, que luego podrán ser traducidas a
programas en lenguajes estándares, como LD, IL o ST. Por tanto, todas son almacenadas en una
biblioteca de estructuras básicas de diseño de modelos. En el caso de utilizar un editor de PN’s
estándar (Visual Object Net ++ [Drath97, Drath98]), estas deben estar guardadas en ficheros
independientes que pueden ser llamados, copiados y luego insertados (pegados) en la parte que
nos interesa del fichero del modelo que estamos construyendo. Luego adaptados a las
particularidades de su aplicación, a conveniencia del diseñador.
Los requisitos funcionales del usuario no son más que la descripción funcional del sistema
controlado deseado. Con estos se pueden definir los problemas de estados prohibidos y cadenas
deseadas, que permitirían definir en el modelo no-controlado cuáles son las transiciones
controlables sobre las que se debe actuar para gobernar los eventos controlables del sistema.
Para la formalización de estas especificaciones se utilizan las reglas TPM [Uzam98], no son más
que estructuras de la forma:
If <marcaje>
Then <una transición controlable estará habilitada>
44
Capítulo 2. Diseño, Verificación y Validación sobre Ghenesys
Lo que significa que la transición indicada en la parte Then solo se habilita de acuerdo a la parte
If de la regla y para otro marcaje está prohibida.
Para llegar a esto, directamente de las especificaciones textuales, es necesaria la creación de una
regla intermedia que, en la parte If, en vez de marcaje tiene condiciones del proceso nocontrolado relacionadas en las especificaciones, y como parte Then tendría las acciones a
ejecutarse. Luego relacionando esto con el modelo no-controlado se puede redactar la regla final.
La política de control a seguir en el método C-TPM se basa en detener el disparo de las
transiciones controlables en el modelo no-controlado para supervisar que en el sistema no ocurran
los estados prohibidos. De esta forma solo se habilita el disparo de las transiciones que permitan
que el sistema se mueva en el espacio de estados máximamente permisibles.
Cada transición del modelo puede estar asociada a la ocurrencia de eventos externos que pueden
ser de dos tipos: controlables (pueden ser deshabilitados a través del control) o incontrolables
(los que no pueden ser deshabilitados a través del control). Sin embargo, las OPN no permiten la
asociación a sensores y actuadores, por lo que hace falta crear extensiones para atender sensores.
Por ejemplo, en GHENeSys el uso lo Pseudoboxes con arcos habilitadores o inhibidores sobre las
transiciones para atender los sensores y para los actuadores utiliza la asociación de acciones de
control a los Lugares (Boxes) y/o Transiciones (Actividades).
Con la introducción de los Pseudoboxes y asociación de acciones se completa la política de
control requerida para culminar el diseño del modelo del sistema controlado. A partir de aquí se
realizan las etapas de verificación y validación del modelo, dejándolo listo para su
implementación posterior.
45
Capítulo 2. Diseño, Verificación y Validación sobre Ghenesys
2.3 Verificación sobre Ghenesys.
En los trabajos de verificación de SIPN [Frey98] se plantea la aplicación de los métodos de
análisis y verificación de PN’s basados en algoritmos de control. La idea es reemplazar la IPN
(Interpreted PN) usada por elementos de PN’s para tener una OPN. Después del reemplazo las
propiedades de la OPN son determinadas por el método del gráfico de alcanzabilidad.
No obstante, las características particulares de este tipo de LabPN obligan a la definición de
nuevas propiedades a verificar en este proceso. Por la asignación de salidas y no de acciones a los
Lugares se tienen asignaciones redundantes o contradictorias en diferentes Lugares de la red a la
misma salida del controlador hacia el proceso. Por tanto, de acuerdo a los invariantes S y T se
definen las salidas correctas estudiando salidas redundantes, contradictorias, marcaje óptimo,
sincronización, etc. Necesita soporte de invariante con marcaje 1 para un diseño óptimo.
Nosotros proponemos una variante similar, pero aplicada al caso de las redes GHENeSys, donde
no se tienen los problemas de redundancia y contradicción de salidas porque se trabaja asignando
acciones y no directamente salidas. En GHENeSys aprovechamos la propuesta de convertir el
modelo a una OPN al eliminar los Pseudoboxes y sus arcos de interconexión hacia las
transiciones controladas para realizar la verificación de propiedades de la red como Vivacidad y
Seguridad sobre una OPN. De esta forma la red elimina lugares fuentes y queda una red pura que
cumple con la condición necesaria de Vivacidad planteada por Murata [Murata89] (no tener
fuentes y sumideros).
El alcance de Vivacidad y Seguridad de esta OPN creada a partir de esa simplificación del
modelo controlado, garantizan un buen comportamiento de la red total (con la adición de los
Pseudoboxes).
Para la verificación en GHENeSys en este trabajo se utilizan herramientas gráficas sin llegar al
RG, como la búsqueda de redes bien-formadas mediante el método gráfico de reducción simple
46
Capítulo 2. Diseño, Verificación y Validación sobre Ghenesys
[Murata89, Bilinski94, Desel&Esparza95], y la aplicación de el teorema del Rango
[Desel&Esparza95] como método analítico de verificación. No obstante, puede usarse el RG si
se desea, pero como nuestras redes son sencillas nos limitamos a usar este método. Verificar los
modelos de subredes sobre GHENeSys, estamos verificando las propiedades de dicho modelo.
La Vivacidad significa que una transición pueda dispararse otra vez, al no cumplirse dicha
propiedad, parte del algoritmo de control no se ejecutara más, y eso es un error de diseño que
debe corregirse. La red es viva si todas sus transiciones lo son. Por tanto, coincidimos que una
propiedad fundamental a comprobar durante la Verificación del modelo controlado es la
Vivacidad. Garantizando esto sobre la OPN que obtenemos de eliminar los Pseudoboxes sobre la
red GHENeSys del modelo controlado, es suficiente para evitar esos errores de diseño en el
programa resultante.
La Reversibilidad garantiza que el controlador descrito por la red alcance otra vez su estado
inicial, esto obliga a un buen comportamiento ante procesos erróneos, lo cual implica que la
recuperación automática de errores es posible. De aquí que si nuestra OPN es reversible el
programa del controlador resultante tendrá posibilidades de recuperación ante errores.
La mayoría de las aplicaciones de automatización con PLC’s pueden considerarse dentro del
rango de las Redes de Libre-selección (FC-nets). Por lo anterior, el análisis de Vivacidad y
Seguridad de los modelos controlados propuestos sobre GHENeSys pueden utilizar los métodos
propuestos por Desel y Esparza en su libro [Desel&Esparza95].
Las reglas de reducción brindan un método alternativo de análisis de buena-formación (well-
formedness) en FC-Nets [Desel&Esparza95]. El algoritmo de chequeo de buena-formación puede
ser transformado fácilmente en un algoritmo de chequeo de Vivacidad y Limitación de FCSystems usando el Teorema 6.17.
47
Capítulo 2. Diseño, Verificación y Validación sobre Ghenesys
Teorema 6.17 Caracterización de Vivacidad y Limitación de sistemas FC (L&B FCsystems) [Desel&Esparza95].
Un sistema de Libre selección (N,M0) es vivo y limitado si:
1. N es bien formada, y
2. M0 marca todos los sifones propios de N
Sifón: Es un subconjunto de Lugares S no vacío en una OPN (también conocido como
deadloock)
si •S ⊆ S• ; o sea, que cualquier transición teniendo un lugar de salida en S tiene
también un lugar de entrada en S; es decir, todas las transiciones están ligadas al menos por un
lugar de entrada. En un Sifón el conteo de tokens se mantiene o decrece. Un sifón es una parte
critica del sistema para el análisis de Vivacidad [Reising82].
Por tanto, primero se revisa si todos los sifones están marcados, y si es así se aplican las reglas de
reducción para comprobar si la red está bien formada.
También se propone el uso de las reglas de reducción simples [Murata89] como un arma eficaz
para permitir el análisis de propiedades de modelos en PN’s de sistemas complejos [Zhou95].
2.3.1 Reglas de Reducción Simple.
Para facilitar el análisis de grandes sistemas generalmente se reduce a uno simple, conservando
las propiedades del sistema. Las técnicas de transformar un modelo abstracto en modelos mas
refinados de una manera jerárquica puede ser usado para la síntesis de estos sistemas.
Las operaciones de reducción conservan las propiedades antes mencionadas de vivacidad,
seguridad y limitación. Es decir, si (N, M0) y (N’, M0’) son las PN’s antes y después de las
transformaciones. Entonces (N’, M0’) es viva, segura y limitada si (N, M0) lo es [Murata89].
48
Capítulo 2. Diseño, Verificación y Validación sobre Ghenesys
Las reglas de transformación simple son:
1. Fusión de Lugares Serie (FSP):
2. Fusión de Transiciones Serie (FST):
3. Fusión de Lugares Paralelos (FPP):
4. Fusión de Transiciones Paralelas (FPT):
49
Capítulo 2. Diseño, Verificación y Validación sobre Ghenesys
5. Eliminación de Auto-Lazo (Self-Loop) de Lugar (ESP):
6. Eliminación de Auto-Lazo (Self-Loop) de Transición (EST):
Luego de realizado cada paso de reducción debe verificarse si la red está estructuralmente
correcta. Si se presenta alguna de las siguientes situaciones luego de realizado cada paso de
reducción, la red contiene un error estructural [Bilinski94]:
‰
Existe una transición con solo un lugar de entrada y uno de salida, y el conjunto de
transiciones de entrada asociadas al lugar de entrada no están separadas del conjunto de
transiciones de entrada asociadas al lugar de salida; en este caso la red no es segura.
‰
Cuando se realiza la fusión de lugares series (FSP), si ambos lugares poseen tokens, la red no
es segura.
‰
Existe una transición con solo un lugar de entrada y uno de salida, y el conjunto de
transiciones de salida asociadas al lugar de entrada no están separadas del conjunto de
transiciones de salidas asociadas al lugar de salida, en este caso la red no es viva.
‰
Existe una subred sin transiciones de entrada y salida, y existe al menos otro lugar o subred
en la red.
La Figura 2.1 representa un ejemplo de aplicación de este método de reducción. Se puede ver a
simple vista que es una red bien- formada; no obstante, aplicando las reglas simples de reducción
[Murata89] vemos que logramos reducir todo el sistema a una red simple de un lugar y una
transición.
50
Capítulo 2. Diseño, Verificación y Validación sobre Ghenesys
Figura 2.1. Ejemplo de la reducción de una subred a una red simple.
Si no se lograse reducir la red a una red mínima elemental de un lugar y una transición, es
necesario buscar la posibilidad de modificar la estructura de la red (sin cambiar su
funcionamiento), pero que permita esa reducción.
En el libro de Zhou[Zhou95] también se propone el uso de las reglas de reducción simple
[Murata89] como un arma eficaz para permitir el análisis de propiedades de modelos en PN’s de
sistemas complejos.
2.3.2 Teorema del Rango.
Si la subred es mucho más compleja puede aplicarse la variante de utilizar el Teorema del
Rango [Desel&Esparza95]. Este teorema brinda una vía de verificación analítica que permite una
solución completa al problema de definir Vivacidad y Seguridad de una FC-net dada, por la vía
polinomial, a todo el tamaño de la red, y a través de la caracterización de Redes Libre-selección
bien- formadas. En nuestro trabajo las redes diseñadas son sencillas pero aplicamos este método
para contar con una herramienta más de análisis de verificación.
Antes de analizar el teorema correspondiente se deben tener en cuenta definiciones importantes.
51
Capítulo 2. Diseño, Verificación y Validación sobre Ghenesys
‰
Invariantes S y T (S- and T-invariants).
Un invariante de un sistema dinámico es una consideración que se mantiene en cualquier estado
alcanzable. En los sistemas de redes es posible calcular ciertos vectores de números racionales
(directamente desde la estructura de la red) los cuales inducen invariantes [Desel&Esparza95].
1. Expresión AY es la diferencia de marcajes en cada lugar. Permiten conocer el número de
veces que un determinado número de transiciones debe ser disparada para que el sistema
regrese a su estado inicial.
2. Expresión ATX es el cambio en una suma compensada de tokens para cada disparo de
transición. Constituye una medida de la conservación de marcas en una red.
Definición 2.26 Invariante S para las redes FC [Desel&Esparza95]:
Una solución entera X del sistema homogéneo AT X = Ø se le llama Invariante S.
Donde AT es la transpuesta de matriz de incidencia, y Ø es un vector columna con todos sus
elementos iguales a cero.
Se define S-invariante como el conjunto de Lugares de una P/T-net en los cuales no cambia el
conteo de tokens durante los disparos de transiciones [Reising82].
Definición 2.35 Invariante T para las redes FC [Desel&Esparza95]:
Una solución entera Y del sistema homogéneo AY = Ø se le llama Invariante T.
Donde A es la de la matriz de incidencia y Ø es un vector columna con todos sus elementos
iguales a cero.
Estos T invariantes indican como aun, comenzando desde algún marcaje M0, cada transición
tiene que dispararse un número de veces para reproducir (volver a producir) este marcaje
[Reising82].
52
Capítulo 2. Diseño, Verificación y Validación sobre Ghenesys
Definición 4.4 Cluster [Desel&Esparza95]:
Sea x un nodo de una red. El cluster de x, denotado por [x], es el mínimo conjunto de nodos tal
que:
‰
x ∈[x],
‰
si el lugar s pertenece a x entonces s• se incluye en [x], y
‰
si la transición t pertenece a x entonces •t se incluye en [x].
(Ver ejemplo en la Figura 2.2)
Figura 2.2 Ejemplo de partición de los nodos de una red FC en 4 clusters.
‰
Teorema del Rango.
Teorema 6.14 Sea N una red FC. Sea A la matriz de incidencia de N y Cn el conjunto de
clusters de N. La red N es bien-formada si [Desel&Esparza95]:
1. Está conectada y tiene al menos un lugar y una transición
2. Tiene un invariante S positivo,
3. Tiene un invariante T positivo, y
4. Rank(A) = |Cn| - 1
De acuerdo a los Teoremas 6.14, 6.17[Desel&Esparza95] y las definiciones anteriores esto puede
ser resuelto en forma polinomial mediante los siguientes pasos:
53
Capítulo 2. Diseño, Verificación y Validación sobre Ghenesys
1º. Debe comprobarse que la red sea well-formed (bien formada), para eso debe cumplir los
4 puntos del Teorema 6.14. Se comprueba fácilmente que N esté conectada, y tenga al
menos un lugar y una transición.
2º. La existencia de un invariante S positivo se logra resolviendo el sistema de inecuaciones
lineales:
AT x X = Ø
X > (1,…,1)
3º. La existencia de un invariante T positivo se logra resolviendo el sistema de inecuaciones
lineales:
AxY=Ø
Y > (1,…,1)
4º. Luego se realiza el conteo de clusters.
Con el valor de este conteo de clusters Cn y el calculo del rango de la matriz de incidencia A de
la red N, se determina si Rank(A) = |Cn| - 1.
A continuación se muestra un ejemplo de aplicación de este método. La Figura 2.3 representa una
subred donde se aplica este teorema para la comprobación de redes bien- formadas siguiendo los
pasos anteriores.
Figura 2.3 Subred de Selección de las Variantes de Control y la partición de sus nodos en 6 clusters
54
Capítulo 2. Diseño, Verificación y Validación sobre Ghenesys
Primeramente comprobamos que la red esté conectada, lo que resulta por simple inspección al
observar que esta cuenta con más de un lugar y una transición conectados entre sí.
Seguidamente para comprobar la existencia de las invariantes de lugar S y de transición T, se
debe obtener la matriz de incidencia A de la red, está matriz es de orden 6 x 9 (lugares x
transiciones) donde sus elementos son los pesos de los arcos que van de las transiciones a los
lugares y viceversa.
La matriz de incidencia está dada por:
A6x9
⎡− 1 − 1 − 1 − 1
⎢1
0
0
0
⎢
⎢0
1
0
0
=⎢
0
1
0
⎢0
⎢0
0
0
1
⎢
0
0
0
⎢⎣ 0
0 0
1 0
0 −1
0
0
0
0
1
1
⎤
⎥
⎥
⎥
⎥
−1 0
0⎥
0 −1 0 ⎥
⎥
1
1 − 1⎥⎦
0
0
0
0
0
0
1
0
0
Obtenida A se pasa a buscar las soluciones del sistema homogéneo AT x X =Ø y A x Y =Ø, donde
el vector X representa las invariantes S y el vector Y las invariantes T.
Utilizando el método de Gauss o de eliminación sucesiva de las incógnitas se escalona la matriz
de ceros obteniéndose un sistema de soluciones, donde en la primera columna están las variables
libres o independientes. Las demás variables se pasan para el otro miembro y se le dan valores,
cabe destacar que este sistema tiene infinitas soluciones.
Calculando las invariantes se obtienen los siguientes resultados:
Invariantes T
Invariantes S
Y1 = −Y6 − Y7 − Y8 + Y9
X1 = X 6
Y 2 = Y6
X2 = X6
Y3 = Y7
X3 = X6
Y4 = Y8
X4 = X6
Y5 = −Y6 − Y7 − Y8 + Y9
X5 = X6
55
Capítulo 2. Diseño, Verificación y Validación sobre Ghenesys
algunas soluciones son
Y = [1 1 1 1 1 1 1 1 1 1 1 4] ,[2 1 1 1 2 1 1 1 5] ...
⎡1⎤ ⎡2⎤
⎢1⎥ ⎢2⎥
⎢⎥ ⎢ ⎥
⎢1⎥ ⎢2⎥
X = ⎢ ⎥ , ⎢ ⎥ ...
⎢1⎥ ⎢2⎥
⎢1⎥ ⎢2⎥
⎢⎥ ⎢ ⎥
⎣⎢1⎦⎥ ⎣⎢2⎦⎥
Con ayuda del MATLAB salimos a buscar las soluciones y comprobamos de esta forma nuestros
cálculos, así como obtuvimos el rango de la matriz A que es 5.
Calculamos si el rango es Rank(A) = |Cn| - 1, sustituyendo |Cn| = 6, Rank(A) = 5. Por tanto el
modelo representa una red bien formada pues cumple con este método de verificación de redes,
comprobando además propiedades importantes como vivacidad (todas las transiciones son
habilitables y por tanto la vivacidad de la red es infinita) y limitación (se conserva el número de
tokens de la red) e invariantes S y T.
Luego de obtener el modelo verificado por alguna de las variantes (métodos), es necesario
comprobar si el controlador cumple con los objetivos para los cuales fue creado, lo cual se realiza
en la validación del modelo.
2.4 Validación sobre GHENeSys.
En el libro de Zhou [Zhou95] se plantea que los métodos de análisis de modelos en PN’s incluyen
la comprobación de si existe correspondencia funcional entre el modelo y las especificaciones
de requerimientos originales (típicamente expresadas informalmente), lo cual se comprueba en la
Validación. Lograr esta correspondencia requiere de experiencia en modelado y conocimiento de
las técnicas que ayudan a la construcción de modelos. Para este objetivo también se incluye el
Completamiento (Completeness) de las especificaciones de requerimientos. Estas últimas se
56
Capítulo 2. Diseño, Verificación y Validación sobre Ghenesys
expresan generalmente como relaciones de E/S del sistema. Hay entradas que no se definen en
los requerimientos iniciales y deben ser completadas. Otro aspecto importante es la Consistencia
(Consistency) de las especificaciones de requerimientos. No existe consistencia (inconsistencia)
cuando una combinación de entradas genera varias combinaciones de salidas. Todo esto debe ser
comprobado minuciosamente durante la validación del modelo.
En este libro también se considera la Simulación de eventos discretos como otra vía para el
chequeo de las propiedades del sistema. Para ello se utiliza un algoritmo de ejecución para
“correr” la red. Es una técnica extensiva y consumidora de tiempo. Muestra la presencia de
propiedades indeseables pero no prueba la corrección (Correctness) del modelo en casos
generales, al ser prácticamente imposible poder probar todos los casos a presentarse. Sin
embargo, se mantiene como una propuesta por muchos autores. Específicamente Desrochers
[Desrochers95] la considera una herramienta de análisis de comportamiento cuando las
limitaciones de memoria de las computadoras no permiten generar los gráficos de alcanzabilidad
(RG). Desrochers plantea que la simulación permite observar cuántas veces un lugar es marcado
o no, y calcular la probabilidad de esto. Por tanto, la simulación del flujo de tokens puede generar
análisis estadísticos importantes del comportamiento de la red. Mucho más cuando la herramienta
de simulación permite trabajar con tiempos reales de ejecución del sistema en el modelo.
Zhou y Zurawaski [Zhou95] proponen un algoritmo que incluye:
1. Inicialización (marcaje inicial).
2. Número de pasos de simulación y criterios de parada (si hay transiciones deshabitadas reporta
un marcaje deadlock).
3. Selecciona aleatoriamente una transición a disparar y comprueba los tokens que remueve y
coloca.
4. Modifica la transición seleccionada en el paso 3 y repite los pasos 2 y 3.
57
Capítulo 2. Diseño, Verificación y Validación sobre Ghenesys
En la validación sobre GHENeSys se plantea el estudio simulado del comportamiento del modelo
controlado verificando el cumplimiento de las restricciones de estados prohibidos y la secuencia
del comportamiento correcto del controlador.
Considerando el diseño modular jerárquico sobre GHENeSys, las subredes a analizar son propias
(una entrada, una salida y caminos E/S que cubren todos los nodos); y además, durante la
verificación debe haberse logrado la vivacidad de la subred. Por ello, como estas subredes no
tienen grandes dimensiones, podemos reincorporar los Pseudoboxes y realizar la simulación de su
comportamiento como un medio de evaluación del cumplimiento de las especificaciones del
usuario para el sistema controlado.
Para lograr esto se plantea la utilización de herramientas de simulación por computadoras para
comprobar el comportamiento de la red. Pues ello permite comprobar que el sistema no presente
bloqueos y nunca ocurran los estados prohibidos que pueden provocar afectaciones a la
producción o situaciones peligrosas. De esta forma el sistema debe transitar siempre solo por las
secuencias deseadas (que corresponden a las cadenas deseadas evaluadas en la formalización de
las especificaciones) en cualquier circunstancia.
Por ello es muy importante definir una herramienta eficaz en la simulación del comportamiento
de una red. En el desarrollo de este trabajo se escogió el Visual Object Net ++ [Dath97, Dath98],
el que aun no constituye la herramienta ideal, pero sí brinda algunas posibilidades al soportar el
trabajo con Place/Transition Nets, Petri Nets Temporizadas, Hybrid Dynamic Nets y Hybrid
Object Nets. De ellas, para los trabajos con GHENeSys interesa la fortaleza en las dos primeras,
utilizando las facilidades de extensión al uso de arcos inhibidores y arcos de habilitadores (test)
de que dispone dicho editor.
58
Capítulo 2. Diseño, Verificación y Validación sobre Ghenesys
2.4.1 Herramienta de diseño sobre GHENeSys e implementación automática.
Para modelar el proceso en Redes de Petri se usa el software Visual Object Net ++ (VON), que
consideramos la herramienta que mejor se adapta a nuestros intereses por sus facilidades visuales
de edición y simulación, aunque tiene la desventaja de no dar grandes facilidades de análisis,
cálculo de invariantes, técnicas de reducción automática, etc. No obstante, éstas pueden ser
suplidas añadiendo una herramienta adicional de cálculo que pueda aprovechar la información de
los ficheros que almacenan la estructura de la red editada sobre el VON.
El VON soporta el trabajo con Redes de Petri, para los trabajos con GHENeSys se utiliza las
facilidades de extensión al uso de arcos inhibidores y arcos de prueba (habilitadores) de que
dispone dicho editor. De esta forma se puede desarrollar cualquier variante de OPN’s,
adicionándole los Pseudoboxes con arcos inhibidores y habilitadores requeridos para la creación
de cualquier aplicación de GHENeSys. Dispone de las facilidades de simulación corrida o por
pasos de forma interactiva (pudiendo el usuario cambiar el marcaje de los Pseudoboxes sin
interrumpir la simulación del sistema).
A pesar de las facilidades del VON esta no es la herramienta ideal para el trabajo con redes
GHENeSys porque no dispone de opciones de:
‰
Utilización de una biblioteca de módulos propios para ayudar al diseño de cada subred.
‰
Uso de facilidades para cálculos automáticos de apoyo al análisis funcional y estructural de la
red, que permitirían realizar la búsqueda de redes bien-formadas para que puedan cumplir la
Vivacidad y Seguridad requeridas, como pueden ser: reducción automática, calculo de
invariantes de Lugar y transición, conteo de clusters, definición de cobertura por
componentes S o T, aplicación del Teorema del Rango, etc.
‰
No dispone de facilidades de implementación automática a lenguajes de PLC’s IEC1131
compatibles que serán incorporadas a GHENeSys.
59
Capítulo 2. Diseño, Verificación y Validación sobre Ghenesys
Por lo anterior, es necesario desarrollar una herramienta específica que permita las facilidades
anteriores junto a las ventajas ya expuestas sobre el VON.
El objetivo final es lograr la traducción automática de la metodología empleada sobre una
herramienta completa. No obstante mientras se mantiene en desarrollo esta nueva herramienta, se
utilizará el Visual Object Net (VON) para el diseño del modelo utilizando una biblioteca de
estructuras típicas en ficheros independientes que puede irse ampliando con nuevas subredes
validadas por el usuario [Drath97, Drath98].
En la Figura 2.4 se presenta la ventana del VON con el modelo de la subred representada en la
Figura 2.3 simulado y verificado, la Variante 2 es la seleccionada en este caso. Se observa como
la transición T1 disparó el token para activar el Macrolugar MP3: Variante 2 que representa una
subred independiente.
Figura 2.4 Simulación y Verificación de la Variante 2 en el Visual Object Net.
60
Capítulo 3.Aplicación de la metodología presenta en la automatización de ...
CAPÍTULO 3. APLICACIÓN DE LA METODOLOGÍA PRESENTADA
EN LA AUTOMATIZACIÓN DE DOS INSTALACIONES DE
LABORATORIO.
En nuestro país no resulta frecuente encontrar en la literatura que trata el tema de las PN’s, la
aplicación de los trabajos desarrollados en este campo a sistemas reales, generalmente aparecen
relacionados a sistemas didácticos utilizados con fines demostrativos (aunque como resultado del
empleo de esta metodología, también se está trabajando con resultados satisfactorios en una
terminal de embarque de azúcar, en Carúpano [Elio02]). La aplicación del novedoso método del
modelado del programa utilizando GHENeSys, y el análisis posterior desarrollado sobre los
modelos de estas automatizaciones de instalaciones de laboratorio reales con PLC’s, resulta una
magnífica ocasión para demostrar las posibilidades de la metodología presentada. Además
demuestra la capacidad representativa de GHENeSys para cualquier tipo de sistema que utilice
PLC’s, ya sea, discreto, continuo o híbrido, con la inclusión de los comparadores y otros bloques
de funciones sin tener que salir del marco de las OPN’s, propiciando de esta forma la utilización
de métodos sencillos de análisis, verificación y validación, así como una fácil traducción a los
lenguajes estándares IEC1131 compatibles.
A continuación se detallan las particularidades de cada una de las instalaciones del Laboratorio
de Control de Procesos de la Universidad de Oriente, los elementos que las forman, las
estructuras de control y las señales a considerar en ellas, así como la secuencia de operación del
sistema, concluyendo con el diseño del modelo y su traducción a lenguajes de PLC’s siguiendo la
metodología desarrollada en el Capítulo 2.
3.1 Panel de nivel
El Panel de Nivel está formado por dos tanques, uno superior y otro inferior. Una bomba que
impulsa el agua del tanque inferior al superior y una electroválvula que evacua el líquido del
61
Capítulo 3.Aplicación de la metodología presenta en la automatización de ...
tanque superior al inferior. El tanque superior tiene tres sensores que indican el nivel del agua y
mandan su señal al panel frontal de la instalación para su indicación con tres leds y a un PLC
esclavo que controla el funcionamiento del sistema según la variante, de cuatro posibles, escogida
(Figura 3.1).
Fig. 3.1 Panel de Nivel.
3.1.1 Funcionamiento de la instalación.
Se controla el nivel de agua en el tanque superior, para ello se cuenta con tres sensores de nivel
ubicados en los extremos bajo (sensor3), alto (sensor1) y un tercero situado en el centro
(sensor2), dando la posibilidad de que el operador escoja las siguientes variantes de control:
1. Implementa la condición inicial (tanque lleno), permitiendo que los sensores puedan trabajar
en la forma prevista. Es de carácter obligatorio para desarrollar las otras variantes.
2. Realiza el control desde el centro (sensor2) hasta la parte superior (sensor1).
3. Realiza el control desde el nivel inferior (sensor3) hasta el centro (sensor2).
62
Capítulo 3.Aplicación de la metodología presenta en la automatización de ...
4. Realiza el control desde el nivel inferior (sensor3) hasta el superior (sensor1).
En la versión de control local estas variantes, así como el encendido, parada y selector de manual
o automático, son interruptores que se encuentran en un pequeño panel de control, y se relacionan
con las diferentes entradas del autómata esclavo, que trabajará como controlador. Sin embargo en
la variante de control remoto el PLC maestro es prioritario sobre el panel frontal de la instalación,
por tanto a través de la red UNI-TELWAY, el maestro le envía la variante de control deseada o le
da el control al panel.
Para la operación del proceso primero se escoge si el control se realizará de forma manual o
automática. Si es automático se pulsa el botón START. Comenzará entonces la operación del
proceso siempre que el selector de variantes esté en variante 1 (condición inicial). A partir de ese
momento el sistema trabajará según la variante escogida. Por ejemplo si se escoge la variante 4 y
el sensor superior se activa, el control desconecta la bomba y manda a abrir la electroválvula, con
la finalidad de que el nivel disminuya, hasta que se active el sensor inferior, momento en el cual
el control conecta la bomba y manda a cerrar la electroválvula, para que el nivel suba hasta llegar
al sensor superior, repitiéndose el mismo proceso hasta que se escoja otra variante o se pulse el
botón STOP. Como puede apreciarse el control utilizado es un control ON-OFF (véase Anexo 1).
3.1.2 Diseño del sistema de control del Panel de Nivel utilizando GHENeSys.
Siguiendo la metodología presentada en el Capítulo 1, el primer aspecto a considerar es el estudio
del proceso a controlar y sus requerimientos (paso 1), que se corresponde con la fase de
especificaciones informales típicas de las aplicaciones con PLC’s.
De esta forma se determinó la secuencia correcta de operación del proceso en las diferentes
variantes (constituye el conjunto de cadenas deseadas a lograr en el modelo), los errores que
pueden ocurrir durante la operación (resultan los estados prohibidos indeseables en el modelo),
63
Capítulo 3.Aplicación de la metodología presenta en la automatización de ...
así como la cantidad y tipo de señales a considerar, entre las que se encuentran las relacionadas
con los sensores y que resultan señales de entrada al PLC (correspondiéndose con los eventos
observables, representándose en GHENeSys por Pseudoboxes) y los actuadores, que constituyen
señales de salida del PLC y están asociadas a las acciones de control (representándose por Boxes
en GHENeSys). Parte de esta información se presentó de forma resumida anteriormente.
Formalización.
Los pasos del 2 al 5 de la metodología están estrechamente relacionados, y se asocian a la fase de
formalización de las aplicaciones con PLC’s, garantizando con ello la obtención del modelo
idóneo. Estos pasos tienen como objetivo fragmentar el sistema en las menores unidades
funcionales posibles, definir los niveles de jerarquía en la estructura del modelo e identificar sus
interrelaciones entre los módulos (subredes) que la forman, correspondiéndose las unidades
funcionales definidas con las subredes, tratando de representarlas en un tipo de OPN lo más
sencilla posible, según lo permita la aplicación dada.
Siguiendo estos principios, la aplicación fue descompuesta en la siguiente estructura modular
jerárquica:
‰
Secuencia principal (selector Manual - Automático).
‰
Selección de las variantes de control.
‰
Variante 1: Tanque lleno.
‰
Variante 2: Alto - Medio.
‰
Variante 3: Medio - Bajo.
‰
Variante 4: Alto - Bajo.
‰
Llenar tanque.
‰
Vaciar tanque.
64
Capítulo 3.Aplicación de la metodología presenta en la automatización de ...
Todas estas unidades funcionales constituyen subredes modeladas con el nivel jerárquico que
indica el escalonamiento de la estructura presentada anteriormente. En los anexos aparece como
éstas quedaron finalmente, luego de todo el proceso de análisis y diseño (Véase Anexo 1).
Debemos mencionar que resulta difícil desde una etapa primaria del diseño, prever la cantidad
total de módulos, su nivel de jerarquía y sus interrelaciones, esto lo genera todo el estudio
ulterior, depurándose y refinándose gradualmente a medida que el proceso alcanza mayor alcance
y profundidad (diseño Top-down y Bottom-up).
Siguiendo los pasos señalados en la metodología, se logró modelar todas las subredes del sistema
no-controlado en la más sencilla de las OPN’s definidas; es decir, en redes Máquinas de Estado
(SM), pues todas las transiciones tienen un único arco de entrada y uno de salida [Murata89], al
permitirlo así el sistema que se analiza y hacer el correspondiente estudio del proceso.
También debemos señalar que en las redes obtenidas el número máximo de tokens en los lugares
es menor o igual a 1; o sea, M(p) ≤1 [Murata89, Piedrafita99], pudiendo modelar el grueso de las
redes dentro de las clasificadas como Condición/Evento. Esto, junto a lo mencionado
anteriormente (las redes SM obtenidas) garantizan un modelo lo más simple posible, y con ello
un análisis mucho más sencillo de sus propiedades, generando a su vez una mayor sencillez de las
etapas de verificación, validación e implementación posterior.
Al realizar la implementación del modelo a su programa correspondiente en lenguaje compatible
de la norma IEC1131, las subredes de mayor complejidad representan subprogramas o
subrutinas, los que se invocan siguiendo la secuencia que indica la jerarquía del modelo; es decir,
las subredes de mayor jerarquía encierran (encapsulan) subredes de menor jerarquía, éstas últimas
se invocarán en el programa siguiendo el encadenamiento implícito en el modelo.
Como se puede observar, se logró un modelo con alto nivel de modularidad y con varios niveles
de jerarquía, estando relacionadas las subredes solamente por aquella información que resulta
65
Capítulo 3.Aplicación de la metodología presenta en la automatización de ...
común a ellas (dada por los Pseudoboxes), logrando de esta forma alta independencia en el
modelo jerárquico, lo que redunda en facilidades de mantenimiento del programa obtenido, al
poder realizar cambios locales en las subredes, sin tener en la mayoría de los casos que modificar
el resto del programa, garantizando además una mayor transparencia de éste; es decir, una fácil
comprensión de lo que hace el programa, la cual mejora con el número de módulos y los niveles
que lo forman [Frey00.4].
En la etapa de formalización, y como se indicó en el Capítulo 2 al tratar el tema de diseño según
GHENeSys, para la conformación del modelo se adapta el método C-TPM [Uzam98] a la
metodología que aplicamos; es decir, para cada subred se sigue la secuencia de obtener
primeramente el modelo no-controlado, luego la definición de los estados prohibidos según las
reglas TPM, y posteriormente se obtiene el modelo controlado por la fusión de los pasos
anteriores.
Veamos cómo se aplica éste método seguidamente, escogiendo como ejemplo una de las
subredes, siendo esta la Variante 2(Alto - Medio).
La subred de Variante 2 es la correspondiente al control entre el medio y el tope del tanque. En
este caso, existen cuatro condiciones, el nivel esté en uno de los tres sensores o no, lo que
dependerá de la información que se obtiene de los sensores ALTO(1), MEDIO(2) o BAJO(3)
ubicados en la parte superior, medio e inferior del tanque respectivamente.
Como se observa en la Figura 3.2 solo se ha tenido en cuenta la secuencia del proceso nocontrolado y los Lugares son interpretados como estados del proceso no-controlado, y las
Transiciones como las transiciones de estado asociadas a algún evento de transición.
Luego se requiere definir los eventos observables del proceso (representados mediante
Pseudoboxes), los que actuarán sobre los eventos controlables (representados por transiciones
66
Capítulo 3.Aplicación de la metodología presenta en la automatización de ...
controlables en el modelo no-controlado), a los que llegan los arcos inhibidores o habilitadores
desde los Pseudoboxes.
Figura 3.2 Primera fase del diseño de la subred Variante 2.
Para esta unidad funcional, donde son varios los caminos a seguir, se escogerán uno de los
posibles, puesto que el análisis para los restantes es similar. Las especificaciones del proceso
controlado establecen que no se puede vaciar el tanque (abrir la electroválvula y cerrar la bomba)
hasta que no se active el sensor 1 indicando que el tanque se ha llenado. Es decir:
If tanque lleno
Then apagar bomba AND abrir electroválvula
En este caso el estado prohibido es el siguiente:
If tanque no lleno
Then apagar bomba AND abrir electroválvula
En el sistema no-controlado la regla TPM para uno de los posibles caminos sería:
If M(p1) = 1
Then T2 estará habilitada
67
Capítulo 3.Aplicación de la metodología presenta en la automatización de ...
El complemento de la regla TPM anterior sería:
If M(p1) = 0
Then T2 estará bloqueada
Pero como vemos, esta definición de las reglas no tiene en cuenta el nivel del tanque, solo la
secuencia de ejecución del sistema y tendríamos un conflicto entre los tres caminos. Por tanto,
deben considerarse los eventos observables (sensor 1) para la solución de éste. En la cadena
deseada sería tanque lleno y el estado prohibido sería que el tanque no estuviera lleno (sensor 1
desactivado). Por consiguiente, tenemos solo un estado inicial en el chequeo del nivel del tanque,
y se tiene en cuenta las señales externas (de los sensores) para resolver el conflicto.
Entonces las reglas TPM generadas de las dos situaciones serían:
De la Cadena deseada
Del Estado prohibido
If M(p1) = 1 AND M(PS2) = 1
If M(p1) = 1 AND M(PS2) = 0
Then T2 estará habilitada
Then T2 estará deshabilitada
De esta forma se adiciona al sistema no-controlado (Figura 3.2) los Pseudoboxes (eventos
observables) actuando sobre las transiciones controlables. Es decir, se agrega la habilitación de
T2 al activarse la señal del Pseudobox PS2.
Considerando el caso contrario en T2 (complemento) para cualquier estado de PS2, la transición
T2 está deshabilitada; en regla TPM sería:
If M(p1) = 0 AND ( M(PS2) = 1 OR M(PS2) = 0 )
Then T2 estará deshabilitada
Esto permite que el bloqueo de T2 permita que la bomba siga funcionando, para ello la transición
controlable T4 queda habilitada en M(p1) = 1 y los sensores deshabilitados, condición contraria a
T2, activando directamente el lugar P5 para mantener la vivacidad de la red y la secuencia de
68
Capítulo 3.Aplicación de la metodología presenta en la automatización de ...
operación del sistema controlado mediante un PLC (donde se chequea el tiempo máximo de cada
ciclo de ejecución).
Figura 3.3 Adición de Pseudoboxes al diseño utilizando el método C-TPM [Uzam98].
El mismo procedimiento anterior se siguió para las demás redes, obteniendo de esta forma el
modelo general del programa.
Verificación.
Posteriormente se siguieron los pasos del 6 al 8 de la metodología, los cuales están
interrelacionados, y se asocian a la fase de verificación, así como las correspondientes
modificaciones que sea necesario realizar para lograr redes vivas y seguras. Como ya se ha visto,
en esta etapa se propone aplicar el método de las reglas de reducción [Murata89, Bilinski94,
Desel&Esparza95] para la comprobación de estas propiedades verificando la buena conformación
de la red.
69
Capítulo 3.Aplicación de la metodología presenta en la automatización de ...
Veamos a continuación en la Figura 3.4, cómo se aplica este método de las reglas de reducción,
tomando nuevamente como ejemplo la subred Variante 2 (Alto-Medio).
Figura.3.4 Aplicación de las reglas de reducción a la subred Variante 2.
Como se puede observar en la figura anterior, la subred puede reducirse hasta lograr una red
mínima; es decir, solamente un lugar y una transición, garantizando con ello las propiedades de
vivacidad y seguridad deseadas.
Se pudo comprobar, cómo luego de todo el proceso de modificación, simplificación y
depuración, todas las redes obtenidas resultan redes bien-formadas (prácticamente se deduce por
simple inspección), y por ende, cumplen con las propiedades de vivacidad y seguridad,
obteniéndose por ello un modelo sintácticamente correcto (Véase Anexo 1).
70
Capítulo 3.Aplicación de la metodología presenta en la automatización de ...
Validación.
Luego de la fase de verificación ya vista anteriormente, continuamos el procedimiento
enmarcándonos en los pasos 9 y 10 de la metodología, los que se asocian a la fase de validación
del modelo, realizando la simulación del trabajo de cada subred auxiliándonos del asistente por
computadoras Visual Object Net ++ (VON) [Drath97, Drath98], comprobando de esta forma que
el funcionamiento de cada una de ellas se correspondiera con las exigencias del sistema,
recogidas en la etapa inicial de diseño. Lo cual se hizo hasta obtener la versión final (ver Figura
3.5), modificando el modelo convenientemente hasta lograr los objetivos que se persiguen con la
aplicación de estos métodos formales de diseño, comprobación y análisis.
En la Figura 3.5 se puede observar como se utilizan Macroboxes (Macrolugares en GHENeSys
[Glez&Silva01]) porque representan subredes de menor jerarquía, que ejecutan las acciones de
vaciar o llenar el tanque. Teniendo como ejemplo el caso de MP6 donde se manda a vaciar el
tanque (abrir electroválvula y apagar bomba) si el sensor 1 (PS2) se ha activado.
Figura 3.5 Modelo general verificado y validado de Variante 2.
71
Capítulo 3.Aplicación de la metodología presenta en la automatización de ...
En la Figura 3.6 se representa la subred asociada a la Selección de las Variantes, utilizándose de
la misma forma ya vista para su diseño, en el VON. En esta subred de Selección se observa el
Macroelemento MP3 que agrupa toda la subred de la Variante 2 analizada anteriormente (Figura
3.5).
Figura 3.6 Representación de la subred de Selección de Variantes del Panel de Nivel.
Se puede observar en esta Figura 3.6 que al iniciarse la red (P1) se dispara automáticamente la
transición T1 si se ha escogido la variante 2 (marcado Pseudobox PS10), y se ejecuta la subred
que en ese momento esté habilitada. En el caso representado en la figura, los Pseudoboxes PS7,
PS8 y PS9 están deshabilitados, por lo que solo se autoriza la ejecución de la Variante 2 (Alto Medio). Esta unidad funcional está encapsulada en el MacroLugar MP3, debido a que solo nos
interesa su habilitación y deshabilitación, pero no los detalles internos a este nivel de jerarquía.
72
Capítulo 3.Aplicación de la metodología presenta en la automatización de ...
Al completarse la operación de esta subred se dispara la transición T6, activando a su vez al lugar
P6; así sucesivamente ocurre para el resto de las variantes siempre que hayan sido seleccionadas.
Implementación.
Los últimos pasos (pasos 11 y 12 de la metodología) están relacionados con la fase de
implementación, y tienen como objetivo lograr la traducción del modelo obtenido a su
equivalente en los lenguajes de programación que admita el equipamiento escogido para la
aplicación. Esta traducción se realiza siguiendo los aspectos definidos en el Capítulo 2
(implementación de GHENeSys a lenguajes IEC1131 compatibles), realizándose comúnmente de
forma intuitiva por la sencillez del método.
En nuestro caso, al utilizar un PLC de la firma TELEMECANIQUE, estamos enmarcados a
realizar la programación en los lenguajes LD o GRAFET (similar al SFC), al no tener
desarrollada esta firma ninguna herramienta hasta el momento que permita otra forma de
programación de sus PLC’s. No obstante, la generalidad y concepción de la metodología
propuesta, y la capacidad de representación de GHENeSys, permiten utilizar cualquiera de los
lenguajes recogidos en la norma IEC1131, así como PLC’s de cualquiera de los fabricantes que
comercializan este tipo de equipamiento, estando limitado solamente en que sus prestaciones y
posibilidades permitan adaptarlos a la aplicación concreta que se analice.
En la Figura 3.7 se representa el programa en FBD/LD del control del Panel de Nivel valiéndonos
para ello de la metodología propuesta (Capítulo 2) y del programa ISaGRAF 3.3 de CJ
International [Bonfatti99].
En esta Figura 3.7 se observa la estructuración del programa en la ventana izquierda y la sección
de un programa para la simulación del proceso.
73
Capítulo 3.Aplicación de la metodología presenta en la automatización de ...
Figura 3.7 Programa en FBD/LD del control del Panel de Nivel utilizando el ISaGRAF 3.3.
Luego de la implementación se realiza la validación final del funcionamiento del sistema
controlado con ayuda de las facilidades que brinda el ISaGRAF 3.3 para esto.
En el Anexo 2 se ven los resultados de la simulación del sistema controlado con su Interfaz
Hombre- Maquina (HMI) de operación. Esto permitió la validación final haciéndose cumplir los
requerimientos del usuario.
3.2 Panel Gaseoso.
El Panel Gaseoso está formado por un tanque cilíndrico metálico que posee una entrada a través
de una válvula neumática normalmente abierta, y tres válvulas manuales de salida, cada una con
una resistencia diferente (Véase Figura 3.8). Para que esta instalación comience a funcionar sólo
74
Capítulo 3.Aplicación de la metodología presenta en la automatización de ...
debemos asegurarnos que el compresor esté en funcionamiento y como medida de seguridad una
de las válvulas de salida del tanque debe estar abierta.
El tanque tiene un sensor-transmisor de presión que le envía la información al PLC, dispositivo
que controla totalmente el sistema.
Figura 3.8 Panel Gaseoso.
3.2.1 Funcionamiento de la instalación.
La presión en el interior del tanque comienza a aumentar, esta se indica en un manómetro, y se
mide con un sensor-transmisor neumático de presión. El PLC (TSX17), recibe la información
transmitida por el sensor- transmisor a través del módulo de entrada analógica (TSX AEG-4110)
de ampliación del equipo. Según el programa elaborado para ello, envía su señal de control al
módulo de salida analógica (TSX ASG-2000) y éste al elemento de acción final (válvula
neumática) a través de un transductor electro- neumático.
75
Capítulo 3.Aplicación de la metodología presenta en la automatización de ...
En la instalación se mide, además, la presión inmediatamente antes y después de la válvula de
regulación, y a la salida del transmisor. Después de dos de las válvulas de salida del tanque se
encuentra instalado un rotámetro, que indica el flujo de aire que se escapa a la atmósfera.
3.2.2 Diseño del sistema de control del Panel Gaseoso utilizando GHENeSys.
Para obtener el modelo de esta instalación se siguieron los pasos de la metodología propuesta en
el Capítulo 1, y en el desarrollo del modelo del Panel de Nivel explicado en el epígrafe anterior.
Por lo tanto no se entrará en muchos detalles de los pasos seguidos y se expondrán directamente
algunos resultados.
Formalización.
Según los pasos del 2 al 5, buscando las menores unidades funcionales posibles, se definen los
niveles de jerarquía en la estructura del modelo y se identifican sus interrelaciones entre las
subredes que la forman.
La aplicación del Sistema del Panel Gaseoso fue descompuesta en la siguiente estructura modular
jerárquica:
‰
Secuencia Principal (Selector Manual- Automático).
‰
Automático.
‰
‰
Control PI discreto.
Manual
‰
Presión hacia la válvula
76
Capítulo 3.Aplicación de la metodología presenta en la automatización de ...
Todas estas unidades funcionales constituyen subredes independientes modeladas con el nivel
jerárquico que se indica. En los anexos aparecen los modelos de estas subredes luego de todo un
proceso de análisis y refinamiento para lograr su diseño final (Véase Anexo 3).
En la formalización del modelo, como se indicó en el Capítulo 2 y luego se aplicó con
anterioridad a este epígrafe, al tratar el tema de diseño para la conformación del modelo se adapta
el método C-TPM [Uzam98] a la metodología que aplicamos. Veamos cómo se aplica éste
método escogiendo como ejemplo la subred de la Secuencia Principal que es la Selección de
Manual – Automático (Figura 3.9).
Figura 3.9 Proceso no-controlado de la subred de Selección Manual-Automático.
Según las especificaciones del proceso controlado, el control será Automático (si el selector así lo
indica) como lo representan las siguientes reglas de cadenas deseadas:
If automático
If no automático
Then Control
Then Manual
77
Capítulo 3.Aplicación de la metodología presenta en la automatización de ...
En cada caso el estado prohibido es el siguiente:
If no automático
If automático
Then Control
Then Manual
En el sistema no-controlado la regla TPM sería:
If M(p1) = 1
Then T2 estará habilitada
El complemento de la regla TPM anterior sería:
If M(p1) = 0
Then T2 estará bloqueada
Pero para poder representar realmente las reglas definidas se deben adicionar al sistema nocontrolado (Figura 3.9) los Pseudoboxes actuando sobre las transiciones controlables. Se agrega
la habilitación de T2 solo al activarse la señal del Pseudobox PS5 que tiene su estado asociado al
estado del selector manual - automático de la HMI del sistema (Figura 3.10).
Figura 3.10 Adición de Pseudoboxes al diseño utilizando el método C-TPM [Uzam98].
78
Capítulo 3.Aplicación de la metodología presenta en la automatización de ...
Las reglas TPM quedarán de la siguiente forma:
Cadenas deseadas
If M(p1) = 1 AND M(PS5) = 1
If M(p1) = 1 AND M(PS5) = 0
Then T2 estará habilitada
Then T1 estará habilitada
Estados prohibidos
If M(p1) = 0 OR M(PS5) = 0
If M(p1) = 0 OR M(PS5) = 1
Then T2 estará deshabilitada
Then T1 estará deshabilitada
Verificación.
En la fase de verificación (pasos del 6 al 8) aplicamos el método analítico del Teorema del
Rango [Desel&Esparza95] mediante la caracterización de Redes Libre-Selección BienFormadas. Esto se hace para demostrar la utilidad de este otro método, aunque por la simplicidad
de nuestras redes es más recomendable el método de Reducción.
En la verificación mediante este método, como se explicó en el Capítulo 2 y se demostró
mediante un ejemplo, se siguen los puntos del Teorema del Rango (Teorema 6.14) para
comprobarse que la red es bien formada y cumple con todas las propiedades que la caracterizan.
Como Ejemplo para la verificación en el Panel Gaseoso se escogió la subred del Programa
Principal (Figura 3.9).
Siguiendo el procedimiento descrito en el Capítulo 2 sobre el Teorema del Rango, se determina la
Matriz de incidencia A del modelo no-controlado, para obtener las invariantes del sistema.
1
0⎤
⎡− 1 − 1 0
⎢0
1 −1 0
0 ⎥⎥
A4x5 = ⎢
⎢0
0
1 −1 1 ⎥
⎢
⎥
0
0
0 − 1⎦
⎣1
79
Capítulo 3.Aplicación de la metodología presenta en la automatización de ...
A partir de la matriz A se buscan las soluciones del sistema de ecuaciones homogéneas A x Y = Ø
y
AT x X = Ø. Aplicando el método de Gauss al sistema matricial se obtiene:
Invariantes S
Invariantes T
X2 = X4
Y1 = Y5
Y2 = Y4 − Y5
X3 = X4
Y3 = Y4 − Y5
X1 = X 4
Dadas las infinitas soluciones (X, Y ≥1), se muestran algunos resultados:
⎡1⎤
⎢1⎥
X =⎢ ⎥
⎢1⎥
⎢⎥
⎣1⎦
⎡2⎤
⎢2⎥
, ⎢ ⎥ ...
⎢2⎥
⎢ ⎥
⎣2⎦
Y = [1 1 1 2 1] , [2 1 1 3 2]...
El que todas las soluciones de las invariantes S de lugar tengan todos sus elementos diferentes de
cero se interpreta, como que todos los elementos de la red pertenecen a conjuntos donde se
conserva el número de tokens y eso es importante desde el punto de vista de control automático
(garantiza entre otras, la propiedad de limitabilidad). En las invariantes T de transición donde
todas tengan también sus elementos diferentes de cero, indica que el número de disparos de cada
transición es finito y distinto de cero, o sea, que no se quedará en un ciclo infinito (libre de
bloqueos) y que todas participan en los caminos entrada/salida (no hay fuentes ni sumideros) lo
que implica cumplimiento de vivacidad de la red.
Conociendo el número de clusters de la red (Figura 3.11), |Cn| = 4, comprobamos si se cumple
que Rank(A) = |Cn| - 1 = 3. Realizada una verificación previa en el MATLAB, el rango de A es
3, por lo que se demuestra que la red es bien-formada, y que cumple con las propiedades de
limitabilidad, vivacidad e invariantes S y T.
80
Capítulo 3.Aplicación de la metodología presenta en la automatización de ...
Figura 3.11 Partición de la red en 4 clusters.
Validación.
Siguiendo los pasos 9 y 10 de la metodología, asociados a la fase de validación del modelo, se
simularon las subredes en el VON, comprobando que el funcionamiento de ellas se correspondía
con las exigencias del sistema, recogidas en la etapa inicial de diseño.
Figura 3.12 Modelo general verificado y validado de la Selección de Manual-Automático.
81
Capítulo 3.Aplicación de la metodología presenta en la automatización de ...
En el modelo general se observa como se utilizan MacroLugares para representar subredes de
menor jerarquía, como Control (MP2) y Manual (MP4) (Véase Anexo 3).
Implementación.
La fase de implementación tiene como objetivo obtener la traducción del modelo a su equivalente
en lenguaje de programación IEC1131 compatible, siguiendo la metodología descrita en el
Capítulo 2.
En la Figura 3.13 se representa el programa en FBD/LD del controlador PI realizado en ISaGRAF
3.3 utilizado en el control del Panel Gaseoso.
Figura 3.13 Programa en LD IEC1131 compatible del controlador PI del Panel de Gaseoso utilizando el
ISaGRAF 3.3.
82
Capítulo 3.Aplicación de la metodología presenta en la automatización de ...
En esta Figura 3.13 se observa la estructuración del programa en la ventana izquierda y la sección
del programa del controlador PI desarrollado en un proyecto anterior.
En el Anexo 4 se ven los resultados de la simulación del sistema controlado con su Interfaz
Hombre- Maquina (HMI) de operación desarrollada en ISaGRAF 3.3. Esto permitió la validación
final haciéndose cumplir los requerimientos del usuario. La HMI permite tanto el inicio del
control y si la operación será manual o automático, como la introducción de la referencia.
3.3 Ventajas del método formal de diseño en OPN’s.
La implementación de modelos de automatizaciones sobre Redes de Petri, específicamente las
OPN’s, y su traducción a programas en lenguajes de PLC’s IEC1131 compatibles, es un tema que
será incorporado en la asignatura Sistemas Automatizados de 5to año de la especialidad y dentro
del postgrado. En este trabajo se abordan las cuestiones teóricas y se muestra su aplicación en
sistemas reales, lo que será utilizado en las conferencias y clases prácticas de este tema en la
asignatura.
El desarrollo de los modelos en OPN’s y su traducción a lenguajes de programación IEC1131
compatibles para su implementación en las dos instalaciones de laboratorio, posibilita la
optimización y reutilización tanto del modelo como del programa. En el caso del Panel de Nivel,
las Variantes pueden ser reutilizadas por los estudiantes en el diseño de otras versiones de control
para esta instalación. Así como la red ProgPcpal (Panel Gaseoso), que básicamente es una red de
selección (dos posiciones) Manual-Automático, puede reutilizarse para encender-apagar, abrircerrar,
etc., pues la estructura es la misma. La alta modularidad y transparencia de la
programación permite que todo el programa ya validado sea reutilizado en otros procesos de
operación similar.
83
Capítulo 3.Aplicación de la metodología presenta en la automatización de ...
La aplicación de la modularidad y las facilidades de los Pseudoboxes y Macroelementos de
GHENeSys, evitaron la explosión de estados al permitir el análisis de vivacidad, seguridad,
ausencia de deadlocks, etc., en subredes propias pequeñas. La modularidad contribuye además, a
simplificar el modelo y el programa resultante, pues al no quedar estos tan grandes (como
resultarían sin el empleo de las macros y los subprogramas o bloques funcionales), se facilita su
estudio y comprensión. La comprobación de estas propiedades constituye una garantía en el
diseño del programa finalmente obtenido y aplicado, pudiéndose comprobar que éste resulta
seguro y libre de bloqueos.
El modelo generado, verificado y validado sobre el Visual Object Net++ y el programa resultante
de éste, es posible aplicarlo en otros muchos sistemas, garantizando la continuidad de la
experiencia de diseño formal de automatizaciones con PLC’s.
La alta compatibilidad de los elementos del modelo con los componentes de programación a
cualquiera de los lenguajes estándares IEC1131 permitió la rápida traducción de todo el sistema
de control para su implementación.
84
Valoración Económica
VALORACIÓN ECONÓMICA.
En la realización de un trabajo ya sea en la esfera productiva como en la no productiva, es
necesario una valoración económica que justifique la realización del mismo.
Para realizar la valoración económica fue empleado un método llamado Modelo Constructivo de
Costo (COCOMO), basado en estimaciones matemáticas y utilizado para calcular los costos “a
priori” de los sistemas de cómputo, así como su tiempo de desarrollo, atendiendo a las etapas
definidas para los mismos.
Este método define una serie de parámetros y ecuaciones que posibilitan tener una idea de cuanto
se invierte en el desarrollo de un trabajo programativo. Estos parámetros son:
Tdes: Tiempo de desarrollo total.
Ks:
Kilo sentencias (1Ks se describe como promedio en 5 días).
CFT: Cálculo diario del costo de la fuerza de trabajo.
TFT: Tarifa de fuerza de trabajo por hora (Para un programador “A” el TFT=$4.90).
CTM: Cálculo diario del costo del tiempo de máquina.
TTM: Tarifa del tiempo de máquina . Para una microcomputadora es de $7.69 h.
Esta tarifa de tiempo de máquina incluye la amortización de su costo de producción y su
aprovechamiento.
El valor económico del aseguramiento programativo se calcula de la forma siguiente:
‰
Tiempo de desarrollo total del software:
Tdes = Ks • 5días
donde Ks = 12
Tdes = 12 • 5días
Tdes = 60 días
85
Valoración Económica
‰
Cálculo diario del costo de la fuerza de trabajo:
CFT = TFT • 8h/días
CFT = 0 • 8h/días
CFT = 0
‰
Cálculo diario del costo del tiempo de máquina:
CTM = TTM • 8 horas/días
CTM = $7.69 • 8 horas/días
CTM = $61.52
Cálculo del tiempo de desarrollo por etapas:
- Factibilidad (tiempo empleado en la investigación o análisis para desarrollar el software):
TF = (30• Tdes)/100
TF = (30 • 60 días)/100
TF = 18 días.
- Diseño:
- Implantación (puesta a punto del
TD = (45 • Tdes)/100
software):
TD = (45 • 60 días)/100
TI = (25 • Tdes)/días
TD = 27 días.
TI = (25 • 60)/días
TI = 15 días.
Cálculo de los costos por etapas:
- Factibilidad:
CF = CFT • TF
CF = 0 .
- Diseño:
- Implantación:
CD = (CFT+CTM) • TD
CI = (CFT+CTM) • TI
CD = (0+$ 61,52) • 27 días
CI = (0+$ 61.52) •15 días
CD = $ 1661,04.
CI = $ 922,8
86
Valoración Económica
El Costo del trabajo por software es:
CT = CF+CD+CI
CT = 0 + 1661,04. + 922 ,8
CT = $ 2583,84
El costo total del soporte programativo es de $ 2583,84 en moneda nacional.
La cantidad de días empleados para las diferentes etapas no es el mismo que si fuera desarrollado
por un personal altamente calificado. Esto se debe a que en el tiempo de factibilidad fue necesario
emplear tiempo de estudio en la revisión de varios trabajos que abordan el tema.
A manera de conclusión cabe destacar que la simulación por computadoras de los modelos
permite establecer la estrategia de control de ante mano haciendo cumplir las especificaciones.
Esto ayuda a evitar riesgos directos que se tuviesen al ejecutar la operación sobre el sistema real.
Disminuye tiempo, por lo tanto acorta los ciclos de trabajo, ajuste y puesta en marcha lo cual
incide en hacer más pequeños los intervalos de incertidumbre a su vez trae consigo aumentar la
confianza al inversionista. No existen actualmente ramas de la técnica que al trabajar sobre la
introducción de nuevos métodos no conciba una concepción previa de simulación del proceso.
Todo proyecto para que resulte atractivo tanto a los usuarios como a los patrocinadores del
mismo debe reflejar un estudio anterior que no podría lograrse con efectividad si no se hiciese
mediante la simulación del mismo.
Todo el trabajo desarrollado sobre estas dos instalaciones de laboratorio permite que los
estudiantes de la especialidad dispongan de experiencias prácticas que los formen bajo estos
principios.
87
Conclusiones
CONCLUSIONES
En este trabajo se presenta una metodología general de modelado, verificación, validación y
programación de automatizaciones con PLC’s. Se dan las bases teóricas generales del modelo
para soportar el trabajo con la red jerárquica GHENeSys.
El modelo se adecua para cualquier aplicación sobre PLC’s utilizando las facilidades de los
Pseudoboxes y Macroelementos de Ghenesys, permitiendo crear un modelo jerárquico con alto
nivel de modularidad similar a lo propuesto en la IEC1131 para programas de PLC’s
Se recoge una amplia revisión bibliográfica, que comprende tanto la teoría y definiciones, como
la actualidad internacional en esta significativa área de aplicación de las PN’s. Se explica en qué
consisten los métodos formales y su aplicación al campo de los PLC’s, así como toda la teoría
sobre la que se sustenta la formalización en PN’s.
Se explica la metodología de traducción de este modelo para lenguajes IEC1131 compatibles, lo
que garantiza la implementación y reinterpretación automática de cualquier aplicación sobre
PLC’s.
Todo esto sirvió de base para aplicar dicha metodología en dos instalaciones del Laboratorio de
Control de Procesos en la UO. Se va explicando la ejecución de cada paso de la metodología en
las dos instalaciones con el objetivo de demostrar su efectividad y que quede una herramienta
didáctica para su utilización docente. De acuerdo a esto se puede concluir que se logro demostrar
la aplicación del método formal de diseño sobre instalaciones reales de laboratorio, aspecto poco
abordado de esta forma en la comunidad científica internacional sobre PN’s. Además se sentaron
88
Conclusiones
las bases requeridas para la enseñanza de esta metodología para la docencia de pre y postgrado,
tanto en los aspectos teóricos como prácticos.
Este análisis realizado a dos instalaciones donde se realizan prácticas de laboratorio, se puede
aplicar totalmente a otros procesos de operación similar que cumplen los mismos requisitos
funcionales o adecuar las experiencias según sea el caso, contribuyendo de esta forma a la
optimización, además de permitir su reutilización y su fácil traducción a las formas de
programación de PLC’s, estandarizadas en la norma internacional IEC1131.
89
Recomendaciones
RECOMENDACIONES
‰
Continuar investigando en esta importante aplicación de las PN’s a los sistemas con PLC’s,
específicamente en la red extendida GHENeSys y su aplicación en las restantes instalaciones
de laboratorio gobernadas con PLC’s de que dispone la UO.
‰
Desarrollar una herramienta por computadoras que garantice las exigencias de GHENeSys,
permitiendo la comprobación automática de las propiedades del modelo editado sobre ella, así
como su traducción directa a lenguajes estándares IEC1131.
‰
Divulgar la utilización de las técnicas formales en los sistemas de automatizaciones con
PLC’s, mostrando las ventajas de la utilización de estos métodos. Continuando el fructífero
intercambio entre las Universidades, Empresas e Instituciones que lo requieran en sus
aplicaciones.
90
Bibliografía
BIBLIOGRAFÍA
1. [Ajmone95] Ajmone M., Marco. "An introduction to generalized Stochastic Petri Nets".
Dipartimento di Elettronica. Politecnico di Torino, Italy. Second International Course on Petri
Nets for Latin America. Campina Grande, PB, Brazil. November 1995.
2. [Benitez&Silva&Glez01] Benítez, I., Silva J., Reinaldo. González, P. "Modelado en Redes de
Petri para la optimización de la automatización de hoteles". Matanzas, Cuba, sept. 2001.
3. [Bernardinello92] Bernardinello, L. DeCindio, F. "A survey of basic net models and modular
net classes". Lecture Notes in Computer Science 609, Springer-Verlag, 1992.
4. [Bonfatti99] Bonfatti, F., Monari, P.D., Sampieri, H. "IEC 1131-3 Programming
Methodology". Fundamentals of Computer Science. University of Modena. Italy. Published
by CJ International. 1999.
5. [Cutts92] Cutts g, Rattigan S. "Using Petri Nets to develop programs for PLC systems". Proc.
Application and theory of PN. Vol 616. Springer 1992.
6. [Couffin99] Lamperiere-Couffin, S. Rossi, O. Roussel, J.M. Lesage J.J. " Formal validation
of PLC programming: A survey". University laboratory in Automated Production Research.
Ecole Normale Superieure de Cachan. France. Proceeding of ECC`99, 1999.
7. [David92] David, R. Alla, H. "Petri Nets and Grafcet – Tools for modelling Discrete Event
Systems. Prentice hall, New York, London. 1992.
8. [Desel&Esparza95] Desel, Jorg. Esparza, Javier. "Free Choice Petri Nets". Cambridge
University Press. Great Britain. 1995.
9. [Desrochers95] Desrochers AA, Al-Jaar RY. "Application of PN in Manufacturing systems".
IEEE Press, Piscataway, USA. 1995.
10. [DiCesare93] DiCesare, F.: “Practice of Petri Nets in Manufacturing”. London Chapman &
Hall. New York. 1993.
11. [Drath98] Drath, R. "Hybrid Object Nets: An Object Oriented Concept for Modeling
Complex Hybrid Systems". In: Hybrid Dynamical Systems. 3rd International Conference on
Automation of Mixed Processes. ADPM'98. Reims. 1998.
12. [Elio02] Avila, E. "Modelado en PN’s en Automatizaciones con PLC’s de la industria
91
Bibliografía
azucarera". Tesis de Maestría. Departamento de Automática. Universidad de Oriente.
Santiago de Cuba. 2002.
13. [Esparza&Silva90] Esparza, J. Silva, M. "Top-Down Synthesis of Live&Bounded Free
Choice Nets". Proc. of 11th International Conference on Petri Nets. Paris. 1990.
14. [Frey98] Frey, G. Litz, L. "Verification and Validation of Control Algoritms by Coupling of
Interpreted Petri Nets". Proceedings of the IEEE. SMC 1998. San Diego. October 11-14.
1998.
15. [Frey00] Frey,G. Litz, L. "Formal methods in PLC programming". Proceedings of the IEEE
SMC 2000. Nashville, TN. October 08-11, 2000.
16. [Frey00.1] Frey, G. "Automatic Implementation of Petri net based Control Algorithms on
PLC". Proceedings of the American Control Conference ACC 2000. Chicago. June 28-30,
2000.
17. [Frey00.2] Frey, G. "Analysis of Petri Net based Control Algorithms - Basic Properties".
Proceedings of the American Control Conference ACC 2000. Chicago. June 28-30, 2000.
18. [Glez01] Glez, P. "GHENESYS: Uma Rede Estendida Orientada a Objetos para o Projeto de
Sistemas Discretos". M.Sc. Thesis. Departamento de Engenharia Mecánica-Mecatrónica.
Universidad de Sao Paulo. 2001.
19. [Hasegawa, 87] Hasegawa, K. "Simulation of Discrete Production Systems Based on Mark
Flow Graph". System Science. Vol. 13. Poland. 1987.
20. [Holloway97] Holloway, L.E. Krogh, B.H. Giua, A. "A Survey of Petri Net Methods for
Controlled Discrete Event Systems". Journal of Discrete Event Dynamic Systems, Vol 7 No.
2. 1997.
21. [Lewis98] Lewis, R.W. "Programming industrial control systems using IEC 1131-3". IEE
Control Engineering Series 50. United Kingdom. 1998.
22. [Murata89] Murata, Tadao. "Petri Nets: Properties, analysis and applications". Proceedings of
IEEE, vol. 77, No. 4. April, 1989.
23. [Piedrafita99] Piedrafita, R. "Ingeniería de la Automatización industrial" Editorial RAMA.
España. 1999.
92
Bibliografía
24. [Ramos&Silva99] Ramos, RLCB. Silva JR. "An Integron based architecture for the modeling
of complex dynamic systems". Proc. IV SBAI, Sao Paulo, Brasil. 1999.
25. [Reising82] Reisig, Wolfgang. "Petri Nets, An introduction". Springer-Velarg. 1982.
26. [Silva00] Silva M. "Place Transition II”
Tutorial “Petri Nets 2000". 21st International
conference on application and theory of PN’s. Aarhus Denmark June 26-30. 2000.
27. [Stanton96] Stanton, MJ. Arnold, WF. Buck, AA. "Modellingand control of manufacturing
systems using PN". Proc. Of 13th IFAC World Congress. 1996.
28. [Thiagarajan86] Thiagarajan, P.S. "Elementary net systems" The Institute of mathematical
Sciences. Madras. India. Lecture Notes in Computer Science, Vol.224. Springer-Verlag,
1986.
29. [Tourlas96] Tourlas, K. "Semantic Analisys and Design of Lenguages for PLC’s". M.Sc.
Thesis. Department of Computer Science. The University of Edinburgh. 1996.
30. [Uzam98] Uzam, M. Jones, AH. "Discrete Event Control System design using automation PN
and their ladder diagram implementation". Journal of Advanced manufacturing systems,
special issue on PN application in manufacturing systems Vol14 No10. 1998.
31. [Uzam98T] Uzam, Murat. "Petri Net Based Supervisory Control of Discrete Event Systems
and their Ladder Logic Diagram Implementations". Ph. D. Thesis. University of Salford. UK.
1998.
32. [Venkatesh95] Venkatesh, K. Zhou, MC. Caudill, RJ. "Discrete event control design for
manufacturing systems via ladder logic diagrans and PN. A comparative study". MC Zhou:
"PN in flexible and agile automation". Kluwer academic publish.1995.
33. [Zhou & DiCesare93] Zhou, M. DiCesare, F. "PN Synthesis for Discrete Event Control of
Manufacturing Systems". Boston MA. Kluwer Academic Publisher. 1993.
34. [Zhou95] Zhou, M. "PN in Flexible and Agile Automation" Boston MA. Kluwer Academic
Publisher. 1995.
93
Anexos
ANEXOS
Anexo 1. Modelo en Redes de Petri del Panel de Nivel.
Subred Programa Principal
Subred Variante 1
Subred Selección de Variantes
94
Anexos
Subred Variante 2
Subred Variante 3
95
Anexos
Subred Variante 4
Subred Llenar
Subred Vaciar
Subred Apagar
96
Anexos
Anexo 2. Programación en FBD/LD y Simulación en ISaGRAF 3.3 del Panel de Nivel.
Programa Principal
Selección de Variantes
97
Anexos
Variante 1
Variante 2
Variante 3
Variante 4
98
Anexos
Simulación
99
Anexos
Anexo 3. Modelo en Redes de Petri del Panel Gaseoso.
Manual
Subred Programa Principal
Subred Control PI
Subred PI
100
Anexos
Anexo 4. Programación en FBD/LD y Simulación en ISaGRAF 3.3 del Panel Gaseoso.
Programa principal
Control
Manual
101
Anexos
Simulación
102