bibing.us.esbibing.us.es/proyectos/abreproy/3713/fichero/proyecto+julián... · Índice capítulo...
TRANSCRIPT
Escuela Superior de Ingenieros de Sevilla
VILLALOBOS GARCIA Julián
PROYECTO FIN DE CARRERA
Asistencia a la generación automática demodelos de evaluación de eficiencia defuncionamientoProfesor Tutor : Dr. Jesús Portillo García-PintosPromotion : 2003/2004
PREFACIO
El presente proyecto fue desarrollado en el departamento de Ingeniería Industrial del
INSA (Instituto Nacional de Ciencias Aplicadas) de Lyón. El estudio, realizado para la
sociedad petrolera TOTAL, fue propuesto al Laboratorio de Automática Industrial de la
escuela.
El contenido a desarrollar en el proyecto fue acordado por la sociedad TOTAL, el tutor
y el autor del mismo. Trata sobre la generación automática de modelos de evaluación de
eficiencia de funcionamiento.
Índice
Capítulo 0. Introducción a la memoria ……………… ….…….………….................5
Capítulo 1. Introducción general ……………………………………….…………....... 8I. Problemática ………………………………………………………………………....…8II. El grupo TOTAL………………………………….....……………….…………......… 10III. Presentación del proyecto……………………………………..………………………12IV. Organización de la memoria ………………………………………………………… 13
Capítulo 2. Seguridad de funcionamiento y sistemas de eventos discretos................. 14I. Introducción …………………………………………………. ………………….….… 14II. Seguridad de funcionamiento………………………...............…………………..…… 14III. Teoría de lenguajes y autómatas a estados…………. …............……………….…… 16
III.1 Lenguajes y autómatas …......…………. …………………………………... 16III.1.1 Lenguajes formales……..…………………………..............……... 16III.1.2 Ejemplo……. …………………………………………………….. 17III.1.3 Prefijo de una cadena.……………………………………. .…..….. 17III.1.4 Modelos autómatas…….…………………..…………..............… 18
III.2. Representación de autómatas. ……………………..….......……………...…19III.3. Control por supervisión dinámica de sistemas de eventos discretos.............. 20
III.3.1 Modelo del proceso y especificaciones……… ……………………21III.3.2. Principios del control por supervisión ………...………………..... 21III.3.3 Definición de un controlador…………………………….……….. 22III.3.4 Ejemplo de control por supervisión.. ……….……………………. 22
IV. Redes de Petri……………………………………………......................………….... 25IV.1 Definición. Ejemplos……………………………………….......…………............... 25
IV.2 Red de Petri estocástica (RdPS)….…………………………..…..……........ 28IV.2.1 Definición…………………………………………........................ 28IV.2.2 Ejemplo de RdPS………………………………….. .............….. 29
V. TCT, UMDES, MOCA RP............................................................................................ 31V.1 Elección entre UMDES y TCT………………………………..........……...... 31
VI. Conclusión…………………………………………………………………….………33
Capítulo 3. Aplicación a un modelo de producción de hidrocarburos……........…….34I. Introducción……………………………………………………………………...…….. 34II. Presentación de la aplicación ………………………………………….……………… 35III. Presentación de los modelos autómatas..……………...……...………….…………... 37
III.1 Línea A...............................................................................….…...........….... 37III.2 Línea B ……………………………………………………....……................39III.3 Resultados de UMDES …..........................……………………….........……41
III.3.1 Línea A …………........................………………….........................41III.3.2 Línea B ………………..……............….............….......................... 42
IV. Especificaciones de productividad……...............................……………………....…. 43IV.1 Línea A ....…………………….............……………………. ……….......... 43IV.2 Línea B …....………................…………………………………..…............. 46
V. Especificaciones de mantenimiento………………………………………..…………. 48
V.1 Línea A…………….………………………………………………………….49V.2 Línea B……….…………………….………………………………………... 53
VI. Especificaciones de funcionamiento…………………………………………………. 56VI.1 Línea A…………………………………………………………………........ 56VI.2 Línea B………………………………………………………………............ 59
VI.2.1 Especificaciones de mantenimiento……………………………… 60VI.2.2 Especificaciones de reconfiguración……………………………… 62VI.2.3 Resultado: modelo autómata……………………………………… 64
VII. Conclusión…………………………………………………………………………... 66
Capítulo 4. Conclusión general y perspectivas……........…......…................................. 67
Glosario …………………………………………………………………………………..70
Bibliografía…………………………………………………………………………….... 76
Anexo 1. UMDES_LIB…………………………………………………………………..78
Anexo 2. MOCA-RP…………………………………………………………………..…86
Anexo 3. Modelo de la línea B en UMDES……………………………………………. 90
Anexo 4. TCT…………………………………………………………………………… 95
Anexo 5. Evolución del modelo………………………………………………………… 103
Anexo 6. Continuación del proyecto……………………………………………………145
Anexo 7. Programa de conversión del grafo de estados ………………………………164
Anexo 8. Programa de conversión de la red de Petri ………………………………… 168
Anexo 9. Fichero de salida de la primera macro Visual Basic ……………………… 175
Anexo 10. Fichero de salida SYNET..………………………..…………………………179
Anexo 11. Fichero de salida de la segunda macro Visual Basic………………………182
Anexo 12. Fichero de resultados tras simulación en MOCA RP…………………….. 185
5
Capítulo 0
Introducción a la memoria
La memoria que sigue a continuación corresponde al proyecto “Asistencia a la
generación automática de modelos de evaluación de eficiencia de funcionamiento”.
Dicho proyecto fue desarrollado en el Laboratorio de Automática Industrial (LAI) del
INSA (Instituto Nacional de Ciencias Aplicadas) de Lyón entre los meses de
Septiembre de 2003 y Marzo de 2004 y defendido ante un tribunal con fecha 30 de
Marzo de 2004. La memoria original en francés constaba de cuatro capítulos más
algunos anexos. El proyecto ha sido traducido al castellano por el mismo autor. Para su
mejor comprensión, este capítulo cero ha sido añadido, así como diversos anexos en los
que se muestra la evolución de los trabajos, y su continuación tras el proyecto.
Este capítulo de introducción, explica brevemente los objetivos y las
conclusiones del proyecto. Para el lector interesado, se recomienda leer los capítulos
uno al cuatro correspondientes a la memoria entregada en Lyón. Para seguir
profundizando aun más en el estudio, los anexos cinco (evolución del modelo) y seis
(continuación del proyecto) explican en detalle la línea seguida en nuestros trabajos, y la
continuación a los mismos en el LAI del INSA de Lyón.
La idea inicial del proyecto surge de la colaboración entre el departamento de
ingeniería de producción del INSA y la sociedad petrolera TOTAL. El industrial utiliza
para realizar simulaciones de sus sistemas de producción de hidrocarburos una
herramienta llamada MOCA RP. Ésta simula el comportamiento de sistemas dinámicos
con el fin de obtener, mediante un tratamiento estadístico, resultados sobre fiabilidad,
disponibilidad y productividad. El sistema a estudiar es modelado bajo la forma de
redes de Petri estocásticas que sirven de soporte para la simulación de Monte-Carlo
clásica. El problema de base que encuentra la sociedad TOTAL es la complicación que
conlleva la construcción de los modelos de gran talla sobre redes de Petri. Los modelos
de comportamiento de los sistemas manipulados pueden con facilidad adquirir tamaños
enormes (el espacio de estados aumenta de forma
6
exponencial con el número de modelos elementales que constituyen el proceso)
haciendo de la construcción de dichos modelos un proceso arduo y difícil.
Para resolver este inconveniente, el Laboratorio de Automática del INSA de
Lyón propone utilizar la teoría del control por supervisión y, en concreto, la síntesis de
controladores para solucionar este problema. Utilizando el formalismo de los autómatas
a estados, pretendemos obtener modelos de comportamiento capaces de ser simulados
posteriormente, con el fin de optimizar la producción. Una vez obtenidos estos modelos
en forma de autómatas a estados, será necesario realizar la traducción autómata-red de
Petri para proceder a la simulación sobre MOCA RP.
Así, podemos dividir el proyecto global en tres fases. La primera, realizada por
el autor de esta memoria, consistente en utilizar la síntesis de lenguaje de autómatas a
estados para definir una metodología para la construcción de modelos de
comportamiento de sistemas productivos, y la construcción de un ejemplo concreto
propuesto por el grupo Total. Esta fase, correspondiente a nuestro proyecto propiamente
dicho, se encuentra desarrollada en la memoria. La segunda fase, realizada parcialmente
en el momento de la redacción de este documento en el laboratorio de Automática del
INSA de Lyón, consistente en realizar la traducción de autómatas a redes de Petri para
la obtención de un modelo simulable por MOCA RP. Una referencia sobre la situación
actual de los trabajos en esta línea se encuentra en el anexo seis. Finalmente la última
fase corresponde a la sociedad TOTAL. Esta tercera fase conllevaría la explotación de
los resultados obtenidos en el diseño de nuevas instalaciones, y en la modificación de
instalaciones ya existentes.
La teoría de control por supervisión que vamos a utilizar, emplea el concepto de
evento controlable y evento no controlable para realizar la síntesis de leyes de control.
Nosotros pretendemos alargar su dominio de aplicación asociándole, por ejemplo, tasas
de productividad a cada estado con el fin de obtener un modelo simulable. La principal
astucia del planteamiento por síntesis desarrollado en nuestro trabajo radica en la
distinción realizada entre el sistema a evaluar y sus especificaciones de funcionamiento.
De un lado se diseñarán los modelos de los componentes básicos del sistema por
separado, y de otro lado se diseñaran las especificaciones (imposiciones) de
funcionamiento. Una vez hecho esto y utilizando el programa adecuado (UMDES), es
7
posible acoplar los modelos automáticamente. Como veremos este enfoque permite
simplificar enormemente la etapa de modelado. Además, es relativamente fácil y rápido
realizar cambios sobre un modelo ya construido.
Una vez desarrollado el método, hemos procedido a la construcción de un caso-
ejemplo proporcionado por el grupo TOTAL (ver capítulo tercero). Este caso simple,
contiene estructuras combinación de serie y paralelo. Cualquier otro caso real no será
más que una combinación de dichas estructuras. Para una visión en profundidad de la
evolución del modelo consultar el anexo cinco. Este modelo prueba que la teoría de
control por supervisión es también válida para la construcción de modelos de
comportamiento. En este punto se dio por concluido el proyecto. A continuación
comenzó la segunda fase mediante otro proyecto fin de carrera en el seno del
laboratorio. Dicho proyecto se encuentra en fase de desarrollo pero los primeros
resultados obtenidos proporcionan datos interesantes para la conclusión del nuestro. El
modelo con forma de autómatas a estados es traducible a redes de Petri mediante un
programa ya existente llamado SYNET. Los primeros intentos han proporcionado
resultados moderadamente satisfactorios, restando únicamente solucionar ciertos
problemas de compatibilidad de formatos entre los diversos programas utilizados
(UMDES, SYNET y MOCA RP).
8
Capítulo 1
Introducción general
I. Problemática
Las presiones socioeconómicas obligan a las empresas de bienes y servicios a
certificar, por un lado, la calidad de su producción de cara a sus clientes, y por otro a
maximizar la productividad y la rentabilidad económica de cara a su accionariado. Este
compromiso entre rentabilidad y calidad de servicio debe tenerse en cuenta tanto en las
primeras etapas de concepción de un proyecto, como en las sucesivas etapas de explotación
(producción).
Los sistemas de tratamiento de la información utilizados hoy en día (informática
integrada, MES,...) son herramientas que ayudan a la concepción y al desarrollo de proyectos.
Además de dichos sistemas, es necesario disponer de métodos de evaluación de la
productividad para asegurar una buena respuesta de los sistemas de producción ante posibles
perturbaciones.
En términos de explotación, una de las técnicas para asegurar la producción consiste
en alternar los modos de funcionamiento (degradado y nominal) en el momento oportuno
(“recubrimiento”). Esta alternancia puede venir acompañada, en ciertos casos, de
modificaciones de las características de carga y/o producción. Si se tienen en cuenta estos
ajustes, la etapa de construcción de modelos se complica enormemente, haciéndose necesarios
los cambios tanto en la estructura del sistema como en los rendimientos para modelar los
distintos modos de funcionamiento. Las técnicas clásicas (cadenas de Markov, redes de filas
de espera, redes de Petri estocásticas,...) se basan en modelos ciertamente concisos, pero que
deben ser reconsiderados a cada modificación del tipo de misión. Los modelos que surgen de
dichas técnicas, no son fácilmente explotables. Si bien es cierto que se han desarrollado
9
durante la última década algunas proposiciones que simplifican la etapa de modelado [1], [2],
éstas no permiten responder a los cambios en el sistema sin reconsideraciones completas del
mismo.
En este marco se encuadran los trabajos realizados en el proyecto. La proposición aquí
desarrollada, utiliza la síntesis de lenguaje de autómatas a estados, inicialmente explotada en
la teoría del control por supervisión [3], [4], para generar los modelos (grafos de estados). Su
principal aportación es la de distinguir el modelo de comportamiento del sistema, del modelo
de sus especificaciones de productividad y de recubrimiento.
La teoría de control por supervisión es eficaz para realizar la síntesis de leyes de
control mediante la consideración de eventos controlables y eventos no controlables. Nosotros
pretendemos alargar su dominio de aplicación asociándole, por ejemplo, tasas de
productividad a cada estado con el fin de obtener un modelo capaz de ser tratado mediante
técnicas de simulación para realizar una optimización de la producción.
10
II. El grupo Total
Resultado de dos fusiones sucesivas de Total con la sociedad petrolera belga Petrofina,
que dio nacimiento a Totalfina, y después de ésta con Elf Aquitaine, que engendró
TotalFinaElf, el nuevo grupo denominado Total es heredero de esta tradición y saber hacer
franco belga. Su origen se remonta a los años veinte del pasado siglo.
El grupo está presente en 120 países, a través de 900 sociedades consolidadas. Sus
actividades cubren el conjunto de la cadena petrolera: exploración y producción de petróleo y
de gas, tratamiento, comercio, transporte, refino y distribución. Las actividades ejercidas por
el grupo en el mundo se reparten en tres sectores:
- Prospección
- Refinado y distribución
- Química
El sector prospección incluye las actividades de explotación, desarrollo y producción,
así como las actividades desarrolladas por el grupo en los sectores del carbón, el gas y la
electricidad. Con un volumen de negocios de 16.200 millones de euros, unas inversiones
totales de 6.100 millones de euros y 14.019 colaboradores en exploración-producción en
2002, Total es el quinto productor mundial de hidrocarburos.
El sector refinado y distribución se encarga de la venta de prácticamente todo el
petróleo bruto producido por el grupo, de la compra de la mayor parte del necesario para
abastecer sus refinerías, de la explotación de las mismas, de la comercialización de los
productos petrolíferos a través de la red y fuera de la misma, y de la gestión de las actividades
de “trading” de sus productos. El grupo se encarga de la explotación directa de 13 refinerías
de las 28 en las que posee intereses. Su red de más de 16.700 gasolineras Total, Elf y Fina
está implantada principalmente en Europa y África.
El sector químico incluye la química de base y los grandes polímeros, vinculados a las
actividades de refinado del grupo, la química intermedia y los polímeros de prestaciones, así
11
como la química especializada, que incluye el caucho, las resinas, los adhesivos y la
metalización. Atofina es la rama química de Total y figura entre los líderes europeos o
mundiales en cada uno de sus mercados con un volumen de negocios en 2002 de 19.300
millones de euros.
Para 2004, Total mantiene un programa de inversiones de 9G€, con una fuerte
prioridad sobre el crecimiento de su sector de prospección. La estrategia del grupo para los
próximos años seguirá las siguientes líneas maestras:
- Desarrollo y mejora de la rentabilidad del sector de prospección.
- Refuerzo de su posición de liderazgo mundial en los mercados del gas natural y del
gas natural licuado.
- Consolidación de su posición en las actividades de refinado y distribución en
Europa, así como el desarrollo de los mercados crecientes del bajo mediterráneo,
África y extremo oriente.
- Optimización del sector químico, dando prioridad a la mejora de rentabilidad,
desarrollo de las actividades petroquímicas, y al crecimiento selectivo de la
química intermedia (acrílicos, fluoroquímica, tioquímica, peróxidos orgánicos y
aditivos plásticos) y especializada (transformación del caucho, revestimientos,
adhesivos y metalización)
12
III. Presentación del proyecto
La temática para el proyecto propuesta por el grupo Total, proviene de la rama de la
ingeniería de exploración y producción (sector prospección).
La sociedad necesita determinar los riesgos unidos a la explotación de sus pozos
petrolíferos con el fin de conocer sus capacidades de producción, de llevar a cabo políticas de
mantenimiento y de obtener costes bajos de las aseguradoras. En efecto, desde el momento de
la extracción del crudo hasta la fase final de refino, los diferentes elementos que constituyen
la estructura productiva pueden averiarse. Es necesario conocer las probabilidades de fallo de
estos elementos así como los modos de reparación y de funcionamiento degradado. El
problema consiste en determinar las tasas de productividad en cada momento.
Para ello, debemos generar un modelo de comportamiento del sistema, integrando
averías y tasas de productividad. Actualmente el problema es tratado con el programa MOCA
RP, basado en redes de Petri (RdP). Sin embargo, la gestión del flujo es muy complicada a
causa del elevado número de componentes, de estados de dichos componentes, y de sus
posibles reconfiguraciones. La propuesta aquí desarrollada, utiliza la síntesis de lenguajes de
autómatas a estados, inicialmente explotada en la teoría del control por supervisión. Su
principal astucia radica en la distinción entre el modelo de comportamiento del sistema y el
modelo de sus especificaciones de productividad, recubrimiento y de funcionamiento. Se
tratará, con más exactitud, de generar un modelo (grafo de estados), representado en lenguaje
de autómatas, compatible con una futura traducción a redes de Petri.
13
IV. Organización de la memoria
El plan de redacción presenta la introducción en el primer capítulo de la memoria. En
ella, se muestra el marco en el que se encuadran nuestros trabajos. Este capítulo introduce la
sociedad Total así como los objetivos del proyecto.
El segundo capítulo, está consagrado a la seguridad de funcionamiento y sistemas
dinámicos discretos. Este capítulo justifica igualmente la elección de los autómatas y
lenguajes formales como herramientas para el modelado y el control. La teoría del control por
supervisión según Ramadge y Wonham (RW), y la teoría de las redes de Petri serán repasadas
igualmente. Los argumentos de este capítulo serán acompañados de diversos ejemplos
ilustrativos. Finalmente, se hará una introducción a los programas utilizados para el
desarrollo.
En el tercer capítulo, se incluye la construcción de varios modelos propuestos por
Total. Para dicha construcción se ha utilizado el programa UMDES. Mostraremos, de igual
forma, la citada distinción que se realiza entre el modelo del proceso y los modelos de sus
especificaciones de productividad, mantenimiento y recubrimiento. Un resumen, presentando
las ventajas de esta metodología con respecto a las técnicas clásicas, será presentado
igualmente.
Finalmente en el cuarto capítulo, las conclusiones generales y las perspectivas que
permitirán hacer balance de los trabajos presentados en esta memoria.
14
Capítulo 2
Seguridad de funcionamiento y sistemasdinámicos de eventos discretos
I. Introducción
En este capítulo se recordarán las nociones de base de la teoría de la seguridad de
funcionamiento, la teoría de lenguajes y autómatas a estados, la teoría de control por
supervisión y la teoría de las redes de Petri. De igual modo se presentará el conjunto de
programas informáticos probados y, especialmente, aquellos que han sido retenidos
finalmente. En resumen, este capítulo introduce todas las “herramientas” utilizadas en el
desarrollo de nuestros trabajos.
II. Seguridad de funcionamiento
La seguridad de funcionamiento puede definirse como la propiedad que permite a los
usuarios de un sistema depositar una confianza justificada en el servicio que dicho sistema les
proporciona. Definido de esta forma, el concepto engloba fiabilidad, disponibilidad,
mantenibilidad, seguridad, durabilidad, etc., así como la combinación de estas aptitudes. En
sentido general, la seguridad de funcionamiento es a menudo definida como:
• Fiabilidad, disponibilidad, mantenibilidad, seguridad.
• Ciencia de las averías.
• Conservación de la calidad a lo largo del tiempo.
Todas estas definiciones son reconocidas a titulo diverso por el “Institut de Sûreté de
Fonctionnement” (Instituto de seguridad de Funcionamiento de Francia). Aunque todas ellas
15
contemplan elementos de la teoría de seguridad de funcionamiento, ninguna puede
considerarse una definición exhaustiva, limitándose todas a definir una parte del concepto.
La definición “Fiabilidad, disponibilidad, mantenibilidad, seguridad” hace referencia a las
definiciones de dichos términos (ver glosario).
La definición “ciencia de las averías” pone el acento sobre las averías y sobre sus efectos,
y subraya con la palabra “ciencia”, la importancia del completo conocimiento de las mismas
(causas, efectos, mecanismos...) sin la que no hay un verdadero planteamiento en materia de
seguridad de funcionamiento. Esta definición es ciertamente limitada y, en este sentido, es
bien cierto que la seguridad de funcionamiento considera y trata algo mas que averías. Por
ejemplo, si consideramos los efectos, la seguridad de funcionamiento considera igualmente
aquellos incidentes que se salen fuera del comportamiento nominal esperado, aunque no
lleven asociada rigurosamente una avería. De igual modo, si consideramos las causas, la
seguridad de funcionamiento estudia las agresiones del medio ambiente, las acciones
inesperadas de los usuarios o de terceros, fenómenos aleatorios, etc.
La definición “Conservación de la calidad a lo largo del tiempo” subraya la importancia
de la duración. Así mismo, se hace referencia a unas ciertas exigencias (explicitas o no).
Tiene, sin embargo, el defecto de dejar traslucir que una actividad dentro de la seguridad de
funcionamiento es conducida necesariamente dentro del marco de un sistema de calidad, cosa
que es falsa. Este es el enfoque, explicable históricamente, de ciertos sectores industriales
donde la seguridad de funcionamiento está muy desarrollada dentro del sistema de calidad.
Sin embargo, otros sectores tienen una larga experiencia en seguridad anterior al desarrollo de
la calidad, en el sentido moderno del término, encarnado entre otras, por las normas ISO
9000. En particular, esta experiencia, estaba orientada a la prevención de los accidentes.
En el desarrollo del proyecto, se ha considerado la definición de ciencia de las averías.
Esto es debido a que una parte de nuestros trabajos consiste en observar la evolución del
sistema y de reaccionar a la ocurrencia de un fallo, pasando de un modo de funcionamiento
nominal a un modo de funcionamiento degradado (ver glosario). De esta forma nos
aseguraremos un proceso que trabajará bajo riesgos controlados.
16
III. Teoría de lenguajes y autómatas a estados
III.1 Lenguajes y autómatas
Los modelos de evaluación de la eficiencia de la producción son estudiados en el
dominio de los sistemas de eventos discretos ya que las disfuncionalidades aparecen en
estados específicos del sistema.
Los lenguajes formales y los autómatas permiten tratar los problemas relativos a los
sistemas de eventos discretos (ver glosario), bien desde un punto de vista lógico, bien desde
un punto de vista temporal. El enfoque lógico se interesa exclusivamente en la ocurrencia de
eventos o en la imposibilidad de dicha ocurrencia (“bloqueo”), así como en la sucesión de los
mismos. Este enfoque ignora el momento preciso en que se producen los eventos. Por el
contrario, en el enfoque temporal, (sistemas de eventos discretos temporales), el tiempo es
tenido en cuenta, así como el instante mismo en el que se producen los eventos.
La teoría de los autómatas a estados finitos, ha sido principalmente desarrollada con la
teoría de los lenguajes formales. Sus modelos están formados por un conjunto de estados, y
unas transiciones entre dichos estados. En este capítulo presentaremos este enfoque de
modelado y control de los sistemas de eventos discretos, repasando sucesivamente los
formalismos de los lenguajes y su utilización como soporte a la síntesis. De esta forma serán
presentados los lenguajes formales en la sección I.1 y los modelos autómatas en la sección I.2
antes de abordar en la sección II el control por supervisión.
III.1.1 Los lenguajes formales
Todo sistema de eventos discretos tiene un conjunto de eventos asociado. Este
conjunto Σ puede ser visto como un alfabeto de un lenguaje y las secuencias de eventos que lo
constituyen como palabras o cadenas. Un autómata es, de esta forma, un dispositivo que
genera un lenguaje que manipula el alfabeto Σ.
17
Llamamos lenguaje definido sobre un alfabeto Σ a todo conjunto de palabras, o
cadenas, formadas a partir de elementos de Σ. Se escribirá L = Φ al lenguaje vacío, es decir,
un lenguaje que no contiene ninguna palabra.
En los párrafos siguientes, describiremos los lenguajes prefijo cerrado. Además de la
condición de controlabilidad, la noción de cierre constituye una condición clave para la
existencia de un controlador.
III.1.2 Ejemplo
Sea el alfabeto Σ={a, b, c} un alfabeto que contiene los eventos a, b y c. Podemos en
ese caso definir un lenguaje, por ejemplo L={ε, a,abb, abc} constituido por cuatro palabras
donde ε es la palabra vacía.
Llamamos Σ* al conjunto de secuencias que podemos construir con los elementos de
Σ. Así, Σ*={ε, a, b, c, aa, ab, ac, ba, abc...}
III.1.3 Prefijo de una cadena
La definición prefijo cerrado de un lenguaje L es importante. Permite determinar la
historia de las evoluciones de todas las palabras del lenguaje L.
Sea s3 una cadena definida sobre el alfabeto Σ, una cadena “s” será un prefijo de s3 si existe
una cadena s2∈ Σ* tal que s3=s1s2, donde la cadena s1s2 define la sucesión de símbolos de s1
seguidos de los símbolos de s2. Por ejemplo, el conjunto de los prefijos de la cadena abba es :
{ε, a, ab, abb, abba}.
Definimos prefijo cerrado de un lenguaje L como el lenguaje que contiene todos los
prefijos de las cadenas de L. Notaremos como L el prefijo cerrado del lenguaje L con L = {s1
∈ Σ* ∃ s2 ∈ Σ*, s1s2 ∈ L}.
18
III.1.4 Modelos autómatas
Los autómatas están estrechamente ligados a los lenguajes formales. Un autómata es
una máquina a estados que describe el funcionamiento entrada /salida de un sistema de
eventos discretos, dicho de otra forma, un autómata es una máquina que tiene entradas y
salidas discretas y que reacciona a una modificación de dichas entradas cambiando sus
salidas. En nuestros trabajos, los autómatas considerados son autómatas finitos (número de
estados finito) y deterministas (estado inicial único y a partir de un estado dado, no existe un
mismo evento de salida que conduzca hacia dos estados diferentes).
Los autómatas finitos están definidos por el conjunto A = {Q, Σ, δ, qo, Qm} donde:
• Q es el conjunto finito de estados: es el espacio discreto,
• S es el conjunto finito de símbolos de entrada, llamado alfabeto de entrada
• d es la función de transición (parcial) de estados de Q × Σ en Q que asocia un
estado de llegada a un estado de salida y a un símbolo de entrada,
• qo es el estado inicial,
• Qm es el conjunto de estados finales (estados marcados) que corresponden al
fin de una tarea.
Un estado qi de un sistema modelado por un autómata resume la información sobre el
pasado. En efecto, el acceso a dicho estado está perfectamente descrito por las trayectorias de
eventos (historia ). Esta información es suficiente para determinar la evolución futura,
conociendo las entradas que pertenecen al conjunto Σ.
Una cadena “s” pertenece a un lenguaje L de un autómata si δ(qo,s) está definido. Ésta
es reconocida por el autómata si δ(qo, s) = q con q ∈ Qm.
Un estado qi ∈ Q es accesible si existe una cadena “s” ∈ Σ* tal que qi = δ(qo, s), es
decir, que podemos acceder a qi desde qo. [Ramadge 1987].
Un estado qj ∈ Q es coaccesible si existe una cadena s ∈ Σ* tal que qi = δ(qo, s), es
decir, que a partir de qj podemos alcanzar un estado marcado.
19
Un autómata A es calificado como no blocante cuando todo estado accesible es
coaccesible, es decir, L(A) = )A(L m . Toda cadena que puede ser generada por A es el prefijo
de una cadena marcada. [Wonham 2002].
III.2 Representación de autómatas
Sea un autómata A = {Q, Σ, δ, qo, Qm }. Asociado a dicho autómata, existe un multi-
grafo (X, Σ, δ) donde X es el conjunto de vértices del grafo, Σ es le conjunto de etiquetas de
los arcos, y δ es el conjunto de arcos etiquetados. [Autebert 94].
Ejemplo:
Sea MA una máquina de producción de piezas. Es posible representar esta máquina
por dos estados. Un estado inicial (o estado de parada) y un estado de funcionamiento. El
modelo autómata de esta máquina es el de la figura 1.
Figura 1. Ejemplo de modelo autómata de una máquina de producciónQ = {qo, q1}, Qm = qo, δ(qo, d) = q1 et δ(q1, f) = qo.
El estado inicial (q0) está representado por una doble flecha. El estado final q1 es un
estado marcado (ver glosario ).
Nota:
El inconveniente mayor de la teoría de control por supervisión es la explosión combinatoria
del número de estados de los modelos. Así, en ciertos casos el modelo del proceso es tan
grande que somos incapaces de sintetizar un controlador. A pesar de estos inconvenientes, la
teoría de los autómatas a estados finitos es la que mejor se adecua a los objetivos de control.
qo q1
d
f
MA
20
En efecto, esta teoría responde bien a las propiedades de controlabilidad, observabilidad, y de
no bloqueo, permitiendo así la síntesis correcta de controladores, de aquí el interés que le
prestamos.
Debemos recordar que este proyecto aprovecha la síntesis para construir un
controlador que, acoplado al proceso, nos proporcionará un modelo de comportamiento
simulable del sistema.
III.3 Control por supervisión dinámica de sistemas de eventosdiscretos
El objetivo del control es restringir el funcionamiento físicamente posible del proceso
imponiéndole un comportamiento específico (funcionamiento deseado). Dicho
comportamiento vendrá definido por un pliego de condiciones. Por ejemplo, en el caso de
sistemas de producción, se trata de optimizar la utilización de los recursos del sistema y de
satisfacer los objetivos de producción definidos a nivel del utilizador, tales como el respeto de
plazos, reducción de stocks, reducción de costes, evaluación de la seguridad en los procesos,
etc. La síntesis de leyes de control está basada en un modelo de proceso. En el planteamiento
de base (descripción lógica), el comportamiento de un sistema de eventos discretos está
especificado por una lista ordenada de eventos, sin tener en cuenta el tiempo entre dos eventos
consecutivos. Un objetivo típico de control por supervisión es, por ejemplo, impedir que una
secuencia de eventos se produzca. Así, impidiendo que se desencadenen ciertos eventos
controlables, el controlador modifica el funcionamiento del sistema con el fin de satisfacer las
especificaciones de funcionamiento. El concepto de control por supervisión permite distinguir
el proceso y su controlador. En este sentido, esta estructura se parece a la de un control por
retroalimentación para sistemas continuos.
Figura 2. Modelo de un proceso unido a su controlador
Proceso G
Controlador
S (i+1) = Eventosautorizados y generadospor el proceso en elinstante lógico i+1
F (i) = Lista de eventos aimpedir en el instante
lógico i
21
Un proceso unido a un controlador puede ser considerado como un sistema que recibe
como entrada una lista de eventos prohibidos y genera como salida un evento, siempre que
éste pueda ser generado por el proceso aislado y si no está prohibido por el controlador. El
funcionamiento obtenido de esta forma será declarado como el más permisivo posible y
deberá respetar las propiedades fuertes de los sistemas de eventos discretos (vivacidad,
controlabilidad y no bloqueo).
III.3.1 Modelado del proceso y especificaciones
En el enfoque de Ramadge y Wonham, se estudian procesos que pueden ser
considerados como sistemas de eventos discretos. Se supone que un proceso evoluciona de
forma espontánea generando eventos. Un sistema tal es definido como un “generador de
eventos”. Su funcionamiento puede ser descrito por un conjunto de secuencias de eventos que
constituyen un lenguaje formal sobre el alfabeto de eventos.
Dados un modelo del proceso (G) y una especificación de funcionamiento (E) que
dicho modelo debe cumplir, el problema de la síntesis consiste en definir un controlador de
forma que el funcionamiento del modelo acoplado al controlador (funcionamiento en bucle
cerrado, ver glosario), respete las especificaciones de funcionamiento.
Para resolver este problema de la síntesis, las especificaciones de funcionamiento han
de ser traducidas, al igual que el modelo del sistema, en forma de autómata como los
mostrados en la figura 3.
III.3.2 Principio de control por supervisión
Un controlador es considerado como un sistema de eventos discretos que observa los
eventos producidos en el proceso y devuelve en cada instante la lista de eventos autorizados a
producirse en función de las condiciones impuestas por el pliego de condiciones. Los eventos
generados por el proceso son de dos tipos:
22
Eventos controlables, cuya ocurrencia puede ser inhibida por el controlador (arranque
de una máquina, apertura de una válvula, envío de un mensaje, etc). Estos eventos pertenecen
al alfabeto ∑c llamado alfabeto controlable, y son representados por barras sobres los arcos de
la transición (ver figura 3).
Los eventos incontrolables, cuya ocurrencia no puede ser inhibida por el controlador.
Son enviados por el proceso como respuesta a la ejecución de una orden (fin de tarea, avería
en máquina, válvula cerrada, etc.) Los eventos incontrolables pertenecen al alfabeto
incontrolable ∑uc.
III.3.3 Definición de un controlador
Conforme a la figura 2, un controlador puede ser entendido como una máquina de
estados cuyas salidas son listas de eventos impedidos Φ(i). Puede representarse un controlador
como un modelo tal que la salida depende solamente del estado. Un controlador puede ser
representado por una máquina de Moore.
III.3.4 Ejemplo de control por supervisión
Sean dos máquinas independientes ligadas por un stock intermedio. A cada máquina le
es asociado un autómata que describe su comportamiento (figura 3).
Figura 3. Modelos autómatas de MA1 y MA2
f1
d1 r1
p1x1x2
xo
MA1
f2
d2 r2
p2x4x5
x3
MA2
23
Σ1 ∩ Σ2 = ∅ et Σ1 ∪ Σ2 = Σ = { d1, f1, p1, r1, d2, f2, p2, r2 }
Sea ∑1 = { d1, f1, p1, r1 } el conjunto de eventos asociados al autómata de MA1 y ∑2 = {
d2, f2, p2, r2 }el conjunto de eventos asociados al autómata MA2. Donde:
§ di = comienzo de funcionamiento de MAi
§ fi = fin de funcionamiento de MAi
§ pi = avería de la máquina MAi
§ ri = reparación.
El modelo del proceso es el producto síncrono de MA1 y MA2 notado G = MA1//s MA2.
Puede observarse en la figura 4.
Figura 4. Comportamiento global del sistema compuesto de dos máquinas MA1 y MA2 .
Σ = { d1, f1, p1, r1, d2,, f2,, p2, r2 } Σuc = { f1, p1, f2,, p2 } et Σc = Σ - Σuc
El objetivo es sintetizar un controlador que respete el pliego de condiciones
correspondiente a la gestión del stock cuya capacidad no puede pasar de dos piezas al mismo
tiempo. Esta condición de funcionamiento impone que MA2 no comienza a trabajar hasta que
no sea posible tomar una pieza del stock. La máquina MA1 no deposita una pieza en el stock
si el stock esta lleno (capacidad < 2). Podemos traducir esta especificación de funcionamiento
a un modelo autómata como el de la figura 5.
x05
r2
p1
p1d1
f2f2
f1
p1
r1
p2p2r2f1
f2
d1
p2
r1
d2
x03 x13 x23
x24
x25x15
x04 x14
d1
r2
f1
d2d2r1
r2
24
Figura 5. Especificación de supervisión (lenguaje deseado)
Sea K el conjunto de trayectorias realizables físicamente que respetan la
especificación de funcionamiento E. K = L(G) ∩ E donde K no es controlable ya que E no es
controlable en este caso. Inicialmente el stock está vacío y el modelo E se encuentra en su
estado inicial xo. Desde xo deseamos impedir que se produzca el evento “comienzo de MA2” o
sea d2. La lista de eventos impedidos Φ en el estado xo es entonces Φ = { d2 }. El evento f1
que existe a la salida de xo es eliminado de Σ para tener una estructura de autómata
determinista (un evento a partir de un estado lleva siempre a un único estado resultante). Así,
el bucle al nivel de xo es Σ \{f1, d2}. En el estado x1, todos los eventos están autorizados (Φ
vacío). En el estado x2 el objetivo es impedir la ocurrencia del evento “fin de funcionamiento
de la máquina MA1”, ya que el stock esta lleno. Φ contiene entonces el evento f1 (Φ = {f1})
donde f1 es un evento incontrolable. La especificación E es entonces no controlable, no se
puede impedir el evento “fin de funcionamiento”.
El algoritmo de Kumar permite entonces obtener a partir de L(E) y de L(G) el
autómata supremo controlable de K=L(G) ∩ L(E), o sea SupC(K)=L(S/G).
SupC(K) es el lenguaje supremo controlable de la especificación E. Este lenguaje es
único y es el más permisivo posible. La supervisión obtenida es óptima. Esto quiere decir que
se obtendrá un controlador que respetará las especificaciones de funcionamiento dando la
máxima libertad posible al sistema.
Boucle = Σ-{f1,d2} = { d1, p1, r1,f2, p2, r2,}
boucle
f1xo x2x1
f1d2
d2
boucle
boucle1f=Φ
2d=Φ
E:
25
IV. Redes de Petri
IV.1 Definición. Ejemplos
Una red de Petri es un grafo compuesto por dos tipos de nodos:
• Las plazas que permiten describir los estados del sistema modelado;
• Las transiciones que representan los cambios de estado.
Plazas y transiciones están unidas por arcos orientados (ver figura). Diremos que una
red de Petri es un grafo “bipartido” orientado.
Figura 2.1. Ejemplo de red de Petri
Una plaza puede contener un número entero de fichas o marcas. El conjunto de marcas
presentes en un instante dado en las plazas constituye el marcaje de la red en cada instante.
El marcaje inicial, describe el estado inicial del sistema modelado. A todo marcaje
accesible a partir del marcaje inicial a través de una secuencia de transiciones corresponde un
estado del sistema. Al contrario que en un grafo de estados, la plaza no es un estado pero
participa, a través de su marcaje, en la descripción de uno o varios estados. El conjunto de
marcajes accesibles es equivalente al grafo de estados; así la figura 2.2 representa el grafo de
marcajes de la red de la figura 2.1
26
Figura 2.2. Grafo de marcaje de la red de Petri de la figura 2.1.
Una transición se compone de uno o varios arcos de entrada y una o varios arcos de
salida. Éstos permiten la creación de secuencias de evolución paralelas y la descripción de la
sincronización entre dichas secuencias paralelas. (figura 2.3)
Figura 2.3. Ejemplo de transición distribución y transición conjunción
Cada arco lleva asociado un número entero positivo llamado peso del arco. En el caso
frecuente donde los arcos son todos de peso unitario, se habla de redes de Petri ordinarias. En
caso contrario se trata de redes de Petri generalizadas.
27
Una transición se denomina sensibilizada si las plazas situadas aguas arriba (plazas de
entrada) poseen cada una un número de fichas superior o igual al peso de los arcos que unen
estas plazas a la transición (figura 2.4).
Figura 2.4. Habilitación de una transición
Habilitar una transición consiste en tomar de cada plaza de entrada un número de
fichas igual al peso del arco que une este estado con la transición y a depositar en cada estado
de salida un número de fichas igual al peso del arco que une la transición a cada uno de los
estados (figura 2.5). La habilitación de las transiciones y las modificaciones de marcaje
asociadas permiten analizar la dinámica del sistema modelado.
Figura 2.5. Habilitación de una transición
28
IV.2 Red de Petri Estocástica
IV.2.1 Definición
Las redes de Petri estocásticas fueron desarrolladas para responder a ciertos problemas
de evaluación cuantitativa de los sistemas informáticos industriales. Cálculos de seguridad de
funcionamiento o de protocolos de comunicación han sido objeto, a menudo, de análisis
predictivos realizados mediante redes de Petri.
En una red de Petri temporal, una duración fija es asociada a cada plaza o cada
transición de la red. De esta forma se obtienen modelos bien adaptados para estudiar sistemas
con tiempos de operación fijos. Este es el caso, por ejemplo, de los sistemas de producción
donde el tiempo de tratamiento de una pieza permanece constante dada una máquina.
En una red de Petri estocástica una duración aleatoria es asociada al traspaso de una
transición. Una transición no será traspasada inmediatamente después de su validación, si no
al cabo de un cierto tiempo calculado mediante una variable aleatoria que le es asociada. La
variable utilizada con mas frecuencia es la ley exponencial. Este tipo de ley es interesante por
varias razones:
• Son muy imprevisibles permaneciendo, sin embargo, alrededor de un valor
medio.
• Carecen de memoria, es decir, la probabilidad de que un evento suceda en un
intervalo de tiempo [t , t+dt] no depende mas que de la longitud (dt) de este
intervalo y no de su posición relativa a los ejes temporales.
Las redes de Petri estocásticas pueden ser utilizadas para obtener resultados teóricos
sobre hipótesis muy generales. Sin embargo, la única forma actual de explotar numéricamente
dichas redes es la simulación. Para obtener modelos explotables por cálculo numérico es
necesario considerar subconjuntos de redes.
29
Gracias a las redes de Petri estocásticas es posible reunir en un mismo modelo redes
de Petri y modelos probabilísticos. Sin embargo puede presentarse el problema de falta de
capacidad en los cálculos.
IV.2.2 Ejemplo de redes de Petri estocástica
Tomemos un neumático reparable. Dicho neumático tendrá una probabilidad de
pinchar después de un tiempo de vida determinado, y una probabilidad de ser reparado
después de un cierto tiempo.
Consideramos que el tiempo de vida medio del neumático será igual a 1000 horas (λ =
10-3) y la duración de su reparación igual a 0.5 horas (µ = 2). La ley asociada será de tipo
exponencial. El neumático puede entonces ser modelado por una red de Petri estocástica
como la de la figura siguiente:
Figura 2.6.
•
PNEU_O
PNEU_NOK
λ = 1exp(10-µ = 1exp(2)
30
Dos plazas con una ficha en su marcaje inicial en la plaza PNEU_OK. Dos
transiciones con un tiempo aleatorio asociado. Este tipo de red es estocástica. Podremos
simular con un programa los diferentes estados de la red a lo largo de un tiempo determinado
con el fin de determinar las fases de buen funcionamiento o de avería.
Después del análisis de resultados, pueden llevarse a cabo mejoras sobre la fiabilidad
y el mantenimiento para obtener un neumático más robusto con un tiempo de reparación
reducido.
31
V. TCT, UMDES, MOCA RP
El sistema estudiado ha sido modelado por los programas TCT y UMDES (basados en
la representación de sistemas de eventos discretos por autómatas), y por el programa MOCA
RP (basado en redes de Petri estocásticas).
TCT permite sintetizar controladores para sistemas de eventos discretos. A tal efecto
contiene numerosos procedimientos que permiten la explotación de los resultados de la teoría
de Ramadge y Wonham. Los procedimientos de este programa son explicados en el anexo 4.
Inicialmente, habíamos decidido utilizar este programa desarrollado por “Systems Control
Group” del departamento “Electrical & Computer Engineering” de la Universidad de Toronto
(Canada). Más tarde, se decidió continuar los trabajos con UMDES por motivos que serán
explicados en este capítulo.
UMDES-LIB es un programa que permite igualmente sintetizar controladores. Fue
desarrollado por “DES group” de la Universidad de Michigan. UMDES-LIB es de hecho, una
librería de rutinas escritas para el estudio de sistemas de eventos discretos modelados por
autómatas a estados finitos. Hay rutinas para la manipulación de autómatas, para las
operaciones de la teoría de control por supervisión, y rutinas para la diagnosis de averías en
sistemas de eventos discretos. Los comandos de este programa son explicados en el anexo 1.
Finalmente MOCA RP es una herramienta gráfica con soporte matemático que
permite crear y analizar, un modelo de control para sistemas de eventos discretos, basándose
en redes de Petri. Este programa está compuesto de una interfaz gráfica, desarrollada sobre
JAVA, con un menú que permite construir redes de Petri, con la ayuda de objetos gráficos:
plaza, transición y arco. Puede encontrarse más información sobre MOCA en el anexo 2.
V.1 Elección entre UMDES y TCT
Los dos permiten sintetizar controladores basándose en una representación de sistemas
de eventos discretos. El comando “create” (crear en inglés) se encuentra en ambos programas.
TCT proporciona como salida un fichero “.DES”. El modelo es introducido rápida y
32
secuencialmente. Si hubiera errores en la introducción, estos pueden ser corregidos utilizando
el comando “Edit”.
UMDES-LIB incluye igualmente una rutina “create_fsm.exe”. Ésta permite la
construcción del modelo de forma más interactiva. La rutina va pidiendo paso a paso los datos
necesarios. El modelo obtenido puede ser corregido directamente sobre el archivo de salida
(.fsm) con el bloc de notas o cualquier otro editor de texto.
Una vez creados los modelos simples, es posible en los dos programas hacer una
composición (producto síncrono), a fin de obtener un modelo más complicado. De esta
manera, se puede realizar la construcción modular de sistemas de grandes proporciones
(sistemas más próximos a los sistemas reales). Este producto es realizado paso a paso por
TCT. Por el contrario, UMDES permite realizar el producto síncrono de varios autómatas al
mismo tiempo. La salida proporcionada por TCT es un nuevo fichero “.DES”. El programa
permite saber el número de estados y transiciones de este último autómata obtenido del
producto síncrono. Sin embargo, la salida obtenida de UMDES no proporciona nada más que
el número de estados del modelo compuesto. La obtención del número de transiciones debe
ser realizada haciendo la cuenta a través, por ejemplo, de EXCEL. A pesar de este último
inconveniente, UMDES proporciona el estado en que se encuentra cada sistema simple en el
modelo completo. En efecto, si se considera el producto síncrono de varios autómatas, el
resultado obtenido es normalmente un autómata con un número de estados y transiciones más
elevado. UMDES proporciona para cada uno de esos estados la combinación de los estados de
los sistemas iniciales. Este aspecto de UMDES ha sido la causa de la elección final del
programa. Por su parte, TCT proporciona únicamente un número por cada estado del modelo
final, sin ninguna información sobre la situación de los autómatas que lo componen. De esta
forma, es necesario conocer el histórico del camino que lleva hasta cada estado del modelo
final para obtener el modo de funcionamiento (Combinación de los diferentes estados de
funcionamiento de cada uno de los componentes simples).
Tras la composición del modelo, los dos permiten hacer la síntesis de leyes de control
para respetar las imposiciones del pliego de condiciones. En efecto, varias especificaciones de
funcionamiento, mantenimiento, arranque, o reanudación pueden ser creadas para modelar el
proceso. La introducción de las especificaciones es realizada de la misma manera que para los
sistemas. Una vez modeladas las diferentes especificaciones, se procede a la composición
33
paralela de las mismas para obtener así, una especificación global que incluya todas las
condiciones a las que debe estar sumido el sistema. En ese caso, los dos programas hacen la
composición paso a paso.
Finalmente se aplican las especificaciones a los modelos para obtener el
funcionamiento acoplado o en bucle cerrado de los modelos (ver glosario ). Este
funcionamiento acoplado será el modelo del sistema, objeto de nuestro estudio, que deberá ser
posteriormente traducido a redes de Petri.
VI. Conclusión
En este capítulo hemos presentado las herramientas necesarias para el desarrollo del
proyecto. La propuesta que vamos a desarrollar en el siguiente capítulo utiliza la síntesis de
lenguajes de autómatas a estados, inicialmente explotada en la teoría de control por
supervisión. Su mayor astucia radica en distinguir el modelo de comportamiento del sistema,
del modelo de las especificaciones de funcionamiento. Vamos a mostrar las ventajas de esta
metodología sobre los enfoques clásicos de evaluación de eficiencia de los sistemas de
producción. Estos no son eficaces debido a su complejidad a la hora de la puesta en práctica.
34
Capítulo 3
Aplicación a un modelo de producción de
hidrocarburos
I. Introducción
Los sistemas industriales, y en concreto el equipamiento eléctrico y electrónico
asociado a ellos, demanda cada vez más flexibilidad, disponibilidad y seguridad en su
funcionamiento. Por ello, es necesario disponer de herramientas capaces de asegurar un alto
nivel de seguridad en dichos equipamientos. El modelado de la propagación de fallos
constituye una excelente herramienta de evaluación cuando va asociada a técnicas de
simulación. Disponiendo de un modelo de comportamiento, estos enfoques permiten evaluar
el impacto de una avería sobre el sistema. Estos enfoques se basan en la concepción de un
fallo sobre el sistema, y la consideración del conjunto de caminos lógicos de propagación de
los efectos de dicho fallo. Desde un punto de vista cuantitativo, para obtener una buena
aproximación de la respuesta del sistema a una avería, es suficiente contabilizar el tiempo de
permanencia en los estados disfuncionales. Basado en la síntesis de lenguajes, el enfoque
propuesto en este capítulo tiene por objetivo la generación automática de modelos de
evaluación de eficiencia. El principio de base radica en la distinción realizada entre el modelo
del sistema considerado por un lado y el de sus especificaciones de productividad y
recubrimiento por otra.
Vamos a ilustrar nuestro planteamiento con una aplicación propuesta por el grupo
Total. Se trata de una combinación de estructuras simples tipo serie-paralelo. La evolución de
la construcción del modelo y sus especificaciones es ilustrada por varios ejemplos gráficos. El
lector interesado encontrará en el anexo 3 los resultados obtenidos por el programa UMDES y
en el anexo 5 la evolución del modelo desde sus inicios y a lo largo del desarrollo de los
trabajos.
35
II. Presentación de la aplicación
El sistema físico considerado representa un conjunto de cadenas de una línea de
explotación de hidrocarburos simulando los diversos tratamientos del crudo. (Figura 3.1). La
cadena compuesta por los equipos B, E1, E2, E3 y T2 corresponde a la cadena prioritaria del
pozo W2.
La cadena compuesta de los equipos A, C1, C2, D1, D2 y T1 corresponde a la cadena
prioritaria del pozo W1. Esto significa que la producción del pozo W1 está orientada
inicialmente a esta cadena y si hubiera excedente, éste sería dirigido hacia la cadena
prioritaria del pozo W2 a condición de que la producción del pozo W2 no fuera saturada. Los
equipos D1 y D2 están en “stand by”. Ambos son puestos simultáneamente en marcha cuando
uno de los equipos C1 o C2 se avería.
Consideramos que los equipos D1 y D2 no pueden averiarse mientras que están en
estado de espera.
Figura 3.1 modelo de cadena de producción de hidrocarburos.
W1 A
W2
C1 C2
D1 D2
T1
T2B
E1
E2
E3
36
Cuando los componentes A y B sufren una avería parcial, su capacidad de tratamiento
pasa al 60%. En caso de avería total, dicha capacidad pasa a 0%.
Para los otros equipos, una avería total les hace pasar a una producción del 0%.
Los tanques T1 y T2 no pueden averiarse al contrario que el resto de equipos.
La política de mantenimiento retenida para esta línea de explotación es una política
FIFO, es decir, el primer elemento en sufrir una avería será el primero en ser reparado.
OBJETIVO:
Se desea conocer la disponibilidad de producción al nivel de las dos cadenas, es decir,
la producción disponible en los tanques. Para ello, vamos a presentar en primer lugar los
modelos de las líneas A y B. Posteriormente presentaremos las especificaciones de
productividad, funcionamiento y mantenimiento correspondientes.
37
III. Presentación de los modelos autómatas
El planteamiento que vamos a seguir será el de una supervisión descentralizada (con
una división estructural). En efecto, la aplicación será dividida en línea A ( elementos A, C1,
C2, D1 y D2), y línea B (elementos B, E1, E2 y E3).
III.1 Línea A
Para modelar los elementos C1, C2, D1 y D2 se utilizarán autómatas con tres estados y
cuatro transiciones. Inicialmente los modelos Ci y Di (Figura 3.2) se encuentran en su estado
inicial (q0). La verificación del evento dci ( ddi respectivamente), puesta en marcha, conduce
al modelo correspondiente a su estado de funcionamiento nominal. A partir de dicho estado,
los elementos pueden ser detenidos (eventos sci y sdi), o pueden averiarse (eventos pci, pdi).
A partir del estado de avería, el evento reparación (rci, rdi) devuelve al elemento
correspondiente a su estado inicial de espera.
Figura 3.2 Modelos autómatas Ci y Di.
Los eventos ddi (puesta en marcha), sdi (parada), rdi (reparación) son eventos
controlables. Evidentemente, un usuario podría decidir voluntariamente arrancar, detener o
reparar una máquina. Sin embargo, el evento pdi (avería) es un evento incontrolable. El
usuario no puede impedir, desgraciadamente, la ocurrencia de una avería. Para hacer la
distinción entre eventos controlables e incontrolables, se ha recurrido a realizar un pequeño
trazo sobre los arcos que representan gráficamente los eventos controlables.
pdi,
Di
ddi
rdi
sdi
q0 q1
q2
pdipci,
Ci
dci
rci
sci
q0 q1
q2
pci
38
El modelo del componente A (Figura 3.3) es diferente. Este elemento puede tener un
funcionamiento degradado debido a una avería parcial (evento pa1). Después de esta avería, el
elemento puede ser reparado (evento ra1) y llegar de nuevo a su estado inicial de parada, o
bien, pasar a un funcionamiento degradado (evento da2). Su productividad será, en este caso,
inferior. En efecto, esta productividad pasa del 100% al 60 %. Una vez en modo degradado, el
elemento A puede volver a sufrir una avería, esta vez total (evento pa2). Su reparación
(evento ra2) conducirá al modelo hasta su estado inicial. Siempre es posible detener el
componente A, si éste funciona en degradado (sa2), a fin de efectuar una reparación que le
llevaría a su estado inicial.
Figura 3.3 Modelo autómata del componente A.
A
pa1 da2 pa2
sa1
sa2
da1
ra2ra1
39
III.2 Línea B
Figura 3.4 Modelo de la línea B.
Para modelar los elementos E1, E2 y E3 se han utilizado autómatas de 3 estados y 4
transiciones, similares a los utilizados para los componentes Ci y Di.
Figura 3.5 Modelo autómata de los componentes E1, E2 y E3.
E1(33%)
E2(33%)
E3(33%)
T1B
pdi,
Ei
dei
rei
sei
q0
q2
q1
40
El elemento B tiene un funcionamiento similar al del elemento A (figura 3.6)
Figura 3.6 Modelo autómata del componente B.
B
pb1 db2 pb2
sb1
sb2
db1
rb2rb1
41
III.3 Resultados de UMDES
El programa UMDES permite realizar una composición (producto síncrono), con el fin
de obtener modelos completos.
III.3.1 La línea A
Los elementos A, C1, C2, D1 y D2 han sido modelados con el programa utilizando la
rutina "create_fsm.exe". De forma interactiva, la rutina va pidiendo sucesivamente el nombre
del autómata a crear, el número de estados, el nombre de dichos estados, si son o no estados
marcados, el número de transiciones que salen de los estados, el nombre de dichas
transiciones, los estados de llegada de las transiciones y, finalmente, las propiedades de
observabilidad y controlabilidad de las transiciones. La salida (archivo.fsm) es una lista de
estados y de transiciones (anexo 3).
Figura 3.7. Modelo de la línea A.
Para obtener la composición de la figura 3.7, debemos utilizar la rutina
"par_comp.exe" que efectúa el producto síncrono de los elementos. Esta rutina requiere en
primer lugar el número de componentes del producto, sus nombres y el nombre del elemento
obtenido. La salida es un “archivo.fsm” del componente obtenido. En este caso el resultado
tiene 405 estados y 2808 transiciones.
C1
D1 D2
C2
AW1 T1
42
III.3.2 La línea B
La obtención del proceso representativo de esta línea ha sido realizada de la misma
manera que la de la línea A. El resultado obtenido tiene 27 estados y 108 transiciones (Figura
3.8). Este segundo caso corresponde al funcionamiento de la parte paralela de la línea B.
Una vez determinados los modelos, este enfoque permite realizar fácilmente la síntesis
de leyes de control para respetar las restricciones del pliego de condiciones del sistema. De
esta forma, podemos imponer restricciones sobre el funcionamiento, productividad, políticas
de mantenimiento, etc. Por consecuencia es muy fácil, utilizando esta sistemática, obtener
automáticamente el modelo simulable que será el funcionamiento en bucle cerrado del
proceso acoplado a las especificaciones.
Figura 3.8 Estructura del proceso de la parte paralela de la línea B.
de2
pe3
re2
de2
de1de3
pe1
de2
pe3
re1
pe1
re3
pe2
re2
de3
pe3
pe1
re1
de1
de1
pe1
pe1
de2
de3
de3
de3
pe3 re3
pe3
de3
de3pe3
pe3
pe3
de2
pe2re2
de1
de1
pe1
de2
pe2
re2
de1
re3
43
IV. Especificaciones de productividad
Para expresar las tasas de producción en cada punto del modelo, se utilizarán variables
integradas a través de especificaciones que llamaremos de productividad.
IV.1 Línea A
En esta especificación todos los estados presentan una productividad nula salvo
aquellos donde el elemento A se encuentra en funcionamiento (nominal o degradado) así
como los elementos C1 y C2 (para un funcionamiento nominal) o D1 y D2 (para un
funcionamiento degradado).
Figura 3.9. Especificación de productividad de la línea A
La capacidad de producción 100 % de C1 y C2 corresponde a un total de 120 u.p.
(unidades de producción), mientras que el 100% para D1 y D2 corresponde a 80 u.p. El
componente A tendrá una capacidad de producción de 170 u.p. cuando funciona al 100 % de
su capacidad y de 102 u.p. en marcha degradada.
ddi ddi
ddi ddi
dci dci
dci dci
da1 da1 da1
da2 da2 da2 da2 da2
sa1,
pa1
sa1,
pa1
sa1,
pa1
sa1,
pa1
sa2,
pa2
sa2,
pa2
sa2,
pa2
sa2,
pa2
sa2,
pa2
sdi,pdi sdi,pdi sci,pci
sci,pci
sa1,
pa1 da1
da1
102 80
80 120
* * * *
***
*
* * *
* *
**
sdi ,pdi sdi ,pdi sci,pci sci,pci
44
Cuando la cadena prioritaria funciona normalmente (A, C1, C2), la tasa de
productividad obtenida (figura 3.9) será de 120 u.p. (funcionamiento nominal). En efecto,
debido a su estructura en serie, la cadena C1, C2 limita la tasa de productividad. A partir de
esta situación, la verificación del evento pa1 (avería parcial de la máquina A), lleva a nuestro
modelo hasta un estado de productividad nula. Bien se repara y arranca la máquina A para
obtener un funcionamiento nominal, bien se arranca en funcionamiento degradado (da2). En
este último caso, el modelo alcanzará un estado con una producción de 102 u.p. donde el
elemento limitante es el equipo A.
La construcción de la especificación de la figura 3.9 sobre UMDES con la rutina
“create_fsm.exe”, proporciona un autómata de 15 estados y 176 transiciones. UMDES
incorpora una rutina para obtener el funcionamiento en bucle cerrado de un proceso
controlado por una especificación. La rutina es “supcon_std.exe”. Existe la posibilidad de
obtener una lista de estados eliminados del proceso, así como la causa de su eliminación. La
aplicación de esta especificación al modelo del proceso proporciona el resultado de la figura
3.10. Ésta representa la evolución del sistema. El autómata final compuesto de 280 estados y
1320 transiciones es demasiado grande para ser representado aquí. Para ilustrar el modelo se
han trazado ciertos caminos del mismo.
45
Figura 3.10 Funcionamiento del sistema sumido a la acción de la especificación deproductividad.
Para comprender como se interpreta el autómata obtenido vamos a seguir alguna de
sus trayectorias. Partiendo del estado inicial marcado por una doble flecha de entrada y salida,
vemos que en él la producción es cero. El único evento posible es la puesta en marcha del
componente A (da1). El estado de llegada tiene, evidentemente, una productividad nula. A
partir de este punto existen varias posibilidades. Se pueden poner en marcha los elementos
C1, C2, D1 y D2. Si decidimos arrancar C1 (dc1) alcanzamos el tercer estado de la gráfica. En
este punto existen varias trayectorias posibles. Por ejemplo sería posible una avería en el
elemento C1 (pc1). Del mismo modo es posible proceder a la puesta en marcha del
componente C2 (dc2). Hecho esto, el funcionamiento nominal es alcanzado. Los elementos A,
C1 y C2 trabajan y la tasa de producción es de 120 u.p. En este punto, tres tipos de avería
pueden producirse (las de los tres elementos). Vamos a seguir dos trayectorias diferentes.
Si es la avería del componente A (pa1) la que se produce, la productividad será cero y
de nuevo existen varios caminos posibles a seguir. Si dejamos a un lado las posibles averías,
pc1
dc1 dc2
pa1
pa1 da1
da2
120
pc2
sc1
ra1
dd1
dd2
102
80
sd1
da1
rc2
0 da2
80pa2
ra1
da1
80
0
0
0
0
0
0 0 0
0 0
0
dc2
pa2sa2
dd1
dd2
sd2pc1
46
las posibilidades que restan son: o bien reparar el elemento (ra1) para luego volver a ponerlo
en marcha (da1), o bien arrancarlo en su forma de funcionamiento degradado. Si seguimos
esta última posibilidad, alcanzaremos una producción de 102 u.p.
Si fuera la avería del componente C2 (pc2) la que consideramos, de nuevo la
producción se detiene. Comenzaría a seguirse la secuencia que asegura la producción de la
rama, poniendo en marcha la cadena redundante. Así, se detendría el elemento C1 (sc1), y se
pondrían en marcha D1 y D2 (dd1 y dd2 respectivamente). La rama volvería a ser productiva
con 80 u.p. Desde este punto siempre es posible, y deseable, arreglar el elemento C2 (rc2), y
proceder a la detención de la cadena redundante para arrancar la principal y recuperar el
funcionamiento nominal de 120 u.p.
IV.2 Línea B
Al contrario que en la línea A, encontramos aquí el funcionamiento de los tres bloques
en paralelo (E1, E2, E3) con una tasa de productividad de 33% cada uno. Los tres módulos
pueden funcionar juntos para obtener un funcionamiento nominal (100%). En ese caso, tanto
si uno de los módulos sufre una avería, como si es detenido (eventos pei y sei
respectivamente), el modelo es llevado hacia un estado de productividad de 66%. De esta
forma si tenemos dos bloques en funcionamiento, la tasa alcanzada será del 66%. Una tasa de
33% correspondería al funcionamiento de un solo bloque, y finalmente si no tenemos ningún
equipo en marcha la tasa obtenida será de 0%.
Para modelar esta situación se ha construido una estructura simple de cuatro estados.
En el estado inicial (marcado en la figura 3.11 por una doble flecha de entrada salida),
encontramos una producción nula. Los tres elementos se encuentran parados. En este punto
solo existen dos opciones: puesta en marcha de un elemento (dei) o reparación (ri). Como
estamos considerando el momento inicial, todos los componentes estarán en buenas
condiciones y en estado de espera. La única opción posible será la puesta en marcha. De esta
forma pasaremos al estado de 33%. En este estado, aparecen dos nuevos eventos de salida: pei
(avería de un elemento) y sei (parada voluntaria ). Si cualquiera de estos eventos se produjese,
el resultado sería la vuelta al estado inicial de producción 0%. En esta situación el evento
reparación sí tendría sentido, pudiendo procederse a dicha reparación. Para el resto de los
47
estados productivos, la situación es análoga. Contienen como transición de salida el evento
puesta en marcha (dei). Este evento aumenta en 33% la productividad del sistema. Del mismo
modo, cada estado contiene como salida el evento parada voluntaria y el evento avería.
Ambos eventos lógicamente disminuyen la productividad del sistema en 33%.
A excepción del estado de producción 100%, en el resto de los puntos existe en bucle
cerrado el evento reparación. Este evento deja al sistema en el mismo punto. Esta transición
no cambia la tasa de productividad, simplemente varía el número de componentes en espera
aptos para cumplir su misión. Generalmente, las especificaciones modelan aspectos concretos
de los sistemas. En este caso, esta especificación modela el aspecto concreto de la
productividad. Cualquier cambio del sistema que mantenga constante la productividad del
mismo, no va a provocar cambios de estado en la especificación.
Figura 3.11 Especificación de productividad de la línea B.
Esta especificación (4 estados y 39 transiciones) contrariamente a la especificación del
caso anterior no limita el funcionamiento del proceso (no realiza control). De esta forma, el
resultado proporcionado por UMDES utilizando la rutina “supcon_std.exe”, tiene el mismo
número de estados y transiciones que el proceso mismo. Sin embargo, el programa añade a los
estados su tasa de productividad.
dei dei dei
pei ,sei
riri ri
pei ,sei
100% 66% 33% 0%
pei ,sei
48
V. Especificaciones de mantenimiento
Para modelar el mantenimiento, se ha seguido una política FIFO. Si al menos dos
elementos sufren una avería, el primero en averiarse será el primero en ser reparado.
V.1 Línea A
En esta línea encontramos cinco elementos que pueden averiarse. Además, el
componente A es capaz de funcionar en degradado con una disminución de su productividad.
La política de reparación FIFO es respetada por todos los componentes a excepción del caso
de una avería total del elemento A. Éste está instalado en serie con los otros componentes. Si
la producción de A se detiene completamente, el sistema global se bloquea (no hay ningún
elemento redundante para remplazarlo).
Se han diseñado siete especificaciones para el mantenimiento de la línea A. Las seis
primeras tienen una estructura idéntica. Para asegurar que el primer elemento que sufre la
avería sea el primero en ser reparado, utilizamos una estructura simple de cuatro estados que
compara siempre dos elementos. De esta manera, siempre será posible dar una prioridad de
reparación a un elemento si es éste el primero en averiarse. En efecto, si observamos la figura
3.12 (especificación FIFO entre A y C1), la especificación compara los elementos A y C1.
Figura 3.12. SP_FIFO_A_C1. Especificación FIFO entre A y C1.
Σ \ (pa 1, pc1, ra1, rc1,
ra2, da2)
pa1, pc1
ra1, rc1, ra2, da2
pa1
pc1
0 1
2
3
Σ \ (pa 1, pc1 )
rc1, ra2, da2
rc1, ra2, da2
Σ\( ra1, rc1, ra2, da 2)
Σ\( ra1, rc1, ra2, da 2)
49
Supongamos que hay una avería parcial del componente A (pa1) y una avería del
componente c1 (pc1), el modelo llega al estado 2 o al estado 3. Si se llega al estado 2, quiere
decir que el segundo evento que se ha producido es la avería parcial de A1, lo cual implica
que es el elemento C el que sufrió la avería en primer lugar. En ese caso, se repara
inicialmente el componente C1 (llegamos al estado 1), y luego el elemento A (política FIFO).
La construcción de las especificaciones sobre UMDES es siempre realizada con la rutina
“create_fsm.exe”.
Por otro lado, podemos observar la existencia de otros eventos en la especificación. De
esta forma pueden observarse eventos de reparación de una avería total del componente A
(ra2), y la puesta en marcha del mismo componente después de dicha reparación (da2). Este
hecho es debido a la única excepción de nuestra política FIFO (avería total del componente A)
que vamos a contemplar. Si esta avería se produjera, no tendría sentido proceder a la
reparación y puesta en marcha del resto de componentes. La configuración en serie con el
elemento A trabajando aguas arriba de la cadena, corta el flujo de carga de los componentes
aguas abajo, si el elemento A sufre una avería total (pa2). Llegado este punto, la prioridad
FIFO debe pasar a un segundo plano, siendo más urgente acudir a la reparación del
componente A. Una vez reparado, se procederá a su puesta en marcha (da1), antes de efectuar
ninguna otra reparación. Para modelar esta prioridad es necesaria una nueva especificación
(figura 3.13). Se debe señalar que esta excepción de la política FIFO corresponde únicamente
al caso de una avería total del elemento A. Si la avería fuera parcial (pa1), nos limitaríamos a
lanzar el componente en funcionamiento degradado (da2), respetando para su posterior
reparación la política FIFO.
Figura 3.13. SP_PA 2. Especificación de mantenimiento, avería total del componente A.
ra2, sc1,sc2, sd1,sd2,
pc1,pc2, pd1,pd2
Σ\{pa2}
pa2
da1
0 1
50
Contrariamente a las otras especificaciones de mantenimiento, ésta está compuesta de
dos estados. El estado inicial (doble flecha), modela todos aquellos puntos de funcionamiento
del sistema en los que la máquina A trabaja, bien en funcionamiento nominal, bien en
degradado. Si se verifica el evento pa2 (avería total del componente A) el autómata se dirige
hacia su estado 1. En esta situación, los eventos controlables permitidos son la parada de
todos los elementos en marcha para proceder a la reparación de A, o directamente dicha
reparación sin detención de las otras máquinas. No está permitida ninguna otra reparación
mientras que el componente A sufre una avería total. Del mismo modo cualquier otra puesta
en marcha no está contemplada más que en el estado cero. Si se observa la figura 3.13, en este
punto podemos encontrar la componente A en situación de parada voluntaria, avería parcial, o
funcionamiento. Mientras esté en este estado, podemos obtener una productividad de nuestro
sistema. Si la especificación se encuentra en el estado 1, la máquina A no es productiva, se
encuentra en avería total. Esta especificación no tiene más que dos estados. El resto de
evolución del sistema está permitido por la especificación, que sólo variará su estado en
función de los cambios de la componente A. Solamente producirá control cuando sea obligada
a desplazarse al estado 1. En el estado cero, todos los eventos están permitidos.
Siguiendo con la política FIFO, como ya se había señalado, tenemos cinco
especificaciones análogas a la de la figura 3.12 (especificación SP_FIFO_A_C1). Las
especificaciones SP_FIFO_A_C2, SP_FIFO_A_D1, SP_FIFO_A_D2, SP_FIFO_C1_C2 y
SP_FIFO_D1_D2 funcionan de manera similar a la comentada.
Figura 3.14. SP_FIFO_A_C2. Especificación FIFO entre A y C2.
Σ \ (pa 1, pc2, ra1,
rc2, ra2, da2)
pa1, pc2
ra1, rc2, ra2, da2
pa1
pc2
0 1
2
3
Σ \ (pa 1, pc2 )
rc2, ra2, da2
rc2, ra2, da2
Σ\( ra1, rc2, ra2, da 2)
Σ\( ra1, rc2, ra2, da 2)
51
Figura 3.15. SP_FIFO_A_D1. Especificación FIFO entre A et D1
Figura 3.16. SP_FIFO_A_D2. Especificación FIFO entre A y D2.
Figura 3.17. SP_FIFO_C1_C2. Especificación FIFO entre C1 y C2.
Figura 3.18. SP_FIFO_D1_D2. Especificación FIFO entre D1 y D2.
Σ \ (pa 1, pd1, ra1,
rd1, ra2, da 2)
pa1, pd1
ra1, rd1, ra2, da2
pa1
pd1
0 1
2
3
Σ \ (pa 1, pd1 )
rd1, ra2, da 2
rd1, ra2, da 2
Σ\( ra1, rd1, ra2, da2)
Σ\( ra1, rd1, ra2, da2)
Σ \ (pa 1, pd2, ra1,
rd2, ra2, da 2)
pa1, pd2
ra1, rd2, ra2, da2
pa1
pc1
0 1
2
3
Σ \ (pa 1, pd2 )
rd2, ra2, da 2
rd2, ra2, da 2
Σ\( ra1, rd2, ra2, da2)
Σ\( ra1, rd2, ra2, da2)
Σ \ (pc1, pc2,
rc1, rc2)
pc1, pc2
rc1, rc2
pc1
pc2
0 1
2
3
Σ \ (pc1, pc2 )
rc2
rc1
Σ\( rc1, rc2)
Σ\( rc1, rc2)
Σ \ (pd1, pd2,
rd1, rd2)
pd1, pd2
rd1, rd2
pd1
pd2
0 1
2
3
Σ \ (pd1, pd2 )
rd2
rd1
Σ\( rd1, rd2)
Σ\( rd1, rd2)
52
Una vez que todas las especificaciones han sido construidas, es posible realizar una
composición paralela entre ellas, para encontrar el funcionamiento del modelo sometido al
control del conjunto. De esta manera con la rutina “product.exe” de UMDES, se realiza el
producto paralelo de las especificaciones. A posteriori se realizará el producto paralelo de
todas las especificaciones (incluyendo aquellas de productividad, mantenimiento y
funcionamiento).
53
V.2 Línea B
La política de mantenimiento de esta línea es mucho más simple. Hay tres equipos que
seguirán estrictamente una política FIFO. Siguiendo el caso precedente, es necesario disponer
de tres especificaciones simples para poder hacer la comparación por parejas de nuestros tres
elementos.
Figura 3.19. SP_FIFO_E1_E2. Especificación FIFO entre E1 y E2.
Figura 3.20. SP_FIFO_E2_E3. Especificación FIFO entre E2 y E3.
Figura 3.21. SP_FIFO_E1_E3. Especificación FIFO entre E1 y E3.
Σ \ (pe1, pe2,
re1, re2)
pe1, pe2
re1, re2
pe1
pe2
0 1
2
3
Σ \ (pe1, pe2 )
re 2
re1
Σ\( re1, re2)
Σ\( re1, re2)
Σ \ (pe2, pe3,
re2, re3)
pe2, pe3
re2, re3
pe2
pe3
0 1
2
3
Σ \ (pe2, pe3 )
re 3
re2
Σ\( re2, re3)
Σ\( re2, re3)
Σ \ (pe1, pe3,
re1, re3)
pe1, pe3
re1, re3
pe1
pe3
0 1
2
3
Σ \ (pe1, pe3 )
re 3
re1
Σ\( re1, re3)
Σ\( re1, re3)
54
Utilizando la rutina “product.exe” de UMDES, se puede construir el autómata que
controla el mantenimiento de la línea (conjunto de especificaciones de mantenimiento). Esta
rutina demanda consecutivamente el nombre de los dos autómatas a combinar. Se hace, por
ejemplo, el producto de SP_FIFO_E1_E2 y SP_FIFO_E1_E3. Con el resultado obtenido
(archivo .fsm), se realiza un segundo producto paralelo ( tomando SP_FIFO_E2_E3). El
resultado final es un autómata (archivo .fsm) de 27 estados y 135 transiciones.
Si se utiliza la rutina “product.exe” de UMDES, se puede construir el funcionamiento en
bucle cerrado de la parte paralela de la línea B controlada por la especificación precedente. El
resultado obtenido tiene la forma de un autómata de 61 estados y 654 transiciones. Una
representación parcial del mismo es presentada en la figura 3.22.
Figura 3.22. Modelo de la parte paralela de la línea B unido a la especificación demantenimiento y productividad.
Se puede comprobar fácilmente como el modelo de comportamiento cumple las
condiciones impuestas por el conjunto de especificaciones. En este caso las especificaciones
pe2
re3
re1
de1
pe1
pe1
de1
de3
re1
pe3
pe3
pe2
re2
re3
pe2
de2
de3
pe3 pe3
de2
re2
pe1
re2
de1
pe2
66% 33%66%
33%
33%
0% 0%
0%100%
66%
0%
33%
33%
0%
0%33%
66%
33%
0%
0%
55
de mantenimiento y productividad. Para ello basta con seguir las trayectorias del autómata
que hemos trazado parcialmente en la figura 3.22.
El estado inicial, marcado por una doble flecha de entrada y salida, carece de
producción. Corresponde al estado de espera en el que todos los equipos están detenidos. El
modelo proporciona tres trayectorias desde este punto: las puestas en marcha de los tres
componentes. De esta forma si se sigue la de E1 (de1), la producción resultante es lógicamente
de 33%. La puesta en marcha del componente E2 (de2) conduce a una producción de 66%. De
esta forma se comprueba como el modelo respeta la especificación de productividad.
Si a partir de este punto de producción 66% sobreviene una avería en el elemento 1
(pe1), nuestro modelo alcanza un estado de producción de 33% (de nuevo se respeta la
especificación de productividad). A su vez, una avería en el otro componente en
funcionamiento E2 (pe2), devuelve un estado sin producción. Desde este punto, la secuencia
seguida cumple la política de reparaciones FIFO, traducida en las diferentes especificaciones
de mantenimiento. Así el evento de salida desde este estado de doble avería es la reparación
de E1 (re1). Posteriormente se procede a la reparación del componente E2. Esta secuencia de
reparaciones respeta la política FIFO (primero en sufrir avería, primero en ser reparado).
56
VI. Especificaciones de funcionamiento
Una vez modelado el proceso, así como las especificaciones de productividad y las de
mantenimiento, se procederá a la construcción de las especificaciones de funcionamiento del
sistema. Es posible añadir otras especificaciones de funcionamiento o de reconfiguración sin
tener que aumentar la talla de los modelos de base precedentes.
VI.1 Línea A
La línea A está compuesta de una cadena prioritaria (equipos A, C1, C2) aguas abajo
del pozo de extracción W1 (fuente de producción), y de una cadena redundante D1 y D2. Los
equipos D1 y D2 están en “stand by”. Ambos son simultáneamente puestos en marcha cuando
uno de los equipos C1 o C2 se avería. Esta cadena redundante solamente se activa en dicha
situación. Se debe modelar este funcionamiento con una especificación adicional. La figura
siguiente presenta el autómata construido.
Figura 3.23. SP_FONCTIONNEMENT. Especificación de funcionamiento de la línea A.
pd1 pc1
A
rc1,rc2, A
rd1,rd2, A rd1,rd2, A
A
dc2
rd1,rd2, A
rc1,rc2, A
pc1,pc2
sc1,sc2,
pc1,pc2
dd1
sd1
dd2
sd1,sd2,
pd1,pd2
sd1,sd2,pd1,pd2
*
sc1,sc2
sc1,sc2
dc1sa1
da1 0
1 2
8 3
7 4
6 5
* = rc1,rc2,A\{sa1}
57
Inicialmente el sistema se encuentra en el estado de espera (estado 0). La secuencia de
arranque es: componente A (da1), componente C1 (dc1), componente C2 (dc2). Mientras no
se produzca una avería, el modelo permanecerá en el estado 3 (funcionamiento nominal con
una producción de 120 u.p.)
Después de una avería en C1 (respectivamente en C2), paramos el elemento C2
(respectivamente en C1) y se arranca D1 y D2 para alcanzar el estado 7 (funcionamiento
degradado). La capacidad de producción pasará entonces de 120 u.p. a 80 u.p. Siempre es
posible desactivar los elementos para efectuar una reparación con el fin de recuperar el estado
de funcionamiento nominal de 120 u.p. Si se produjese una avería en el elemento C1 (pc1) en
mitad de la secuencia de arranque (estado 2), el modelo evolucionaría hacia el estado 5.
Después de esta avería en la cadena prioritaria, la cadena redundante sería puesta en marcha
(dd1 y dd2) para alcanzar el funcionamiento degradado. La reparación del componente C1
será únicamente posible en esta situación. La especificación SP_FONCTIONNEMENT
permite después de esta reparación llevar el sistema hasta un estado de funcionamiento
nominal parando sucesivamente los componentes D1 y D2 (dd1, dd2). Desde el estado 1, la
secuencia de arranque es ya conocida.
Para someter al sistema al conjunto de especificaciones, es necesario, en primer lugar,
realizar el producto paralelo de las mismas. Con la ayuda de la rutina “product.exe” de
UMDES, se puede construir el autómata que controla el mantenimiento y el funcionamiento
de la línea. El producto paralelo de SP_FIFO_A_C1, SP_PA 2, SP_FIFO_A_C2,
SP_FIFO_A_D1, SP_FIFO_A_D2, SP_FIFO_C1_C2 y SP_FIFO_D1_D2 proporciona una
especificación final. El modelo resultante de esta especificación global, aplicado al proceso
con la especificación de tasa de productividad (figura 3.9) es representado parcialmente por el
autómata de la figura 3.24. (484 estados y 1396 transiciones).
A partir de este modelo, podemos determinar los caminos que llevan a los estados que
poseen una productividad de 80, 102 y 120 unidades de producción.
58
Figura 3.24. Funcionamiento del sistema sumido a la acción de las especificaciones de
productividad, mantenimiento y funcionamiento.
Sobre la figura se pueden observar las diferentes tasas de productividad sobre los
estados. Estas tasas son proporcionadas por la especificación de productividad. Podemos
comprobar que tras la puesta en marcha de A, C1 y C2, la producción es de 120 u.p. Una
avería en A y una posterior puesta en marcha degradada, nos conduce a la producción de 102
u.p.
De igual forma, la política de reparaciones FIFO, incluyendo su excepción en el
elemento A, puede comprobarse siguiendo los diferentes caminos representados en la figura.
Debemos señalar que este autómata no es más que una representación parcial del
autómata resultado. Su gran tamaño (484 estados y 1396 transiciones), impide una
representación total del mismo sobre esta memoria. Para el lector interesado, será adjuntada
una copia de los resultados en formato digital. Esta copia contiene los resultados completos de
nuestros trabajos.
pc2, sa1
d
dc1 dc2
pa1 da1
da2
120
pc1
dd1
sd1
00
0
00
0
sc2
pc1, sa1
pa1
da2
dc2
pc2
sc1
dd1 dd2
102
dd2
0
80
pa1
da2
rc1
rc2
sd2
dc1
dc2
0
80
80
0
0
0
80 0 0
0
0
0
sa1
sc1
59
VI.2 La línea B
Contrariamente al caso de la línea A, el funcionamiento general de la línea B está ya
modelado completamente, sin necesidad de añadir nuevas especificaciones de
funcionamiento.
Consideramos ahora un nuevo enfoque. Según se había señalado a lo largo del
desarrollo mostrado hasta el momento, para realizar cambios sobre un modelo, tan solo ciertas
especificaciones habrían de ser modificadas. Los elementos base del modelo no tienen por
qué cambiar. Para comprobar este hecho, vamos a variar el funcionamiento de la línea B. En
lugar de los tres elementos en paralelo se modelará un funcionamiento dos elementos sobre
tres. Esta es una de las principales ventajas de la generación automática de modelos.
Realizando cambios en algunas de las especificaciones de funcionamiento, se obtiene un
nuevo modelo si necesidad de revisar una a una cada transición del modelo general. El trabajo
de la regeneración completa del sistema, corre a cargo el programa informático.
El sistema físico de la cadena está compuesto de tres elementos en paralelo. En ese
caso, se considera que el elemento E3 es redundante y que el funcionamiento nominal es E1 y
E2 en marcha. El componente E3 no funcionará a menos que uno de los otros dos
componentes se averíe. Si esto sucede, el componente E3 es lanzado inicialmente para
sustituir al elemento averiado. La política de reparaciones sigue siendo la política FIFO entre
los dos elementos prioritarios E1 y E2. Para el elemento redundante E3, la situación es
diferente. No se procederá a su reparación hasta que no se alcance el funcionamiento nominal.
Es decir, se da una prioridad a la reparación de los componentes prioritarios E1 y E2.
Además, una vez que uno de ellos es reparado, será necesario ponerlo en marcha y detener el
componente redundante E3. Para modelar estos diferentes modos de funcionamiento, varias
especificaciones son necesarias.
60
VI.2.1 Especificaciones de mantenimiento
La especificación de mantenimiento (figura 3.25) de cuatro estados es similar a las de
la línea A (ver figura 3.12).
Figura 3.25. SP_FIFO_E1_E2. Especificación FIFO entre E1 y E2.
Esta estructura, ya conocida, da una prioridad FIFO entre los dos componentes E1 y
E2. El elemento E3 será considerado en la especificación siguiente.
Figura 3.26. SP_MAINTENANCE_E. Especificación mantenimiento del componente E3.
La especificación SP_MAINTENANCE_E3 (figura 3.26) modela las operaciones de
mantenimiento sobre el componente redundante. En efecto, el evento reparación de E3 (re3),
aparece exclusivamente en el estado número 2 de la especificación. Este estado de
funcionamiento nominal es el único que permite detener y reparar el elemento. Siempre es
posible detener los componentes para alcanzar el estado inicial de espera. La puesta en
marcha de E3 (de3) es siempre provocada por la avería de uno de los componentes
prioritarios. Esta circunstancia será modelada más adelante con una nueva especificación.
Σ \ (pe1, pe2,
re1, re2)
pe1, pe2
re1, re2
pe1
pe2
0 1
2
3
Σ \ (pe1, pe2 )
re2
re1
Σ\( re1, re2)
Σ\( re1, re2)
se3, re3, pe3
pe1, pe2
se1, se2
pe1, pe2
se1, se2
de1,de2
0 1 2
de1,de2
de3, pe3
re1, re2
de3, pe3
re1, re2
61
Para concluir con la política de mantenimiento, es necesario considerar el caso
particular de una avería que coincida con la puesta en marcha de un elemento. Siempre que
haya un elemento en parada, se dará la prioridad a la puesta en marcha sobre la reparación
(aseguramiento de la producción). En efecto, si se considera la secuencia de eventos siguiente:
arranque E1, arranque E2, avería E2, el modelo permite dos posibilidades. O bien se repara
E2, o bien se pone en funcionamiento E3. Para forzar la puesta en marcha de E3, se va a
añadir una nueva especificación simple. La estructura utilizada a tal efecto, impide las
operaciones de mantenimiento mientras que sea posible esperar el funcionamiento nominal (2
sobre 3).
Para poder reparar los elementos averiados, es necesario que el tercer elemento haya
sido arrancado. Este tipo de estructura puede ser utilizada igualmente para generar secuencias
de puesta en marcha.
Figura 3.27. SP_DEMARRAGE_SYSTEME. Especificación de puesta en marcha del sistema.
sei sei
deidei
0 1 2 3
dei
peipei
Σ \(sei)
i = 1, 2, 3
62
VI.2.2. Especificaciones de reconfiguración
Consideremos el funcionamiento del componente E3. Para su puesta en marcha en
caso de avería de los elementos prioritarios E1 y E2, es necesario añadir una nueva
especificación. Se trata de la estructura de 3 estados mostrada en la figura 3.28.
Figura 3.28. SP_DEMARRAGE_E3. Especificación puesta en marcha componente E3.
El estado inicial 0 no permite la puesta en marcha del componente E3. Tan solo están
permitidas las puestas en marcha de los componentes prioritarios E1 y E2. La línea B puede
por lo tanto alcanzar su estado de funcionamiento nominal. Si hubiera una avería en los
elementos E1 o E2 (eventos pe1 y pe2 respectivamente), esta especificación llegaría a su
estado 1. En ese caso, todas las operaciones están impedidas salvo la puesta en marcha del
componente redundante. Evidentemente, como en cualquier especificación, los eventos no
controlables se encuentran presentes en cada estado. Para que una especificación sea
controlable, debe permitir en cada momento la verificación de los eventos no controlables. En
el caso de la figura, esta máxima se puede observar, por ejemplo, en este estado 1. Una vez
alcanzado dicho estado, tenemos uno de los dos componentes prioritarios averiado. La
especificación permite únicamente un evento controlable: la puesta en marcha del elemento
redundante E3. Sin embargo, existe la posibilidad de que se produzca una avería en el
segundo elemento prioritario. Este evento no controlable está contemplado en el bucle pe1, pe2
que se incluye en el estado 1.
Σ\{de3, re3, se3}
de3pe1,pe2
se3, re30
1
2
pe1,pe2
Σ\{pe1,pe2,de3}
63
La estructura de esta especificación puede ser interpretada como la de un mecanismo
de emergencia. Una vez que E3 está en funcionamiento (de3), el autómata se encuentra en su
estado 2. Este estado permite la evolución normal del modelo. Tanto si los elementos
averiados son reparados y arrancados y E3 detenido, como si E3 se avería y es posteriormente
reparado, la especificación vuelve de nuevo a su estado inicial 0. La interpretación de este
estado es clara. Mientras que el modelo se encuentre en su estado inicial 0, el mecanismo de
emergencia (puesta en marcha de E3) está listo para funcionar. Si no estuviera listo (dos
causas principalmente: componente averiado o componente ya en funcionamiento), el
autómata permanecería en el estado 2.
Además es necesario diseñar una última estructura para modelar el retorno del sistema
a su funcionamiento nominal (E1 y E2 en paralelo), tras la reparación de los elementos
prioritarios. De esta forma, la especificación siguiente (figura 3.29), representa la condición
necesaria para la puesta en marcha. Así, el evento reparación de E1 (E2 respectivamente),
lleva al sistema hasta su estado1. En éste, todas las operaciones están impedidas a excepción
de la puesta en marcha de E1 (E2 respectivamente). La interpretación a esta estructura es la
siguiente: “Los elementos prioritarios serán puestos en marcha una vez sean reparados”.
Figura 3.29.SP_REPRISE. Especificación de recuperación de funcionamiento nominal.
de1, de2
pe1,pe2,pe3
0 1
re1,re2
Σ\{re1,re2}
64
VI.2.3 Resultado: modelo autómata
Las operaciones a realizar sobre esta línea para obtener un resultado final con UMDES
son análogas a las realizadas en el caso precedente. De esta forma, en primer lugar, se
construye el producto paralelo (rutina “product.exe” de UMDES) de SP_FIFO_E1_E2,
SP_MAINTENANCE_E3, SP_DEMARRAGE_SYSTEME, SP_ DEMARRAGE _E3 y
SP_REPRISE. Después aplicando el resultado al modelo (rutina “supcon_std.exe”), se obtiene
el funcionamiento del sistema unido al conjunto de especificaciones. El autómata obtenido
(52 estados y 110 transiciones) ha sido trazado parcialmente en la figura siguiente.
Figura 3.30 Funcionamiento del sistema sumido a la acción de las especificaciones deproductividad, reconfiguración y mantenimiento.
Como en los casos anteriores se puede comprobar que el autómata obtenido cumple las
especificaciones, respetando así el funcionamiento deseado. Para ello basta con seguir algunas
de las trayectorias posibles observando que esto se cumple en todo momento.
Desde el estado inicial seguimos la secuencia de1, de2, pe1, pe2, de3, re1, de1, re2, de2, se3.
En ella se comprueba como en todo momento la tasa de producción obtenida corresponde a la
cantidad establecida por la especificación. Así mismo, la política de reparaciones FIFO es la
seguida por el autómata. Finalmente, el comportamiento de dos sobre tres, con el elemento E3
66%
de1
pe1
de2
pe2
de3
de2
pe2
de1
se3
re2
de1re1
se1
de1
se1
pe2
pe1
de3 re1 de2
33%
66% 33% 66%
33% 0% 33%
100%
66% 33%
66% 33%
0%
66%
65
como elemento auxiliar es respetado. Dicho elemento es arrancado tras la avería del
componente principal, y detenido una vez este es reparado y puesto en marcha. De esta forma
podemos observar como tras la avería sucesiva de los dos componentes E1 y E2, E3 es puesto
en marcha. La nueva tasa de producción será de 33%. El evento reparación de E1 y su
posterior puesta en marcha nos proporcionan una producción de 66%. Finalmente, una vez
reparado y arrancado E2, el elemento redundante es detenido alcanzando de nuevo la
producción nominal de 66% a través de los dos componentes prioritarios.
66
VII. Conclusión
En el presente capítulo hemos modelado en UMDES una estructura propuesta por el
grupo Total. Se trata de una combinación de estructuras simples de tipo serie y paralelo. Sin
embargo es posible construir modelos más complejos realizando una composición de estas
estructuras simples. El método seguido para la construcción del modelo de proceso y de sus
especificaciones es común para todos los casos. En primer lugar se construyen procesos sin
ninguna limitación en su comportamiento. Es decir, se consideran todas las trayectorias
físicamente posibles. Mas tarde, se añaden especificaciones que impiden la ocurrencia de
ciertos eventos. Esta distinción entre modelo del sistema por un lado y sus especificaciones de
productividad, funcionamiento y recuperación por otro, es la mayor contribución de nuestro
trabajo.
Un cambio en el sistema a modelar no tendrá influencia que salvo sobre la parte
afectada. Para modelar una nueva política de funcionamiento en la línea B, hemos añadido
nuevas especificaciones al modelo de proceso inicial de esta línea. De esta forma, hemos
mostrado que una vez construido un modelo, es relativamente fácil añadir nuevas
especificaciones para simular variaciones en el sistema.
67
Capítulo 4
Conclusión general y perspectivas
La obtención de un modelo de comportamiento de un sistema de producción de
hidrocarburos (o de producción de forma más general) integrando eventos de excepción tipo
avería o fallo, y al que le es asociada una política de mantenimiento y de reconfiguracion es
un proceso fastidioso. Esto es debido en parte a la complejidad del sistema estudiado pero
también a la manipulación de diferentes puntos de vista tales como la productividad o el
aseguramiento de la producción, en los que los objetivos pueden, en ocasiones, oponerse.
Nuestra contribución se encamina en este sentido, y hemos pretendido colaborar a la creación
de modelos de simulación de tales sistemas.
La teoría de la síntesis de lenguajes, inicialmente desarrollada por el control por
supervisión, toma el relevo en el dominio de los sistemas de eventos discretos y utiliza
netamente el formalismo de los autómatas a estados. Hemos mostrado que es posible explotar
el enfoque de la síntesis de lenguajes para definir modelos de estados capaces de ser
simulados posteriormente, con el fin de optimizar la producción.
Los modelos de comportamiento de los sistemas manipulados pueden con facilidad
adquirir tamaños enormes (el espacio de estados aumenta de forma exponencial con el
número de modelos elementales que constituyen el proceso) haciendo de la construcción de
dichos modelos un proceso arduo y difícil. La principal astucia del planteamiento por síntesis
desarrollado en nuestro trabajo radica en la distinción realizada entre el sistema a evaluar y
sus especificaciones de funcionamiento. Este enfoque permite simplificar enormemente la
etapa de modelado.
Una vez que el modelo del sistema es construido, además es relativamente fácil y
rápido añadir una nueva especificación para simular una política de mantenimiento diferente,
un nuevo componente o una mejora en las tasas de producción. En este sentido hemos
realizado cambios sobre el funcionamiento de una de las ramas del sistema ya modelado. No
68
ha sido necesario contemplar el modelo global en su totalidad e ir revisando una a una
todas las transiciones. Simplemente, se han cambiado los modelos de base, y el resto ha sido
ejecutado por el computador. Esta manera de modelar ahorra mucho tiempo y es más segura
ya que evita la revisión manual del modelo, fuente segura de errores, cuando los tamaños
aumentan acercándose a la realidad.
Para clarificar los procedimientos empleados, se han recordado las nociones básicas de
la teoría de control por supervisión. Del mismo modo se han propuesto y confrontado dos
programas (TCT, UMDES) para la construcción de modelos de sistemas de eventos discretos.
UMDES se ha revelado como una herramienta eficaz para nuestros objetivos siendo capaz de
tratar casos de magnitudes reales. En este sentido, el citado problema de la “explosión de
estados”, esto es, modelos de grandes dimensiones que dificultan, tanto los cálculos
numéricos, como la representación de los modelos nos ha acompañado hasta el final del
proyecto, decidiendo a menudo, trazar representaciones parciales de los mismos.
Una de las mayores dificultades encontradas a la hora de construir modelos de
especificaciones mediante autómatas a estados es la carencia de reglas fijas. Es a menudo a
partir de la experiencia que se consigue desarrollar la habilidad necesaria para el modelado.
El objetivo final es tomar en consideración los efectos de los fallos y considerar las
consecuencias de la puesta en obra políticas de reparación o mantenimiento preventivo. Para
ello habrá que convertir, en un futuro, el modelo obtenido (grafo de estados), en un modelo
basado en redes de Petri explotable mediante las técnicas de simulación. En concreto, el
programa a utilizar es MOCA-RP. Esta transposición o traducción no es evidente. En este
sentido, hemos construido los modelos de las líneas A directamente en MOCA-RP,
constatando las dificultades mencionadas para añadir las especificaciones (ver anexo 2).
Además, hemos encontrado un programa llamado SYNET para la traducción de los autómatas
en Redes de Petri. El algoritmo de SYNET genera una red de
Petri cuyo grafo de marcaje es isomorfo al autómata dado. Esta aplicación trabaja con la
teoría de las regiones (eliminación de regiones redundantes para generar una red de Petri
bornada).
Sin embargo, los ficheros UMDES no son compatibles con Synet. Es necesario
desarrollar un procedimiento para convertir los ficheros generados por UMDES en ficheros
69
compatibles con Synet. En este sentido, un nuevo proyecto fin de carrera ha sido lanzado en el
laboratorio de automática industrial del INSA de Lyón (ver anexos 6 a 12). Estos trabajos
deberán permitir el paso del modelo autómata que hemos obtenido, en un modelo de redes de
Petri con el fin de realizar la simulación con el programa MOCA RP que la sociedad TOTAL
utiliza para simular sus modelos.
70
Glosario
Capacidad de mantenimiento
Aptitud de una entidad, dadas unas condiciones, para ser devuelta al estado en el que
es capaz de realizar las funciones requeridas, a través de un mantenimiento.
Se caracteriza por la probabilidad M(t) de estar en estado de realizar sus funciones, en
el instante t, sabiendo que estaba averiada en el instante 0. La capacidad de mantenimiento
caracteriza la prontitud de vuelta al servicio dada una interrupción, esto es, la brevedad de las
averías (estado debido a un fallo). No se puede medir la capacidad de mantenimiento hasta
después de haber considerado los medios (procedimientos, herramientas, organización...)
puestos en obra para volver a llevar a la entidad a su estado de servicio. De hecho, a priori, no
es un concepto intrínseco de la entidad. Sin embargo, dadas unas condiciones de utilización, y
unos medios de mantenimiento, si es una característica de la misma.
Disponibilidad
Aptitud de una entidad para estar en estado de realizar las funciones requeridas en las
condiciones dadas.
Se caracteriza por la probabilidad A(t) o D(t) de estar en el estado requerido. La letra
A es la inicial del termino inglés “Availability”. La disponibilidad es una síntesis de fiabilidad
y capacidad de mantenimiento. Es la proporción de tiempo pasado en estado de servicio en las
condiciones dadas. La indisponibilidad es la proporción de tiempo pasado en avería.
Durante mucho tiempo, y aun en la mayoría de las publicaciones, la disponibilidad
estaba situada en el mismo plano que la fiabilidad y la capacidad de mantenimiento.
Resultado de la adición de ambas, representa la proporción de tiempo en que la entidad es
apta para el servicio. Para una entidad no reparable, no se distingue verdaderamente de la
fiabilidad.
71
Para una entidad reparable, la disponibilidad es tanto mayor cuanto más raras
(fiabilidad) y cortas (capacidad de mantenimiento) fueran las averías.
Cada vez mas, el interés de este concepto aparece como una síntesis de las nociones
elementales de fiabilidad y capacidad de mantenimiento, ligando estos conceptos al de la
calidad de servicio tal y como la percibe el cliente o el utilizador. La remarca realizada
anteriormente sobre la importancia de la determinación de los medios de mantenimiento es
también valida para la disponibilidad.
Estado marcado
En una representación de un sistema de eventos discretos a través del lenguaje formal
de los autómatas a estados, se suele utilizar el concepto de estado marcado. Un autómata a
estados está formado por A = {Q, Σ, δ, qo, Qm} donde Q es el conjunto finito de estados.
Algunos de esos estados pueden ser estados marcados. Dichos estados son tomados así por
conveniencia. Generalmente, un estado marcado suele ser aquel en el que se obtiene algún
tipo de producción o que ha de ser alcanzado como objetivo. El resto de estados, serán
normalmente contemplados como estados de transición. Esto es, un conjunto de estados por
los que el sistema tiene que evolucionar para alcanzar un estado marcado.
En nuestro caso, los estados marcados serán el estado inicial de los modelos tanto de
componentes como de especificaciones. El resultado final de nuestros trabajos, tiene tan solo
como estado marcado el estado inicial de espera. En el inicio de los trabajos se planteó
utilizar este concepto de estado marcado para obtener las tasas de producción (ver anexo 5).
Fiabilidad
Probabilidad de buen funcionamiento durante una duración determinada (medida de la
continuidad de un servicio ).
Sea T la duración de vida de un equipo, representada en los modelos como una variable
aleatoria finita. La teoría clásica de la fiabilidad se centra en el estudio de dicha variable
aleatoria para la que la medida fundamental es la fiabilidad en el instante t, definida como la
72
probabilidad R(t) de que el sistema sea operativo hasta el instante t sabiendo que lo es en el
instante 0. La esperanza de T es el tiempo medio de funcionamiento (MTTF del inglés “mean
time to failure”), que se expresa en función de la fiabilidad por:
MTTF = E(T) = R(t)dt.
Tradicionalmente, esta teoría ha concentrado esencialmente sus esfuerzos en el estudio
de dichas cantidades. Esto es debido al hecho de que, en su origen, era apropiado llamar
sistema a una entidad sin capacidad para ser reparada. Con el incremento en la complejidad de
la tecnología, se ha hecho necesario evaluar los sistemas incluyendo los medios de reparación,
lo que conduce a la teoría moderna, donde se habla de seguridad de funcionamiento.
De igual modo, este enfoque se ha generalizado y no es exclusivo de los productos
sino que es directamente aplicable a los servicios, unidades de producción, empresas, talleres,
etc. De aquí la elección del término “entidad”.
Finalmente, lo que diferencia la fiabilidad de sus vecinos (capacidad de
mantenimiento, disponibilidad,...) es la frase “durante un periodo determinado”. En efecto, la
fiabilidad es la noción que caracteriza la continuidad y la ausencia de interrupciones en el
servicio esperado.
Funcionamiento nominal
El funcionamiento nominal es definido como un funcionamiento prescrito, esperado y
natural. Está controlado por el conjunto de órdenes que autorizan el comportamiento deseado
del proceso. El proceso posee un conjunto de estados físicamente alcanzables, las
especificaciones de funcionamiento nominal reducen este conjunto por composición. El
conjunto de estados así obtenidos y que definen el funcionamiento nominal se compone de los
estados físicamente realizables por el proceso y el conjunto de estados aceptados por las
especificaciones.
73
Funcionamiento degradado
El funcionamiento degradado es un funcionamiento excepcional y no esperado, pero
puede ser en algunos casos previsible. El funcionamiento degradado se traduce en el
incumplimiento de las especificaciones de funcionamiento nominal debido a la ocurrencia de
una avería.
Desde el punto de vista del estudio del funcionamiento de un sistema, es importante
ser capaz de controlar la alternancia entre funcionamiento nominal y degradado.
Funcionamiento en bucle cerrado (acoplado)
Una vez construidos los modelos de base de los componentes de un sistema, la
metodología expuesta, procede a la construcción del sistema global en el que están incluidos
cada uno de estos componentes base. De esta forma el resultado es un modelo en el que se
contemplan todas las trayectorias físicamente posibles sin tener en cuenta ninguna de las
propiedades que debe cumplir el sistema. Así, en un modelo tal, cualquiera de los elementos
puede ser puesto en marcha, reparado o detenido a voluntad. Un modelo más fiel a la realidad
debe seguir ciertas normas o reglas impuestas bien por el propio proceso, bien por sus
manipuladores. Por ejemplo, la secuencia de puesta en marcha, o de parada de un sistema
sigue, normalmente, una serie de pasos. Lo mismo sucede con la política de reparaciones
FIFO, LIFO, elementos prioritarios, etc. Para construir un modelo que se comporte bajo estas
imposiciones, se construyen especificaciones de funcionamiento, mantenimiento,
productividad, etc. Dichas especificaciones no son más que autómatas a estados cuyas
transiciones corresponden a aquellas de los modelos de base. Utilizan el concepto de evento
controlable para realizar el control del modelo del sistema. Una vez modelados de un lado el
sistema físico, y de otro sus especificaciones, se procede con la ayuda de un programa (TCT o
UMDES), a la construcción del funcionamiento del sistema sometido a las especificaciones.
Este funcionamiento se denomina funcionamiento en bucle cerrado o funcionamiento
acoplado, y debe ser el funcionamiento más permisivo del sistema que cumpla cada una de las
imposiciones de las especificaciones. El resultado será un el modelo de comportamiento del
sistema, que podrá posteriormente ser tratado mediante herramientas de simulación.
74
En términos del control por supervisión, este funcionamiento acoplado se denomina
lenguaje supremo controlable de una especificación sobre un proceso. Este lenguaje es único
y es el más permisivo posible que respeta la especificación. La supervisión realizada en este
caso es óptima.
MES
Sistemas de Ejecución de Manufactura (Manufacturing Execution System). Este
nuevo tipo de software permite a las empresas alcanzar un concepto integral de fabricación,
mediante el empleo de un sistema capaz de cubrir de cabo a rabo los procesos en la línea de
producción. No fue sino hasta la década de los noventa en que este término comenzó a
utilizarse. Un sistema MES genera toda la información necesaria para optimizar las
actividades de manufactura, desde que se genera la orden de producción hasta que el artículo
está terminado. El concepto tiene una aceptación muy amplia en todo tipo de procesos de
manufactura, sean estos discretos, de bache o continuos, como los que se encuentran en la
industria automotriz, electrónica, de alimentos y farmacéutica, entre otras.
Sistemas de eventos discretos
El tipo de sistema de eventos discretos que vamos a considerar concierne a los
sistemas dinámicos que evolucionan en un espacio discreto según la verificación de eventos
físicos sobre intervalos de tiempo no necesariamente regulares independientemente de todo
reloj externo (sistemas asíncronos) [Cassandras 95].
Los sistemas de eventos discretos forman un dominio de investigación muy abierto
por la comunidad automática (modelado, simulación, control). La simulación es ampliamente
utilizada netamente para la concepción y dimensionado de sistemas industriales. [Zeigler 84].
Tales sistemas pueden ser definidos por oposición a los sistemas clásicos en los que la
evolución es continua y está descrita por ecuaciones diferenciales. En los sistemas de eventos
discretos, las transformaciones son desencadenadas por eventos puntuales, típicamente,
75
llegada de un cliente, una señal o el fin de la realización de una tarea. Estos eventos dan lugar
a los fenómenos de sincronización y concurrencia.
Los sistemas de eventos discretos aparecen de forma natural en el modelado de
sistemas informáticos, redes de telecomunicaciones, redes de transporte o sistemas de
producción (líneas de ensamblado, talleres flexibles). Para describirlos pueden utilizarse
teorías de colas, redes de Petri o autómatas temporizados.
76
Bibliografía
Cassandras C., Lafortune S., Olsder G. introduction to the modelling, control and
optimisation of discrete event systems. Trends in control, A European perspective, A Isidori
Edición , 1995. p. 218-252.
Chafik S. Proposition d’une structure de contrôle par supervision hiérarchique et
distribuée : Application à la coordination ; Tesis, INSA- Lyon.
Chafik S., Niel E. Du contrôle par supervision hiérarchique distribuée à la coordination
hiérarchique. CIFA, Lille, Francia, 5-8 julio 2000. p 331-336.
Niel E., Chafik S., Signoret J. P., Villalobos J. Contribution à l’évaluation de l’efficience
des systèmes basée sur la synthèse de langages. CIFA (Conferencia Internacional Francófona
de automática). 2004.
Lin F., Wonham W. on observability of discrete event systems. information sciences, 1988.
Vol. 44, no. 2, p. 173-198.
Ramadge P., Wonham W. Modular feedback logic for discrete event systems. SIAM Journal
of Control and Optimisation, 1987. Vol. 25, no. 5, p. 1202- 1218.
Ramadge P., Wonham W. Supervisory control of class of discrete event processes. SIAM
Journal of Control and Optimisation, 1987. Vol. 25, no. 1, p. 206- 230.
Ramadge P., Wonham W. Control of discrete-event systems. IEEE transaction on automatic
control, January 1989. Vol. 77, no. 1, p. 81.98.
Staroswiecki M. La problématique et les approches de la surveillance des systèmes
technologiques. Jornadas de estudios S3: Seguridad, vigilancia, supervisión, detección y
localización de averías, Paris, 17-18 noviembre 1994.
Villemeur A. Sûreté de fonctionnement des systèmes industriels. Paris : Eyrolles, 1988. 795p.
77
Wonham W., Ramadge P. On the supremal controlable sublanguage of a given language.
SIAM Journal of Control and Optimisation, 1987. Vol. 8, no. 3, p. 637-659.
Wonham W., Ramadge P. Modular supervisory control of discrete event systems.Mathematics of Control, Signal.
Guía de uso de UMDES-LIB.(http://www.eecs.umich.edu/umdes/projects/lib/umdeslib.html )
Anexo 1. UMDES_LIB
78
Anexo 1. UMDES_LIB
Anexo 1. UMDES_LIB
79
Anexo 1. UMDES_LIB
UMDES_LIB es una librería de rutinas programadas en C, desarrolladas para el
estudio de sistemas de eventos discretos modelados mediante autómatas a estados finitos. Hay
rutinas para la manipulación de autómatas, para las operaciones de la teoría del control por
supervisión, y rutinas para el diagnóstico de averías.
Este programa ha sido desarrollado por “DES group” de la Universidad de Michigan y
puede ser descargado gratuitamente de la dirección (www.eecs.umich.edu/umdes/).
Las principales rutinas de UMDES utilizadas para la realización de nuestros trabajos
son descritas en la tabla siguiente:
Rutinas inserción / obtención de datos
create_fsm Creación interactiva de sistemas de eventos discretos
write_ev Escribe todos los eventos de un sistema
write_o Escribe los eventos observables
write_st Escribe todos los estados de un sistema
write_uo Escribe todos los eventos no observables del sistema
Manipulacion de sistemas
change_cprop Cambia las propiedades de los eventos
change_oprop Cambia las propiedades de la observabilidad de los eventos
par_comp Realización de la composición síncrona de sistemas
product Realización del producto paralelo de sistemas
Control
ctrb Verifica la controlabilidad de un sistema con respecto a otro
obs Verifica la observabilidad de un sistema con respecto a otro
Supcon_std Construcción del lenguaje supremo controlable
Anexo 1. UMDES_LIB
80
Figura1. Diferentes rutinas de la librería UMDES_LIB
La salida proporcionada es un archivo.fsm que contiene una lista de estados y
transiciones. Puede ser abierta y corregida directamente con el bloc de notas o cualquier otro
editor de texto. La figura siguiente muestra un ejemplo de fichero de salida.
Figura 2. Ejemplo de salida de UMDES_LIB del modelo el componente A
Anexo 1. UMDES_LIB
81
En el archivo de salida podemos observar el número de estados, el nombre de cada
estado, el número de transiciones de salida de cada estado, si éstas son o no controlables, el
nombre de las mismas, y la observabilidad (concepto que no ha sido utilizado en el desarrollo
de los trabajos).
Figura 3. Ejemplo de fichero de salida de UMDES
El autómata de la figura 3 es el producto de la composición de tres autómatas. El
número de estados es 27. El número total de transiciones no es proporcionado directamente
por UMDES. Para obtener dicho número, abrimos el fichero en Excel y obtenemos de esta
manera el número de transiciones (ver figura 4). El primer estado (0,0,0) tiene tres
transiciones de salida. Así f1, f2, f3 llevan al modelo respectivamente a los estados (1,0,0),
(0,1,0) o (0,0,1). Las tres transiciones son controlables y observables. El nombre de un estado,
en el ejemplo, es la combinación de los estados de los autómatas iniciales utilizados para
realizar la composición. En efecto, el primer estado (0,0,0) modela la situación inicial de
27
(0,0,0) 1 3
f1 (1,0,0) c of2 (0,1,0) c of3 (0,0,1) c o
(1,0,0) 0 4
f2 (1,1,0) c of3 (1,0,1) c os1 (0,0,0) c op1 (2,0,0) uc o
.
.
.
Número de estados
Nombre de losestados
Nombre de lastransiciones
Número detransiciones desalida
Controlabilidad
Observabilidad
Anexo 1. UMDES_LIB
82
espera de los tres componentes. El modelo inicial de los componentes simples es un modelo
de tres estados: 0 (máquina en espera), 1 (máquina en funcionamiento), y 2 (máquina
averiada). Así, un hipotético estado (2,0,1) de nuestro modelo final representado en nuestra
figura, modelaría los estados de avería del primer componente, de espera del segundo y de
funcionamiento del último.
Este aspecto de UMDES justifica la elección final del programa con respecto a TCT,
utilizado inicialmente en el desarrollo de nuestros trabajos. Para un sistema global, UMDES
permite asociar a cada uno de sus estados la combinación de los estados de los modelos
originales que lo componen.
De esta manera, es posible conocer la situación del modelo global a partir de la
combinación de sus elementos. Además, es posible añadir propiedades a los estados para
obtener directamente, por ejemplo, las diferentes tasas de productividad.
Figura 4. Obtención del número de transiciones en EXCEL
Anexo 1. UMDES_LIB
83
Para la construcción de sistemas de eventos discretos, UMDES-LIB incluye una rutina
“create_fsm.exe”. Ésta permite la construcción del modelo de forma interactiva. La rutina va
pidiendo paso a paso los datos necesarios. El modelo obtenido puede ser corregido
directamente sobre el archivo de salida (.fsm) con el bloc de notas o cualquier otro editor de
texto.
Figura 5. creación de un sistema de eventos discretos
Como puede observarse en la figura 5, UMDES_LIB demanda en primer lugar el
nombre del sistema de eventos discretos a crear (en este caso A) y el número de estados del
mismo. Posteriormente estado por estado, su nombre, si es o no estado marcado y el número
de transiciones que parten de dicho estado. Una vez insertados estos datos, UMDES_LIB
solicita que se introduzca el nombre de cada transición y su estado de llegada.
Una vez creados los modelos simples, es posible hacer una composición (producto
síncrono), a fin de obtener un modelo más complicado. A tal efecto el programa incluye la
rutina “par_comp.exe” (ver figura 6). UMDES permite realizar el producto síncrono de varios
autómatas al mismo tiempo. Esta rutina pide sucesivamente el número de sistemas a
componer, el nombre de los mismos y posteriormente el del nuevo sistema creado. La salida
es proporcionada en forma de archivo de lectura.
La creación de especificaciones se realiza igualmente con la rutina “create_fsm.exe”.
El proceso es análogo al mostrado para el modelo del proceso. Una vez modeladas las
diferentes especificaciones, se procede a la composición paralela de las mismas para obtener
Anexo 1. UMDES_LIB
84
así, una especificación global que incluya todas las condiciones a las que debe estar sumido el
sistema. Para construir el producto paralelo, se utiliza la rutina “product.exe” (figura 7)
Figura 6. Construcción del modelo de proceso (producto síncrono)
Figura 7. Composición de especificaciones (producto paralelo)
Una vez compuesto el modelo del proceso por un lado y el modelo de las
especificaciones por otro, se procede a obtener el funcionamiento acoplado o en bucle cerrado
de los modelos. Este funcionamiento acoplado será el modelo del sistema, objeto de nuestro
estudio. La librería UMDES_LIB proporciona la rutina “supcon_std.exe”. Se introduce
sucesivamente el nombre del modelo de proceso y el nombre del modelo de las
especificaciones. Finalmente se proporciona el nombre para el nuevo modelo creado (ver
figura 8).
Anexo 1. UMDES_LIB
85
Figura 8. Obtención del funcionamiento acoplado.
Anexo 2. MOCA RP
86
Anexo 2. MOCA-RP
Anexo 2. MOCA RP
87
Anexo 2. MOCA-RP
El programa MOCA-RP (Monte-Carlo basado en Redes de Petri) está enfocado a la
simulación del comportamiento de sistemas dinámicos complejos con el fin de obtener,
mediante un tratamiento estadístico, resultados sobre fiabilidad, disponibilidad y
productividad, así como cualquier otro parámetro probabilístico. El modelo del sistema a
estudiar está realizado bajo la forma de redes de Petri estocásticas que sirven de soporte para
la simulación de Monte-Carlo clásica. En 2002, una colaboración entre Total-Fina-Elf y la
sociedad IXI-GFI Consulting ha conducido al desarrollo de la versión 12 del programa
MOCA-RP.
La línea A de nuestro sistema ha sido modelada utilizando el programa (ver figura 1).
Los elementos C1, C2, D1 y D2 son caracterizados por tres plazas y tres transiciones con el
fin de modelar los estados de espera, funcionamiento y avería. Por ejemplo el bloque
compuesto por las plazas (5, 7, 17) de la figura, corresponde al elemento C1. La plaza 5
corresponde al estado de funcionamiento de C1, la plaza 17 es una plaza de avería mientras
que la plaza 7 corresponde al estado de espera. Para el componente A, será necesario añadir
plazas suplementarias para modelar el funcionamiento degradado. (Bloque 1, 2, 21, 3, 4 )
Figura 1. Representación de la línea A en MOCA-RP.
Anexo 2. MOCA RP
88
Los arcos inhibidores que parten de los estados de avería y espera del modelo
(representados por líneas de trazo), permiten obtener el conjunto de tasas de productividad
posibles del sistema (120, 102, 80, 0 unidades de producción). Así, la tasa de 120 unidades,
será definida para un funcionamiento nominal de los componentes A, C1 y C2. En ese caso, la
transición aguas arriba de la plaza 120 no será franqueada mientras que no haya fichas en las
plazas 1, 2, 21, 3 para el elemento A, las plazas 7 y 17 para el elemento C1, y las plazas 12 y
13 para el elemento C2, que corresponden respectivamente a las plazas de espera o
funcionamiento degradado en el caso del componente A (plaza 2).
Gracias a este ejemplo podemos constatar que si el modelado en redes de Petri se
presta bien al análisis cualitativo (accesibilidad, bloqueo, ...) pudiendo validar un modelo, la
concisión, citada a menudo como ventaja, no es aparente. Además, toda modificación que se
desee realizar en el sistema exige la revisión de una buena parte del modelo.
Del mismo modo se ha modelado la rama B sobre MOCA RP (figura 2).
Figura 2. Representación dela línea B en MOCA-RP.
En esta figura pueden observarse los tres componentes modelados por dos plazas y dos
transiciones. Además se incluyen cuatro plazas para simular las tasas de productividad de 0
%, 33 %, 66 % y 100 %.
Anexo 2. MOCA RP
89
Queda de manifiesto que la construcción de modelos esquemáticos es posible
directamente sobre MOCA RP. Sin embargo a la hora de construir modelos reales de gran
tamaño que deban cumplir políticas de funcionamiento, o mantenimiento, el modelado
mediante redes de Petri es muy complicado. La construcción manual de redes de gran tamaño
es un proceso arduo y laborioso y es siempre una fuente de errores. De ahí nuestro interés por
desarrollar un método que utilice la síntesis de controladores para construir modelos en forma
de autómatas a estados. El paso de autómata a red de Petri es un proceso no evidente, pero
una vez resuelto, compensa con creces la tarea del modelado.
En definitiva, vamos a emplear MOCA RP como motor de simulación, pero sobre
modelos procedentes de una traducción, con origen en los autómatas a estados.
Anexo 3. Modelo de la línea B en UMDES
90
Anexo 3. Modelo de la línea B en UMDES
Anexo 3. Modelo de la línea B en UMDES
91
Anexo 3. Modelo de la línea B en UMDES
27
0,0,01 3d1 1,0,0 c od2 0,1,0 c od3 0,0,1 c o
1,0,00 4d2 1,1,0 c od3 1,0,1 c os1 0,0,0 c op1 2,0,0 uc o
0,1,00 4d1 1,1,0 c od3 0,1,1 c os2 0,0,0 c op2 0,2,0 uc o
0,0,10 4d1 1,0,1 c od2 0,1,1 c os3 0,0,0 c op3 0,0,2 uc o
1,1,00 5d3 1,1,1 c os1 0,1,0 c op1 2,1,0 uc os2 1,0,0 c op2 1,2,0 uc o
2,0,00 3d2 2,1,0 c od3 2,0,1 c or1 0,0,0 c o
1,0,10 5d2 1,1,1 c os1 0,0,1 c op1 2,0,1 uc os3 1,0,0 c op3 1,0,2 uc o
0,2,00 3d1 1,2,0 c o
Anexo 3. Modelo de la línea B en UMDES
92
d3 0,2,1 c or2 0,0,0 c o
0,1,10 5d1 1,1,1 c os2 0,0,1 c op2 0,2,1 uc os3 0,1,0 c op3 0,1,2 uc o
0,0,20 3d1 1,0,2 c od2 0,1,2 c or3 0,0,0 c o
2,1,00 4d3 2,1,1 c os2 2,0,0 c op2 2,2,0 uc or1 0,1,0 c o
1,2,00 4d3 1,2,1 c os1 0,2,0 c op1 2,2,0 uc or2 1,0,0 c o
1,1,10 6s1 0,1,1 c op1 2,1,1 uc os2 1,0,1 c op2 1,2,1 uc os3 1,1,0 c op3 1,1,2 uc o
2,0,10 4d2 2,1,1 c os3 2,0,0 c op3 2,0,2 uc or1 0,0,1 c o
1,0,20 4d2 1,1,2 c os1 0,0,2 c op1 2,0,2 uc or3 1,0,0 c o
0,2,10 4d1 1,2,1 c os3 0,2,0 c o
Anexo 3. Modelo de la línea B en UMDES
93
p3 0,2,2 uc or2 0,0,1 c o
0,1,20 4d1 1,1,2 c os2 0,0,2 c op2 0,2,2 uc or3 0,1,0 c o
2,2,00 3d3 2,2,1 c or1 0,2,0 c or2 2,0,0 c o
2,1,10 5s2 2,0,1 c op2 2,2,1 uc os3 2,1,0 c op3 2,1,2 uc or1 0,1,1 c o
1,2,10 5s1 0,2,1 c op1 2,2,1 uc os3 1,2,0 c op3 1,2,2 uc or2 1,0,1 c o
1,1,20 5s1 0,1,2 c op1 2,1,2 uc os2 1,0,2 c op2 1,2,2 uc or3 1,1,0 c o
2,0,20 3d2 2,1,2 c or1 0,0,2 c or3 2,0,0 c o
0,2,20 3d1 1,2,2 c or2 0,0,2 c or3 0,2,0 c o
2,2,10 4s3 2,2,0 c op3 2,2,2 uc or1 0,2,1 c or2 2,0,1 c o
Anexo 3. Modelo de la línea B en UMDES
94
2,1,20 4s2 2,0,2 c op2 2,2,2 uc or1 0,1,2 c or3 2,1,0 c o
1,2,20 4s1 0,2,2 c op1 2,2,2 uc or2 1,0,2 c or3 1,2,0 c o
2,2,20 3r1 0,2,2 c or2 2,0,2 c or3 2,2,0 c o
Anexo 4. TCT
Anexo 4. TCT
Anexo 4. TCT
96
Anexo 4. TCT
Desarrollado por “Systems Control Group” del departamento “Electrical &
Computer Engineering” de la Universidad de Toronto (Canada), TCT es un programa
que permite sintetizar controladores para la supervisión de sistemas de eventos
discretos.
Figura 1. Pantalla presentación de TCT
Los sistemas de eventos discretos son representados por un conjunto de cinco
elementos:
[Tamaño, estado inicial, estados marcados, estados vocales, transiciones]
• El tamaño es el número de estados del sistema.
• El estado inicial es normalmente el estado 0.
• Los estados marcados serán a menudo los estados de producción del
modelo y el estado inicial.
• Estados vocales: no utilizados en nuestro desarrollo.
Figura 2. Sistema de eventos discretos
Evento EI J
Anexo 4. TCT
97
• La transición (evento) es una lista de la forma [I,E,J] representando la
transición desde la fuente (estado I) hasta el destino (estado J) teniendo E
como nombre (o etiqueta). Esta etiqueta será par o impar según se trate
de un evento controlable o incontrolable.
Figura 3. Principales opciones de TCT
Los principales comandos de TCT utilizados para la realización de nuestros
trabajos son descritos en la tabla siguiente:
comandos inserción / obtención de datos
CREATE Creación de nuevos sistemas de eventos discretos
SELFLOOPAumenta un sistema ya existente añadiendo eventos en bucle procedentes
de una lista a cada estado
EDIT Permite modificar un sistema ya existente
SHOW Proporciona como salida un sistema ya creado
Manipulación de sistemas
SYNC Realización de la composición síncrona de sistemas
MEET Realización del producto paralelo de sistemas
Control
SUPCON Construcción del lenguaje supremo controlable
Anexo 4. TCT
98
Los sistemas de eventos discretos utilizados en TCT deben tener una estructura
determinista. Esto es, distintas transiciones a partir del mismo estado de salida deben
tener distintos nombres.
El comando “create” (crear en inglés) proporciona como salida un fichero
“.DES”. El modelo es introducido rápida y secuencialmente. Si hubiera errores en la
introducción, éstos pueden ser corregidos utilizando el comando “Edit”. La siguiente
figura muestra la pantalla en la que se introduce el sistema de eventos discretos a través
de este comando.En primer lugar se introduce el número de estados, el estado inicial y
la lista de estados marcados.
Figura 4. Rutina “CREATE” de TCT
Posteriormente una a una las transiciones con el formato [fuente, etiqueta, destino].
Figura 5. Creación de un sistema de eventos discretos
Anexo 4. TCT
99
Una vez creados los modelos simples, es posible hacer una composición
(producto síncrono), a fin de obtener un modelo más complicado. De esta manera, se
puede realizar la construcción modular de sistemas de grandes proporciones (sistemas
más próximos a los sistemas reales). Este producto es realizado paso a paso por TCT.
La salida proporcionada es un nuevo fichero “.DES”.
Para construir este producto síncrono se utiliza el comando SYNC. TCT requiere
sucesivamente la introducción del nombre de los sistemas a componer y posteriormente
aquel del sistema resultado.
Figura 6. Rutina “SYNC” de TCT
Después de obtener el modelo del proceso, se crean las diferentes
especificaciones de la misma manera utilizando el comando CREATE. Posteriormente
se procede a la composición paralela de las mismas para obtener así, una especificación
global que incluya todas las condiciones a las que debe estar sumido el sistema. Para
ello TCT incorpora el comando MEET. Éste funciona de forma similar a SYNC.
Anexo 4. TCT
100
Figura 7. Introducción de los datos necesarios a la rutina “SYNC”
Finalmente se aplican las especificaciones a los modelos para obtener el
funcionamiento acoplado o en bucle cerrado de los modelos. Este funcionamiento
acoplado será el modelo del sistema, objeto de nuestro estudio. Para ello, TCT
incorpora el comando SUPCON. De manera similar a MEET y SYNC, esta rutina
demanda la introducción secuencial del proceso, de las especificaciones y, finalmente,
del nombre del sistema creado. TCT lo denomina lenguaje supremo controlable
siguiendo la denominación utilizada por Ramadge y Wonham. Para nosotros será
simplemente el modelo final del sistema.
Figura 8. Rutina “SUPCON” de TCT
Anexo 4. TCT
101
El programa permite conocer el número de estados y transiciones de este último
autómata obtenido. Para estudiar un sistema creado en TCT se incluye el comando
SHOW.
Figura 9. Rutina “SHOW” de TCT
TCT demanda el nombre del sistema de eventos discretos que se desea obtener.
Todos los sistemas creados se encuentran en una carpeta llamada “User”, la cual se
encuentra en el mismo fichero que el propio programa. TCT proporciona únicamente un
número por cada estado del modelo final, sin ninguna información sobre la situación de
los autómatas que lo componen. De esta forma, es necesario conocer el histórico del
camino que lleva hasta cada estado del modelo final para obtener el modo de
funcionamiento (Combinación de los diferentes estados de funcionamiento de cada uno
de los componentes simples). Así, una salida típica de TCT puede observarse en la
figura siguiente. Este sistema de eventos discretos corresponde al modelo del
componente A de la memoria. El autómata obtenido tiene por tanto 5 estados. Su estado
inicial es el estado 0. La lista de estados marcados incluye exclusivamente el estado
inicial. Contiene ocho transiciones cuya lista se especifica.
Anexo 4. TCT
102
Figura 10. Sistema de eventos discretos creado por TCT
Para TCT tanto los estados como las transiciones se nombran mediante números.
En el caso de las transiciones, un número impar designa una transición controlable. En
el ejemplo los eventos 1, 3, 5, 7, 9 y 11 son los eventos controlables que definen puesta
en marcha, parada, reparación avería parcial, puesta en marcha degradada, parada desde
funcionamiento degradado y reparación avería total respectivamente. Los eventos
incontrolables, definidos mediante números pares son avería parcial (2) y avería total
(4).
Figura 11. Modelo base del componente A de la memoria
A
2 7 4
3 9 1
11 5
0
1 2 3 4
Anexo 5. Evolución del modelo
Anexo 5. Evolución del modelo
Anexo 5. Evolución del modelo
104
Anexo 5. Evolución del modelo
La memoria de este proyecto fin de carrera titulado “Asistencia a la generación
automática de modelos de evaluación de eficiencia de funcionamiento” contiene en su
capítulo tercero la versión final en forma de autómatas a estados del modelo propuesto
por el grupo Total. Sin embargo hasta obtener dicho modelo han sido necesarios varios
meses de trabajo a lo largo de los cuales se han ido obteniendo sucesivos modelos que
han ido evolucionando hasta el modelo final presentado en dicho capítulo. En este
anexo se incluyen algunos de los modelos intermedios que consideramos pueden ayudar
a clarificar ideas.
De igual modo se incluyen conclusiones y reflexiones del autor a cada una de las
modificaciones que se fueron realizando. Algunas de ellas fueron acertadas, siendo
finalmente incluidas en el modelo final. En otros casos los cambios realizados sobre
alguno de los modelos no fueron tan acertados, teniendo que dar marcha atrás en algún
punto.
Anexo 5. Evolución del modelo
105
Método de los lenguajes marcados
El método que exponemos a continuación, fue la primera tentativa que se realizó
para construir los modelos del sistema en el lenguaje de autómatas. Este método fue,
como veremos posteriormente, sustituido por otro que recurría a una astucia de
modelado, utilizando el concepto de bucle, para proporcionar las tasas de
productividad. Pese a tener diversos problemas, como se explicará a continuación, esta
primera tentativa nos ayudó a comprender bien el problema al que nos enfrentábamos, y
sirvió de base para el desarrollo de los sucesivos modelos, que guardan siempre, un
origen común en el mismo.
El principio de base del método, consiste en marcar los estados de
funcionamiento de los elementos de base. Como se puede observar en la figura
siguiente, tanto el componente A, como el C y el D, guardan una gran similitud con los
elementos que se han desarrollado finalmente en el proyecto.
Figura 1. Elementos de base.
A
fa1
pa1pa2fa2
ra2
Ci
fci
pci
rci
Di
pdi
fdi rdi
Anexo 5. Evolución del modelo
106
Inicialmente, los modelos C1, C2, D1, y D2 se encuentran en su estado inicial.
La verificación de fci o fdi conduce al modelo correspondiente a su estado de
funcionamiento. En este estado, un elemento puede averiarse (evento pci o pdi). A partir
de la avería, el evento reparación devuelve al elemento a su estado inicial. Tras la avería
pa1, el elemento A puede bien ser reparado (ra1), bien pasar a un estado de
funcionamiento degradado (evento fa2). Una vez en degradado, el elemento A puede
averiarse completamente (evento pa2). Su reparación (ra2), le devuelve a su estado
inicial. Todos estos estados a excepción del estado avería son estados marcados del
modelo. El estado de la primera avería no es un estado marcado ya que sirve únicamente
de estado de paso hacia el modo de funcionamiento degradado. El segundo estado de
avería será un estado de avería total, que no será tampoco marcado.
Anexo 5. Evolución del modelo
107
Obtención del modelo del proceso.
Dicho modelo se obtenía utilizando la función SYNC del programa TCT. De
hecho, esta función no realiza más que el producto síncrono de los diferentes elementos
de base (A, C1, C2, D1 y D2).
Especificación de productividad
Para determinar las tasas de flujo se aplicaba al modelo del proceso la
especificación siguiente:
Figura 2. Especificación de productividad
Los estados marcados corresponden a los estados del proceso donde podemos
encontrar una producción no nula. Esta especificación no pretende realizar control, sino
únicamente determinar las trayectorias marcadas donde los estados marcados
representen estados de producción.
pA2fC1 fC2
fC2 fC1
pD1
pD2
pC1,pC2
fA1
pA1
fA2
fC1 fC2
fC2
fD1
fD2
pC1,pC2
fD1
fD2
fD2
fD1
pD1,pD2
fC1110
102
80 0
Anexo 5. Evolución del modelo
108
Resultado del proceso con la especificación de productividad
Figura 3. Proceso acoplado a la especificación de productividad
Como resultado se obtienen todos los caminos posibles (trayectorias marcadas)
del proceso que conducen a estados en los que hay una producción. Por ejemplo, si en la
especificación hemos marcado un estado con una tasa de flujo de 110, en el resultado
obtenemos una cadena marcada que será s = (fa1 fc1 fc2).
fC1fC2
fC2fC1
fD2fD1
pDpD
fD1fD280
0
102
pCpC
fD2
fD2
pD2
fD1
pD1
fD1
fD1
fD2
fD1fD2
pDpD2
pA2fA1 pA fA2
fC1fC2
fC2fC1
fD2fD1
pDpD
fD1fD280
0
110
pCpC
fD2
fD2
pD2
fD1
pD1
fD1
fD1
fD2
fD1fD2
pDpD2
80 80 80 80
0 0 0 0 0 0 0 0
0 0
Anexo 5. Evolución del modelo
109
TCT permite obtener una lista de todos los estados marcados. De ahí nuestra
idea original de aplicar esta metodología. Para que un estado sea marcado en el modelo
final debe de estarlo en todos los modelos parciales que lo forman. Así un estado como
el anterior con la producción de 110 u.p. será un estado marcado ya que hemos marcado
los estados de funcionamiento de las máquinas A, C1 y C2.
Conclusión sobre la metodología de los lenguajes marcados
Este método nos permite determinar trayectorias en las que podemos saber si los
estados son estados de producción nula o producción distinta de cero (estados
marcados). Sin embargo, este método plantea ciertos inconvenientes. Únicamente
podemos determinar las tasas de flujo sobre los estados marcados del proceso. Además
para conocer dichas tasas, es necesario conocer el histórico del camino que nos lleva
hacia los estados marcados. Con TCT, esta determinación es imposible. Es necesario
trazar manualmente cada una de las trayectorias marcadas para conocer qué elementos
están en funcionamiento, y así conocer la productividad de cada punto. Este trazado se
hace fastidioso cuando el modelo del proceso es complejo (modelos más cercanos a la
realidad), y es una gran fuente de errores.
Así mismo, surge otro problema a la hora de la determinación de los estados
productivos. Como se ha dicho en la explicación del método, para que un estado sea
marcado, ha de estarlo en cada uno de sus componentes por separado. Si suponemos
para el caso de la memoria una situación en la que la combinación de elementos sea la
siguiente: funcionamiento de A, D1 y D2, y el componente C1 en avería. Es evidente que
obtendremos una producción no nula e igual a 80 u.p. Sin embargo este estado no será
marcado ya que el estado de avería del elemento C1 no lo es y, en el modelo final
combinación de estados, no lo será tampoco. Por tanto, la lista que obtendremos como
respuesta a la consulta “estados marcados del modelo final”, no será una lista exhaustiva
de estados productivos, si no que pasará por alto aquellos estados en los que
encontremos una producción y alguno de sus componentes permanezca averiado.
Para solucionar el problema del trazado de las trayectorias a la mano, se planteó
un cambio en los modelos utilizando un bucle en cada uno de los puntos de producción.
Anexo 5. Evolución del modelo
110
Método de los bucles
La modelización utilizando autómatas de estados con bucles, o simplemente
método de bucles, consiste en añadir eventos en bucle a los modelos de base. Lo
aplicaremos a la segunda rama del sistema a estudiar. Esta rama está compuesta del
elemento B en serie con tres módulos E1, E2, E3 en paralelo. Cada elemento Ei puede ser
representado por el autómata de la figura 5 que es idéntico a los autómatas que
representan los elementos Ci y Di del capítulo precedente, salvo que se añade un evento
funcionamiento (fEi) en bucle, al estado de funcionamiento. Así mismo los estados de
funcionamiento y avería no son ya estados marcados.
Figura 4. bloques en paralelo
Figura 5. modelo de base
Este método permite teóricamente determinar directamente las tasas de flujo
sobre los estados del proceso obtenido. Para ello es suficiente localizar los estados que
tienen bucle para determinar los componentes que están en funcionamiento y después
determinar las tasas de flujo que pueden ser de 33%, 66% o 100%, según tengamos uno,
dos o tres componentes trabajando respectivamente. La mayor ventaja de este método
(33%)
(33%)
(33%)
Ei
fEi rEi
pEifEi
Anexo 5. Evolución del modelo
111
reside en el hecho de que no es necesario escribir una especificación de productividad,
por otro lado difícil de escribir. Además no es necesario conocer el camino histórico
para determinar la tasa de flujo en un estado determinado. En la figura, el estado de
funcionamiento de un elemento Ei contiene un bucle fEi, esto significa que la tasa de
flujo en dicho estado es de 33%.
En el modelo del proceso obtenido por el producto síncrono de E1, E2, E3 (figura
6), se puede obtener directamente las tasas de flujo de 0%, 33%, 66% y 100%. En
efecto, a partir del estado inicial, la ocurrencia del evento fE1, lleva al proceso hacia un
estado que contiene fc1 en bucle, lo cual significa que es un estado de 33% de
producción. A partir de este último estado, si el evento fE2 tuviera lugar, el modelo del
proceso sería conducido a un estado que contendría fE1 y fE2 en bucle. Por consiguiente
la tasa de producción de este estado será de 66%. Se puede confirmar que en dicho
estado los modelos E1 y E2 están en funcionamiento. El modelo de proceso obtenido
tiene 27 estados y 108 transiciones.
Figura 6. Comportamiento global del sistema compuesto de tres bloques en paralelo
con una tasa de flujo de 33% cada uno.
Anexo 5. Evolución del modelo
112
Para ilustrar este procedimiento, podríamos cambiar las tasa de flujo en E1, E2 y
E3 que tomarían respectivamente los valores de 20%, 30% y 50%. En ese caso, las tasas
de flujo que podrían obtenerse serían de 0%, 20%, 30%, 50%, 70%, 80% y 100%. Ver
figura 7.
Figura 7. Tres bloques en paralelo
Para obtener las tasas de productividad de los modelos sería suficiente contar el
número de bucles de cada estado y multiplicarlas por un coeficiente según se tratara de
fE1, fE2 o fE3.
Figura 8. comportamiento global del sistema compuesto de tres bloques en paralelo
con tasas de productividad de 20%, 30% y 50%.
E1 (20%)
E2 (30%)
E3 (50%)
Anexo 5. Evolución del modelo
113
Políticas de mantenimiento
Una vez determinados los flujos es posible hacer la síntesis de leyes de control
para respetar las imposiciones del pliego de condiciones del sistema. Una de estas
imposiciones es, como se ha visto, la política de mantenimiento FIFO. En principio
funcionan los tres elementos. Si al menos dos de ellos sufren una avería, el primer
elemento en averiarse será el primero en ser reparado.
Figura 9. Especificaciones de mantenimiento
En el caso de tres elementos en paralelo, esta política FIFO es expresada
mediante tres especificaciones simples. Suponiendo que los elementos E1 y E2 están en
avería, la especificación SP1 muestra que si en el estado 1 se produce el evento “avería
de E1”, el elemento E2 es el primero que se había averiado. En ese caso, se procede a la
reparación del elemento E2 en primer lugar, y después a la de E1. Las especificaciones
SP2 y SP3 funcionan de manera similar a SP1. Esta estructura de especificación FIFO
se ha mantenido en el modelo final a excepción de pequeños cambios que se detallarán
más adelante.
Σ\{rE3,rE2}
rE2pE1,pE2
rE1, rE2
pE1
pE2rE1
rE3pE1,pE3
rE1, rE3
pE1
pE3
rE1
rE3pE2,pE3
rE2, rE3
pE2
pE3rE2
Σ\{rE1,rE2}
Σ- rE2
Σ\{rE3,rE1}
Σ\{rE3,rE2}
Σ\{pE1,pE2}
Σ\{pE1,pE2,rE1, rE2}
Σ\{pE2,pE3}
Σ\{pE3,pE2,rE3, rE2}
Σ\{pE1,pE3}
Σ\{pE1,pE3,rE1, rE3} Σ\{rE3,rE1}
SP1: SP2:
SP3:
0 0
0
1
1
1
2
2
2
33
3
Anexo 5. Evolución del modelo
114
Para poder acoplar el conjunto de las especificaciones al modelo del proceso, es
preciso en primer lugar, componer su producto paralelo. Para ello hacíamos uso del
comando “meet” de TCT. El resultado es una única especificación global, la cual
comprende las otras tres especificaciones FIFO. Esta nueva especificación es un
autómata de 61 estados y 471 transiciones.
Posteriormente, obtenemos el funcionamiento en bucle cerrado de proceso y
especificación mediante el comando “supcon” de TCT. El resultado final tiene 38
estados y 120 transiciones. Éste es demasiado grande para ser representado en su
totalidad. En la figura 14 pueden verse ciertos caminos trazados donde se comprueba
que la política FIFO es respetada.
Figura 10. Proceso global tras la aplicación de las especificaciones de mantenimiento
Anexo 5. Evolución del modelo
115
Conclusión al método de los bucles
El modelado mediante autómatas con bucles en los estados de productividad,
proporcionó los primeros resultados de modelos en los que comprobamos que era
posible diseñar por separado proceso y especificaciones. Una vez realizados estos
diseños, la operación para encontrar el funcionamiento acoplado es automática
utilizando la aplicación informática adecuada (en este caso TCT).
Del mismo modo, nos encontramos por primera vez el problema de la
“explosión de estados”, esto es, modelos de grandes dimensiones que dificultan, tanto
los cálculos numéricos, como la representación de los modelos. Este problema nos va a
acompañar hasta el final del proyecto, decidiendo a menudo, trazar representaciones
parciales de los mismos.
Sin embargo, los modelos con bucles presentan algunas dificultades que
debieron irse resolviendo. Por un lado, el cálculo de tasas de productividad no es
evidente. Teóricamente, bastaría realizar un pequeño programa que hiciera la cuenta del
número de bucles de cada estado para obtener las tasas de producción. Sin embargo,
TCT no es capaz por si mismo de darnos estos valores que son, por otro lado, la clave
para correr una simulación que pretenda extraer conclusiones sobre eficiencias de
producción. De igual modo, existe un segundo fallo en esta proposición de bucles. Para
construir un modelo que se asemeje lo más fielmente posible a la realidad, es
imprescindible contemplar un evento que se había pasado por alto: la parada de un
componente. Si se observa con atención, en los modelos de bucles existen tres eventos
exclusivamente. Funcionamiento, avería y reparación. Para simular políticas de
funcionamiento, siempre ha de existir la posibilidad de detener algún componente no
prioritario. Hasta ahora, la parada de un elemento pasaba ineludiblemente por una avería
y su posterior reparación. Para resolver estos aspectos negativos, se decidió realizar
cambios en el modelo y buscar una nueva herramienta informática capaz de
proporcionar las tasas de producción directamente. Esta nueva herramienta es UMDES-
LIB.
Anexo 5. Evolución del modelo
116
Primera modificación del modelo: evento de parada.
En el apartado anterior se ha expuesto el modelo de bucles, base de todos los
modelos construidos posteriormente. Sin embargo, existen algunos puntos débiles en su
diseño que llevaron a realizar ciertas modificaciones sobre el mismo. En este punto nos
concentraremos sobre la primera de ellas. Para obtener un modelo fiel de la realidad, el
sistema diseñado ha de contemplar la posibilidad de una detención voluntaria de
cualquier componente. Este evento “parada” había sido obviado en nuestro modelo
inicial de bucles. En él, la única posibilidad para detener un elemento era a través de una
avería. Si se observan los modelos, sería necesario añadir un evento “parada”,
lógicamente controlable, entre los estados de funcionamiento y espera. Gracias a este
nuevo evento, será posible modelar especificaciones de funcionamiento tales como el de
una cadena de producción, con una rama no prioritaria. En un caso tal, la rama no
prioritaria sólo sería puesta en marcha al producirse una avería en la principal. Una vez
reparada esta última, la política de funcionamiento nos llevaría a detener la cadena de
reserva. Para poder modelar esto, se hace imprescindible el evento parada. En la figura
1 se muestra el esquema de una parte de una instalación de producción de
hidrocarburos. Este caso es el propuesto por el grupo TOTAL.
Figura 11. Modelo propuesto por TOTAL
W A
W
C1 C2
D1 D2
T1
T2B
E1
E2
E3
Anexo 5. Evolución del modelo
117
La rama perteneciente al pozo 1 (W1), es modelada mediante una cadena principal (A,
C1, C2) y una cadena de reserva (A, D1, D2). La cadena de reserva es puesta en marcha
en caso de parada de la principal y es detenida en el momento en que la principal vuelve
a producir. Este funcionamiento es definido mediante una especificación, como se verá
más adelante. Esta especificación requiere el evento controlable “parada” para su
funcionamiento.
En este punto es necesario notar ciertas divergencias surgidas en el seno del
laboratorio de investigación sobre dicho evento. De una parte, algunos de los
compañeros del laboratorio eran de la opinión de que este evento debería ser
considerado como no controlable. Defendiendo el hecho de que, una vez acabada la
reacción del proceso, este habría terminado, no teniendo sentido dotar de la propiedad
de controlabilidad al mismo. De otra parte, existían opiniones a favor de dicha
controlabilidad alegando el hecho de que, es también cierto, que si algún componente
del proceso se avería, los componentes aguas abajo deben de ser detenidos
voluntariamente (eventos controlables).
Posiblemente ambas opiniones tienen parte de razón y sería adecuado añadir dos
tipos de evento de parada. Uno controlable que uniría los estados de funcionamiento y
espera del modelo, que podría denominarse “parada voluntaria”, y otro no controlable
que uniera los mismos dos estados y que se denominara “fin de proceso”. Con el ánimo
de simplificar los cálculos y el número de transiciones de nuestros modelos, se tomó la
decisión de añadir únicamente el evento controlable “parada voluntaria”. La razón para
adoptar esta postura radica en la necesidad de añadir este evento para la simulación de
políticas de funcionamiento, clave de nuestro trabajo. El evento “parada por fin de
proceso” no tiene una importancia tan crítica en dicho modelado y, en nuestra opinión,
iría en detrimento de la claridad de la exposición de ideas del proyecto. En cualquier
caso es una decisión de modelado que podría haberse tomado, bien es cierto, de otra
manera.
Anexo 5. Evolución del modelo
118
Evento parada
El modelo de bucles usado hasta el momento es el de la figura 12
Figura 12. Modelo base del método de bucles.
Los eventos fEi y rEi son controlables (funcionamiento y reparación). El evento
pEi (avería) es lógicamente incontrolable. Como se ha expuesto en los párrafos
anteriores se tomó la decisión de añadir un evento controlable “parada voluntaria” o
simplemente “parada”. Tal evento será denominado sEi, y ha sido trazado en rojo sobre
la figura 13.
Figura 13. Nuevo modelo con evento“parada”.
El modelo de proceso obtenido con la ayuda de TCT tiene 27 estados y 135
transiciones. Como puede comprobarse el número de estados permanece constante
mientras que el número de transiciones aumenta.
Ei
fEirEi
pEifEi
Ei
fEi rEi
pEi
fEi
sEi
Anexo 5. Evolución del modelo
119
Una vez construido el modelo de proceso, habrá que modificar las
especificaciones de reparación FIFO, construidas para el caso anterior, añadiendo en
cada bucle el nuevo evento parada. El producto paralelo (comando “meet” de TCT)
proporciona un autómata de 61 estados y 654 transiciones. De nuevo el número de
estados permanece constante variando exclusivamente el número de transiciones.
Finalmente, obtenemos el funcionamiento en bucle cerrado de proceso y
especificación mediante el comando “supcon” de TCT. El resultado final tiene 38
estados y 150 transiciones.
Conclusión al evento parada
En el desarrollo del proyecto, la inclusión del evento parada permitió el
modelado de especificaciones de funcionamiento necesarias para una simulación
completa y realista de la cadena de producción.
De igual modo, se pudo comprobar por primera vez cómo afectaba sobre los modelos el
hecho de incluir una nueva transición (evento parada) sobre un modelo ya construido.
En este caso, el número de transiciones aumenta permaneciendo constante el número de
estados.
Una de las principales ventajas de este sistema automático de generación de
modelos es su sencillez a la hora de realizar cambios en un modelo ya construido. En
este caso, lógicamente trivial pero no por ello menos esclarecedor, un modelo de 38
estados y 120 transiciones ha sido transformado en uno con el mismo número de
estados y 150 transiciones. No ha sido necesario contemplar el modelo del sistema en su
totalidad e ir revisando una a una todas las transiciones. Simplemente se ha cambiado el
modelo de base añadiendo un evento “parada”, y el resto ha sido ejecutado por el
computador. Esta manera de modelar ahorra mucho tiempo y es más segura ya que evita
la revisión manual del modelo, fuente segura de errores, cuando los tamaños aumentan
acercándose a la realidad.
Anexo 5. Evolución del modelo
120
Segunda modificación del modelo: eliminación del bucle,UMDES
El modelo base de bucles con el nuevo evento de parada es muy parecido al
modelo final que encontramos en la memoria del proyecto. Sin embargo, como ya se
había adelantado, existe el problema del cálculo de las tasas de productividad. Este
cálculo no es evidente. TCT no es capaz por si mismo de proporcionar estos valores que
son, por otro lado, la clave para obtener resultados en una futura simulación.
Pese a haber considerado diversos cambios en la forma de modelado, la solución
más práctica pareció el cambio de programa informático. TCT, inicialmente
desarrollado para la síntesis de controladores en sistemas de eventos discretos, resultaba
una herramienta ineficaz a la hora de plantear la construcción de un modelo cara a una
simulación que permitiera extraer conclusiones sobre eficiencias de producción.
Sin perder de vista que nuestros trabajos se basan en la teoría de Ramadge y
Wonham, nuestra finalidad no es la simple síntesis de leyes de control. Pretendemos
construir un verdadero modelo de comportamiento de un sistema de producción en el
que se han de incluir algunos parámetros como la tasa de productividad. En realidad, en
nuestro proyecto, no se ha considerado más que este parámetro. Sin embargo la
metodología desarrollada permite incluir cualquier otro tipo de parámetro asociado a los
componentes. De esta forma, además de estudiar la tasa de productividad, y por tanto el
nivel de producción de la planta, sería posible añadir el número de trabajadores, las
horas de mantenimiento o cualquier otro parámetro con vistas a medir la eficiencia en la
producción.
Para poder añadir estos parámetros se buscó una herramienta informática que
debía incluir, al igual que TCT, la posibilidad de sintetizar controladores. El programa
encontrado a tal efecto es UMDES-LIB. Desarrollado en la de la Universidad de
Michigan, UMDES-LIB es una librería de rutinas escritas para el estudio de sistemas de
eventos discretos modelados por autómatas a estados finitos. Permite la manipulación
de autómatas, realizar operaciones de la teoría de control por supervisión, y la diagnosis
de averías en sistemas de eventos discretos. En el anexo 1 puede encontrarse una
pequeña guía sobre su funcionamiento.
Anexo 5. Evolución del modelo
121
El modelo sin bucle
UMDES permite asociar a cada estado del modelo una propiedad o nombre que
proporcione información sobre el mismo. Además, esta propiedad va a mantenerse una
vez realicemos operaciones con los autómatas. En efecto, si se considera el producto
síncrono de varios autómatas, el resultado obtenido es la combinación de los estados de
los autómatas iniciales. UMDES nos muestra en este resultado final, la situación de
cada uno de los componentes iniciales a los que podremos reconocer por la propiedad
asociada. Por su parte, TCT proporciona únicamente un número por cada estado del
modelo final, sin ninguna información sobre la situación de los autómatas que lo
componen.
De esta forma se prosiguieron los trabajos utilizando UMDES. Las tasas de
productividad son determinadas automáticamente como se verá más adelante. Gracias a
ello fue posible eliminar el bucle de los estados productivos cuya única finalidad era
permitir los cálculos de productividad, simplificando de esta forma y de manera
considerable los modelos.
El nuevo modelo de componente base puede observarse en la figura 14
Figura 14. Nuevo modelo base.
La estructura es similar a la utilizada hasta el momento. Puede observarse la
eliminación del bucle en el estado de productividad. Este autómata, modelo del
componente base, es el que se ha adoptado finalmente hasta la conclusión de nuestros
trabajos.
Ei
fEi rEi
pEi
sEi
Anexo 5. Evolución del modelo
122
El modelo de proceso obtenido con la ayuda de UMDES tiene 27 estados y 108
transiciones. Como puede comprobarse el número de estados permanece constante
mientras que el número de transiciones disminuye.
En este caso las especificaciones de reparación FIFO, construidas para el caso
anterior, son completamente válidas. La lista de los estados y de las transiciones de los
componentes base no sufre ningún cambio. El producto paralelo (realizado esta vez con
UMDES) proporciona un autómata de 61 estados y 654 transiciones. Este autómata es
exactamente el mismo que habíamos obtenido con TCT.
El funcionamiento en bucle cerrado de proceso y especificación mediante el
comando “supcon_std” de UMDES tiene 38 estados y 150 transiciones.
Anexo 5. Evolución del modelo
123
Conclusión a la eliminación del bucle y UMDES
Para continuar avanzando en nuestros trabajos, decidimos comenzar a manejar
UMDES. Por un lado, esto permitió abandonar el uso del bucle de producción, lo cual
simplificaba los cálculos. Por otro lado, UMDES es una herramienta más potente y
permite construir modelos con más información.
La utilización de UMDES tuvo como consecuencia la ralentización temporal del
desarrollo del proyecto ya que fue necesario aprender su manejo. De igual modo fue
preciso construir todos los modelos desde cero ya que los formatos de TCT y UMDES
no son compatibles. Por seguridad y hasta la conclusión de los trabajos, todos los
modelos han sido construidos en ambos programas, comparando a cada ocasión los
resultados.
Una vez adoptados tanto UMDES como los modelos de base para los
componentes (sin bucle y con el evento parada), pasamos a una segunda fase del
proyecto. Fijadas ya las herramientas que serían precisas para el desarrollo completo, se
procedió a un trabajo puramente de modelado. En lo que resta, y hasta la finalización,
todos los modelos de especificaciones son diseñados con UMDES, y son realizados para
ser acoplados sobre el modelo de base de la figura 14.
Anexo 5. Evolución del modelo
124
Modelado del funcionamiento de la rama B: dos sobre tres
Utilizando siempre UMDES y el modelo de base desarrollado en el apartado
anterior, procedimos al diseño del funcionamiento de la rama B de la aplicación
propuesta por TOTAL (ver figura 15)
Figura 15. Modelo propuesto por TOTAL.
El sistema físico de la cadena está compuesto de tres elementos en paralelo. En
ese caso, se considera que el elemento E3 es redundante y que el funcionamiento
nominal es E1 y E2 en marcha. El componente E3 no funcionará a menos que uno de
los otros dos componentes se averíe. Si esto sucede, el componente E3 es lanzado
inicialmente para reparar posteriormente el elemento averiado. La política de
reparaciones sigue siendo la política FIFO entre los dos elementos prioritarios E1 y E2.
Para el elemento redundante E3, la situación es diferente. No se procederá a su
reparación hasta que no se alcance el funcionamiento nominal. Es decir, se da una
prioridad a la reparación de los componentes prioritarios E1 y E2. Además, una vez que
uno de ellos es reparado, será necesario ponerlo en marcha y detener el componente
W A
W
C1 C2
D1 D2
T1
T2B
E1
E2
E3
Anexo 5. Evolución del modelo
125
redundante E3. Para modelar estos diferentes funcionamientos, varias especificaciones
son necesarias.
Este modelo es presentado en la memoria en su capítulo tercero. Está compuesto
de cinco especificaciones acopladas al modelo del proceso del apartado anterior. El
resultado final proporcionado por UMDES tiene 52 estados y 110 transiciones y es
trazado parcialmente en la figura 16.
Figura 16. Modelo final.
ConclusiónSe ha obtenido una parte del modelo final. UMDES es una herramienta eficaz
para nuestros objetivos. A partir de ahora restará modelar la rama A de nuestra línea de
producción.
de1
pe1
de2
pe2
de3
de2
pe2
de1
se3
re2
de1re1
se1
de1
se1
pe2
pe1
de3 re1 de2
33%
66% 33% 66%
33% 0% 33%
100
66%
66%33%
66%33%
0%
Anexo 5. Evolución del modelo
126
Modelado del funcionamiento de la rama A
La construcción del modelo de la línea A no fue inmediata. Diversos problemas
a lo largo del desarrollo del modelo obligaron a realizar cambios para conseguir un
resultado que contemplara todas los aspectos a modelar. El funcionamiento de la línea A
es el siguiente. Los equipos D1 y D2 están en “stand by”. Ambos son puestos
simultáneamente en marcha cuando uno de los equipos C1 o C2 se avería. Cuando el
componente A sufre una avería parcial, su capacidad de tratamiento pasa al 60%. En
caso de avería total, dicha capacidad pasa a 0%. Para los otros equipos, una avería les
hace pasar a una producción del 0%.
Figura 17. Línea A
W A
W
C1 C2
D1 D2
T1
T2B
E1
E2
E3
Anexo 5. Evolución del modelo
127
Los modelos de los componentes son los siguientes:
Figura 18. modelos de los componentes C1, C2, D1 y D2
Figura 19. Modelo autómata del componente A
Los modelos de los componentes de base son los mismos que podemos
encontrar en la memoria en el capítulo tercero. Las especificaciones diseñadas en primer
lugar fueron evolucionando, sin embargo, para resolver los sucesivos problemas que se
iban presentando. Las primeras especificaciones que diseñamos fueron las siguientes:
pci,pdi,
Cidci
rci
sci
q0 q1Di
ddi
rdi
sdi
q0 q1
q2 q2
pdi pci
A
pa1 da2 pa2
sa1
sa2
da1 ra2ra1
Anexo 5. Evolución del modelo
128
Figura 20. Especificación de funcionamiento de D1 y D2
Esta especificación SP__DD modela el comienzo del funcionamiento de las
componentes redundantes D1 y D2. El sistema permanece en el estado cero hasta que
alguna avería es producida en los componentes principales C1 y C2. A partir de
entonces se genera la secuencia para el arranque de la línea redundante. Una vez sean
reparados los elementos averiados, se procederá a la detención de la cadena auxiliar y al
arranque de la principal.
Figura 21. Especificación de parada para cadena auxiliar
Esta especificación SP__SD modela la parada de los elementos redundantes D1
y D2. El modelo se encuentra en el momento inicial en el estado cero. Una vez en
marcha la cadena principal (C1, C2), se alcanza el funcionamiento nominal en el estado
2. Si cualquiera de sus elementos sufre una avería, el autómata llega, de nuevo, al estado
1. En este punto se permite la puesta en marcha de la cadena redundante. La evolución
S\{sd1,sd2,rd1,rd2}
pd1,pd2pc1,pc2{A}
sd1,sd2,
rd1,rd2
dd1,dd2 0 1 2
4 3
{A} = da1, da2, ra1, ra2, pa1, pa2, sa1, sa2
pc1,pc2
pc1,pc2,sc1,sc2,{A}
dd1,dd2
S\{sd1,sd2,rd1,rd2}
sd1,sd2,
rd1,rd2
S\{dd1,dd2
pc1,pc2}
SP_DD
S\{pc1, pc2,dd1, dd2, sc1,
sc2}
pc1, pc2
sc1, sc2
pc1, pc2
sc1, sc2
dc1,dc2
0 1 2
dc1,dc2
(*)
S\{dc1,dc2}
(*) = S\{dc1, dc2,pc1, pc2, sc1, sc2}
SP_SD
Anexo 5. Evolución del modelo
129
lógica nos lleva, a partir de este punto, hasta el estado cero a través de la parada o avería
del otro componente prioritario. En este punto, tenemos la cadena auxiliar en
funcionamiento y la prioritaria en reparación. Una vez realizada la reparación del
componente principal, sería deseable volver a poner en marcha su cadena. De esta
manera volveríamos a encontrarnos en el punto 2. Es en este punto exclusivamente,
cuando se hace posible la parada y la reparación de la cadena redundante. En definitiva,
esta especificación, modelada por el autómata de la figura 5 es la traducción lógica de la
frase “sólo será posible reparar la cadena redundante si la principal está en
funcionamiento”. O lo que es lo mismo, prioridad absoluta de reparación a la cadena
principal (rompiendo en este caso la política FIFO).
Figura 22. Parada de los elementos de la cadena principal por avería
La especificación de la figura 22, modela la parada de un elemento de la cadena
principal cuando otro sufre una avería. De esta forma el estado 2 representa la situación
de funcionamiento nominal de la cadena. Si a partir de este punto se produce el evento
pc1 o pc2, nos desplazaríamos hasta el punto 3 en el que uno de los dos componentes
estaría averiado. Las únicas posibilidades para salir de este punto son o bien que el otro
elemento se averíe, o bien que lo detengamos. En cualquier caso, el destino es siempre
el punto cuatro en el que encontramos la cadena parada en su totalidad. A partir de aquí
siempre es posible efectuar las reparaciones y puestas en marcha correspondientes para
recuperar el funcionamiento deseado.
sc1,sc2,
pc1,pc2
{A} = da1, da2, ra1, ra2, pa1, pa2, sa1, sa2
S\{pc1,pc2
sc1,sc2}{A}
dc1,dc2dc1,dc2
4 0 3 1 2
rc1,rc2
pc1,pc2
pc1,pc2
sc1,sc2
S\{rc1,rc2dc1,dc2}
sc1,sc2
S\{pc1,pc2sc1,sc2,dc1,
dc2}
SP_c1_c2
S\{dc1
dc2}
Anexo 5. Evolución del modelo
130
Figura 23. Parada de los elementos de la cadena redundante por avería.
El funcionamiento de esta especificación es análogo al de SP_c1_c2.
Figura 24. Puesta en marcha automática del funcionamiento degradado
La especificación SP_PA1 de la figura 24 es un autómata que modela el
lanzamiento en degradado del componente A. El estado de funcionamiento nominal del
sistema se encuentra en el punto cero. A partir de él, el evento pa1 (avería parcial) nos
conduce al estado 2. En este punto, la única acción controlable posible es la puesta en
marcha en modo degradado (da2). Hecho esto, en el estado cero se procederá a la
parada y reparación del elemento A siempre que se considere oportuno (ambas acciones
permitidas).
sd1,sd2,
pd1,pd2
{A} = da1, da2, ra1, ra2, pa1, pa2, sa1, sa2
S\{pd1,pd2sd1,sd2}
{A}
dd1,dd2dd1,dd2
4 0 3 1 2
rd1,rd2
pd1,pd2
pd1,pd2
sd1,sd2
S\{rd1,rd2
dd1,dd2}
sd1,sd2
S\{pd1,pd2
sd1,sd2,dd1,dd2}
SP_d1_d2
S\{dd1dd2}
da2
pc1,pc2,pd1,pd2
0 1
pa1
Σ\{pa1}
SP_PA1
Anexo 5. Evolución del modelo
131
Figura 25. Reparación de la máquina A
Esta especificación SP_PA2, modela la prioridad de reparación del componente
A cuando éste sufre una avería total. Es necesario recordar que este componente no
tiene otro componente redundante que nos asegure la producción llegado el caso de la
avería total.
Figura 26. Especificación de reparación FIFO
La política de reparaciones como ya se ha visto en la memoria, es la FIFO (salvo
las citadas excepciones). Para asegurar que el primer elemento que sufre la avería sea el
primero en ser reparado, utilizamos una estructura simple de cuatro estados que
compara siempre dos elementos. De esta manera, siempre será posible dar una prioridad
de reparación a un elemento si es éste el primero que sufrió la avería. En efecto, si
observamos la figura 26 (especificación FIFO entre A1 y C2), la especificación
compara los elementos A y C2. Supongamos que hay una avería parcial del componente
A (pa1) y una avería del componente C2 (pc2), el modelo llega al estado 2 o al estado 3.
Si llega al estado 2, quiere decir que el segundo evento que se ha producido es la avería
da1
ra2,pc1,pc2,pd1,pd2
sc1,sc2,sd1,sd2 0 1
pa2
Σ\{pa2}
SP_PA2
Σ \ (pa1, pc2,
ra1, rc2, ra2,da2)
pa1, pc2
ra1, rc2, ra2,da2
pa1
pc2
0 1
2
3
Σ \ (pa1, pc2 )
rc2, ra2, da2
rc2, ra2, da2
Σ\( ra1, rc2, ra2, da2)
Σ\( ra1, rc2, ra2, da2)SP_FIFO_A_C2
Anexo 5. Evolución del modelo
132
parcial de A1, lo cual implica que es el elemento C2 el que sufrió la avería en primer
lugar. En ese caso, se repara inicialmente el componente C2 (llegamos al estado 1), y
luego el elemento A (política FIFO).
Con idéntica estructura, hemos diseñado especificaciones FIFO para modelar las
políticas de reparación de los distintos componentes. Así, teniendo cinco componentes
(A, C1, C2, D1 y D2), el número de especificaciones FIFO será de 10. Nos limitamos a
incluir una de ellas (figura 26).
Anexo 5. Evolución del modelo
133
Conclusión
Todas estas especificaciones han sido construidas sobre UMDES con la rutina
“create_fsm.exe”. Una vez creadas todas las necesarias, es posible realizar una
composición paralela entre ellas, para encontrar el funcionamiento del modelo sometido
al control del conjunto. De esta manera, con la rutina “product.exe” de UMDES, se
realiza su producto paralelo. En este caso, el número de especificaciones es demasiado
elevado. El número de cálculos que tiene que realizar el programa impide la obtención
de resultados. Para solucionar este problema, hemos estudiado las especificaciones
llegando a la conclusión de que algunas de ellas son redundantes, y que no hacen si no
complicar los cálculos. En el siguiente apartado comentaremos las modificaciones
realizadas hasta conseguir un modelo capaz de ser tratado informáticamente.
En cualquier caso, la mayoría de las especificaciones diseñadas han sido
conservadas en el modelo final, y sirvieron para desarrollar la capacidad de diseño del
autor del proyecto. A la hora de construir modelos de especificaciones mediante
autómatas a estados, no hay reglas fijas. Es a menudo a partir de la experiencia que se
consigue desarrollar la habilidad necesaria para el modelado.
Anexo 5. Evolución del modelo
134
Modelado del funcionamiento de la rama A: primeramodificación
En el apartado anterior se ha detallado la primera construcción del un modelo
para la cadena A de nuestro sistema. Su complejidad y elevado número de
especificaciones impedían la obtención de resultados. Para resolver este problema, se
intentaron eliminar algunas de las especificaciones redundantes o algunas partes de las
mismas.
El modelo del proceso (autómatas de los componentes base) permanece sin
cambios hasta el final de nuestros trabajos. La lista de las especificaciones del apartado
anterior es la siguiente:
• SP_DD
• SP_SD
• SP_D1_D2
• SP_C1_C2
• SP_PA1
• SP_PA2
• 10 Especificaciones FIFO
En total 16 especificaciones. La primera tentativa para disminuir el número de
las mismas es hacer la siguiente consideración: una vez producida la avería en un
componente de la cadena C o la cadena D, el otro será detenido inmediatamente,
impidiendo así la posibilidad de que éste último se averíe. Esta nueva consideración
tiene como consecuencia la eliminación directa de dos especificaciones FIFO. Aquellas
que gobiernan la reparación de los dos elementos de la misma cadena. Así las
especificaciones SP_FIFO_C1_C2 y SP_FIFO_D1_D2 se eliminan directamente. Del
mismo modo la especificación FIFO entre la máquina A y C1 (SP_FIFO_A_C1) y la
especificación FIFO entre la máquina A y C2 (SP_FIFO_A_C2) puede transformarse en
una sola. Lo mismo sucede con SP_FIFO_A_D1 y SP_FIFO_A_D2. De esta manera
eliminamos dos nuevas especificaciones. A cambio, se creará una sola especificación
para detener el elemento que acompaña al que se averíe en las cadenas C o D.
Anexo 5. Evolución del modelo
135
Figura 27. Especificación FIFO entre el componente A y la cadena C
Esta especificación sustituye a la FIFO entre A y C1, y a la FIFO entre A y C2.
C1 y C2 nunca sufrirán una avería al mismo tiempo.
El razonamiento es similar para la cadena D. El autómata de la especificación es
idéntico al anterior de la figura 27:
Figura 28. Especificación FIFO entre el componente A y la cadena D
El resto de especificaciones FIFO son las mismas que en el apartado anterior.
Así en contramos SP_FIFO_C1_D1, SP_FIFO_C1_D2, SP_FIFO_C2_D1 y
SP_FIFO_C2_D2.
Σ \ (pa1, pc1,
ra1, rc2, rc1,pc2)
pa1, pc1, pc2
ra1, rc1, rc2
pa1
pc1, pc2
0 1
2
3
Σ \ (pa1,
pc1 pc2 )
rc1, rc2
ra1
Σ\(rc1, rc2, ra1)
Σ\(rc1, rc2, ra1)SP_FIFO_A_C
Σ \ (pa1, pd1,
ra1, rd2, rd1,pd2)
pa1, pd1, pd2
ra1, rd1, rd2
pa1
pd1, pd2
0 1
2
3
Σ \ (pa1,
pd1,pd2 )
rd1, rd2
ra1
Σ\(rd1, rd2, ra1)
Σ\(rd1, rd2, ra1)SP_FIFO_A_D
Anexo 5. Evolución del modelo
136
Se ha conseguido reducir el modelo en cuatro especificaciones. A cambio es
necesario crear una nueva como se ha dicho anteriormente. Esta especificación obligará
a detener inmediatamente una cadena que haya sufrido una avería.
Figura 29. Especificación parada de cadena por avería.
Como se puede observar sobre la figura 29, el sistema evoluciona hasta el
funcionamiento nominal en el punto 2. Si se produjera una avería en este momento en
los elementos de la cadena C o D (pc1,pc2 pd1,pd2), la cadena sería detenida llegando
al punto 4. A partir de aquí el sistema evoluciona normalmente poniendo en marcha la
cadena redundante y procediendo a efectuar las reparaciones correspondientes.
Conclusión
Se ha conseguido en esta primera tentativa disminuir el número de
especificaciones de 16 a 13. El modelo resultante, pese a estar aligerado no es todavía
óptimo. Los programas de que disponemos, en concreto UMDES, no son capaces de
procesar aun el modelo.
sc1,sc2,pc1pc2,sd1,sd2
pd1,pd2
{A} = da1, da2, ra1, ra2, pa1, pa2, sa1, sa2
S\{pc1,pc2,
sc1,sc2,pd1,pd2,sd1,sd2}
{A}
dc1,dc2,dd1,dd2
dc1,dc2,dd1,dd2
4 0 3 1 2
rc1,rc2
rd1,rd2
pc1,pc2pd1,pd2
sc1,sc2
sd1,sd2
S\{rc1,rc2
dc1,dc2,rd1,rd2,dd1,dd2}
sc1,sc2
sd1,sd2
S\{pc1,pc2sc1,sc2,dc1,dc2}
SP_c1_c2_d1_d2
S\{dc1dc2,dc1
dc2}
dc1,dc2,dd1,dd2
Anexo 5. Evolución del modelo
137
Modelado del funcionamiento de la rama A: segunda
modificación
El modelo del apartado anterior es todavía demasiado complejo para la obtención de
resultados. La lista de las especificaciones del apartado anterior es la siguiente:
• SP_DD
• SP_SD
• SP_D1_D2
• SP_C1_C2
• SP_PA1
• SP_PA2
• SP_C1_C2_C1_C2
• 6 especificaciones FIFO
En total 13 especificaciones. Para seguir simplificando, se decidió construir una
especificación global de funcionamiento que permitiera englobar 4 especificaciones
FIFO, SP_DD, SP_C1_C2, SP_D1_D2 y SP_C1_C2_C1_C2. Pese a ser una
especificación complicada, gracias a ella podemos reducir en 8 el número de
especificaciones totales. El autómata correspondiente es mostrado en la figura siguiente.
Figura 30. Especificación de funcionamiento
pd1 pc1
A
rc1,rc2, A
rd1,rd2, A rd1,rd2, A
A
dc2
rd1,rd2, A
rc1,rc2, A
pc1,pc2
sc1,sc2,
pc1,pc2
dd1
sd1
dd2
sd1,sd2,
pd1,pd2
sd1,sd2,pd1,pd2
*
sc1,sc2
sc1,sc2
dc1sa1
da1 0
1 2
8 3
7 4
6 5
* = rc1,rc2,A\{sa1}
SP_FONCTIONNEMENT
Anexo 5. Evolución del modelo
138
Esta especificación regula gran parte del comportamiento de la cadena A. La
secuencia de puesta en marcha es la siguiente: Componente A (da1), componente C1
(dc1), componente C2 (dc2). Mientras no se produzca una avería, el modelo
permanecerá en el estado 3. Si ésta se produjera en C1 (respectivamente en C2), se
detendría el elemento C2 (respectivamente en C1) y se pondría en marcha D1 y D2 para
alcanzar el estado 7 (funcionamiento degradado). Siempre es posible detener los
elementos para efectuar una reparación con el fin de recuperar el estado de
funcionamiento nominal. Si se produjese una avería en el elemento C1 (pc1) en mitad
de la secuencia de arranque (estado 2), el modelo evolucionaría hacia el estado 5.
Después de esta avería en la cadena prioritaria, la cadena redundante sería puesta en
marcha (dd1 y dd2) para alcanzar el funcionamiento degradado. La reparación del
componente C1 será únicamente posible en esta situación. La especificación
SP_FONCTIONNEMENT permite después de esta reparación llevar el sistema hasta un
estado de funcionamiento nominal parando sucesivamente los componentes D1 y D2
(dd1, dd2). Desde el estado 1, la secuencia de arranque es ya conocida.
Anexo 5. Evolución del modelo
139
Conclusión
Hemos conseguido reducir el modelo del sistema, el cual consta en este
momento de proceso (que no ha cambiado desde el principio), y 6 especificaciones. De
esta forma conseguimos los primeros resultados sobre UMDES. El funcionamiento de
proceso acoplado a especificaciones proporciona el primer modelo completo de la línea
A.
La lista de especificaciones actual es la siguiente:
• SP_FIFO_A_C
• SP_FIFO_A_D
• SP_SD
• SP_PA1
• SP_PA2
• SP_FONCTIONNEMENT
Sin embargo, el modelo no es perfecto. La suposición realizada en el apartado
anterior causa problemas. No puede considerarse que una vez producida la avería, la
máquina de la misma línea sea inmediatamente detenida. Siempre será posible que
ambas máquinas sufran la avería al mismo tiempo. El evento avería es incontrolable. No
se puede impedir mediante un controlador la ocurrencia de un evento incontrolable. El
modelo proporcionado por UMDES es un modelo no controlable, y por tanto, no válido.
En cualquier caso, este primer modelo de la línea A permite confirmar que UMDES
es capaz de tratar casos con magnitudes reales, y que tan sólo es necesario afinar bien
las especificaciones.
Anexo 5. Evolución del modelo
140
Modelado del funcionamiento de la rama A: terceramodificación
En cierta forma el siguiente paso a realizar es un paso atrás. La suposición de
que los dos elementos de la misma cadena no pueden sufrir la avería al mismo tiempo
no es válida. En su momento decidimos probar con esta suposición para disminuir el
tamaño del modelo. Si bien es cierto que esto se consiguió, el resultado fue una
estructura no controlable. La teoría de Ramdge y Wonham propone un controlador que
impide que se verifiquen los eventos controlables para conseguir un funcionamiento
deseado. Esto no es cierto con los eventos no controlables, como una avería.
Vamos a volver a crear especificaciones FIFO para permitir la avería de los
pares C1-C2 y D1-D2. Dichas especificaciones tendrán la estructura ya conocida de
cuatro estados que compara el momento en que dos eventos han tenido lugar. De esta
forma, serán necesarias seis especificaciones:
Figura 31. SP_FIFO_A_C1. Especificación FIFO entre A y C1.
Figura 32. SP_FIFO_A_C2. Especificación FIFO entre A y C2.
Σ \ (pa 1, pc1, ra1,
rc1, ra2, da2)
pa1, pc1
ra1, rc1, ra2, da2
pa1
pc1
0 1
2
3
Σ \ (pa 1, pc1 )
rc1, ra2, da2
rc1, ra2, da2
Σ\( ra1, rc1, ra2, da 2)
Σ\( ra1, rc1, ra2, da 2)
Σ \ (pa 1, pc2, ra1,
rc2, ra2, da2)
pa1, pc2
ra1, rc2, ra2, da2
pa1
pc2
0 1
2
3
Σ \ (pa 1, pc2 )
rc2, ra2, da2
rc2, ra2, da2
Σ\( ra1, rc2, ra2, da 2)
Σ\( ra1, rc2, ra2, da 2)
Anexo 5. Evolución del modelo
141
Figura 33. SP_FIFO_A_D1. Especificación FIFO entre A et D1
Figura 34. SP_FIFO_A_D2. Especificación FIFO entre A y D2.
Figura 35. SP_FIFO_C1_C2. Especificación FIFO entre C1 y C2.
Figura 36. SP_FIFO_D1_D2. Especificación FIFO entre D1 y D2.
Σ \ (pa 1, pd1, ra1,
rd1, ra2, da 2)
pa1, pd1
ra1, rd1, ra2, da2
pa1
pd1
0 1
2
3
Σ \ (pa 1, pd1 )
rd1, ra2, da 2
rd1, ra2, da 2
Σ\( ra1, rd1, ra2, da2)
Σ\( ra1, rd1, ra2, da2)
Σ \ (pa 1, pd2, ra1,
rd2, ra2, da 2)
pa1, pd2
ra1, rd2, ra2, da2
pa1
pc1
0 1
2
3
Σ \ (pa 1, pd2 )
rd2, ra2, da 2
rd2, ra2, da 2
Σ\( ra1, rd2, ra2, da2)
Σ\( ra1, rd2, ra2, da2)
Σ \ (pc1, pc2,
rc1, rc2)
pc1, pc2
rc1, rc2
pc1
pc2
0 1
2
3
Σ \ (pc1, pc2 )
rc2
rc1
Σ\( rc1, rc2)
Σ\( rc1, rc2)
Σ \ (pd1, pd2,
rd1, rd2)
pd1, pd2
rd1, rd2
pd1
pd2
0 1
2
3
Σ \ (pd1, pd2 )
rd2
rd1
Σ\( rd1, rd2)
Σ\( rd1, rd2)
Anexo 5. Evolución del modelo
142
Son necesarias seis especificaciones ya que en ellas se comparan dos a dos los
elementos. Teóricamente sería necesario construir diez. Las otras cuatro están
integradas en la especificación de funcionamiento SP_FONCTIONNEMENT.
De esta forma, construimos la especificación global de funcionamiento
realizando como siempre el producto paralelo de todas las especificaciones: las seis
FIFO, SP_FONCTIONNEMENT, SP_PA2 y SP_SD. Aplicando esta especificación al
modelo del proceso se obtiene el modelo del sistema total (funcionamiento en bucle
cerrado). El resultado es un autómata con 484 estados y 1396 transiciones.
Anexo 5. Evolución del modelo
143
Modelado del funcionamiento de la rama A: últimamodificación
El modelo obtenido con 484 estados y 1396 transiciones es el modelo final del
proyecto. Sin embargo aun quedaría una última modificación a realizar en los modelos
parciales. Esto es posible ya que hay una especificación redundante. La especificación
SP_SD está contenida en SP_FONCTIONNEMENT. Veamos de nuevo las figuras.
Figura 37. SP_SD
Figura 38. SP_FONCTIONNEMENT
pd1 pc1
A
rc1,rc2, A
rd1,rd2, A rd1,rd2, A
A
dc2
rd1,rd2, A
rc1,rc2, A
pc1,pc2
sc1,sc2,
pc1,pc2
dd1
sd1
dd2
sd1,sd2,
pd1,pd2
sd1,sd2,pd1,pd2
*
sc1,sc2
sc1,sc2
dc1sa1
da1 0
1 2
8 3
7 4
6 5
* = rc1,rc2,A\{sa1}
SP_FONCTIONNEMENT
S\{pc1, pc2,
dd1, dd2, sc1,
sc2}
pc1, pc2
sc1, sc2
pc1, pc2
sc1, sc2
dc1,dc2
0 1 2
dc1,dc2
(*)
S\{dc1,dc2}
(*) = S\{dc1, dc2,pc1, pc2, sc1, sc2}
SP_SD
Anexo 5. Evolución del modelo
144
Recordemos que la especificación SP__SD modelaba la parada de los elementos
redundantes D1 y D2 y daba prioridad absoluta de reparación a la cadena principal
(rompiendo en este caso la política FIFO). Si se observa la figura 2, la especificación
SP_FONCTIONNEMENT realiza esta función, regulando los cambios de cadena y los
instantes en que se puede proceder a las distintas reparaciones.
Conclusión
Efectivamente, se comprueba que la especificación SP_SD de la figura 1 es
redundante. Si se excluye del producto paralelo de las especificaciones, y
posteriormente se realiza el funcionamiento acoplado de especificaciones y proceso, el
resultado es el mismo que obteníamos con SP_SD. El autómata tiene 484 estados y
1396 transiciones. Este autómata (Figura 39) es el resultado final del proyecto, y el que
se explica en la memoria.
Figura 39. Autómata modelo final.
pc2, sa1
d
dc1 dc2
pa1 da1
da2
120
pc1
0
dd1
sd1
00
0
00
0
sc2
pc1, sa1
pa1
da2
dc2
pc2
sc1
dd1 dd2
102
dd2
0
80
pa1
da2
rc1
rc2
sd2
dc1
dc2
0
80
80
0
0
0
800 0
0
0
0
sa1
sc1
Anexo 6. Continuación del proyecto
145
Anexo 6. Continuación del proyecto
Anexo 6. Continuación del proyecto
146
Anexo 6. Continuación del proyecto
Una vez creado el modelo de autómatas de estados utilizando la síntesis de
lenguajes, es necesario realizar la traducción a un modelo de redes de Petri capaz de ser
tratado mediante el programa de simulación MOCA RP. Esta labor fue realizada en el
seno del laboratorio de automática de Lyon entre los meses de Marzo y Junio de 2004.
De esta forma se continuaron los trabajos comenzados en este proyecto. Los objetivos
de esta traducción son varios. Mostrar la posibilidad de realizar la conversión de un
grafo de estados en una red de Petri explotable por MOCA RP, demostrar la validez del
modelado a través de la síntesis de lenguajes de autómatas a estados, y realizar la
aplicación a un caso propuesto por el industrial.
El proceso de la conversión del grafo de estado a red de Petri
El modelo obtenido en nuestro trabajo no es explotable directamente a través de
MOCA RP. Este programa realiza simulaciones con el fin de optimizar el
funcionamiento de una cadena de producción, y trabaja exclusivamente con redes de
Petri.
La primera etapa de este trabajo, en la que participó el autor de este proyecto,
consistió en encontrar una herramienta que permitiera la conversión del modelo de
autómatas en redes de Petri. Esta herramienta encontrada en Internet es el programa
SYNET.El proceso “creación del modelo/conversión/simulación” es detallado en la
figura siguiente.
Figura 1. creación del modelo/conversión/simulación
x elementos
y especificaciones
UMDES
Grafo de estadoFichero txt 1
Macro1
Grafo de estadoFichero txt 2
SYNET
Macro2
RdP nosimulableFichero
txt 3
MOCA RPRdP
simulableFichero
txt 4
Anexo 6. Continuación del proyecto
147
Programas empleados
Inicialmente se ha empleado UMDES, con el que se crearon los modelos de
autómatas (ver memoria). Posteriormente, para convertir estos modelos en modelos de
redes de Petri, el programa SYNET. Finalmente, para efectuar las simulaciones a partir
de la red de Petri, se utilizó el programa MOCA RP, utilizado por el grupo TOTAL.
Sin embargo, cada programa tiene su propia sintaxis. Ha sido necesario
desarrollar dos rutinas de conversión programadas en Visual Basic. La primera para
convertir los ficheros utilizados por UMDES en ficheros utilizados por SYNET, el otro
para la conversión de la red de Petri en el lenguaje de SYNET en el lenguaje de MOCA
RP.
SYNET
SYNET es un paquete que contiene herramientas capaces de tratar redes de
Petri. Contiene una función importante para nosotros capaz de convertir un lenguaje de
estados (utilizado por UMDES) en una red de Petri. SYNET ha sido desarrollado por
Benoît Caillaud y Eric Badouel del IRISA (institut de recherche en informatique et
système aléatoire) de Rennes (Francia). Este programa trabaja sobre la plataforma
LINUX. Permite, a partir de un fichero de entrada que describe un Automáta de estados
finito, construir una red de Petri. Para ello en la consola de LINUX, tecleamos: synet –r
–x –o <el nombre del fichero de salida.net> <el nombre del fichero de entrada.aut>.
La sintaxis del fichero de entrada (autómata) es la siguiente:
des(0, 96, 27) (estado inicial, número de transiciones, número de
estados)
( 0,de1, 1) (desde el estado 0, si la transición de1 se verifica,
alcanzamos el estado 1)
( 1,se1, 0)
( 1,pe1, 2)
Anexo 6. Continuación del proyecto
148
( 1,de2, 3)
( 2,re1, 0)
…
La sintaxis del fichero de salida (red de Petri) :
transición de1 lista de todas las transiciones
transición se1
plaza x_5 lista de todas las plazas, con el número de fichas en el instante
inicial
plaza x_6 := 1
flow x_9 ---> de3 lista de arcos, éste va de la plaza 9 a la transición de3
flow x_0 <--- pe1 arco que va de la transición pe1 a la plaza 0
El programa propone igualmente una interfaz gráfica, que permite visionar tanto
el autómata de entrada como la red de Petri. Para grandes sistemas, esta interfaz no es
práctica, ya que la vista se reparte en numerosos folios perdiendo claridad.
Figura 2. Ejemplo de salida gráfica de SYNET
Anexo 6. Continuación del proyecto
149
MOCA RP
El programa MOCA RP es comentado en el anexo 2. Para realizar la simulación,
se introducen los elementos siguientes:
• Duración de una simulación
• Número de simulaciones efectuadas. El resultado será la media de todas
las secuencias.
• Duración máxima de cálculo: tiempo tras el cual la simulación será
obligada a detenerse.
• Germen del generador: serie de cifras que sirven de base para la
generación de números aleatorios.
Figura 3. Página de entrada de los parámetros del motor de cálculo
Anexo 6. Continuación del proyecto
150
Una vez realizados los cálculos, los resultados obtenidos tienen forma de archivo
de texto exportable a un fichero EXCEL o WORD. Los diferentes parámetros de salida
son:
• Número medio de traspaso de las transiciones: frecuencia, desviación
típica y confianza al 90%.
• Tiempo medio de estancia en una plaza: tiempo medio, desviación típica
y confianza al 90% y porcentaje con respecto al tiempo total.
• Marcaje medio de cada plaza: marcaje medio, desviación típica y
confianza al 90%.
• Número medio de fichas al final de la historia: marcaje medio,
desviación típica y confianza al 90%.
Herramientas de conversión
Para pasar de un fichero de salida de un programa a un fichero de entrada de otro
(por ejemplo de UMDES a SYNET), es necesario convertir los datos de salida a una
sintaxis comprensible por el otro programa.
Estas herramientas son macros Microsoft Excel, programados en Visual Basic.
El funcionamiento es simple. Almacenan la información de entrada en forma de tablas
para, posteriormente, transformar en el formato deseado el fichero de salida.
Para hacer funcionar estos programas, es suficiente copiar-pegar del fichero de
texto en Excel para luego lanzar la rutina haciendo clic sobre el botón correspondiente.
Los códigos de ambas macros se adjuntan en anexo.
Anexo 6. Continuación del proyecto
151
Aplicación a casos simples
Para asegurar el buen funcionamiento del planteamiento, se aplicó esta
metodología a dos casos simples. De esta forma se comprobó que la traducción y la
posterior simulación daban buenos resultados, antes de aplicarlas al modelo propuesto
por el grupo TOTAL.
Para este caso de prueba se construyeron dos modelos de tres componentes
dispuestos, por un lado en paralelo, y por otro en serie. Así, para poder realizar una
comparación, se procedió a la construcción de dichos modelos sobre redes de Petri sin
la ayuda de SYNET. Del mismo modo se construyeron los modelos grafo de estados, y
se ha procedió a su traducción. Los resultados proporcionados por los distintos modelos
fueron comparados validando el método.
Grafo de estado
En primer lugar se construyó el autómata. Para ello se utilizó la librería
UMDES como se ha mostrado a lo largo del proyecto. El modelo creado es una
máquina de tres estados y cuatro transiciones (modelos de base de nuestros trabajos).
Después de la construcción de autómatas para los tres componentes, se construyó el
producto síncrono para obtener la línea de tres máquinas. A este modelo de proceso se
le han aplicado especificaciones de reparación FIFO y de productividad.
Anexo 6. Continuación del proyecto
152
UMDES, para el caso serie, ha proporcionado un autómata compuesto de 38 estados y
106 transiciones.
Figura 4. Trazado parcial del autómata del caso serie.
Para el caso en paralelo el modelo autómata está compuesto de 38 estados y 120transiciones.
Figura 5. Trazado parcial del autómata del caso paralelo.
d1
s1 s2
d2
p1 p1, p2
d3
s3
p1, p2, s1, s2
100p3
p1
s1, s2, p2
p2, s2
r1r3
d1
d1
s1 s2
d2
p1 p1,p
d3
s3
p1, p2, s1,s
100p3
p1
s1, s2, p2
p2,s
r1r3
d1
33 66 66
3333333333
d2d3
Anexo 6. Continuación del proyecto
153
Red de Petri
La simulación de estos modelos con el motor de cálculo de MOCA RP requiere
la traducción del grafo de estados en red de Petri. Para ello es necesario convertir el
fichero obtenido de UMDES a través de la primera macro hecha sobre Visual Basic (ver
anexo 7). Posteriormente, tras pasar por SYNET, obtenemos una red de Petri que
podemos convertir a la sintaxis aceptada por MOCA RP gracias a una segunda macro
sobre Visual Basic (ver anexo 8).
Las dos redes de Petri obtenidas poseen:
• Para el caso serie: 13 plazas, 12 transiciones y 48 arcos.
Figura 6. Red de Petri obtenida por SYNET en MOCA RP para el caso serie
Anexo 6. Continuación del proyecto
154
• Para el caso paralelo: 12 plazas, 12 transiciones y 36 arcos.
Figura 7. Red de Petri obtenida por SYNET en MOCA RP para el caso paralelo
Modelado directo en MOCA RP
Para validar el método, se realizó el modelado directo sobre la interfaz gráfica de
MOCA RP. La red de Petri para ambos casos está compuesta de tres redes
independientes correspondientes a los tres componentes.
Anexo 6. Continuación del proyecto
155
Figura 8. Red que describe el comportamiento de un componente
Vemos en la figura que cada componente está modelado por 3 plazas y 4
transiciones. Los reenvíos presentes en la figura (hacia las plazas 10 y 11) son añadidos
únicamente para obtener las tasas de producción en un instante dado.
Cuando el funcionamiento es en paralelo, cada componente funciona sin relación
con el resto. Si por el contrario, se encuentran distribuidos en serie, para modelar la
especificación de funcionamiento (puesta en marcha secuencial de 1, después 2 y
finalmente 3), se utiliza una función de MOCA RP que consiste en modificar el valor de
un mensaje de verdadero a falso y viceversa. Por ejemplo, cuando todas las máquinas
están en espera, es imposible poner en marcha la máquina 2, ya que la transición d2
(puesta en marcha de la máquina 2), exige que el mensaje M1 esté en “verdadero”. Este
mensaje permanecerá en “falso” hasta el arranque de la máquina 1.
Anexo 6. Continuación del proyecto
156
Figura 9. Red de Petri del funcionamiento de la línea con tres componentes en serie.
A cada puesta en marcha, el mensaje correspondiente a la máquina afectada pasa
a verdadero. Lo contrario sucede con los eventos avería o parada voluntaria. La puesta
en marcha de la máquina 2 exige el valor lógico “verdadero” para el mensaje M1, en
caso contrario, la transición d2 no podrá ser habilitada. El caso es análogo para el resto
de elementos.
Anexo 6. Continuación del proyecto
157
Figura 10. Red de Petri del funcionamiento de la línea con tres componentes en
paralelo.
A partir de estas redes, se utilizan reenvíos sobre otra página que contiene la
estructura que proporciona en cada momento la tasa de productividad.
Existen dos plazas que componen el número de máquinas que funcionan al
mismo tiempo. Así mismo se indica también el número de máquinas que no funcionan
(bien se encuentren averiadas o simplemente en espera). Se utilizan arcos inhibidores y
mensajes internos de MOCA RP para obtener las plazas que corresponden a las tasas de
producción esperadas. El caso paralelo posee cuatro estados posibles: 0%, 33%, 66%,
100%. En serie encontramos dos estados: 0% y 100%.
Anexo 6. Continuación del proyecto
158
Figura 11. Red conteniendo las tasas de producción.
Figura 12. Red de Petri para las tasas de producción en serie.
Anexo 6. Continuación del proyecto
159
Resultados
A partir de las cuatro redes de Petri creadas, se procede a lanzar la simulación
con el motor de cálculos de MOCA RP en lenguaje C.
La simulación, en nuestro caso, consiste en una repetición de 100 escenarios de un año
de funcionamiento para cada red. Las leyes que gobiernan las transiciones son fijadas
por el diseñador. De esta forma, la puesta en marcha de una máquina seguirá una ley de
Dirac 0. Esto es, cuando la máquina se encuentra en espera, ésta es arrancada
inmediatamente si no hay ninguna especificación que lo impida. La avería y la parada
son gobernadas por una ley exponencial de parámetro µ = 0.01, lo cual significa que
cada transición será franqueada alrededor de una vez cada 100 horas. La reparación
obedece a una ley exponencial de parámetro ? = 1, equivalente a una duración de
reparación de una hora.
La simulación de 100 ciclos de un año cada uno (8760 horas), proporciona los
siguientes resultados:
Modelo procedente de la traducción Modelo directo sobre red de Petri
Serie Paralelo Serie Paralelo
Producción 0% 262 h 0.09 h 255 h 0.003 h
33% 5 h 2.6 h
66% 255 h 253 h
100% 8498 h 8500 h 8505 h 8503 h
Los resultados obtenidos son totalmente coherentes. Las diferencias existentes
entre la salida procedente del modelado directo en MOCA RP, y la procedente de
nuestra metodología, son mínimas. Sobre una simulación de 8760 horas, la diferencia es
del orden de 0.1%. Se da por válido el método y se procede a la simulación del caso
propuesto por total.
Anexo 6. Continuación del proyecto
160
El caso propuesto por TOTAL
Una vez comprobada la validez de nuestro procedimiento, se ha procedido a la
simulación del caso propuesto por el grupo Total. El modelo obtenido en nuestros
trabajos, fue traducido a redes de Petri y simulado sobre MOCA RP.
Figura 13. caso propuesto por TOTAL
El caso de la figura es el estudiado en el capítulo 3 de la memoria. Recordamos:
problema separado en dos líneas. La línea A conteniendo los elementos A, C1, C2, D1 y
D2 por un lado, y la línea B con los tres elementos E en paralelo. El modelo UMDES es
el mismo creado en nuestros trabajos.
A
D1
C1
E2
E1
W
B
C2
D2
T
E3
TW
170/102/0
120/0 120/0
80/0 80/0
A,C1,C2:120/102/0
A,D1,D2:80/80/0
50
50
50
B,E1-E2:0/50/100
Producción en miles debarriles al día
100/72/0
Elementos de la cadenasometidos a riesgos de
avería
Anexo 6. Continuación del proyecto
161
Línea AEl modelo de la línea A es un autómata de 484 estados y 1396 transiciones. Al
realizar la transformación a red de Petri con la ayuda de SYNET, la red obtenida
contiene 43 plazas, 24 transiciones (las 24 transiciones posibles en los diferentes
componentes de la línea) y 262 arcos. Tras realizar algunos retoques sobre MOCA RP
para hacer aparecer las tasas de producción, hemos simulado un año de producción
obteniendo los siguientes resultados:
• 120 barriles /hora durante 7456 horas.
• 102 barriles / hora durante 73 horas.
• 80 barriles / hora durante 156 horas.
• 0 barriles / hora durante 1075 horas.
Simulación del funcionamiento de la
línea A a lo largo de un año
120 barriles/h 102 barriles/h 80 barriles/h 0 barriles/h
Figura 14. Gráfica con la producción de la línea A a lo largo de un año
Anexo 6. Continuación del proyecto
162
Línea B
Compuesta por los elementos E1, E2 y E3 cuyo funcionamiento es similar al de
C o D.
El modelo UMDES posee 52 estados y 102 transiciones. La conversión a red de
Petri da un sistema de 19 plazas, 12 transiciones y 89 arcos. Los resultados tras la
simulación con el motor de cálculos dan:
• 8758 horas de funcionamiento de dos bloques.
• 2 horas de funcionamiento de un solo elemento.
• Ausencia de parada total.
• Ningún funcionamiento de los tres elementos a l mismo tiempo (de acuerdo con
nuestras exigencias).
Simulación del funcionamiento de la
línea B a lo largo de un año
2 bloques en funcionamiento 1 bloque en funcionamiento
Figura 15. Gráfica con la producción de la línea B a lo largo de un año
Anexo 6. Continuación del proyecto
163
Conclusión
Se ha establecido un método para realizar la conversión de sistemas de eventos
discretos en forma de autómatas a estados a una representación en redes de Petri a
través del programa SYNET. Para ello han sido programadas dos macros en Visual
Basic para realizar la transferencia de datos entre los diferentes programas utilizados.
A través de dos casos simples, se han comparado los resultados obtenidos de la
simulación entre el modelo en redes de Petri y el modelo de grafos de estado convertido
posteriormente a redes de Petri siguiendo nuestro método. Una vez obtenidos resultados
muy próximos podemos concluir que:
• El modelado utilizando la síntesis de lenguajes y autómatas de estados está bien
adaptado a este tipo de sistema de producción.
• Nuestro método de conversión es válido y aplicable a todos los modelos.
Finalmente de ha realizado una primera simulación del caso industrial en MOCA
RP, a partir de una modelización utilizando la síntesis de lenguajes y autómatas a
estados y la posterior traducción según nuestro método. Los resultados obtenidos son
coherentes con los datos proporcionados por el industrial.
En el momento actual, los trabajos continúan en el seno del laboratorio LAI del
INSA. El proyecto no está totalmente acabado debido a algunos problemas que
subsisten en la conversión a red de Petri. Se eliminan las tasas de producción de ciertos
estados en algún punto del proceso de traducción, provocando la consiguiente pérdida
de información. Probablemente será necesario modificar las macros de Visual Basic
para solucionar el problema.
Anexo 7. Programa de conversión del grafo de estados
Anexo 7. Programa de conversión del grafo de estados
Anexo 7. Programa de conversión del grafo de estados
165
Anexo 7. Programa de conversión del grafo de estados(UMDES è SYNET)
Private Type Type_EtatTransitionEtat etat1 As Integer transition As String etat2 As IntegerEnd Type
Dim caseSelectionne As VariantDim compteurEtat As LongDim compteurTransition As LongDim compteurCase As LongDim etatEnCours As LongDim collectionEtat As CollectionDim i As LongDim caseTabEncours As LongDim Tab_Etat_Transition() As Type_EtatTransitionEtatPrivate Sub CommandButton1_Click()compteurEtat = 0compteurCase = 0compteurTransition = 0Set collectionEtat = New CollectioncaseTabEncours = 1
For Each caseSelectionne In Selection
If TestEtat(caseSelectionne) = True And (compteurCase / 2 - Round(compteurCase /2)) = 0 Then If IsNumeric (caseSelectionne) Then collectionEtat.Add compteurEtat, Str(caseSelectionne) Else collectionEtat.Add compteurEtat, caseSelectionne End If compteurEtat = compteurEtat + 1 End If
If TestTransition(caseSelectionne) = True And (compteurCase / 2 -Round(compteurCase / 2)) = 0 Then compteurTransition = compteurTransition + 1 End If
compteurCase = compteurCase + 1Next
compteurCase = 0
ReDim Tab_Etat_Transition(1 To compteurTransition)
Anexo 7. Programa de conversión del grafo de estados
166
For Each caseSelectionne In Selection
If TestEtat(caseSelectionne) = True And (compteurCase / 2 - Round(compteurCase /2)) = 0 Then
If IsNumeric (caseSelectionne) Then etatEnCours = collectionEtat(Str(caseSelectionne)) Else etatEnCours = collectionEtat(caseSelectionne) End If i = 0 End If
If i > 1 And (i / 2 - Round(i / 2)) = 0 Then Tab_Etat_Transition(caseTabEncours).etat1 = etatEnCours Tab_Etat_Transition(caseTabEncours).transition = caseSelectionne End If
If i > 1 And (i / 2 - Round(i / 2)) <> 0 And TestEtat(caseSelectionne) = True Then If IsNumeric (caseSelectionne) Then Tab_Etat_Transition(caseTabEncours).etat2 =collectionEtat(Str(caseSelectionne)) Else Tab_Etat_Transition(caseTabEncours).etat2 = collectionEtat(caseSelectionne) End If caseTabEncours = caseTabEncours + 1 End If i = i + 1 compteurCase = compteurCase + 1NextSet collectionEtat = Nothing
Dim tempString As StringDim temppath As StringDim tempname As Stringtemppath = Sheets("Procede").Cells(9, 7)tempname = Sheets("Procede").Cells(6, 7)myfile = temppath + tempname
Open myfile For Append As #1tempString = "des(0," & Str(compteurTransition) & "," & Str(compteurEtat) & ")"Print #1, tempStringFor i = 1 To compteurTransition tempString = "(" & Str(Tab_Etat_Transition( i).etat1) & "," &Tab_Etat_Transition(i).transition & "," & Str(Tab_Etat_Transition( i).etat2) & ")" Print #1, tempStringNext iClose #1MsgBox "La conversion du fichier est terminée!!!"
Anexo 7. Programa de conversión del grafo de estados
167
End Sub
Function TestEtat(arg) As BooleanTestEtat = FalseDim tempString As StringIf arg <> "" Then tempString = Left(arg, 1) If IsNumeric (tempString) Then TestEtat = True End IfEnd IfEnd Function
Function TestTransition(arg) As BooleanTestTransition = FalseDim tempString As StringIf arg <> "" Then tempString = Left(arg, 1) If Not IsNumeric (tempString) Then TestTransition = True End IfEnd IfEnd Function
Anexo 8. Programa de conversión de la red de Petri
Anexo 8. Programa de conversión de la red de Petri
Anexo 8. Programa de conversión de la red de Petri
169
Anexo 8. Progra ma de conversión de la red de Petri (SYNETè MOCA RP)
Private Type Type_TabTransition transition As String nbreCaractereTrans As IntegerEnd Type
Private Type Type_TabPlaceAmont placeAmont As StringEnd Type
Private Type Type_TabPlaceAval placeAval As StringEnd Type
Private Type Type_TabPlaceMarquage place As Long marquage As IntegerEnd Type
Dim caseSelectionne As VariantDim compteurTransition As LongDim compteurPlaceAmontEncours As LongDim compteurPlaceAvalEncours As LongDim Tab_Transition() As Type_TabTransitionDim caseTabTransEncours As LongDim i As LongDim k As LongDim Tab_PlaceAmont () As Type_TabPlaceAmontDim Tab_PlaceAval() As Type_TabPlaceAvalDim caseTabPlAmontEncours As LongDim caseTabPlAvalEncours As LongDim Tab_PlaceMarquage() As Type_TabPlaceMarquageDim compteurPlace As LongDim caseTabPlMarqEncours As LongDim test As Boolean
Sub SynetMoca()Dim tempsString As StringcompteurTransition = 0compteurPlace = 0caseTabTransEncours = 1caseTabPlMarqEncours = 1
For Each caseSelectionne In Selection
If TestTransition(caseSelectionne) = True Then
Anexo 8. Programa de conversión de la red de Petri
170
compteurTransition = compteurTransition + 1 End If
If TestPlace(caseSelectionne) = True Then compteurPlace = compteurPlace + 1 End If
Next
ReDim Tab_Transition(1 To compteurTransition)ReDim Tab_PlaceMarquage(1 To compteurPlace)
For Each caseSelectionne In Selection
If TestTransition(caseSelectionne) = True Then Dim nbreCaractere As Integer nbreCaractere = Len(caseSelectionne) - 11 Tab_Transition(caseTabTransEncours).nbreCaractereTrans = nbreCaractere Tab_Transition(caseTabTransEncours).transition = Right(caseSelectionne,nbreCaractere) caseTabTransEncours = caseTabTransEncours + 1 End If
If TestPlace(caseSelectionne) = True Then
If Not IsNumeric (Mid(caseSelectionne, 10, 1)) Then Tab_PlaceMarquage(caseTabPlMarqEncours).place = Mid(caseSelectionne, 9,1) + 1 Else If Not IsNumeric (Mid(caseSelectionne, 11, 1)) Then Tab_PlaceMarquage(caseTabPlMarqEncours).place = Mid(caseSelectionne,9, 2) + 1 Else Tab_PlaceMarquage(caseTabPlMarqEncours).place = Mid(caseSelectionne,9, 3) + 1 End If End If
test = False
For k = 1 To Len(caseSelectionne) If Mid(caseSelectionne, k, 1) = ":" Then Tab_PlaceMarquage(caseTabPlMarqEncours).marquage =Right(caseSelectionne, 1) test = True Else If test = False Then Tab_PlaceMarquage(caseTabPlMarqEncours).marquage = 0 End If End If
Anexo 8. Programa de conversión de la red de Petri
171
Next k
caseTabPlMarqEncours = caseTabPlMarqEncours + 1 End If
Next
Dim tempString As Stringmyfile = "D:\DOCS\PFE\Notre PFE\" + "synetmoca.txt"
Open myfile For Append As #1Print #1, "*TITRE"Print #1, "*MON TITRE"Print #1, "*LANGUE"Print #1, " F"Print #1, "*IMPRESSION DU RESEAU"Print #1, " N"Print #1, "*SORTIE TABLEUR"Print #1, " N"Print #1, "*DONNEES CENSUREES"Print #1, " N"Print #1, "*DUREE POUR LE CALCUL (T)"Print #1, " 100"Print #1, "*NOMBRE D'HISTOIRES (NHI)"Print #1, " 1000"Print #1, "*NOMBRE DE SORTIES (NSIT)"Print #1, " 1"Print #1, "*1ER NOMBRE AU HASARD (SEED)"Print #1, " 12345681.D0"Print #1, "*DUREE MAX STEP GO (Secondes)"Print #1, " 30"Print #1, "*DESCRIPTION DU RESEAU"Print #1, "$ PAGE N° 1"
For i = 1 To compteurTransition
tempsString = " TR: " & CStr(Tab_Transition(i).transition) & " AM " compteurPlaceAmontEncours = 0 compteurPlaceAvalEncours = 0 nbreCaratere = Tab_Transition(i).nbreCaractereTrans For Each caseSelectionne In Selection
If TestArcAmont(caseSelectionne) = True And Tab_Transition( i).transition =Right(caseSelectionne, nbreCaratere) Then compteurPlaceAmontEncours = compteurPlaceAmontEncours + 1 End If
If TestArcAval(caseSelectionne) = True And Tab_Transition( i).transition =Right(caseSelectionne, nbreCaratere) Then compteurPlaceAvalEncours = compteurPlaceAvalEncours + 1
Anexo 8. Programa de conversión de la red de Petri
172
End If
Next
ReDim Tab_PlaceAmont (1 To compteurPlaceAmontEncours) ReDim Tab_PlaceAval(1 To compteurPlaceAvalEncours) caseTabPlAvalEncours = 1 caseTabPlAmontEncours = 1 For Each caseSelectionne In Selection
If TestArcAmont(caseSelectionne) = True And Right(caseSelectionne,nbreCaratere) = Tab_Transition( i).transition Then If Not IsNumeric (Mid(caseSelectionne, 9, 1)) Then Tab_PlaceAmont(caseTabPlAmontEncours).placeAmont =Mid(caseSelectionne, 8, 1) + 1 Else If Not IsNumeric (Mid(caseSelectionne, 10, 1)) Then Tab_PlaceAmont(caseTabPlAmontEncours).placeAmont =Mid(caseSelectionne, 8, 2) + 1 Else Tab_PlaceAmont(caseTabPlAmontEncours).placeAmont =Mid(caseSelectionne, 8, 3) + 1 End If End If caseTabPlAmontEncours = caseTabPlAmontEncours + 1 End If
If TestArcAval(caseSelectionne) = True And Right(caseSelectionne, nbreCaratere)= Tab_Transition( i).transition Then If Not IsNumeric (Mid(caseSelectionne, 9, 1)) Then Tab_PlaceAval(caseTabPlAvalEncours).placeAval = Mid(caseSelectionne, 8,1) + 1 Else If Not IsNumeric (Mid(caseSelectionne, 10, 1)) Then Tab_PlaceAval(caseTabPlAvalEncours).placeAval = Mid(caseSelectionne,8, 2) + 1 Else Tab_PlaceAval(caseTabPlAvalEncours).placeAval = Mid(caseSelectionne,8, 3) + 1 End If End If caseTabPlAvalEncours = caseTabPlAvalEncours + 1 End If
Next For k = 1 To compteurPlaceAmontEncours tempsString = tempsString & (Tab_PlaceAmont(k).placeAmont) & " 1 " Next k tempsString = tempsString & "AV "
Anexo 8. Programa de conversión de la red de Petri
173
For k = 1 To compteurPlaceAvalEncours tempsString = tempsString & (Tab_PlaceAval(k).placeAval) & " 1 " Next k Print #1, tempsString If Left(Tab_Transition(i).transition, 1) = "p" Or Left(Tab_Transition( i).transition, 1)= "s" Then Print #1, "LOI EXP 1e-2 $" & i & "" Else If Left(Tab_Transition(i).transition, 1) = "r" Then Print #1, "LOI EXP 1 $" & i & "" Else Print #1, "LOI DRC 0 $" & i & "" End If End IfNext i
Print #1, "*TA"Print #1, "*MNEMONIQUES DES PLACES"
tempString = ""For k = 1 To compteurPlace tempString = tempString & (Tab_PlaceMarquage(k).place) & " PL" &(Tab_PlaceMarquage(k).place) & " "Next k
Print #1, tempString
Print #1, "*MNEMONIQUES DES MESSAGES"Print #1, "*MARQUAGE INITIAL DES PLACES"
tempString = ""For k = 1 To compteurPlace tempString = tempString & (Tab_PlaceMarquage(k).place) & " " &(Tab_PlaceMarquage(k).marquage) & " "Next k
Print #1, tempString
Print #1, "*ETAT INITIAL DES MESSAGES"Print #1, "*TYPE DES STATISTIQUES"Print #1, "1"Print #1, "*ETAT POUR LES STATISTIQUES"Print #1, "*CALCUL DE PRODUCTIVITE"Print #1, "***"
Close #1MsgBox "La conversion du fichier est terminée!!!"
End Sub
Anexo 8. Programa de conversión de la red de Petri
174
Function TestTransition(arg) As BooleanTestTransition = FalseDim tempString As StringtempString = Left(arg, 1) If tempString = "t" Then TestTransition = True End IfEnd FunctionFunction TestPlace(arg) As BooleanTestPlace = False If Left(arg, 1) = "p" Then TestPlace = True End IfEnd FunctionFunction TestArcAmont(arg) As BooleanTestArcAmont = FalseDim j As Long If Left(arg, 1) = "f" Then For j = 1 To Len(arg) If Mid(arg, j, 1) = ">" Then TestArcAmont = True End If Next j End IfEnd FunctionFunction TestArcAval(arg) As BooleanTestArcAval = FalseDim j As Long If Left(arg, 1) = "f" Then For j = 1 To Len(arg) If Mid(arg, j, 1) = "<" Then TestArcAval = True End If Next j End If End Function
Anexo 9. Fichero de salida de la primera macro Visual Basic
175
Anexo 9. Fichero de salida de la primera macro Visual Basic
Anexo 9. Fichero de salida de la primera macro Visual Basic
176
Anexo 9. Fichero de salida de la primera macro Visual Basic
des(0, 106, 38)( 0,d1, 1)( 1,p1, 2)( 1,s1, 0)( 1,d2, 3)( 2,r1, 0)( 3,p1, 4)( 3,s1, 5)( 3,p2, 6)( 3,s2, 1)( 3,d3, 7)( 4,r1, 5)( 4,p2, 8)( 4,s2, 2)( 5,d1, 3)( 5,p2, 9)( 5,s2, 0)( 6,p1, 10)( 6,s1, 9)( 6,r2, 1)( 7,p1, 11)( 7,s1, 13)( 7,p2, 14)( 7,s2, 15)( 7,p3, 12)( 7,s3, 3)( 8,r1, 9)( 9,d1, 6)( 9,r2, 0)( 10,r1, 9)( 11,r1, 13)( 11,p2, 17)( 11,s2, 18)( 11,p3, 16)( 11,s3, 4)( 12,p1, 19)( 12,s1, 20)( 12,p2, 21)( 12,s2, 22)( 12,r3, 3)( 13,d1, 7)( 13,p2, 23)( 13,s2, 24)( 13,p3, 20)( 13,s3, 5)( 14,p1, 25)( 14,s1, 23)
Anexo 9. Fichero de salida de la primera macro Visual Basic
177
( 14,r2, 15)( 14,p3, 26)( 14,s3, 6)( 15,p1, 18)( 15,s1, 24)( 15,d2, 7)( 15,p3, 22)( 15,s3, 1)( 16,r1, 20)( 16,p2, 27)( 16,s2, 28)( 17,r1, 23)( 17,p3, 29)( 17,s3, 8)( 18,d2, 11)( 18,r1, 24)( 18,p3, 28)( 18,s3, 2)( 19,r1, 20)( 19,p2, 30)( 19,s2, 31)( 20,d1, 12)( 20,p2, 32)( 20,s2, 33)( 20,r3, 5)( 21,p1, 34)( 21,s1, 32)( 21,r2, 22)( 22,p1, 31)( 22,s1, 33)( 22,d2, 12)( 22,r3, 1)( 23,d1, 14)( 23,r2, 24)( 23,p3, 35)( 23,s3, 9)( 24,d1, 15)( 24,d2, 13)( 24,p3, 33)( 24,s3, 0)( 25,r1, 23)( 25,p3, 36)( 25,s3, 10)( 26,p1, 37)( 26,s1, 35)( 26,r2, 22)( 27,r1, 32)( 28,r1, 33)( 29,r1, 35)( 30,r1, 32)
Anexo 9. Fichero de salida de la primera macro Visual Basic
178
( 31,r1, 33)( 32,d1, 21)( 32,r2, 33)( 33,d1, 22)( 33,r3, 0)( 34,r1, 32)( 35,d1, 26)( 35,r2, 33)( 36,r1, 35)( 37,r1, 35)
Anexo 10. Fichero de salida de SYNET
Anexo 10. Fichero de salida SYNET
Anexo 10. Fichero de salida de SYNET
180
Anexo 10. Fichero de salida SYNET, describiendo la red dePetri del caso serie
transition d1transition p1transition s1transition d2transition r1transition p2transition s2transition d3transition r2transition p3transition s3transition r3place x_0place x_1place x_2place x_3place x_4place x_5place x_6 := 1place x_7place x_8 := 1place x_9 := 1place x_10 := 1place x_11 := 1place x_12 := 1flow x_0 ---> r1flow x_1 ---> r2flow x_2 ---> p3flow x_2 ---> s3flow x_3 ---> r3flow x_4 ---> p1flow x_4 ---> s1flow x_4 ---> d2flow x_4 ---> p3flow x_4 ---> s3flow x_5 ---> p1flow x_5 ---> s1flow x_5 ---> d3flow x_6 ---> d1flow x_7 ---> p2flow x_7 ---> s2flow x_7 ---> d3flow x_8 ---> d2flow x_9 ---> d3flow x_10 ---> p1flow x_10 ---> r2flow x_11 ---> p1flow x_11 ---> r3flow x_12 ---> p2flow x_12 ---> r3flow x_0 <--- p1flow x_1 <--- p2flow x_2 <--- d3flow x_3 <--- p3flow x_4 <--- d1
Anexo 10. Fichero de salida de SYNET
181
flow x_4 <--- d2flow x_4 <--- d3flow x_5 <--- d1flow x_5 <--- d3flow x_6 <--- s1flow x_6 <--- r1flow x_7 <--- d2flow x_7 <--- d3flow x_8 <--- s2flow x_8 <--- r2flow x_9 <--- s3flow x_9 <--- r3flow x_10 <--- r1flow x_10 <--- r2flow x_11 <--- r1flow x_11 <--- r3flow x_12 <--- r2flow x_12 <--- r3
Anexo 11. Fichero de salida de la segunda macro Visual Basic
Anexo 11. Fichero de salida de la segunda macro Visual Basic
Anexo 11. Fichero de salida de la segunda macro Visual Basic
183
Anexo 11. Fichero de salida de la segunda macro Visual Basicdescribiendo el caso serie
*TITRE*MON TITRE*LANGUE F*IMPRESSION DU RESEAU N*SORTIE TABLEUR N*DONNEES CENSUREES N*DUREE POUR LE CALCUL (T) 100*NOMBRE D'HISTOIRES (NHI) 1000*NOMBRE DE SORTIES (NSIT) 1*1ER NOMBRE AU HASARD (SEED) 12345681.D0*DUREE MAX STEP GO (Secondes) 30*DESCRIPTION DU RESEAU$ PAGE N° 1 TR: da1 AM 15 1 AV 1 1 11 1 13 1 17 1 18 1 20 1 25 1 26 1 30 1LOI DRC 0 $1 TR: dc1 AM 11 1 19 1 21 1 24 1 40 1 42 1 AV 11 1 12 1 21 1 32 1 37 1 43 1LOI DRC 0 $2 TR: sa1 AM 1 1 11 1 13 1 17 1 18 1 20 1 25 1 26 1 30 1 AV 15 1LOI EXP 1e-2 $3 TR: pa1 AM 1 1 11 1 13 1 17 1 18 1 20 1 25 1 26 1 30 1 AV 2 1LOI EXP 1e-2 $4 TR: dc2 AM 12 1 17 1 21 1 22 1 23 1 29 1 31 1 32 1 39 1 43 1 AV 3 1 12 1 17 1 34 140 1 42 1LOI DRC 0 $5 TR: sc1 AM 12 1 18 1 32 1 37 1 43 1 AV 18 1 19 1 24 1 40 1 42 1LOI EXP 1e-2 $6 TR: pc1 AM 12 1 32 1 43 1 AV 4 1 16 1 24 1 34 1 36 1 40 1 42 1LOI EXP 1e-2 $7 TR: ra1 AM 2 1 AV 15 1LOI EXP 1 $8 TR: da2 AM 2 1 AV 5 1 11 1 13 1 17 1 18 1 20 1 25 1 26 1 30 1LOI DRC 0 $9 TR: sc2 AM 3 1 20 1 34 1 40 1 42 1 AV 20 1 21 1 22 1 23 1 29 1 31 1 32 1 39 1 43 1LOI EXP 1e-2 $10 TR: pc2 AM 3 1 40 1 42 1 AV 6 1 16 1 21 1 22 1 29 1 31 1 32 1 36 1 37 1 39 1 43 1
Anexo 11. Fichero de salida de la segunda macro Visual Basic
184
LOI EXP 1e-2 $11 TR: dd1 AM 13 1 16 1 24 1 27 1 29 1 31 1 AV 13 1 14 1 16 1 22 1 31 1 39 1LOI DRC 0 $12 TR: pa2 AM 5 1 11 1 13 1 17 1 18 1 20 1 25 1 26 1 28 1 30 1 35 1 38 1 41 1 AV 7 1LOI EXP 1e-2 $13 TR: sa2 AM 5 1 11 1 13 1 17 1 18 1 20 1 25 1 26 1 30 1 AV 2 1LOI EXP 1e-2 $14 TR: dd2 AM 14 1 21 1 22 1 25 1 31 1 32 1 33 1 36 1 39 1 40 1 42 1 43 1 AV 8 1 14 124 1 25 1 29 1 36 1LOI DRC 0 $15 TR: sd1 AM 14 1 22 1 26 1 39 1 AV 24 1 26 1 27 1 29 1LOI EXP 1e-2 $16 TR: pd1 AM 14 1 22 1 39 1 AV 9 1 24 1 29 1LOI EXP 1e-2 $17 TR: ra2 AM 7 1 AV 15 1 28 1 35 1 38 1 41 1LOI EXP 1 $18 TR: rc1 AM 4 1 16 1 22 1 24 1 28 1 34 1 36 1 37 1 AV 19 1 22 1 24 1 28 1LOI EXP 1 $19 TR: sd2 AM 8 1 24 1 29 1 30 1 AV 21 1 22 1 30 1 31 1 32 1 33 1 39 1 40 1 42 1 43 1LOI EXP 1e-2 $20 TR: pd2 AM 8 1 24 1 29 1 AV 10 1 21 1 22 1 31 1 32 1 39 1 40 1 42 1 43 1LOI EXP 1e-2 $21 TR: rc2 AM 6 1 16 1 29 1 34 1 35 1 36 1 37 1 39 1 AV 23 1 29 1 35 1 39 1LOI EXP 1 $22 TR: rd1 AM 9 1 32 1 34 1 38 1 40 1 AV 27 1 32 1 34 1 38 1 40 1LOI EXP 1 $23 TR: rd2 AM 10 1 37 1 41 1 42 1 43 1 AV 33 1 37 1 41 1 42 1 43 1LOI EXP 1 $24*TA*MNEMONIQUES DES PLACES1 PL1 2 PL2 3 PL3 4 PL4 5 PL5 6 PL6 7 PL7 8 PL8 9 PL9 10 PL10 11 PL11 12 PL1213 PL13 14 PL14 15 PL15 16 PL16 17 PL17 18 PL18 19 PL19 20 PL20 21 PL21 22PL22 23 PL23 24 PL24 25 PL25 26 PL26 27 PL27 28 PL28 29 PL29 30 PL30 31 PL3132 PL32 33 PL33 34 PL34 35 PL35 36 PL36 37 PL37 38 PL38 39 PL39 40 PL40 41PL41 42 PL42 403 PL403*MNEMONIQUES DES MESSAGES*MARQUAGE INITIAL DES PLACES1 0 2 0 3 0 4 0 5 0 6 0 7 0 8 0 9 0 10 0 11 0 12 0 13 0 14 0 15 1 16 0 17 0 18 0 19 1 20 021 1 22 1 23 1 24 1 25 0 26 0 27 1 28 1 29 1 30 0 31 1 32 1 33 1 34 0 35 1 36 0 37 0 381 39 1 40 1 41 1 42 1 403 1*ETAT INITIAL DES MESSAGES*TYPE DES STATISTIQUES1*ETAT POUR LES STATISTIQUES*CALCUL DE PRODUCTIVITE***
Anexo 12. Fichero de resultados después de la simulación en MOCA RP
185
Anexo 12. Fichero de resultados tras simulación en MOCA RP
Anexo 12. Fichero de resultados después de la simulación en MOCA RP
186
Anexo 12. Fichero de resultados después de la simulación enMOCA RP del caso serie
NOM DU RESEAUX exemple_serie
HISTOIRE 100
GERME DU GENERATEUR DE NOMBRES ALEATOIRES 12345681.00
VALEUR COURANTE DU GERME 1188327334.00
NOMBRE D'HISTOIRES 100
DUREE MAXIMALE DE CALCUL 60 secondes
DUREE D'UNE HISTOIRE 8760.00
NOMBRE DE SORTIES 1
LONGUEUR DES BOUCLES 1000
TPS MOYEN CUMULE DE SEJOUR POUR CHAQUE ETAT ON
NB MOY PRESENCE EN FIN D HISTOIRE OFF
NOMBRE MOYEN DE JETONS EN FIN D'HISTOIRE OFF
NB MOY D OCCURENCE PENDANT HISTOIRE OFF
PREMIERE OCCURENCE DES ETATS OFF
NOMBRE MOYEN DE TIRS DE CHAQUE TRANSITION
N NOM FREQUENCEECART-TYPE CONF. 90% - E.T.
1 d3 1.72710E+002 1.07170E+001 1.75759E+000
2 d2 1.74500E+002 1.31014E+001 2.14863E+000
3 d1 1.73370E+002 1.38043E+001 2.26391E+000
4 s3 8.62800E+001 9.37984E+000 1.53829E+000
Anexo 12. Fichero de resultados después de la simulación en MOCA RP
187
5 s2 8.50600E+001 8.99025E+000 1.47440E+000
6 s1 8.59600E+001 1.04755E+001 1.71798E+000
7 p3 8.54400E+001 7.08722E+000 1.16230E+000
8 p2 8.84600E+001 1.03528E+001 1.69786E+000
9 p1 8.64300E+001 8.45458E+000 1.38655E+000
10 r3 8.54300E+001 7.08570E+000 1.16206E+000
11 r2 8.84400E+001 1.03527E+001 1.69784E+000
12 r1 8.64100E+001 8.45917E+000 1.38730E+000
13 prod_0% 2.55180E+002 1.54425E+001 2.53258E+000
14 prod_100% 2.56130E+002 1.54381E+001 2.53186E+000
15 TR15 2.56130E+002 1.54381E+001 2.53186E+000
16 TR16 2.55180E+002 1.54425E+001 2.53258E+000
TEMPS MOYEN DE SEJOUR DANS UNE PLACEMARQUAGE MOYEN POUR CHAQUE PLACE NOMBRE
MOYEN DE JETONS EN FIN D'HISTOIRE
N NOM TPS MOYEN ECART-TYPE CONF. 90% - E.T. % DUTEMPS TOTAL MARQUAGE MOYEN ECART-TYPE CONF. 90% -E.T. MARQUAGE MOYEN ECART-TYPE CONF. 90% - E.T.
1 PL1 9.04135E+001 1.26016E+001 2.06665E+000 1.031.03212E-002 1.43853E-003 2.35920E-004 2.00000E-002 1.40705E-0012.30757E-002
2 PL2 8.66876E+003 1.29378E+001 2.12180E+000 98.969.89584E-001 1.47692E-003 2.42214E-004 9.90000E-001 1.00000E-0011.64000E-002
3 PL3 8.96204E+001 1.27449E+001 2.09016E+000 1.021.02306E-002 1.45489E-003 2.38603E-004 1.00000E-002 1.00000E-0011.64000E-002
4 PL4 8.75775E+003 2.15511E+000 3.53437E-001 99.971.97970E+000 2.13920E-003 3.50829E-004 1.97000E+0001.71447E-001 2.81172E-002
Anexo 12. Fichero de resultados después de la simulación en MOCA RP
188
5 PL5 8.67338E+003 1.26131E+001 2.06855E+000 99.019.90111E-001 1.43985E-003 2.36136E-004 9.80000E-001 1.40705E-0012.30757E-002
6 PL6 0.00000E+000 0.00000E+000 0.00000E+000 0.000.00000E+000 0.00000E+000 0.00000E+000 0.00000E+0000.00000E+000 0.00000E+000
7 PL7 8.66959E+003 1.26016E+001 2.06665E+000 98.979.89679E-001 1.43853E-003 2.35920E-004 9.80000E-001 1.40705E-0012.30757E-002
8 PL8 0.00000E+000 0.00000E+000 0.00000E+000 0.000.00000E+000 0.00000E+000 0.00000E+000 0.00000E+0000.00000E+000 0.00000E+000
9 PL9 1.62380E+000 1.67806E+000 2.75202E-001 0.021.85365E-004 1.91559E-004 3.14157E-005 0.00000E+000 0.00000E+0000.00000E+000
10 nb_mach_OK 8.75995E+003 2.06649E-001 3.38904E-002 100.002.96937E+000 2.74268E-003 4.49800E-004 2.95000E+0002.19043E-001 3.59230E-002
11 nb_mach_NOK 2.61987E+002 2.20908E+001 3.62289E+000 2.99 3.06258E-002 2.74268E-003 4.49800E-004 5.00000E-002 2.19043E-0013.59230E-002
12 PL12 8.66959E+003 1.26016E+001 2.06665E+000 98.979.89679E-001 1.43853E-003 2.35920E-004 9.80000E-001 1.40705E-0012.30757E-002
13 PL10 8.67338E+003 1.26131E+001 2.06855E+000 99.019.90111E-001 1.43985E-003 2.36136E-004 9.80000E-001 1.40705E-0012.30757E-002
14 PL0 8.66242E+001 1.26131E+001 2.06855E+000 0.999.88861E-003 1.43985E-003 2.36136E-004 2.00000E-002 1.40705E-0012.30757E-002
15 PL11 8.67338E+003 1.26131E+001 2.06855E+000 99.019.90111E-001 1.43985E-003 2.36136E-004 9.80000E-001 1.40705E-0012.30757E-002
20 prod_0% 2.61987E+002 2.20908E+001 3.62289E+0002.99 2.99072E-002 2.52178E-003 4.13571E-004 5.00000E-002 2.19043E-001
3.59230E-002
21 prod_100% 8.49801E+003 2.20908E+001 3.62289E+00097.01 9.70093E-001 2.52178E-003 4.13571E-004 9.50000E-001 2.19043E-001
Anexo 12. Fichero de resultados después de la simulación en MOCA RP
189
3.59230E-002
TEMPS DE CALCUL 1s
MALLOC FREE DIFF
1539 1538 1