Diseño de código PLC para control supervisorio local bajo un enfoque holárquico
Autor: Cataño Berrío,  Mauricio Esteban
Asesor: Zapata Madrigal, Germán Darío (Thesis advisor)
Fecha: 2007
Programa: Bogotá - Medicina -Fisioterapia
Facultad: Facultad de Medicina

Resumen: En el modelamiento de los procesos industriales, en la ejecución de sus tareas y en la asignación de ellas es necesario contar con ciertas arquitecturas de diseño, que permitan asegurar la flexibilidad y la agilidad en la transferencia de información de ciertos niveles de manufactura, operacionales, a otros más inteligentes, administradores. Desde esta perspectiva, se hace más confiable contar con sistemas de manufactura holónicos, que brinden la posibilidad de que las unidades de trabajo, holones, cooperen con las tareas programadas por el administrador y restringir la autonomía a ciertos niveles que la hagan conocida al proceso como tal. Es así, como el conjunto de eventos y acciones que se desarrollan a partir de las interacciones de las unidades operacionales de la planta, permiten modelar todo a partir de la discretización de eventos y llevarlo a las redes de Petri; sin olvidar, claro está, que la optimización del sistema exige que la síntesis del proceso y su modelación a eventos discretos, permita que la planta guíe el proceso a partir de condiciones que garanticen la alcanzabilidad de estados deseados para el tráfico de la información y el producto. Todo lo anterior, lleva a centrar como meta específica el desarrollo de un supervisor y de su metodología de diseño, que permita llevar los cálculos algebraicos y el modelamiento en redes de Petri a la implementación en controladores lógicos programables (PLCs) y hacer que las condiciones adicionales que hacen que el sistema funcione más eficientemente, permita cumplir con los objetivos de flexibilidad y agilidad. / Abstract: In the modelling of the industrial processes, in the execution of their tasks and in the assignment of them it becomes necessary to have certain design architectures, that allow to assure the flexibility and the agility in the transfer of information from certain manufacture levels, operationals, to other more intelligents, manager. Seen from this perspective, it becomes more reliable to have Holonic Systems Manufacturing, that offer the possibility that the work units, holons, allow to cooperate with the tasks programmed by the manager and to restrict the autonomy at certain levels them not to make it unknown to the process like such. It is this way, as the group of events and actions that are developed from the interactions of the operational units of the plant, they allow to model everything from the discrete of events and to take it to the nets of Petri; without forgetting, clearing it is, that the optimization of the system demands that the synthesis of the process and its modelling to discreet events, allow that the plant guides the process from conditions them to guarantee the achievable of states wanted for the traffic of the information and the product. All the previous mentioned, takes to center like specific goal the development of a Supervisor and of its design methodology, that allows to take the algebraic calculations and the modelling in nets of Petri to the implementation in Programmable logical controllers (PLCs) and to make that the additional conditions that make that the system works more efficiently, allow to fulfill the objectives of flexibility and agility.

DISEÑO DE CÓDIGO PLC PARA CONTROL SUPERVISORIO LOCAL
BAJO UN ENFOQUE HOLÁRQUICO
MAURICIO ESTEBAN CATAÑO BERRÍO
UNIVERSIDAD NACIONAL DE COLOMBIA
SEDE MEDELLÍN
FACULTAD DE MINAS
ESCUELA DE INGENIERÍA ELÉCTRICA Y MECÁNICA
INGENIERÍA ELÉCTRICA
2007DISEÑO DE CÓDIGO PLC PARA CONTROL SUPERVISORIO LOCAL
BAJO UN ENFOQUE HOLÁRQUICO
MAURICIO ESTEBAN CATAÑO BERRÍO
Trabajo dirigido de grado para optar al título de
Ingeniero Electricista
DIRECTOR
GERMÁN ZAPATA MADRIGAL
Profesor asociado
Universidad Nacional de Colombia – Sede Medellín
UNIVERSIDAD NACIONAL DE COLOMBIA
SEDE MEDELLÍN
FACULTAD DE MINAS
ESCUELA DE INGENIERÍA ELÉCTRICA Y MECÁNICA
INGENIERÍA ELÉCTRICA
2007DEDICATORIA
A mis Padres, mi Hermana y mi Novia.
Quienes de una u otra manera me brindaron todo su apoyo y comprensión para alcanzar
mis metas como persona y como futuro profesional.AGRADECIMIENTOS
Al asesor e ingeniero Rubén Darío Vásquez Salazar, por su orientación y
acompañamiento en el desarrollo de este Trabajo Dirigido de Grado.
Al profesor Germán Zapata por la confianza y la posibilidad de adelantar trabajos
de grado en el área de Automatización Industrial.Mauricio Esteban Cataño Berrío CONTENIDO
CONTENIDO
INTRODUCCIÓN .............................................................................................................. 9
1. ARQUITECTURA DE SISTEMAS DE MANUFACTURA .................................. 11
1.1 JERÁRQUICO ........................................................................................................................ 12
1.2 HETERÁRQUICO ................................................................................................................. 13
1.3 HOLÁRQUICO ..................................................................................................................... 14
2. SISTEMAS DE MANUFACTURA HOLÓNICOS ............................................ 15
2.1 GENERALIDADES ............................................................................................................... 15
2.2 TIPOS DE HOLONES ........................................................................................................... 16
2.2.1 Holón Orden (OH) ........................................................................................................... 17
2.2.2 Holón Misión (MH) ......................................................................................................... 17
2.2.3 Holón Recurso (RH) ........................................................................................................ 17
3. SISTEMAS A EVENTOS DISCRETOS ............................................................... 18
3.1 TEORÍA DE CONTROL SUPERVISORIO ......................................................................... 19
3.1.1 Metodología de Diseño ..................................................................................................... 20
3.1.2 Redes de Petri (Petri Nets‐ PN) ....................................................................................... 20
3.1.3 Supervisor del Proceso ..................................................................................................... 23
3.2 EJEMPLO DE APLICACIÓN .............................................................................................. 25
3.2.1 Descripción y Análisis del Proceso .................................................................................. 25
3.2.2 Representación en Redes de Petri (PN) ............................................................................ 28
3.2.3 Supervisor del Proceso ..................................................................................................... 32
4. DISEÑO DE CÓDIGO PLC ................................................................................... 36
4.1 ESTÁNDAR IEC 61131 ......................................................................................................... 36
4.1.1 Elementos Comunes ......................................................................................................... 37
4.1.2 Los lenguajes de Programación ........................................................................................ 40
4.2 IMPLEMENTACIÓN DEL PROCESO EN SIMATIC S7‐300 .......................................... 42
4.2.1 Características Operativas del PLC S7‐300 ..................................................................... 42
4.2.2 Generación de Código PLC .............................................................................................. 43
4.3 SIMULACIÓN DEL PROCESO ........................................................................................... 45
5. CONCLUSIONES .................................................................................................... 46
BIBLIOGRAFÍA ............................................................................................................... 48Mauricio Esteban Cataño Berrío CONTENIDO
ANEXO A: CÓDIGO PLC BAJO CONTROL SUPERVISORIO LOCAL ............. 50
LISTA DE TABLAS
Tabla 1: Funciones en la manufactura Jerárquica ............................................................... 13
Tabla 2: Estados y Eventos asociados al vehículo 1 durante el proceso ............................... 29
Tabla 3: Estados y Eventos asociados al vehículo 2 durante el proceso ............................... 30
Tabla 4: Símbolos del Supervisor del proceso definido en el PLC S7‐300 ........................... 43
LISTA DE FIGURAS
Figura 1: Esquema Holónico ............................................................................................... 16
Figura 2: Estado inicial del Proceso .................................................................................... 26
Figura 3: Restricción de simultaneidad 1 ........................................................................... 27
Figura 4: Restricción de simultaneidad 2 ........................................................................... 27
Figura 5: Restricción de Obstaculización ........................................................................... 28
Figura 6: Modelado en Redes de Petri del Proceso ............................................................. 31
Figura 7: Modelo en Redes de Petri del Sistema Supervisado ............................................ 34
Figura 8: Gráfico secuencial funcional ............................................................................... 39
Figura 9: Lenguaje de Programación .................................................................................. 41
Figura 10: Lenguaje Ladder obtenido a partir de la Red de Petri sin Supervisor ............... 44
Figura 11: Lenguaje Ladder obtenido de la Red de Petri con Supervisor ........................... 44
Figura 12: Simulación del Supervisor ................................................................................ 45Mauricio Esteban Cataño Berrío RESUMEN
RESUMEN
En el modelamiento de los procesos industriales, en la ejecución de sus tareas y en
la asignación de ellas se hace necesario contar con ciertas arquitecturas de diseño,
que permitan asegurar la flexibilidad y la agilidad en la transferencia de
información de ciertos niveles de manufactura , operacionales, a otros más
inteligentes, administradores. Visto desde esta perspectiva, se hace más confiable
contar con sistemas de manufactura holónicos, que brinden la posibilidad de que
las unidades de trabajo, holones, permitan cooperar con las tareas programadas
por el administrador y restringir la autonomía a ciertos niveles que no la hagan
desconocida al proceso como tal. Es así, como el conjunto de eventos y acciones
que se desarrollan a partir de las interacciones de las unidades operacionales de la
planta, permiten modelar todo a partir de la discretización de eventos y llevarlo a
las redes de Petri; sin olvidar, claro está, que la optimización del sistema exige
que la síntesis del proceso y su modelación a eventos discretos, permita que la
planta guíe el proceso a partir de condiciones que garanticen la alcanzabilidad de
estados deseados para el tráfico de la información y el producto. Todo lo anterior,
lleva a centrar como meta específica el desarrollo de un Supervisor y de su
metodología de diseño, que permita llevar los cálculos algebraicos y el
modelamiento en redes de Petri a la implementación en controladores lógicos
Programables (PLCs) y hacer que las condiciones adicionales que hacen que el
sistema funcione más eficientemente, permita cumplir con los objetivos de
flexibilidad y agilidad.Mauricio Esteban Cataño Berrío ABSTRACT
ABSTRACT
In the modelling of the industrial processes, in the execution of their tasks and in
the assignment of them it becomes necessary to have certain design architectures,
that allow to assure the flexibility and the agility in the transfer of information
from certain manufacture levels, operationals, to other more intelligents, manager.
Seen from this perspective, it becomes more reliable to have Holonic Systems
Manufacturing, that offer the possibility that the work units, holons, allow to
cooperate with the tasks programmed by the manager and to restrict the autonomy
at certain levels them not to make it unknown to the process like such. It is this
way, as the group of events and actions that are developed from the interactions of
the operational units of the plant, they allow to model everything from the discrete
of events and to take it to the nets of Petri; without forgetting, clearing it is, that the
optimization of the system demands that the synthesis of the process and its
modelling to discreet events, allow that the plant guides the process from
conditions them to guarantee the achievable of states wanted for the traffic of the
information and the product. All the previous mentioned, takes to center like
specific goal the development of a Supervisor and of its design methodology, that
allows to take the algebraic calculations and the modelling in nets of Petri to the
implementation in Programmable logical controllers (PLCs) and to make that the
additional conditions that make that the system works more efficiently, allow to
fulfill the objectives of flexibility and agility.Mauricio Esteban Cataño Berrío INTRODUCCIÓN
INTRODUCCIÓN
El constante avance de las tecnologías de la automatización y en especial las que
involucran los procesos de manufactura, han hecho que el principal factor en
consideración para saber si un proceso es eficiente y ágil, sea la rápida actuación
del proceso frente a las situaciones en que el sistema presenta fallas, estados de
error o notificación de acciones realizadas.
Dentro de este contexto, se pretende con este trabajo, tener otras alternativas de
organización, o dicho en otras palabras, de esquematización de todo un proceso,
que permitan modelar, bajo el concepto de control supervisorio, aquellas
arquitecturas de sistemas de manufactura holárquicos.
Bajo este enfoque, se pretende entonces, hacer que el proceso y el control, sean
entes dinámicos e integrados; donde el flujo de la información no sea
unidireccional, y así, mediante la Teoría de Control Supervisorio poder modelar las
Redes de Petri enfocadas a los procesos de decisión discreta.
Todo proceso involucra la modelación a partir de una serie de eventos y de
acciones que ocurren durante determinado tiempo, y que hacen posible localizar
los estados donde es factible que el sistema presente bloqueos o situaciones donde
no se cumpla con la dinámica de marcaje. Es así, como las técnicas de cálculo y
modelación permiten despejar estados indeseables y hacer que la implementación
se constituya como el principal medio para probar que no sólo se basa en teoría la
metodología de diseño que se plantea a continuación, sino por el contrario,
garantiza su ejecución en dispositivos lógicos programables, PLC, donde es más
frecuente encontrar codificados en lenguaje ladder la dinámica discreta de todo un
proceso controlado.
Se espera por tanto, que el siguiente trabajo sirva como herramienta para reconocer
que la interacción del proceso y el control no son condiciones aisladas, sino por el
9Mauricio Esteban Cataño Berrío INTRODUCCIÓN
contrario, son un conjunto de estados y eventos que pueden ser integrados y
coordinados a partir de Supervisores que involucren las necesidades del
administrador en un proceso, sin que éste pierde de vista las tareas programadas
inicialmente y con las propiedades de cooperación y autonomía lograr que el
sistema de manufactura, sea un sistema holárquico controlado.
10Mauricio Esteban Cataño Berrío ARQUITECTURA DE SISTEMAS DE
MANUFACTURA
1. ARQUITECTURA DE SISTEMAS DE MANUFACTURA
Por procesos de Manufactura se entiende al conjunto de transformaciones que se le
hacen a la materia prima para darle un uso práctico a nivel industrial, comercial o
residencial1 . Todo este conjunto de transformaciones involucran actividades tales
como el torneado, el taladrado, el fresado, entre otros, que permiten que la
elaboración de piezas tenga mejores resultados cuando son realizados a partir de
procesos automatizados, los cuales cada vez se hacen más necesarios.
Como consecuencia a todo el auge industrializado y a la incursión de la
automatización en todos los procesos de producción, se han llevado a cabo
múltiples avances tecnológicos que han permitido que cada día los sistemas
industriales de las empresas sean eficientes y ágiles, donde la competitividad y la
optimización sean las metas para que toda organización busque mejorar las
técnicas de producción.
Visto de esta manera, se hace completamente necesario que un proceso quede
integrado con muchas funciones, torneado, taladrado, fresado; donde el flujo de
información y de producción, esté totalmente ligado a los niveles de inteligencia
que debe poseer todo esquema organizacional y de los cuales se ocupa la
arquitectura de sistemas de manufactura.
La arquitectura de sistemas de manufactura plantea alternativas para la
integración de varias unidades de producción, con niveles de autonomía y
cooperación restringidos, lo que lleva al desarrollo de esquemas de
automatización, denominados “esquemas de automatización integrada”. (Chacón,
2003).
1 http://www.wikipedia.org.es [Consulta en noviembre 1 de 2007, 9:46 am]
11Mauricio Esteban Cataño Berrío ARQUITECTURA DE SISTEMAS DE
MANUFACTURA
Sin embargo, el control de los sistemas de manufactura responden débilmente
frente a los cambios que surgen en dichos sistemas y hacen, por tanto, que esta
principal debilidad se constituya en el centro de atención para mejorar la
flexibilidad en las arquitecturas de control (Pinto, 2004). Lo que permite por tanto,
pensar más en un proceso controlado y supervisado sin que éste pierda las
condiciones iniciales para las que fue programado.
Dentro de estos esquemas de automatización, que se han identificado como
arquitecturas de sistemas de manufactura, se destacan tres tipos: La Jerárquica, La
Heterárquica y la Holárquica u Holónica.
1.1 JERÁRQUICO
Dentro de la arquitectura jerárquica, prevalecen los modelos simples y se
proporciona la facilidad de implantación, dado que el principio es sustentado por
la dependencia de los elementos a los niveles superiores, es decir, cada parte del
proceso está subordinado a las estructuras que mandan sobre el sistema. Sin
embargo, la simplicidad y la facilidad a la hora de implantar y modelar
respectivamente, se ven minimizadas por “la complejidad en la coordinación”
(Zapata et al, 2005), y la poca reacción que puedan tener los elementos que la
conforman; en otras palabras, carece de autonomía frente a las situaciones de
demanda de producción, estados falla y flujo del producto.
Bajo el modelo de control Jerárquico, el control del sistema precisa seguir la
secuencia de tareas establecidas por un administrador, haciendo la dinámica del
proceso totalmente dependiente (Valckenaers et al, 1994).
En la Tabla 1, se aprecia el control de una fábrica, orientada a partir de la
arquitectura jerárquica, donde la dinámica del proceso va desde las máquinas o
unidades operacionales hasta los niveles de control más especializados, encargados
de la planificación de operaciones en el proceso.
12Mauricio Esteban Cataño Berrío ARQUITECTURA DE SISTEMAS DE
MANUFACTURA
Tabla 1: Funciones en la manufactura Jerárquica
(Tomada y adaptada de [Boucher, 1996])
Orden de Producción
Adquisición
Nivel 4 Planta Adiciones a los planes de
producción
Facturación
Gestión de materiales
Nivel 3 Almacén Programación
Gestión de calidad
Inspección
Celdas de
Nivel 2 Material para
Trabajo
maquinaria
Secuencias
Herramientas para
máquinas
Robots
Nivel 1 Máquinas
Controladores Lógicos
Programables ‐ PLCs
1.2 HETERÁRQUICO
La Arquitectura Heterárquica, se desarrollada a partir de un conjunto de agentes,
cuyo objetivo es la ejecución de tareas de forma autónoma y hacer del proceso un
sistema más flexible y dinámico; donde la inteligencia se concentre en el más alto
nivel y los modelos sean más complejos (Chacón, 2003).
13Mauricio Esteban Cataño Berrío ARQUITECTURA DE SISTEMAS DE
MANUFACTURA
Si bien este esquema suministra agilidad y rapidez al proceso; es responsable de
restarle optimización al sistema, dado que cada agente se centra en su tarea
específica, no en la tarea global del proceso.
Bajo el modelo de control Heterárquico, el control del sistema ignora seguir la
secuencia de tareas establecidas por el administrador, exceptuando las órdenes de
producción. Cada estación posee un conjunto de agentes que administran
localmente las actividades de producción independientemente de la dinámica del
proceso, lo que las convierten en esquemas totalmente autónomos (Valckenaers et
al, 1994).
1.3 HOLÁRQUICO
La arquitectura holárquica, tema en el cual se centrará el desarrollo de este trabajo,
proporciona un punto intermedio entre las dos arquitecturas anteriormente
mencionada, y ofrece la fusión entre las mismas, proporcionando alternativas de
flexibilidad (autonomía‐cooperación), agilidad y optimización; y dentro de la cual
se destacan los Sistemas de Manufactura Holónicos, como una holarquía que
integrará todos los rangos en las actividades de manufactura. (Torrealba, 2005).
De lo anterior se desprende que los esquemas holárquicos dan una visión más
“dinámica y descentralizada”, a la vez que proporcionan los lineamientos bajo los
cuales se estructurará el sistema de manufactura holónico.
Además, bajo el modelo de control Holárquico, el sistema de control coopera con
las actividades programadas por el administrador y considera dicha planeación
como una recomendación, que en principio hay que seguir. (Valckenaers et al,
1994).
14Mauricio Esteban Cataño Berrío SISTEMAS DE MANUFACTURA
HOLÓNICOS
2. SISTEMAS DE MANUFACTURA HOLÓNICOS
2.1 GENERALIDADES
Las unidades de Producción (Chacón, 2003), que en principio son los denominados
holones, constituyen los organismos que hacen parte de todo un proceso, en otras
palabras, un hólon representa unidades o bloques funcionales autónomos y
cooperantes en los Sistemas de Manufactura, que están diseñados para la
transformación, transporte, almacenamiento y validación de la información de los
objetos físicos de un proceso (Valckenaers et al, 1994)
A partir del holón, que es una combinación del griego holos (todo) con el sufijo on
(partícula o parte) y de los aportes de Koestler (1989), se piensa en el holón como
un elemento que describe la naturaleza híbrida de las partes que conforman un
todo en los sistemas reales, es decir, los holones vienen siendo organismos
intermedios que reúnen las ventajas de la dependencia y la independencia en un
proceso, y las fusionan con el objetivo de mejorar la funcionalidad de un sistema.
Permitiendo así que se caractericen por sus formas estables que sobreviven a los
disturbios y formas intermedias provistas de su propia funcionalidad (Valckenaers
et al, 1994).
Los Sistemas de Manufactura Holónicos (HMS), están enfocado principalmente en
el control de procesos de manufactura, en el flujo de información y en la variedad
de productos a elaborar. Basándose, en una estructura de unidades operacionales,
denominadas holones (Torrealba, 2005).
Una vez conocida la definición del holón, es conveniente identificar las principales
funciones que desempeñaría dentro de una organización holónica, que en
resumidas cuentas vienen siendo la autonomía, como la capacidad de una entidad
15Mauricio Esteban Cataño Berrío SISTEMAS DE MANUFACTURA
HOLÓNICOS
para crear y controlar la ejecución de sus propios planes y estrategias, y la
cooperación como el conjunto de entidades que desarrollan planes mutuamente
aceptables y ejecutables. Con respecto a estos sistemas de holones que pueden
cooperar para cumplir con una meta u objetivo, se puede definir las holarquías,
que definen las reglas básicas para la cooperación entre holones y la autonomía. Lo
cual permite definir un Sistema de Manufactura Holónico, como la holarquía que
integra a todos los rangos en las actividades de manufactura, desde registrar una
orden, hasta el diseño, producción y mercadeo de una empresa de manufactura
(Torrealba, 2005).
2.2 TIPOS DE HOLONES
Como se mencionó anteriormente, todo proceso se compone de unidades
operativas cuya actividad depende del nivel desde donde sea enviada la tarea, ello
permite entonces, identificar una serie de holones que se caracterizan por tener
ventajas en determinados niveles de inteligencia y que facilitan el flujo de
información tal y como se observa en la figura 1.
Figura 1: Esq uema Holónico
Tomada de (Chacón, 2003)
16Mauricio Esteban Cataño Berrío SISTEMAS DE MANUFACTURA
HOLÓNICOS
2.2.1 Holón Orden (OH)
Representa una tarea en el sistema de manufactura. Es responsable de realizar el
trabajo asignado, correctamente y a tiempo. Maneja el producto físico que está
produciéndose, la información del estado producto y todo lo relacionado a la
información logística del proceso. Un Holón Orden, tal y como Torrealba lo
expresa, puede representar las órdenes del cliente, realizar órdenes para reparar y
mantener recursos, etc.
2.2.2 Holón Misión (MH)
Mantiene el proceso y el conocimiento del producto para asegurar la fabricación
correcta del producto con la calidad suficiente. El Holón misión contiene
información consistente y actualizada sobre el ciclo de vida del producto, los
requisitos del usuario, diseño, planes del proceso factura de materiales, garantía de
los procedimientos de calidad, etc. Así como también, el modelo del producto. En
síntesis, el holón misión actúa como un servidor de información para otros holones
en el HMS (Torrealba, 2005).
2.2.3 Holón Recurso (RH)
Contiene partes físicas, llamadas recursos de producción de los sistemas de
manufactura, y una parte del proceso de producción que controla el recurso. Este
holón ofrece la capacidad y funcionalidad a los holones circundantes. Tiene la
habilidad para localizar los recursos de producción, y el conocimiento para
organizarlos (Torrealba, 2005). Es una abstracción de medios de producción como
las máquinas, las herramientas y en especial, para el caso de estudio, para los
controladores lógicos programables (PLCs) encargados de controlar y ejecutar el
conjunto de eventos discretos del proceso.
17Mauricio Esteban Cataño Berrío SISTEMAS A EVENTOS DISCRETOS
3. SISTEMAS A EVENTOS DISCRETOS
Los Sistemas a Eventos Discretos (DES) son modelos de los sistemas dinámicos que
presentan una serie de cambios en los estados, dados por la ocurrencia de eventos
individuales. Los estados de un DES, representan un conjunto infinito de
posibilidades discretas; donde las transiciones de estado a estado son activadas de
acuerdo al orden en que ocurren los eventos (Moody y Antsaklis, 1998).
Los DES son una herramienta empleada para el modelamiento de sistemas como lo
son los sistemas de manufactura, donde la principal característica de los DES
radica en que cada instante de tiempo los sistemas a eventos discretos ocupan un
valor discreto en un determinado estado y representan cambios en los estados en
los que ocurren los eventos ( Fabian y Hellgren, 1998).
De lo anterior, se infiere que, el comportamiento de los DES está descrito por una
secuencia de eventos que ocurren y una secuencia de estados que son
influenciados por estos. Luego, los Sistemas a Eventos Discretos describen el
comportamiento no controlado de la planta y las especificaciones de un
comportamiento controlado.
Para la descripción formal del comportamiento de los sistemas a eventos discretos,
es necesario de la definición de un alfabeto E, que reúna todos los eventos, finitos,
de un proceso (Cassandras y Lafortune, 1999) y que estén contenidos en un
lenguaje L, tal que , de donde una secuencia o cadena de eventos es
denotada por s. De tal forma que el comportamiento dinámico de un sistema
puede ser descrito por un conjunto L (lenguaje) que permita propiedades como la
unión, la intersección y otros como la concatenación y cerramiento de prefijos, que
puedan ser modelados a partir de Redes de Petri, que permiten discretizar los
eventos y a su vez se convierte en el de mayor interés para el desarrollo de este
trabajo.
18Mauricio Esteban Cataño Berrío SISTEMAS A EVENTOS DISCRETOS
En cuanto al control, los DES cuentan con agentes llamados supervisores que se
encargan de observar los acontecimientos que ocurren en la planta. Cada vez que
un evento ocurre, la planta presenta una serie de estados no deseados, en los
cuales, el supervisor tratará de dirigir el proceso a estados deseados y fuera de lo
prohibido, de tal forma, que se prevengan estados no deseados; que será el objetivo
de inicio para el desarrollo de la Teoría del Control Supervisorio que a
continuación se abordará.
3.1 TEORÍA DE CONTROL SUPERVISORIO
Todo proceso industrial involucra la ejecución de diferentes tareas, que pueden ser
modeladas a partir de una serie de estados y eventos que identifiquen las etapas
del sistema a controlar. Un ejemplo de ello lo constituyen las plantas flexibles de
manufactura en las que se involucran diversas funciones de control discreto
(Mušič, 1998).
El Control Supervisorio pretende lograr la coordinación de los diferentes niveles
de jerarquía que implican las actividades de control y programación de
operaciones, así como la notificación de los estados de encendido, apagado y/o
emergencia del sistema. El proceso normalmente cuenta con diversas unidades de
operación y control, denominadas PLCs, en cuyo caso el Control Supervisorio
permitirá desarrollar modelos con propiedades deseables a partir de
especificaciones adicionales del Sistema.
La Teoría de Control Supervisorio (Supervisory Control Theory ‐ SCT) es un
enfoque general o técnica de cálculo que se le da a los sistemas de Control a
Eventos Discretos, con el que se pretende integrar los Sistemas a Eventos Discretos,
las especificaciones de control y la síntesis automática del proceso a controlar; y
así, generar los estados y eventos deseados (Fabian y Hellgren, 1998).
La SCT fue desarrollada gracias a los trabajos de Ramadge y Wonham (1989), en
los cuales el término Supervisor es empleado con la intención de controlar eventos
19Mauricio Esteban Cataño Berrío SISTEMAS A EVENTOS DISCRETOS
a partir de la especificación de funcionamiento del sistema, y que hacen del
Supervisor una técnica que garantiza que en el proceso no se presenten estados
específicos fuera de alcance.
3.1.1 Metodología de Diseño
El procedimiento sistemático a seguir en el desarrollo del Supervisor está
sustentado en el análisis y descripción del proceso, la identificación de los eventos
discretos, su posterior modelación en Redes de Petri y, finalmente, en el análisis
bajo SCT. En este punto, la planta o proceso a controlar es modelado bajo el
concepto de Redes de Petri de lugares Invariantes introducido por (Moody et al,
1994) y (Yamalidou et al, 1996).
Inicialmente se parte del objetivo al cual se quiere llegar con el control
supervisorio, es decir, las restricciones que permitirán que el proceso despeje esos
marcajes inalcanzables (Moody, 1998), μ , tal que
p
Lμ ≤b
p (3.1)
Donde,
μ : Es el vector de marcaje del proceso.
p
n ×n
L: Es una matriz de enteros de orden c , donde n es el número de restricciones
c
de los lugares a controlar y n el número de estados o lugares del proceso.
b: Es un vector de restricciones, es decir, aquellos estados o lugares donde el
marcaje es inalcanzable. Cuyo valor es de 1, si hay presencia de marca en el lugar o
cero en caso contrario.
3.1.2 Redes de Petri (Petri Nets‐ PN)
Una Red Petri, en adelante PN, es una herramienta gráfica y matemática que
permite modelar y analizar Sistemas a Eventos Discretos, distinguidos por ser
arreglos dinámicos que en el transcurso del tiempo presentan variaciones y que no
20Mauricio Esteban Cataño Berrío SISTEMAS A EVENTOS DISCRETOS
permanecen estáticos, que se encuentran presentes en los procesos de manufactura,
en los sistemas de comunicación y de control (Díaz et al, 2002).
Para desarrollar un proceso en PN es necesario la distinción de dos conceptos
importantes: Los estados y los eventos (Chaparro, 1993). Los eventos son las
acciones presentes en el sistema y que nos llevan a los estados, que se describen
como un conjunto de condiciones.
Para modelar un proceso en PN es necesario contar con una estructura de diseño
que establezca los lineamientos a seguir, entre los cuales se distinguen:
(cid:143) El conjunto de lugares.
(cid:143) El conjunto de transiciones.
(cid:143) Funciones de entrada.
(cid:143) Funciones de salida.
Las funciones permiten relacionar las transiciones con los lugares, dependiendo de
si son de entrada o de salida. Las funciones de entrada, hacen que un conjunto de
transiciones, t, estén asociadas a un conjunto de lugares, p, conocidos como los
i i
lugares de entrada de una transición. Y una función de salida hace que un conjunto
de transiciones esté asociado a un conjunto de lugares Tal que:
P = (P, T, I, O)
Donde,
P = {p , p ,…, p }, es un conjunto finito de lugares o estados, con n≥1.
1 2 n
T = {t , t ,…, t }, es un conjunto finito de transiciones o eventos, con m≥1.
1 2 m
P ∩ T = φ, siendo φ una función que asocia a toda transición t Є T con una
i
condición de disparo.
I: P→T es la función de entrada un mapeo de los lugares de entrada hacia el
conjunto de transiciones.
O: T→P es la función de salida, un mapeo desde las transiciones hacia el conjunto
de lugares de salida.
Para comprender la dinámica de una PN es necesario entender qué función
desempeñan los arcos y las marcas dentro de un proceso. En el caso de los arcos se
21Mauricio Esteban Cataño Berrío SISTEMAS A EVENTOS DISCRETOS
pretende unir los lugares con transiciones y viceversa, pero nunca nodos de un
mismo tipo. Las marcas de cada lugar, en cambio, demuestran la activación de los
diferentes estados en el sistema.
Se dice que una transición está sensibilizada cuando los diferentes lugares que
tienen arcos hacia ella disponen de por lo menos de una marca. Una vez
sensibilizada, esa transición es disparada cuando se produce el evento que se le
asocia, de ahí que se defina una transición como un evento que se sucede. Con la
evolución del marcado se logra entonces el disparo, que consiste en remover la
marca de los lugares de entrada y llevarlo a cada uno de los lugares de salida.
De lo anterior se tiene entonces que una PN puede representarse como una función
de R = (P,T, D , μ ), siendo P y T los lugares y transiciones del proceso, μ el
p po po
marcaje inicial de cada lugar en la planta y D la matriz de incidencia, que viene a
p
ser la representación matricial del sistema, en donde se tienen tantas filas como
lugares del proceso hallan y tantas columnas como transiciones existan y donde
cada componente de la matriz toma el valor de 1, ‐1 ó 0 (en el caso de las Redes de
Petri binarias, que corresponden al caso de estudio), dependiendo de la relación
que exista entre lugar y transición, es decir, 1 para el caso en que la transición se
dirige al lugar; ‐1 para la situación en que el lugar se dirige a la transición y 0 para
el caso en el que no exista ningún tipo de vínculo entre el lugar y la transición.
Vale la pena destacar que dentro del modelado de las Redes de Petri, existen
diversas propiedades de las redes, entre las que se destacan: la Red Pura, en la que
ninguna transición contiene a la vez un lugar que sea de entrada y salida; la Red
Binaria donde los marcajes de todos los lugares son menores o iguales que uno; la
Red Estable, si la red está limitada por marcajes finitos; y la Red Ordinaria, de la
que se desprenderá el análisis para el modelamiento del SCT y que restringe los
pesos de los arcos a cero o uno.
El sistema que se pretende controlar entonces con el Supervisor está modelado por
p lugares y t transiciones, que describen la dinámica del proceso o planta, y de los
cuales se distinguen los estados en los que las acciones son duraderas y los eventos
donde las acciones son fugaces (Chaparro, 1993) A partir de ello, se toma como
22Mauricio Esteban Cataño Berrío SISTEMAS A EVENTOS DISCRETOS
referencia las condiciones que se dan en el sistema, representados por los lugares o
estados (ya que el marcaje indicará si esta condición se cumple o no), y los eventos
con las transiciones (que necesitan de condiciones para poder ser disparadas).
3.1.3 Supervisor del Proceso
Continuando con el procedimiento sistemático para derivar el control supervisorio
y una vez obtenido el modelo en Redes de Petri del proceso, se procede a analizar
el sistema a partir del método de lugares invariantes (Moody 1996: Yamalidou,
1996) que a continuación es descrito paso por paso.
Inicialmente se parte de una serie de restricciones o condiciones adicionales (nc),
que se le impondrán al sistema, con el objeto de despejar estados no deseados del
proceso, como lo son los marcajes inalcanzables. En este punto, los marcajes en
cada uno de los lugares del proceso, serán denotados por μp.
Los estados del proceso, son representados por un vector de n x 1 componentes
enteros no negativos, donde cada componente del vector es igual al marcaje del
lugar correspondiente en la Red de Petri del proceso, como fue denotado
inicialmente. Las restricciones se expresan de acuerdo a la ecuación 3.1. Siendo L
una matriz de enteros de orden n x n y cuya desigualdad es leída con respecto a
c
cada elemento del lado izquierdo y derecho de la misma.
Luego, tal y como se muestra en (Yamalidou, 1996), si el marcaje inicial no viola las
restricciones dadas en la desigualdad anterior, entonces, puede hacerse cumplir
mediante un Supervisor, D , que es una matriz de incidencia controlada, que
c
combinará la matriz de incidencia D del proceso original con los controladores
p
(restricciones). En consecuencia,
D = ‐ L D
c p
Ahora, reconociendo que la meta principal del Supervisor es la de hacer cumplir
las restricciones del proceso, podría darse el caso en que la restricción a cumplir
23Mauricio Esteban Cataño Berrío SISTEMAS A EVENTOS DISCRETOS
sea del tipo μ +μ ≤ 1, dicho de otra forma, ambos lugares no pueden tener marca al
1 2
mismo tiempo; dado que el Supervisor no ejecutará dos acciones simultáneamente
iguales que involucren el uso compartido recursos idénticos para ambos casos.
Por tanto, la desigualdad de la restricción puede ser transformada en una igualdad
al introducir una variable de referencia, slack, denotada como μ , que hará las
c
veces del controlador o conjunto de restricciones impuestas en el proceso. Tal que
la restricción se convierte en μ +μ +μ = 1. En cuyo caso la variable slack representa
1 2 c
un nuevo lugar c, que espera los marcajes extras necesarios para hacer cumplir la
igualdad (Moody, 1998). Teniendo presente que las reglas de marcaje en la
evolución de las PN, aseguran que μ , es por definición no negativo.
c
Es importante aclarar, que en el caso donde las restricciones sean mayores a uno, el
número de slack, aumenta por cada restricción que se le adicione al proceso, es
decir, que el número de variables de referencia es proporcional a la cantidad de
restricciones que se tengan. En forma genérica,
Lμ ≤b
P
Lμ +μ = b
P C
Una vez se tiene calculados e identificados la matriz del Supervisor, la matriz de
incidencia y los marcajes con control y sin control del proceso, se puede decir de
manera generalizada, que la Técnica de Control Supervisorio, diseña un tipo de
matriz de incidencia tal que
⎡D ⎤
D = p
⎢ ⎥
D
⎣ ⎦
c
D∈Ζ(n+n C)×m μ∈Ζn C
Donde, . Y un tipo de vector de marcas representado por
⎡μ ⎤
μ= p
⎢ ⎥
μ
⎣ ⎦
C
Si bien, el Supervisor y el marcaje controlado constituyen la parte fundamental de
la SCT, es necesario para el análisis de todo proceso, disponer de condiciones
24Mauricio Esteban Cataño Berrío SISTEMAS A EVENTOS DISCRETOS
iniciales que den puntos de partida en el sistema. Lo cual lleva a definir al marcaje
inicial como:
⎡μ ⎤
μ =⎢ P 0 ⎥
0 μ
⎣ C ⎦
0
Donde,
μ : Corresponde al marcaje inicial del proceso a controlar.
po
μ : Corresponde al marcaje inicial del proceso controlado, es decir, al marcaje con
co
el que iniciará el Supervisor una vez hallado y que se calcula como:
μ =b−Lμ
C P
0 0
3.2 EJEMPLO DE APLICACIÓN
Luego de haber detallado los pasos y los formalismos necesarios para calcular el
Supervisor, resulta pertinente, desarrollar un ejemplo ilustrativo, que ponga en
práctica la Teoría de Control Supervisorio. Razón por la cual, un análisis detallado
puede ser el que se presenta en la coordinación de vehículos automatizados que a
continuación se pretende estudiar.
3.2.1 Descripción y Análisis del Proceso
Considérese un proceso de manufactura flexible, en el que se tienen dos estaciones
de trabajo, “A” y “B”, en las que se desempeñan actividades de maquinado de
piezas y ensamblaje, respectivamente. Dentro del proceso se cuenta con la
presencia de dos vehículos automatizados, carro 1 y carro 2, ubicados sobre un
mismo riel; cuya función será abastecer las estaciones de trabajo, según como sean
coordinados los vehículos.
La dinámica del proceso puede ser explicada e ilustrada de la siguiente manera:
25Mauricio Esteban Cataño Berrío SISTEMAS A EVENTOS DISCRETOS
1. Inicialmente se tendrán los dos vehículos en sus respectivos puestos de salida
(parqueaderos) Figura 2 (De izquierda a derecha, estación de trabajo A y estación
de trabajo B), donde claramente se observa cual es la condición inicial en la cual se
encuentra el proceso al momento de inicializar.
Figura 2: Estado inicial del Proceso
2. El vehículo se dirigirá a la estación de trabajo donde sea solicitado,
independientemente que sea el carro 1 o el carro 2.
3. El movimiento de los vehículos será de manera lineal.
26Mauricio Esteban Cataño Berrío SISTEMAS A EVENTOS DISCRETOS
Figura 3: Restricción de simultaneidad 1
Choque ocurrido por la ocurrencia de los dos vehículos a la misma estación de
trabajo A.
Figura 4: Restricción de simultaneidad 2
Choque ocurrido por la ocurrencia de los dos vehículos a la misma estación de trabajo B
4. La ejecución de las acciones por parte de los vehículos se llevará a cabo con la
restricción de que en una misma estación de trabajo no pueden estar los dos
vehículos al mismo tiempo, como se aprecia en la Figura 3 y la Figura 4. Además,
no podrán ser ocupados los parqueaderos de vehículos contrarios, es decir, el
vehículo 1 no invadirá el parqueadero del vehículo 2 y viceversa; y el máximo
estado al que podrán llegar será el de impedir la salida de uno de los vehículo, con
27Mauricio Esteban Cataño Berrío SISTEMAS A EVENTOS DISCRETOS
la garantía que el Supervisor a calcular supervisará la nueva dinámica del proceso
(Ver Figura 5).
Figura 5: Restricción de Obstaculización
Obstaculización del vehículo 1 por parte del vehículo 2. Téngase en cuenta que
igual sucede de forma contraria.
3.2.2 Representación en Redes de Petri (PN)
El problema puede ser analizado a partir de los estados y eventos del proceso, tal y
como se aprecian en las Tablas 1 y 2; en ellas se definen cuatro estados posibles en
los que se puede encontrar el vehículo automatizado y seis eventos necesarios para
que se pueda desplazar; téngase en cuenta que cada vehículo se comporta de
manera independiente, lo cual puede ser tratado en dos problemas por separado,
tanto para el carro 1 como para el carro 2.
28Mauricio Esteban Cataño Berrío SISTEMAS A EVENTOS DISCRETOS
Tabla 2: Estados y Eventos asociados al vehículo 1 durante el proceso
CARRO 1
Estados (Lugares) Eventos (Transiciones)
Llamado a
Carro 1 en
P1 T1 Estación de
Parqueadero 1
Trabajo A
Llamado a
Estación de Trabajo
P2 T2 Estación de
A
Trabajo B
Paso del carro 1 al
Estación de Trabajo
P3 T3 parqueadero del
B
carro 2
Carro 1 de regreso
Carro 1 en
P4 T4 a Estación de
Parqueadero 2
Trabajo B
Carro 1 de regreso
T5 a Estación de
Trabajo A
Carro 1 de regreso
T6 a Parqueadero
carro 1
29Mauricio Esteban Cataño Berrío SISTEMAS A EVENTOS DISCRETOS
Tabla 3: Estados y Eventos asociados al vehículo 2 durante el proceso
CARRO 2
Estados (Lugares) Eventos (Transiciones)
Llamado a
Carro 2 en
P5 T7 Estación de
Parqueadero 2
Trabajo B
Llamado a
Estación de
P6 T8 Estación de
Trabajo B
Trabajo A
Paso del carro 2 al
Estación de
P7 T9 parqueadero del
Trabajo A
carro 1
Carro 2 de regreso
Carro 2 en
P8 T10 a Estación de
Parqueadero 1
Trabajo A
Carro 2 de regreso
T11 a Estación de
Trabajo B
Carro 2 de regreso
T12 a Parqueadero
carro 2
30Mauricio Esteban Cataño Berrío SISTEMAS A EVENTOS DISCRETOS
Una vez identificados los estados y eventos del proceso, se puede proceder al
modelado en Redes de Petri (Figura 6), cuyo objetivo será controlar la coordinación
de los vehículos automatizados, una vez conocida la Red de la Planta.
Figura 6: Modelado en Redes de Petri del Proceso
La matriz de incidencia que describe el proceso está dada por
31Mauricio Esteban Cataño Berrío SISTEMAS A EVENTOS DISCRETOS
⎡−1 0 0 0 0 1 0 0 0 0 0 0 ⎤
⎢ ⎥
1 −1 0 0 1 −1 0 0 0 0 0 0
⎢ ⎥
⎢ 0 1 −1 1 −1 0 0 0 0 0 0 0 ⎥
⎢ ⎥
0 0 1 −1 0 0 0 0 0 0 0 0
⎢ ⎥
D =
p ⎢ 0 0 0 0 0 0 −1 0 0 0 0 1 ⎥
⎢ ⎥
⎢ 0 0 0 0 0 0 1 −1 0 0 1 −1⎥
⎢ ⎥
0 0 0 0 0 0 0 1 −1 1 −1 0
⎢ ⎥
⎢⎣ 0 0 0 0 0 0 0 0 1 −1 0 0 ⎥⎦
Y el marcaje inicial por:
=[ 0]T
μ 1 0 0 0 1 0 0
p
0
El cual representa las condiciones iniciales del sistema, es decir, los puntos de
partida de los vehículos, que en este caso específico corresponden a lo
parqueaderos.
3.2.3 Supervisor del Proceso
El objetivo del Supervisor, tal y como se especificó al inicio, es asegurar que los
vehículos no se encuentren simultáneamente en la misma estación de trabajo, lo
cual se convierte en las siguientes cuatro restricciones, tal y como fueron definidas
en el numeral 4 de la descripción del proceso, que se encargarán de que el proceso
evite alcanzar aquellos estados no deseados, a partir de las variables de referencia
o slacks que se introducen.
μ +μ ≤1 μ +μ +μ =1
1 8 1 8 C 1
μ +μ ≤1 μ +μ +μ =1
2 7 (cid:214) 2 7 C 2
μ +μ ≤1 μ +μ +μ =1
3 6 3 6 C3
μ +μ ≤1 μ +μ +μ =1
4 5 4 5 C
4
Las cuatro variables slack corresponden a los cuatro lugares de control, en otras
palabras, constituyen los estados necesarios para que el proceso inicial pueda
cumplir con las restricciones.
32Mauricio Esteban Cataño Berrío SISTEMAS A EVENTOS DISCRETOS
[ ]
μ = μ μ μ μ
C C C C C
1 2 3 4
Siguiendo con la metodología que se introdujo en la Sección 3.2.3, del presente
capítulo, se tiene que
[ ]
μ = 1 1 1 1T
C
[ ]
b = 1 1 1 1T
Y
⎡1 0 0 0 0 0 0 1⎤
⎢ ⎥
0 1 0 0 0 0 1 0
L = ⎢ ⎥
⎢0 0 1 0 0 1 0 0⎥
⎢ ⎥
⎣0 0 0 1 1 0 0 0⎦
De ahí que el Supervisor del proceso esté dado por
⎡ 1 0 0 0 0 −1 0 0 −1 1 0 0 ⎤
⎢ ⎥
−1 1 0 0 −1 1 0 −1 1 −1 1 0
D = ⎢ ⎥
p ⎢ 0 −1 1 −1 1 0 −1 1 0 0 −1 1 ⎥
⎢ ⎥
⎣ 0 0 −1 1 0 0 1 0 0 0 0 −1⎦
El marcaje inicial para los lugares que corresponden a los slacks viene a ser
⎡1⎤ ⎡1 0 0 0 0 0 0 1⎤
⎢ ⎥ ⎢ ⎥
1 0 1 0 0 0 0 1 0
μ = b−Lμ = ⎢ ⎥−⎢ ⎥⋅[ 1 0 0 0 1 0 0 0]T
C 0 p 0 ⎢1⎥ ⎢0 0 1 0 0 1 0 0⎥
⎢ ⎥ ⎢ ⎥
⎣1⎦ ⎣0 0 0 1 1 0 0 0⎦
=[ 0]T
μ 0 1 1
C
0
33Mauricio Esteban Cataño Berrío SISTEMAS A EVENTOS DISCRETOS
El Supervisor se encargará de que los dos carros no se encuentren en el mismo
lugar; además garantizará que la coordinación de los vehículos sea bajo
parámetros permitidos y deseados. El diagrama de la planta acoplada con el
supervisor (Figura 7) se construye a partir de la matriz de incidencia del
Supervisor, D , el cual permite añadir los arcos punteados a los lugares y slack
c
correspondientes, de acuerdo a los criterios que fueron definidos con anterioridad
en el momento de construir una matriz de incidencia a partir de la Red del proceso.
Figura 7: Modelo en Redes de Petri del Sistema Supervisado
El esquema del Supervisor que se observa en la Figura 7, muestra la dinámica del
proceso de los vehículos automatizados, controlados y supervisados, de tal forma
que la habilitación de transiciones sea dada a partir de su debida sensibilización.
En el caso en que el carro 1 se dirija a la estación de trabajo B y el carro 2 a la
estación de trabajo A, la acción se puede entender de la siguiente manera:
34Mauricio Esteban Cataño Berrío SISTEMAS A EVENTOS DISCRETOS
1. Para el vehículo automatizado 1: P1 y slack 2, sensibilizan a T1 y por
tanto, su marcaje pasa a P2 y a slack 1.
2. Para el vehículo automatizado 2: P5 y slack 3, sensibilizan a T7 y por tanto
su marcaje pasa a P6 y a slack 4.
3. Para el vehículo automatizado 1: P2 y slack 3, deben sensibilizar a T2,
pero por la acción del control del Supervisor y la acción del carro 2 al
movilizarse a la estación B. Indican que el carro 1 debe esperar a que el carro
2 se dirija hacia la estación de trabajo A, situación que no es posible dado
que el carro 1 está en ella y el Supervisor sabe de su presencia allí, luego el
Supervisorio plantea como solución que: Uno de los dos vehículos debe
regresar a su estado inicial de partida, dado que tanto T6 como T12 están
sensibilizadas para permitir el regreso a la estación de salida.
Lo anterior muestra que el Supervisor es una herramienta importante, que permite
la dinámica del proceso, pero a nivel controlado y restringido, de acuerdo a ciertas
condiciones que se impongan o se añadan al proceso.
35Mauricio Esteban Cataño Berrío DISEÑO DE CÓDIGO PLC
4. DISEÑO DE CÓDIGO PLC
4.1 ESTÁNDAR IEC 61131
El estándar IEC 61131, es un recurso de programación estándar cuya finalidad es
brindar una colección completa de estándares diferentes a controladores
programables y sus periféricos asociados, de tal forma que no se cree vínculo de
dependencia entre los proveedores y compradores, al existir gran cantidad de
lenguajes de programación diseñados por un gran número de fabricantes
diferentes (IEC, 2003).
∗
El Estándar IEC 61131 , constituido como norma consta de cinco partes a saber:
(cid:142) Parte 1. Vista General: Que establece las definiciones e identifica las
principales características significativas a la selección y aplicación de los
controladores y sus periféricos asociados.
(cid:142) Parte 2. Hardware: Especifica los requisitos del equipo y pruebas
relacionadas para los PLCs y sus periféricos (salidas) asociados.
(cid:142) Parte 3. Lenguaje de Programación.: Define como un conjunto mínimo,
los electos básicos de programación. Reglas sintácticas y semánticas para
los lenguajes de programación usados más comúnmente, incluyendo los
lenguajes gráficos de Diagrama de Escalera (LadderDiagram) y
diagrama de bloques de funciones (Function Block Diagram) y los
lenguajes textuales de lista de instrucciones y Texto estructurado. Así
como sus principales campos de aplicación, pruebas aplicables y los
medios por los cuales pueden expandir o adaptar esos conjuntos básicos
a sus propias implementaciones de controlador programable.
(cid:142) Parte 4. Guías de Usuario: Reportes técnicos que proporcionan un
panorama general y guías de aplicación de estándar para usuarios
finales de PLCs.
∗ Tomado y adaptado de PLCopen, Estandarización en la programación de control industrial.
36Mauricio Esteban Cataño Berrío DISEÑO DE CÓDIGO PLC
(cid:142) Parte 5. Comunicación: Define la comunicación de datos entre los PLCs y
otros sistemas electrónicos usando Manufacturing Message Specification
(MMS) acorde a la ISO/IEC 9506.
Para el ejemplo de aplicación desarrollado con anterioridad, es conveniente la
aplicación del estándar IEC 61131‐3, el cual abarca las especificaciones de la
sintaxis y semántica del lenguaje de programación incluyendo el modelo de
software y la estructura del lenguaje. Dicho estándar se encuentra dividido en dos
partes:
(cid:142) Los Elementos Comunes.
(cid:142) Los Lenguajes de Programación.
4.1.1 Elementos Comunes
Los constituyen:
(cid:142) Los Tipos de Datos.: Booleanas, Integer, Real, Byte, Word, Date,
Time_of_Day y string, permiten definir el tipo de dato de cualquier
parámetro usado en el proceso y aquellos datos definidos por el usuario,
conocidos como datos derivados. De tal forma que un canal de entrada
analógico pueda definirse como un tipo de dato.
(cid:142) Variables: Permiten identificar los objetos de datos cuyos contenidos en
el curso del proceso pueden cambiar. Una variable puede declararse
como un tipo de dato elemental definidos anteriormente o como uno de
los tipos de datos derivados; de tal modo que se crea un alto nivel de
independencia con el hardware, permitiendo a su vez la reusabilidad del
software.
La extensión de las variables está normalmente limitada a la unidad de
organización en la cual han sido declaradas como locales. Esto significa
que sus nombres pueden ser reutilizados en otras partes sin conflictos,
eliminando una frecuente fuente de errores. Si las variables deben tener
una extensión global, han de ser declaradas como globales utilizando la
palabra reservada VAR_GLOBAL.
Pueden ser asignados parámetros y valores iniciales que se restablecen
al inicio, para obtener la configuración inicial correcta.
37Mauricio Esteban Cataño Berrío DISEÑO DE CÓDIGO PLC
(cid:142) Configuración, recursos y tareas: Una configuración es específica
para cada tipo de sistema de control, incluyendo las características
del hardware: procesadores, direccionamiento de la memoria para los
canales de I/O y otras capacidades del sistema. Dentro de una
configuración se encuentran otro tipo de elementos denominados
recursos. Se entiende por recurso como un procesador capaz de
ejecutar programas IEC. Con un recurso, pueden definirse tareas, las
cuales controlan la ejecución de un conjunto de programas y/o
bloques de función. Cada una de ellos puede ser ejecutado
periódicamente o por una señal de disparo especificada, como el
cambio de estado de una variable.
Los programas están diseñados a partir de un conjunto de elementos
de software, escritos en algunos de los distintos lenguajes definidos
en la IEC 61131‐3.
Por lo general, un programa es una interacción de Funciones y Bloques
Funcionales, con la capacidad para intercambiar datos. Funciones y
Bloques funcionales son las partes básicas de construcción de un
programa, que contienen una declaración de datos y variables y un
conjunto de instrucciones.
Comparado todo esto con un PLC convencional, éste contiene un solo
recurso, ejecutando una tarea que controla un único programa de
manera cíclica.
(cid:142) Unidades de Organización de Programas: Las Unidades de Organización
de Programas, POU’s, reúnen el conjunto de programas, bloques
funcionales y funciones de los que contará la configuración del PLC.
Las Funciones
El estándar IEC 61131‐3 especifica funciones estándar y funciones
definidas por usuario. Entre las funciones estándar tenemos la suma
(ADD), el valor absoluto (ABS), raíz cuadrada (SQRT), seno (SIN) y
coseno (COS). Las funciones definidas por el usuario, una vez
implementadas pueden ser usadas indefinidamente en cualquier POU.
Las funciones no pueden contener ninguna información de estado
interno, es decir, que la invocación de una función con los mismos
argumentos (parámetros de entrada) debe suministrar siempre el mismo
valor (salida).
38Mauricio Esteban Cataño Berrío DISEÑO DE CÓDIGO PLC
Bloques Funcionales, FB’s
Los Bloques son los equivalentes de los circuitos integrados, IC’s, que
representan funciones de control especializadas. Los FB’s contienen tanto
datos como instrucciones, y además pueden guardar los valores de las
variables (que es una de las diferencias con las funciones).Los Bloques
pueden contener código estructurado reutilizable y pueden ser escritos
por el usuario en alguno de los lenguajes de la norma IEC, pero también
existen FB’s estándar (biestables, detección de flancos, contadores,
temporizadores, etc.). Los FB’s pueden ser llamados múltiples veces a
partir de las instancias, copias de bloque funcional, que llevará asociado
un identificador y una estructura de datos que contenga sus variables de
salida e internas.
Programas
Son “un conjunto lógico de todos los elementos y construcciones del lenguaje de
programación que son necesarios para el tratamiento de señal previsto que se
requiere para el control de una máquina o proceso mediante el sistema de
autómatas programable” (IEC 61131) .Un programa puede contener, a parte
de la declaración de los tipos de datos, variables y su código interno,
distintas instancias de funciones y bloques funcionales. En la Figura 8
se describe la estructura gráfica de una secuencia funcional, SFC), que
ilustra el comportamiento secuencial de un programa de control.
Figura 8: Gráfico secuencial funcional
Las SFC ayudan a estructurar la organización interna de un programa, y
a descomponer un problema en partes manejables, manteniendo
simultáneamente una visión global. Los elementos de la SFC
proporcionan un medio para subdividir una POU de un autómata
39Mauricio Esteban Cataño Berrío DISEÑO DE CÓDIGO PLC
programable en un conjunto de etapas y transiciones interconectadas por
medio de enlaces directos. Cada etapa lleva asociados un conjunto de
bloques de acciones, estados, y a cada transición va asociada una
condición de transición, evento, que cuando se cumple, causa la
desactivación de la etapa anterior a la transición y la activación de la
siguiente. Los bloques de acción permiten realizar el control del proceso.
Cada elemento puede ser programado en alguno de los lenguajes IEC,
incluyéndose el propio SFC. Dado que los elementos del SFC requieren
almacenar información, las únicas POU’s que se pueden estructurar
utilizando estos elementos son los bloques funcionales y los programas.
4.1.2 Los lenguajes de Programación
De acuerdo al Estándar, se definen cuatro lenguajes de programación
normalizados, lo que significa que su sintaxis y semántica ya han sido establecidas
y definidas, permitiendo su uso en diversos sistemas basados en esta norma.
Los lenguajes consisten en dos de Tipo literal y dos de tipo gráfico:
Literales:
(cid:142) Lista de Instrucciones (Instruction List – IL)
(cid:142) Texto Estructurado (Structured Text – St)
Gráficos
(cid:142) Diagrama de Contactos o Diagrama de Escalera (Ladder Diagram – LD)
(cid:142) Diagrama de Bloques Funcionales (Function Block Diagram – FBD)
Los cuatro lenguajes de programación describen la misma acción y su elección
depende de:
(cid:142) Los conocimientos del programador.
(cid:142) El problema a tratar.
(cid:142) El nivel de descripción del proceso.
(cid:142) La estructura del sistema de control.
40Mauricio Esteban Cataño Berrío DISEÑO DE CÓDIGO PLC
(cid:142) La coordinación con otras personas o departamentos
Figura 9: Lenguaje de Programación
Tomada de [Mateos, 2000])
El Diagrama de Contactos (LD), el cual será usado para la implementación del
ejemplo de aplicación, está basado en representación gráfica de la lógica de
relés. La Lista de Instrucciones (IL) es el modelo de lenguaje ensamblador
basado en un acumulador simple. El Diagrama de Bloques Funcionales (FBD)
es muy común en aplicaciones que implican flujo de información o datos entre
componentes de control. El lenguaje Texto Estructurado (ST) es un lenguaje de
alto nivel con orígenes en el Ada, Pascal y ‘C’; puede ser utilizado para
codificar expresiones complejas e instrucciones anidadas; este lenguaje dispone
de estructuras para bucles (REPEAT‐UNTIL; WHILE‐DO); ejecución
condicional (IF‐ THEN‐ELSE; CASE), funciones (SQRT, SIN, etc.).
A la hora de programar, la norma permite dos formas de desarrollar el
programa de control. En el caso de los vehículos automatizados, se empleará de
arriba a abajo (Top – down), en la que se especifica inicialmente la aplicación
completa y dividirla en partes, declarar las variables y todo lo demás. La otra
manera es de abajo a arriba (Bottom‐up).
41Mauricio Esteban Cataño Berrío DISEÑO DE CÓDIGO PLC
4.2 IMPLEMENTACIÓN DEL PROCESO EN SIMATIC S7‐300
El Simatic S7‐300 permite adelantar diversas tareas de automatización entre las
cuales se encuentran los sistemas de fabricación y procesos en general. En el caso
desarrollado a lo largo de este trabajo, es posible la implementación en un
controlador lógico programable, debido a que los sistemas de manufactura se
constituyen como una de las aplicaciones adelantadas a partir de los eventos
discretos como se observa en la vida real, dado que al modelar los DES mediante
las redes de Petri, es posible diseñar el código PLC, bajo un lenguaje Ladder; cuyo
punto intermedio entre el esquema y la programación es la traducción de las Redes
Petri a los diagramas de contactos que requiere el PLC.
4.2.1 Características Operativas del PLC S7‐300
El controlador Lógico Programable (PLC) S7‐300 trabaja por módulos, de
pendiendo de la magnitud de la aplicación, soportando hasta 32 módulos, 512
entradas o salidas digitales y 64 entradas o salidas análogas; mayor velocidad de
procesamiento por instrucción binaria (300ns) y comunicación MPI (Multi Point
Interface – MPI, Interfaz multipunto). Esta última constituye una gran ventaja ya
que permite la comunicación con diversos PLCs, interfaz hombre – máquina y
función de enrutamiento para llegar a otras partes de la red (Blanco y Montes,
2004).
Los componentes de la CPU 314 IFM son las siguientes:
(cid:142) Marcas: 2048.
(cid:142) Bloques OB: 8.
(cid:142) Bloques FB: 128.
(cid:142) Bloques FC: 128.
(cid:142) Contadores: 64.
(cid:142) Temporizadores: 128.
42Mauricio Esteban Cataño Berrío DISEÑO DE CÓDIGO PLC
4.2.2 Generación de Código PLC
Para convertir el Supervisor del proceso mostrado en figura 7, en una aplicación en
lenguaje ladder de un PLC, se definen un conjunto de símbolos que identifiquen
los estados y eventos del proceso, como se ilustran en la tabla 4, definidos en el
Software Simatic S7‐300.
Tabla 4: Símbolos del Supervisor del proceso definido en el PLC S7‐300
Posterior a ello, se continúa con el traspaso de la dinámica de la Red de Petri al
lenguaje Ladder (ver figuras 10 y 11), de tal forma que el barrido de información
que hace el PLC, logré tomar todos los datos necesarios para la ejecución posterior
en el simulador.
43Mauricio Esteban Cataño Berrío DISEÑO DE CÓDIGO PLC
Figura 10: Lenguaje Ladder obtenido a partir de la Red de Petri sin Supervisor∗
Figura 11: Lenguaje Ladder obtenido de la Red de Petri con Supervisor
∗ La parte codificada corresponde sólo a la parte inicial del proceso, el objetivo es simplemente
ilustrar la estructura en que se ha programado e implementado el proceso.
44Mauricio Esteban Cataño Berrío DISEÑO DE CÓDIGO PLC
4.3 SIMULACIÓN DEL PROCESO
Para la simulación del Proceso se recurrió al simulador que brinda el programa
Simatic S7‐300 versión 5.3, en el cual se puede disponer de los siguientes
visualizadores:
(cid:142) Ventana de Lugares y estados del proceso.
(cid:142) Ventana de transiciones y eventos del proceso.
Y a partir de los cuales se pudo seguir la dinámica del proceso y las posiciones
respectivas de los marcajes, tal y como se aprecia en la figura 12.
Figura 12: Simulación del Supervisor
45Mauricio Esteban Cataño Berrío CONCLUSIONES
5. CONCLUSIONES
(cid:143) La meta de toda industria es poder hacer que sus procesos garanticen
flexibilidad y agilidad; sin que ello implique la reducción de actividades
programadas. Es por ello que la eficiencia de una industria se mide tanto
por su producción como por la calidad de sus productos; lo que se traduce
en la coordinación de las tareas de cada sistema, que han de ser ejecutadas
de acuerdo a las exigencias del administrador y que llevan a definir la
arquitectura Holárquica, como una de las posibilidades más fiables en
cuanto a cooperación y autonomía para la ejecución de procesos; y que
brinda opciones de independencia y dependencia entre un proceso y otro,
en pos de la espera de reportes necesarios a la hora que se quiere y en el
instante deseado.
(cid:143) Al trabajar bajo un esquema holárquico es indispensable reconocer todo los
tipos de holones que componen el proceso e identificar, como es el objetivo
de este trabajo, los holones recurso, que se han de encargar de controlar los
procesos de cada máquina, a partir de controladores lógicos y que han de
contener las dinámicas discretas de la planta, modeladas a partir de las
Redes de Petri e implementadas con el lenguaje Ladder, en los dispositivos
lógicos programables (PLCs).
(cid:143) Al modelarse los procesos de una planta, muchas veces no se tienen en
cuenta todas los requerimientos necesarios para que el proceso funcione
siempre en las condiciones ideales, ello hace que al presentarse fallas,
atrasos en la producción y hasta veces accidentes, toda la industria flaquee y
tenga pérdidas cuantiosas. Es en este punto, donde se pregunta por el
control del proceso, abriéndose la posibilidad de que el proceso y el control
no estén adecuadamente relacionados, es por ello, que los agentes
supervisores adquieren gran importancia en la dinámica discreta del
sistema, y son pensados para solucionar las situaciones, sin que ello
requiera el cambio radical de toda la dinámica del proceso, sino más bien en
la adición de ciertos controladores (Supervisores) que se encargaran de
46Mauricio Esteban Cataño Berrío CONCLUSIONES
monitorear la planta y brindar las posibilidades de despejar los estados no
deseados.
(cid:143) La metodología de diseño desarrollada en este trabajo de grado, ha
permitido identificar las características básicas que componen todo un
proceso. Inicialmente, se identifica que tipo de arquitectura se está
manejando (holárquica); posteriormente se describe el proceso, su dinámica,
todo el conjunto de acciones y estados por los que la planta pasa (Sistemas a
Eventos Discretos); seguido de ello se pasa a la modelación en Redes de
Petri y al cálculo del supervisor (controlador) y finalmente se implementa
en el PLC, a partir de la traducción del modelo en PN general con
Supervisor incluido a lenguaje Ladder a través del Estándar IEC 61131‐3.
(cid:143) Entre las ventajas de manipular la Teoría de Control Supervisorio se
encuentran la facilidad de analizar el proceso y el control como entes
independientes, que luego serán fusionados en uno sólo, que involucrará las
dinámicas de un proceso Supervisado. Además, la posibilidad de trabajar el
cálculo del supervisor a partir del método de los lugares invariantes,
permite que a la hora de implementarlo, se facilite su programación al
contar con un supervisor modelado en Redes de Petri que no implique
complejidades en la programación del lenguaje Ladder.
(cid:143) A la hora de trabajar bajo la SCT se hace indispensable tener muy claras las
restricciones o condiciones sobre las cuales serán modificadas las
interacciones entre lugares y transiciones; permitiendo de esta manera,
garantizar que el supervisor en todo momento brindará la posibilidad de
llevar la dinámica actual del proceso a situaciones ya planeadas y deseadas,
o en caso extremo al bloqueo, al hacer cumplir en todo momento las
restricciones bajo las cuales fue diseñado; por lo que se puede decir que la
principal tarea del SCT es hacer que la planta goce de confiabilidad.
(cid:143) La implementación del proceso en el S7‐300, brinda la posibilidad de
simular el sistema bajo el modelo del Supervisor y observar el
comportamiento frente a las situaciones que se le exijan. Haciéndolo por
tanto, un excelente dispositivo para la implementación de procesos
industriales reales.
47Mauricio Esteban Cataño Berrío BIBLIOGRAFÍA
BIBLIOGRAFÍA
BLANCO Q., Pedro A., y MONTES T., Hugo H. Implementación de algoritmos de
control secuencial para PLC Simatic S7‐300 en la automatización de una
Subestación doble barra más seccionador de transferencia. Medellín, 2004, 51 p.
Trabajo de grado (Ingenieros Electricistas). Universidad Nacional de Colombia.
Facultad de Minas. Escuela de Ingeniería Eléctrica y Mecánica.
BOUCHER, Thomas O. Computer Automation in Manufacturing. London:
Chapman & Hall, 1996.
CASSANDRAS, Cristos G. y LAFORTUNE, Stéphane. Introduction to Discrete
Event Systems. United State of America. 1999. pp 61‐66.
CHACÓN E., BESEMBEL I., NARCISO, F., MONTILVA, J., y COLINA E. (2003).
An Integration Architecture for the Automation of Continuous production
Complex. 28 pags. Escuela de Ingeniería de Sistemas. Universidad de los Andes.
Mérida, Venezuela.
DÍAZ A., Alezander, ELEAZAR V., Jorge y HERNÁN V., Jorge. Redes de Petri.
http:// xue.unalmed.edu.co/~grupocpn/html/tdg/indextdg.htm.[enero 16:2007]
International Standard IEC 611131‐3. Second Edition 2003‐01.
MATEOS M., Felipe. Autómatas programables: Introducción al Estándar IEC
61131. Archivo Power Point. 2005.
MOODY, John O., y ANTSAKLIS, Panos J. Supervosory Control of Discrete Event
Systems Using Petri Nets. United States of America. 1998. 187 p. University of
Notre Dame in USA.
MUŠIČ, G. y MATKO D. (1998). Petri Net Based Supervisory Control of Flexible
Batch Plants. Symposium on Large Scale Systems, Río Patras, Greece, Vol. 2, pp.
989‐994.
48Mauricio Esteban Cataño Berrío BIBLIOGRAFÍA
PINTO LEITÃO., Paulo J. An Agile and Adaptative Holonic Arquitectura for
Manufacturing Control. Porto. 2004. 297 p. PhD Thesis. Facultad de ingeniería de
la Universidad de Porto.
SIEMENS S.A. Manual SIMATIC S7‐300. 2002
TORREALBA, A. (2005). Desarrollo de un sistema de supervisión de sistemas de
producción continua. Tesis Msc. Universidad de Los Andes, Venezuela.
VALCKENAERS, P., et al. IMS TEST CASE 5: HOLONIC MANUFACTURING
SYSTEMS. Leuven, Belgium: Katholieke University Leuven, Division PMA.
“IEC 61131‐3: Un recurso de programación estándar”. PLCopen Estandarización en
la programación de control industrial.
CIBERGRAFÍA
http://www.wikipedia.org.es [Consulta en noviembre 1 de 2007, 9:46 am]
49ANEXO
ANEXO A: CÓDIGO PLC BAJO
CONTROL SUPERVISORIO
LOCALSIMATIC VEHÍCULOS_AUTOMATIZADOS\SIMATIC 300(1)\CPU 314IFM\...\OB1 23/11/2007 8:26:13
- <offline>
OB1 - <offline>
""
Nombre: Familia:
Autor: Versión: 0.1
Versión del bloque: 2
Hora y fecha Código: 23/11/2007 8:00:52
Interface: 15/02/1996 16:51:12
Longitud (bloque / código / datos): 00350 00202 00022
Nombre Tipo de datos Dirección Comentario
TEMP 0.0
Bits 0-3 = 1 (Coming event), Bits 4-7 = 1 (Event class
OB1_EV_CLASS Byte 0.0
1)
OB1_SCAN_1 Byte 1.0 1 (Cold restart scan 1 of OB 1), 3 (Scan 2-n of OB 1)
OB1_PRIORITY Byte 2.0 Priority of OB Execution
OB1_OB_NUMBR Byte 3.0 1 (Organization block 1, OB1)
OB1_RESERVED_1 Byte 4.0 Reserved for system
OB1_RESERVED_2 Byte 5.0 Reserved for system
OB1_PREV_CYCLE Int 6.0 Cycle time of previous OB1 scan (milliseconds)
OB1_MIN_CYCLE Int 8.0 Minimum cycle time of OB1 (milliseconds)
OB1_MAX_CYCLE Int 10.0 Maximum cycle time of OB1 (milliseconds)
OB1_DATE_TIME Date_And_Time 12.0 Date and time OB1 started
Bloque: OB1 "Main Program Sweep (Cycle)"
Segm.: 1 ESTACIÓN DE TRABAJO A
PROCESO VEHÍCULO AUTOMATIZADO 1
II112244..00
LLAMADO
CARRO 1 A MM00..11
ESTACIÓN ESTACIÓN
MM00..00 DE DE
CARRO 1 TRABAJO A TRABAJO A
"P1" "T1" "P2"
S
MM00..00
CARRO 1
"P1"
R
Página 1 de 7SIMATIC VEHÍCULOS_AUTOMATIZADOS\SIMATIC 300(1)\CPU 314IFM\...\OB1 23/11/2007 8:26:13
- <offline>
Segm.: 2 ESTACIÓN DE TRABAJO B
II112244..11
LLAMADO
DE CARRO
MM00..11 1 A MM00..22
ESTACIÓN ESTACIÓN ESTACIÓN
DE DE DE
TRABAJO A TRABAJO B TRABAJO B
"P2" "T2" "P3"
S
MM00..11
ESTACIÓN
DE
TRABAJO A
"P2"
R
Segm.: 3 PARQUEADERO CARRO 2
II112244..22
MM00..22 PASO DE
ESTACIÓN CARRO 1 A MM00..33
DE PARQUEADER PARQUEADER
TRABAJO B O CARRO 2 O CARRO 2
"P3" "T3" "P4"
S
MM00..22
ESTACIÓN
DE
TRABAJO B
"P3"
R
Segm.: 4 ESTACIÓN DE TRABAJO B
II112244..33
REGRESO
DE CARRO
EN
PARQUEADER
O DE
CARRO 2 A MM00..22
MM00..33 ESTACIÓN ESTACIÓN
PARQUEADER DE DE
O CARRO 2 TRABAJO B TRABAJO B
"P4" "T4" "P3"
S
MM00..33
PARQUEADER
O CARRO 2
"P4"
R
Página 2 de 7SIMATIC VEHÍCULOS_AUTOMATIZADOS\SIMATIC 300(1)\CPU 314IFM\...\OB1 23/11/2007 8:26:13
- <offline>
Segm.: 5 ESTACIÓN DE TRABAJO A
II112244..44
CARRO 1/
MM00..22 DE MM00..11
ESTACIÓN ESTACIÓN ESTACIÓN
DE B A DE
TRABAJO B ESTACIÓN A TRABAJO A
"P3" "T5" "P2"
S
MM00..22
ESTACIÓN
DE
TRABAJO B
"P3"
R
Segm.: 6 CARRO 1
II112244..55
CARRO 1/
DE
MM00..11 ESTACIÓN
ESTACIÓN A A
DE PARQUEADER MM00..00
TRABAJO A O CARRO 1 CARRO 1
"P2" "T6" "P1"
S
MM00..11
ESTACIÓN
DE
TRABAJO A
"P2"
R
Segm.: 7 ESTACIÓN DE TRABAJO B
PROCESO VEHÍCULO AUTOMATIZADO 2
II112244..66
LLAMADO
CARRO 2 A MM00..55
ESTACIÓN ESTACIÓN
MM00..44 DE DE
CARRO 2 TRABAJO B TRABAJO B
"P5" "T7" "P6"
S
MM00..44
CARRO 2
"P5"
R
Página 3 de 7SIMATIC VEHÍCULOS_AUTOMATIZADOS\SIMATIC 300(1)\CPU 314IFM\...\OB1 23/11/2007 8:26:13
- <offline>
Segm.: 8 ESTACIÓN DE TRABAJO A
II112244..77
LLAMADO
DE CARRO
MM00..55 2 A MM00..66
ESTACIÓN ESTACIÓN ESTACIÓN
DE DE DE
TRABAJO B TRABAJO A TRABAJO A
"P6" "T8" "P7"
S
MM00..55
ESTACIÓN
DE
TRABAJO B
"P6"
R
Segm.: 9 PARQUEADERO CARRO 1
II112255..00
MM00..66 PASO DE
ESTACIÓN CARRO 2 A MM00..77
DE PARQUEADER PARQUEADER
TRABAJO A O CARRO 1 O CARRO 1
"P7" "T9" "P8"
S
MM00..66
ESTACIÓN
DE
TRABAJO A
"P7"
R
Segm.: 10 ESTACIÓN DE TRABAJO A
II112255..11
REGRESO
DE CARRO
EN
PARQUEADER
O DE
CARRO 1 A MM00..66
MM00..77 ESTACIÓN ESTACIÓN
PARQUEADER DE DE
O CARRO 1 TRABAJO A TRABAJO A
"P8" "T10" "P7"
S
MM00..77
PARQUEADER
O CARRO 1
"P8"
R
Página 4 de 7SIMATIC VEHÍCULOS_AUTOMATIZADOS\SIMATIC 300(1)\CPU 314IFM\...\OB1 23/11/2007 8:26:13
- <offline>
Segm.: 11 ESTACIÓN DE TRABAJO B
II112255..22
CARRO 2/
MM00..66 DE MM00..55
ESTACIÓN ESTACIÓN ESTACIÓN
DE A A DE
TRABAJO A ESTACIÓN B TRABAJO B
"P7" "T11" "P6"
S
MM00..66
ESTACIÓN
DE
TRABAJO A
"P7"
R
Segm.: 12 CARRO 2
II112255..33
CARRO 2/
DE
MM00..55 ESTACIÓN
ESTACIÓN B A
DE PARQUEDADE MM00..44
TRABAJO B RO CARRO 2 CARRO 2
"P6" "T12" "P5"
S
MM00..55
ESTACIÓN
DE
TRABAJO B
"P6"
R
Segm.: 13 SLACK 1
IMPLEMENTACIÓN DEL SUPERVISOR
II112244..55
CARRO 1/
DE
ESTACIÓN
MM11..00 A A MM11..11
LUGAR DE PARQUEADER LUGAR DE
CONTROL 1 O CARRO 1 CONTROL 2
"SLACK 1" "T6" "SLACK 2"
S
II112255..00
PASO DE
CARRO 2 A MM11..00
PARQUEADER LUGAR DE
O CARRO 1 CONTROL 1
"T9" "SLACK 1"
R
Página 5 de 7SIMATIC VEHÍCULOS_AUTOMATIZADOS\SIMATIC 300(1)\CPU 314IFM\...\OB1 23/11/2007 8:26:13
- <offline>
Segm.: 14 LUGAR DE CONTROL 1
SLACK 2
II112244..00
LLAMADO
CARRO 1 A
MM11..11 ESTACIÓN MM11..00
LUGAR DE DE LUGAR DE
CONTROL 2 TRABAJO A CONTROL 1
"SLACK 2" "T1" "SLACK 1"
S
II112255..11
REGRESO
DE CARRO
EN
PARQUEADER
O DE
CARRO 1 A
ESTACIÓN MM11..11
DE LUGAR DE
TRABAJO A CONTROL 2
"T10" "SLACK 2"
R
II112244..77
LLAMADO
DE CARRO
2 A
ESTACIÓN MM11..22
DE LUGAR DE
TRABAJO A CONTROL 3
"T8" "SLACK 3"
S
II112244..44
CARRO 1/
DE
ESTACIÓN MM11..11
B A LUGAR DE
ESTACIÓN A CONTROL 2
"T5" "SLACK 2"
R
Página 6 de 7SIMATIC VEHÍCULOS_AUTOMATIZADOS\SIMATIC 300(1)\CPU 314IFM\...\OB1 23/11/2007 8:26:13
- <offline>
Segm.: 15 LUGAR DE CONTROL 2
SLACK 3
II112244..11
LLAMADO
DE CARRO
1 A
MM11..22 ESTACIÓN MM11..11
LUGAR DE DE LUGAR DE
CONTROL 3 TRABAJO B CONTROL 2
"SLACK 3" "T2" "SLACK 2"
S
II112255..22
CARRO 2/
DE
ESTACIÓN MM11..22
A A LUGAR DE
ESTACIÓN B CONTROL 3
"T11" "SLACK 3"
R
II112244..33
REGRESO
DE CARRO
EN
PARQUEADER
O DE
CARRO 2 A
ESTACIÓN MM11..33
DE LUGAR DE
TRABAJO B CONTROL 4
"T4" "SLACK 4"
S
II112244..66
LLAMADO
CARRO 2 A
ESTACIÓN MM11..22
DE LUGAR DE
TRABAJO B CONTROL 3
"T7" "SLACK 3"
R
Segm.: 16 LUGAR DE CONTROL 3
SLACK 4
II112244..22
PASO DE
MM11..33 CARRO 1 A MM11..22
LUGAR DE PARQUEADER LUGAR DE
CONTROL 4 O CARRO 2 CONTROL 3
"SLACK 4" "T3" "SLACK 3"
S
II112255..33
CARRO 2/
DE
ESTACIÓN
B A MM11..33
PARQUEDADE LUGAR DE
RO CARRO 2 CONTROL 4
"T12" "SLACK 4"
R
Página 7 de 7