Modelling Control Systems en Español

Modelling Control Systems using IEC 61499
Robert Lewis
ndice general
1. Introduccin
1.1. Bloque de Funcin Estndar IEC 61499 . . . . . . . . . . . . . . . . . . . .
1.2. Desarrollo del Concepto de Bloque de Funciones tras la Norma IEC 61131-3
1.3. IEC 61499 - Una norma en Desarrollo . . . . . . . . . . . . . . . . . . . . .
1.4. Por qu Usar Bloques de Funcin? . . . . . . . . . . . . . . . . . . . . . .
1.5. Visiones de Diseo del Sistema . . . . . . . . . . . . . . . . . . . . . . . . .
1.6. El Futuro Ms All de la Norma IEC 61499 . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
5
9
12
15
17
19
22
2. Modelos y Conceptos IEC 61499

2.1. Modelo del Sistema . . . . . . . . . . . . . . . . . . . .
2.2. Modelo del Dispositivo . . . . . . . . . . . . . . . . . .
2.3. Modelo del Recurso . . . . . . . . . . . . . . . . . . . .
2.4. Modelo de Aplicacin . . . . . . . . . . . . . . . . . . .
2.5. Modelo de Bloque de Funcin . . . . . . . . . . . . . .
2.6. Tipos de Bloques de Funcin . . . . . . . . . . . . . . .
2.7. Modelo de Ejecucin de los Bloques de Funcin Bsicos
2.8. Modelo de Distribucin . . . . . . . . . . . . . . . . . .
2.9. Modelo de Gestin . . . . . . . . . . . . . . . . . . . .
2.10. Modelo de Estado Operacional . . . . . . . . . . . . . .
2.11. Interfaces Comunes Utilizando Adaptadores . . . . . . .
2.12. Sintaxis Textual para Entes IEC 61499 . . . . . . . . . .
2.13. Resumen . . . . . . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
23
24
24
25
27
28
30
30
33
34
36
37
39
41
3. Definicin de Tipo Bloque de Funciones y Subaplicacin

3.1. Tipos e Instancias . . . . . . . . . . . . . . . . . . .
3.2. Diferentes Formas de Bloque de Funcin . . . . . .
3.3. Definiendo Bloques de Funcin Bsicos . . . . . . .
3.4. Definiciones Para Bloques de Funcin Compuestos .
3.5. Definiendo Subaplicaciones . . . . . . . . . . . . . .
3.6. Resumen . . . . . . . . . . . . . . . . . . . . . . .
3.7. Notas . . . . . . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
43
43
43
44
54
60
66
66
.
.
.
.
.
.
67
67
68
73
78
80
82
.
.
.
.
.
.
.
.
.
.
.
.
.
.
4. Bloques de Funcin de Interfaz de Servicio

4.1. Descripcin General . . . . . . . . . . . . . . . . . . . . . . .
4.2. Definiciones de Tipo . . . . . . . . . . . . . . . . . . . . . . .
4.3. Comportamiento de Bloques de Funcin de Interfaz de Servicio
4.4. Bloques de Funcin de Interfaz de Servicio Asociado . . . . . .
4.5. Bloques de Funcin de Gestin . . . . . . . . . . . . . . . . . .
4.6. Resumen . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
NDICE GENERAL
4
5. Bloques de Funcin de Evento
5.1. Descripcin General . . . . . . . . . . . . . .
5.2. Tipos de Bloque de Funcin de Evento Estndar
5.3. Usando Bloques de Funcin de Evento . . . . .
5.4. Resumen . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
85
85
87
96
97
Captulo 1
Introduccin
En este captulo introductorio se revisan los antecedentes y las razones detrs de la elaboracin de la norma IEC 61499. Concretamente vamos a:
revisar el diseo de sistemas de control actuales y considerar el impacto de nuevas tecnologas
examinar las razones para iniciar el desarrollo de la norma IEC 61499
considerar las razones por las cuales los bloques de funcin son todava un concepto importante para los ingenieros de procesos y sistemas
mostrar cmo los bloques de funcin tienen algunas de las caractersticas del software
orientado a objetos
y por ltimo mostrar cmo los modelos IEC 61499 se pueden utilizar en el desarrollo de
sistemas de control de ciclo de vida.
Nota: Se ha hecho todo lo posible para que este libro describa con precisin los conceptos y
definiciones de la norma IEC 61499. Sin embargo, aunque las partes 1 y 2 de la norma IEC 61499
estn bastante avanzadas en su desarrollo, pueden estar sujetas a cambios de menor importancia,
que no se reflejan en este libro.
Dado que las empresas manufactureras luchan por competir en los mercados globales impredecibles y cambiantes de hoy, surge un aumento en la urgencia de mejorar la agilidad de los sistemas
de fabricacin. Para generar productos competitivos e innovadores, las empresas deben ser capaces de disear y crear rpidamente nuevas formas de produccin automatizada avanzada. Tales
niveles de automatizacin requieren la creacin de grandes sistemas que implican una amalgama
de control industrial, fabricacin y logstica empresarial. Una caracterstica clave de todos estos
nuevos sistemas ser una capacidad propia para manejar cambios con rapidez, es decir, sistemas
de fabricacin gil. Una planta de produccin deber ser capaz de cambiar rpidamente los tipos
de productos y poner nuevos procesos en marcha para permanecer activa.
En la actualidad existe un creciente inters por las nuevas tecnologas y arquitecturas para la creacin de la prxima generacin de sistemas distribuidos para la automatizacin industrial. Estos sern sistemas donde el software se organiza como conjuntos de componentes que
cooperan en lugar de la integracin de grandes unidades de medida de software [1]. REVISAR
XXXXXXXXXXX
Hasta ahora los sistemas de control industrial han cado en uno de los dos campos principales,
ya sea sobre la base de sistemas de control distribuido tradicionales (DCS) o en los controladores lgicos programables (PLCs). Los DCSs actuales, tpicamente en las plantas petroqumicas y
refineras, se estructuran en torno al uso de unos pocos procesadores centrales grandes, que proporcionan un control de supervisin y adquisicin de datos, comunicacin a travs de redes locales
5
CAPTULO 1. INTRODUCCIN
Figura 1.1: Sistema de control distribuido

con numerosos controladores, instrumentos, sensores y actuadores situados en planta. Un sistema
puede tener ambos instrumentos discretos y estaciones externas con grupos de instrumentos con
controladores locales. En un DCS, el principal control de supervisin proviene de uno o ms procesadores centrales. Instrumentos posicionados en planta tpicamente proporcionan un control de
lazo cerrado local, como para el control PID (Figura 1.1).
En cambio, para muchos procesos de control de maquinaria y de produccin, sobre todo en
las lneas de produccin de automviles, los sistemas han sido generalmente diseados utilizando
controladores lgicos programables (PLCs). En estos sistemas, la interfaz hombre-mquina (HMI)
normalmente se proporciona por una amplia variedad de diferentes tipos de paneles, luces e interruptores. Las HMIs avanzadas tambin pueden ser proporcionadas por paneles de color con
entradas de operador a travs de teclados especiales o de pantallas tctiles.
Un sistema de PLC grande tendr generalmente un nmero de PLCs que se comunican a travs
de una o ms redes propietarias de alta velocidad. Los PLCs tpicamente se conectan a un gran
nmero de seales de entrada y salida (E/S) para el manejo de sensores y actuadores. En algunos
casos, instrumentos discretos, como por ejemplo para el control de temperatura y presin, son
tambin conectados a los PLCs (Figura 1.2).
Con ambos enfoques de diseo, los sistemas han tendido a desarrollar por escrito grandes paquetes de software monolticos, que generalmente son difciles de reutilizar en nuevas aplicaciones
y son notablemente difciles de integrar con otros. Los datos y la funcionalidad de una aplicacin
no estn disponibles para otras aplicaciones, incluso si las aplicaciones estn escritas en el mismo
Figura 1.2: Sistema de control por PLC
lenguaje de programacin y se ejecutan en la misma mquina. El tiempo de desarrollo significativo

del sistema se refiere a la asignacin de seales entre los dispositivos y los controladores proporcionados para permitir que diferentes tipos de instrumentos y controladores puedan comunicarse.
REVISAR XXXXXXXXXXXXXXXX
Ambos tipos de sistemas, DCS y PLC, tienden a ser difciles de modificar y ampliar, y no proporcionan el alto grado de flexibilidad que se espera en sistemas para la automatizacin avanzada
y flexible.
Con la aparicin de las normas en materia de comunicaciones industriales tales como Fieldbus que permitirn a los diferentes tipos de instrumentos y dispositivos de control interoperar,
las diferencias entre DCS y los sistemas basados en PLC estn empezando a desaparecer. Los
instrumentos de DCS y PLCs estn empezando a ofrecer una funcionalidad similar. Aplicaciones
industriales tambin estn siendo implementadas en hardware PC con conceptos como el SoftPLC,
es decir, la lgica PLC ejecutndose en un PC normal. Como las plataformas de PC industrialmente endurecidas que ofrecen una alta fiabilidad se vuelven ms comunes, vamos a ver una tendencia
a usar ms controladores basados en PC. Hasta hace poco, los PLCs clsicos slo pudieron ser
programados utilizando lenguajes propietarios como los ofrecidos por el proveedor de PLC. Con
los usuarios ahora solicitando un enfoque ms abierto de software, una nueva raza de softcontroller
que es capaz de ser programado en una amplia gama de lenguajes est surgiendo.
Ahora podemos predecir el momento en que los sistemas para controlar procesos industriales,
de fabricacin y empresariales comienzan a fusionarse. Por ejemplo, considere el caso en el que
Figura 1.3: Funcionalidad distribuida avanzada

una empresa podra vincular a la perfeccin un sistema empresarial que se ejecuta en una oficina
central para los procesos de fabricacin y los sistemas de control industrial o incluso controladores
se ejecutan en cualquier planta en cualquier parte del mundo.
La Figura 1.3 representa parte de un sistema que tiene una funcionalidad distribuida avanzada.
En tales sistemas, cada dispositivo conectado a la red industrial puede proporcionar parte de la
funcionalidad de control. Los dispositivos inteligentes, tales como bombas, vlvulas y sensores
tendrn en su interior funcionalidad de control que puede estar vinculada por el software con los
dispositivos ms avanzados, tales como paneles de HMI, controladores de temperatura y softcontrollers para formar la funcionalidad total del sistema de control. Por ejemplo, un sensor de presin
puede estar conectado directamente por el software a un accionador de vlvula y a un grfico de
barras en la pantalla de un panel de operador. Un controlador deslizante en un panel HMI puede
ser directamente conectado mediante software al setpoint de un controlador PID que controla la
velocidad de una bomba.
Para alcanzar estos altos niveles de integracin y aun as permitir la creacin de sistemas flexibles que puedan ser re-diseados con cambios en las necesidades industriales y empresariales se
requerir un nuevo enfoque para el diseo de software una nueva tecnologa basada en la interaccin de los objetos distribuidos [2 ]. Hay varias tecnologas de software bastante avanzadas que
van a tener una influencia en esta rea. CORBA [2] (Common Object Request Broker Architecture) es un nuevo estndar para el diseo de objetos distribuidos que est siendo desarrollado por un
consorcio de los principales proveedores de software, el Object Management Group (OMG).
OPC [2] (OLE for Process Control), basado en OLE/COM de Microsoft (Object Linking and
Embedding, Common Object Model) es una tecnologa que permitir software en la forma de
componentes de software para interoperar con independencia del lugar en que se encuentren, ya
sea en un controlador industrial remoto en un alto horno o dentro del PC de la oficina del jefe
de produccin. La tecnologa de Internet con Java y la World Wide Web tambin estn siendo
considerados para el desarrollo de componentes de software para sistemas de fabricacin. Incluso
existen propuestas para dispositivos industriales, tales como vlvulas inteligentes, para ser capaces
de ejecutar directamente cdigo Java embebido.
La comunidad industrial ha sido consciente de que la interconexin de componentes de software en la forma de bloques de funcin, tendr importantes ventajas, especialmente para los usuarios
finales. Estas ventajas incluyen una mayor productividad de software a travs de la reutilizacin de
soluciones estndar, y una mayor flexibilidad de diseo al ser capaces conectarse y funcionar con
distintos softwares y dispositivos de diferentes fabricantes. Hasta el momento, las nuevas normas
1.1. BLOQUE DE FUNCIN ESTNDAR IEC 61499
permiten a todos "integracin tcnica" de componentes distribuidos, pero el siguiente obstculo

es la integracin semntica. Podemos ser capaces de enlazar e intercambiar de datos entre el
software en un controlador industrial a distancia y un algoritmo de control que se ejecuta en un
PC, pero la conexin tendr validez?
1.1.
Bloque de Funcin Estndar IEC 61499
La Comisin Electrotcnica Internacional (IEC) ha desarrollado un nuevo estndar IEC 61499

[3], que define cmo los bloques de funciones se pueden utilizar en sistemas de procesos industriales distribuidos, medicin y control. Esta norma puede ayudar a resolver parte del problema de
la integracin semntica.
En los sistemas industriales, los bloques de funcin son un concepto creado para definir componentes de software robustos, reutilizables. Un bloque de funcin puede proporcionar una solucin
de software a un pequeo problema, tal como el control de una vlvula, o el control de una unidad
principal de la planta, tal como una lnea de produccin completa. Los bloques de funcin permiten
algoritmos industriales que se encapsulan en una forma que puede ser fcilmente comprendida y
aplicada por personas que no son especialistas en software. Cada bloque tiene definido un conjunto
de parmetros de entrada, que son ledos por el algoritmo interno cuando se ejecuta. Los resultados
del algoritmo se escriben en las salidas del bloque. Aplicaciones completas se pueden construir a
partir de las redes de los bloques de funcin formados por la interconexin de entradas y salidas
de los bloques.
La norma IEC 61499, que se basa en los conceptos de bloques de funciones definidos en el
lenguaje PLC estndar IEC 61131-3, se est desarrollando en colaboracin con la labor de normalizacin de Fieldbus. Se prev que la parte de capa de aplicacin de la pila de comunicaciones
Fieldbus proporcionar la interfaz de software para permitir que los bloques de funcin remotos
puedan interoperar sobre Fieldbus. Sin embargo, la norma IEC 61499 est siendo desarrollada como un estndar genrico que tambin es aplicable en otros sectores industriales, de hecho siempre
que haya un requisito para componentes de software que se comportan como bloques de funcin,
tales como en la construccin de sistemas de gestin.
La norma IEC 61499 define un modelo general y la metodologa para la descripcin de bloques
de funcin en un formato que es independiente de la implementacin. La metodologa puede ser
usada por los diseadores de sistemas para la construccin de sistemas de control distribuido. Se
permite que un sistema se define en trminos de bloques de funcin conectados lgicamente que
se ejecutan en diferentes recursos de procesamiento.
La Figura 1.4 representa cmo la metodologa IEC 61499 podra ser utilizada como parte del
ciclo de vida del diseo del sistema. El diseo de un sistema de control comienza tpicamente con
el anlisis de los diagramas fsicos de la planta y la documentacin de los requisitos del sistema
de control. Este anlisis lleva a las reas de definicin de funcionalidades y su interaccin con la
planta. La fase final resulta ser la asignacin de funciones en los recursos fsicos tales como PLCs,
instrumentos y controladores.
El uso de la norma IEC 61499 puede ser mejor demostrado considerando las siguientes fases
en el diseo de un sistema de control distribuido:
1.
Fase de Diseo Funcional

Durante esta fase, los ingenieros de procesos analizan el diseo fsico de la planta, por ejemplo, utilizando diagramas de tuberas e instrumentacin (P&IDs), para crear los requisitos
funcionales de alto nivel. Estos pueden ser representados como una serie de bloques que
describen los principales componentes de software y sus interconexiones primarias. En esta
fase de diseo, no se considera la distribucin fsica de los componentes de software. En
10
Figura 1.4: Aplicacin de la norma IEC 61499

muchos casos, diagramas que muestran el diseo fsico de la planta o de la maquinaria, tales
como P&IDs, tambin muestran la ubicacin de los dispositivos activos, tales como vlvulas
y bombas; y puntos de instrumentacin, tales como la ubicacin de sensores de presin y
temperatura.
2.
Fase de Distribucin Funcional

En un sistema distribuido se requiere una fase de diseo para definir an ms la distribucin
de la funcionalidad de control a los recursos de procesamiento. La norma IEC 61499 proporciona modelos y conceptos para definir la distribucin de la funcionalidad en los bloques de
funciones interconectados. Ingenieros de sistemas completan el diseo detallado mediante
la asignacin de los requisitos de software siguiendo la norma IEC 61499 sobre los bloques
de funcin. Estos pueden ser distribuidos en diferentes recursos de procesamiento. En muchos casos, los bloques de funcin segn lo dispuesto en los dispositivos de campo sern
explotados; por ejemplo, dispositivos tales como vlvulas inteligentes pueden proporcionar
software empaquetado como un bloque de funcin.
Cada bloque de funcin, a su vez contar con su propio diseo de software en particular del
ciclo de vida. Algunos bloques tendrn que ser diseados especficamente para una aplicacin del sistema, en otros casos, los bloques existentes dentro de la instrumentacin y los
controladores pueden utilizarse.
Veremos ms adelante que el modelo de bloque de funcin definido por IEC 61499 proporciona una
sola vista de un diseo de sistemas distribuidos. Otros puntos de vista de diseo sern necesarios
para dar con todos los aspectos de un diseo de sistema. La norma IEC 61499 es el primer paso para
proporcionar metodologas de diseo para el desarrollo y modelado de aplicaciones distribuidas.
A medida que contine la tendencia de usar software basado en componentes, se prev que
los controladores y los instrumentos industriales o bien proporcionarn bloques de funcin como
1.1. BLOQUE DE FUNCIN ESTNDAR IEC 61499
11
Figura 1.5: Flujo de datos y eventos en bloques de funcin

parte del firmware del dispositivo o proporcionarn bibliotecas de bloques de funcin de la cual los
bloques podrn ser seleccionados y descargados. El diseo del sistema se convertir en el proceso
de seleccin, configuracin e interconexin del software, as como tambin gran parte del diseo
del hardware electrnico resulta ser ahora principalmente la seleccin y la interconexin de los
chips de circuitos integrados.
La norma IEC 61499 permite que los bloques de funcin que encapsulan funcionalidades y
algoritmos de software sean definidos en un formato estndar. Esto nos da la posibilidad de que las
herramientas y otras normas que tienen que ver con los bloques de funcin utilicen los mismos conceptos y metodologa. La norma IEC 61499 tambin define una serie de bloques de comunicacin,
como bloques servidor y cliente, que pueden utilizarse para formalizar el intercambio de datos
entre los bloques en diferentes recursos de procesamiento fsicos. Tambin hay bloques de interfaz
de servicio para proporcionar interfaces con la infraestructura de recursos de procesamiento.
La Figura 1.5 muestra tres bloques de funcin interconectados que representan la conexin
entre un transmisor de presin, un bloque de control PID y una bomba utilizando conceptos de la
norma IEC 61499. Observe que coexisten ambos flujos entre los bloques: de datos y de eventos.
Veremos ms adelante que la metodologa IEC 61499 permite que los datos y su evento asociado
estn estrechamente acoplados, es decir, para ser coherentes, o bien para los eventos y los datos
que se manejan de forma asncrona.
La Figura 1.6 muestra las tendencias de la tecnologa de control industrial durante los ltimos
cincuenta aos; desde 1950, ha habido un crecimiento constante en la funcionalidad proporcionada
por los sistemas de control, debido a los avances en el hardware y el software. Como los sistemas
de control se convirtieron en digitales, utilizando microprocesadores, ha habido un incremento
necesario de normas para reducir la diversidad innecesaria de software y disminuir los problemas
de integracin de sistemas cruzados.
La norma IEC 61131-3 se ha centrado en la estandarizacin de lenguajes PLC para procesadores individuales o configuraciones pequeas con algunos multi-procesadores estrechamente
acoplados. Con el paso a la funcionalidad distribuida a gran escala, aparece la necesidad necesidad
de nuevas normas como IEC 61499 para armonizar la forma en que la funcionalidad es definida y
distribuida. Tambin hay un requisito creciente de que todas las herramientas de construccin del
sistema se puedean integrar tambin. Por ejemplo, todas las herramientas de software utilizadas
para disear, configurar y administrar un sistema distribuido deben ejecutarse como una suite integrada. La herramienta de diseo que define un sistema debe ser integrada con las herramientas de
12
Figura 1.6: Desarrollo de la tecnologa de control industrial

programacin y configuracin de dispositivos, junto con herramientas para definir pantallas HMI y
configuracin de redes industriales. La intencin de la norma IEC 61499 es que defina los modelos
de sistemas que ayuden no slo con el diseo de la funcionalidad en los sistemas distribuidos, sino
tambin con la integracin de las herramientas del sistema a travs de la definicin de modelos de
datos e informacin.
1.2.
Desarrollo del Concepto de Bloque de Funciones tras la

Norma IEC 61131-3
Por qu no fue posible el uso de los conceptos de bloques de funciones definidos en la norma
IEC 61131-3 para sistemas distribuidos? Hay una serie de limitaciones en el concepto de bloque de
funcin original introducido por el lenguaje PLC de la norma IEC 61131-3. Con el lenguaje grfico
Diagrama de Bloques de Funcin (FBD) de la norma IEC 61131-3, los bloques de funcin se puede
enlazar con slo unir las conexiones de flujo de datos entre la entrada del bloque y variables de
salida, como se observa en la Figura 1.7a. Cada bloque de funcin proporciona un nico algoritmo
interno que es ejecutado cuando el bloque de funciones es invocado. El orden normal de ejecucin
es determinado por la dependencia del bloque de funcin con los otros bloques; normalmente se
ejecuta de izquierda a derecha porque los bloques a la derecha dependen de los valores de salida
de bloques de la izquierda.
Sin embargo, cuando se introduce una red de realimentacin (ver la Figura 1.7b), el orden de
ejecucin no puede ser determinado a partir del diagrama, ya que la ejecucin de ambos bloques
depende de un valor de salida del otro bloque. En una red compleja, es muy difcil para el sistema
de programacin determinar un orden vlido de ejecucin. Para superar este problema, muchos
sistemas de programacin IEC 61131-3 proporcionan mecanismos adicionales que definen el orden
de ejecucin de los bloques. Por ejemplo, el usuario puede ver una lista de los los bloques de
funcin y asignar manualmente una orden de ejecucin. Por desgracia, dichos mecanismos estn
fuera del mbito de aplicacin de la norma IEC 61131-3. Como consecuencia de ello, un aspecto
importante de una red de bloques de funcin, es decir, el mtodo para definir el orden de ejecucin
de los bloques, no es consistente o porttil a travs de diferentes sistemas de control.
1.2. DESARROLLO DEL CONCEPTO DE BLOQUE DE FUNCIONES TRAS LA NORMA IEC 61131-313
(a) Red de bloques de funcin
(b) Red con Realimentacin
Figura 1.7: Bloques de funcin usando la norma IEC 61131-3
Figura 1.8: Seales EN y ENO usando la norma IEC 61131-3

Hay una caracterstica en la norma IEC 61131-3 que proporciona un mecanismo crudo para
pasar flujo de ejecucin a travs de una cadena de bloques de funcin que vale la pena considerar;
ste es el uso de las seales EN y ENO de entrada y salida respectivamente (Figura 1.8). Las
seales EN y ENO fueron destinadas a bloques de funcin para pasar "flujo de energa" cuando
se utilizan en escalones de Diagramas de Escalera (Ladder). Sin embargo, ahora se reconoce que
el uso de las seales EN y ENO no proporciona el grado de flexibilidad necesario para redes
realimentadas complejas. En efecto, las seales EN y ENO pueden considerarse como un medio
para pasar eventos entre los bloques. La seal EN del bloque puede ser invocada porque sus datos
de entrada estn listos; la seal "ENO" est indicando que el bloque se ha ejecutado y los datos de
salida estn listo para el siguiente bloque. Veremos que esta idea de evento se ha extendido en la
norma IEC 61499. REVISAR XXXXXXXXXXXXXXXXXXX
El objetivo de la norma IEC 61131-3 [4] ha sido definir un modelo de software y lenguajes
para PLCs donde el software est funcionando tpicamente en un medio de procesamiento. Sin
embargo, el modelo de software IEC 61131-3, (Figura 1.9), considera configuraciones con mltiples recursos. La norma proporciona dos mecanismos diferentes para pasar seales de datos y de
14
Figura 1.9: Modelo de software IEC 61131-3

control entre los medios, variables globales y comunicaciones de los bloques de funcin.
1.
Variables Globales
Mediante el uso de variables globales situadas a nivel de configuracin, es posible transferir
datos y seales de control entre programas y bloques de funciones que se estn ejecutando
en diferentes medios. Sin embargo, se entiende bien que el uso de variables globales es un
mecanismo muy pobre y a veces inseguro para el manejo de la transferencia de datos entre
los procedimientos que se ejecutan en diferentes procesadores. No es posible identificar
claramente dnde se actualizan las variables globales y dnde se utilizan. No hay manera
grfica en la norma IEC 61131-3 para definir la relacin entre las variables globales y las
variables que, referenciadas a ellas, se encuentran dentro de los programas y bloques de
funcin. Tambin hay problemas ms graves con las variables globales ya que el tiempo
y la sincronizacin de las seales pasadas por stas variables es difcil de definir. Por otra
parte, los mecanismos previstos dentro de la configuracin para el manejo de la inicializacin
y actualizacin de las variables globales compartidas no estn definidos en la norma IEC
61131-3.
2.
Comunicaciones de los Bloques de Control

La Parte 5 de la norma PLC, IEC 61131-5 [8], se ocupa de los servicios de comunicaciones
para PLCs programados con el modelo de software IEC 61131-3. La norma IEC 61131-5
define una serie de bloques de funciones que pueden ser utilizados para el intercambio de
datos entre los PLCs. Esto incluye bloques para permitir a un PLC poder funcionar como un
"servidor", es decir, permitir que un PLC d soporte y responda a las peticiones de servicios
externos. Tambin hay bloques de soporte con comportamiento "cliente", es decir, servicios
1.3. IEC 61499 - UNA NORMA EN DESARROLLO
15
de soporte que permiten a un PLC solicitar y controlar a otro PLC o a un sistema funcionando
como un servidor.
La norma IEC 61131-3 permite un sub-conjunto de variables dentro de una configuracin para
acceder externamente. stas se llaman variables de acceso (ACCESS) y se puede acceder a ellas a
travs de una interfaz de comunicaciones de un PLC externo utilizando los bloques de funciones de
comunicacin o se puede acceder desde otros dispositivos (que no siguen la norma IEC 61131-3)
utilizando servicios que estn fuera de dicha norma.
Hemos visto que la norma IEC 61131-3, junto con la fabricacin de mensajera estndar IEC
61131-5, ofrece una gama de diferentes mecanismos de software para permitir a los PLC comunicarse. Estos son muy adecuados para sistemas con slo unos pocos PLC. Sin embargo, estaba claro
para el grupo de desarrollo de la norma IEC de bloque de funciones que el modelo de comunicaciones IEC 61131 presentaba serias limitaciones. Conceptos como variables globales y bloques de
funciones de comunicaciones no proporcionan un mtodo claro y conciso para definir las conexiones entre los bloques de funciones distribuidas.
Un modelo de comunicaciones consistente que podra ser utilizado no slo para comunicaciones PLC a PLC, sino tambin entre dispositivos grandes y pequeos distribuidos a travs de redes
industriales, era requerido. El nuevo modelo de bloque de funcin tena que ser escalable y extensible, por lo que sera igualmente aplicable para el modelado de comunicaciones entre sistemas
de control, PLCs y controladores como entre los dispositivos Fieldbus ms pequeos, tales como
vlvulas y sensores inteligentes. De hecho, se busc un modelo de bloque de funcin que cubra
todos los tipos de dispositivos y controladores.
Para resumir, las principales deficiencias del modelo de software proporcionado por la norma
IEC 61131-3 para sistemas distribuidos son las siguientes:
Las aplicaciones en el modelo IEC 61131-3 no son distribuibles a travs de mltiples recursos.
El orden de ejecucin de los bloques de funcin no siempre claramente definido.
La asignacin de tareas a los programas y bloques de funcin no proporciona suficiente
flexibilidad.
El escaneado natural de la ejecucin del bloque de funcin IEC 61131-3 no se puede
asignar a los bloques de funcin conectados a travs de recursos distribuidos.
1.3. IEC 61499 - Una norma en Desarrollo

Cuando la Comisin Electrotcnica Internacional estableci por primera vez en 1990 el grupo
de trabajo de Bloque de Funcin, se di cuenta de que los bloques de funcin seran un concepto
genrico que podra ser aplicado a una amplia gama de normas. Por ejemplo, los conceptos de bloques de funciones pueden utilizarse dentro de PLCs, dispositivos inteligentes, sistemas de gestin
de edificios (REVISAR XXXXXXXXXXXXXXX) y protocolos Fieldbus. Por lo tanto, era prudente colocar el grupo de trabajo WG 6 de bloque de funciones directamente bajo la direccin del
comit tcnico de medicin y control de procesos industriales, TC 65. Era la intencin de la IEC
que el bloque de funcin estndar se convertira en una norma genrica que podra ser utilizado
como una base para las normas en todo el dominio de la medicin y el control de procesos industriales. Por esta razn, debido a su carcter genrico, la norma IEC 61499 resulta ser un estndar
acadmico (REVISAR XXXXXXXX). Ha sido definida deliberadamente para ser "dominio de
aplicacin neutral", es decir, no contiene caractersticas especficas para ningn rea de aplicacin
16
Figura 1.10: Estructura del Grupo de Trabajo IEC

industrial particular. Est diseada para que otras normas pueden basarse en los conceptos de la
norma IEC 61499 y agregar sus propias extensiones de dominio especfico.
Un buen ejemplo de una norma basada en el modelo de bloques de funcin IEC 61499 es
demostrado por el grupo de Bloques de Funcin para Control de Procesos WG7, creado bajo el
subcomit SC65C de comunicaciones digitales. Este grupo tiene el objetivo primordial de establecer bloques de funcin para su uso en las industrias de procesos, pero se han tomado conceptos del
modelo genrico de bloque de funciones IEC 61499 como la base de su trabajo. Aplicando el modelo genrico para aplicaciones de control de procesos industriales reales, el grupo de Control de
Procesos ha proporcionado informacin til para el grupo de trabajo IEC 61499. En muchos casos,
han puesto de manifiesto deficiencias en el modelo de bloque de funciones que se han traducido
en mejoras a la norma IEC 61499.
El grupo de trabajo para la norma IEC 61499 tiene miembros de EE.UU., Japn, Reino Unido y
muchos pases europeos que representan tanto a los proveedores de sistemas de control industrial
como a los usuarios finales. La norma IEC 61499 es un estndar multi-parte que tomar varios
aos en completarse. La parte 1 cubre la arquitectura de bloque de funciones, que en el momento
de escribir este libro ya est muy avanzada y est lista para ser distribuida como una "Norma
Disponible Pblicamente" (Publicly Available Standard - PAS) - esto se discute con ms detalle en
el captulo 7.
La Parte 1 abarca la arquitectura y los conceptos para el diseo y modelado de sistemas orientados a bloques de funcin y se tratan los siguientes temas:
1. requisitos en general incluidos una introduccin, referencias de alcance y normativa (es
decir, a otras normas), definiciones y modelos de referencia
2. reglas para la declaracin de tipos de bloques de funcin, y reglas para el comportamiento
de las instancias de los tipos de bloques de funcin
3. reglas para el uso de bloques de funcin en la configuracin de sistemas de medicin y
control de procesos industriales distribuidos (Industrial Process Measurement and Control
Systems - IPMCSs)
1.4. POR QU USAR BLOQUES DE FUNCIN?
17
4. reglas para el uso de bloques de funciones para cumplir los requerimientos de comunicacin
de IPMCSs distribuidos
5. reglas para el uso de bloques de funcin en la gestin de aplicaciones, recursos y dispositivos
en IPMCSs distribuidos
6. requisitos de los sistemas y estndares compatibles.
El objetivo principal de este libro se refiere a la arquitectura y los modelos definidos en la Parte 1
de la norma IEC 61499.
La Parte 2 define los requisitos de herramientas de software para crear definiciones de tipos de
bloques de funcin y gestionar bibliotecas de bloques de funcin. Incluye un extenso anexo de tipos
de definicin de documentos XML para el intercambio de diseos de bloques de funciones entre
las herramientas de software de diferentes proveedores. XML es ahora el formato de intercambio
preferido para diseos de bloques de funcin. El objetivo principal de la parte 2 es "el soporte de
tareas de ingeniera" y proporcionar orientacin sobre las tareas de ingeniera relacionadas con
el diseo, la implementacin, la operacin y el mantenimiento de IPMCSs construidos usando la
arquitectura y los conceptos definidos en la Parte 1.
El estndar para el intercambio de datos de productos, STEP (standard for the exchange of
product data) (ISO 10303), haba sido considerado previamente para este propsito. STEP es utilizado por las estaciones CAD para el almacenamiento y la portabilidad de los diseos de circuitos
electrnicos en una forma de implementacin independiente. Es evidente que hay una fuerte sinergia entre esquemas electrnicos y diseos de sistemas de control basados en bloques de funcin.
Tambin se propone ahora en la Parte 2 de la norma IEC 61499 que el lenguaje de marcado
extendido (XML Extended Markup Language) puede ser utilizado como una forma de guardar
y portar definiciones de bloque de funcin. Esto proporcionar la posibilidad de ser capaz de
transferir diseos a travs de Internet y verlos con la prxima generacin de exploradores Web.
XML ha sido desarrollado como una importante mejora en el lenguaje de marcado de hipertexto
(HTML) que se utiliza actualmente para la creacin de la pgina web. El uso de XML permite
diseos que se guardan con varios atributos, incluyendo detalles de la informacin sobre la versin
y el diseo grfico - esto es discutido con ms detalle en el captulo 7.
1.4. Por qu Usar Bloques de Funcin?

Para muchos ingenieros de software, la idea de bloques de funcin parece en cierta medida arcaica, un paradigma de software extrao que parece representar software como piezas de hardware.
En efecto, eso es exactamente lo que un bloque de funcin es, un modelo de software que trata el
comportamiento encapsulado en una forma que es similar a un circuito electrnico. Los objetos
utilizados en el mundo de la programacin orientada a objetos (OO) se han convertido en un xito
debido a que pueden ser utilizados para modelar el comportamiento de entidades y conceptos en
el mundo real.
En el diseo orientado a objetos, el diseador de software se ocupa principalmente de las relaciones entre los objetos, como por ejemplo ver cmo un objeto puede heredar el comportamiento
de una super-clase o cmo objetos que tienen un comportamiento similar pueden ser tratados de
una manera similar - tambin llamado comportamiento polimrfico. El polimorfismo proviene de
una palabra griega que significa "muchas formas". Cuando es aplicada a objetos, significa que el
desarrollador puede aplicar el mismo tipo de operaciones con los objetos similares. Por ejemplo,
dos clases de objeto cliente y proveedor pueden ambos tener un mtodo llamado getAddress
para devolver la direccin del cliente y proveedor. En muchos casos, el polimorfismo permite a un
desarrollador utilizar el mismo cdigo para el tratamiento de diferentes objetos que comparten un
cierto aspecto del comportamiento. Veremos ms adelante, que el modelo IEC 61499 de bloques
18
de funcin ofrece facilidades que permiten a los bloques de funcin compartir las interfaces y por
lo tanto tener un comportamiento polimrfico.
En el mundo de bloques de funciones, el enfoque principal del diseador del sistema es tomar
estndar probado y funcionalidad encapsulada y vincularlos en la forma ms rpida y ms intuitiva
posible. La utilizacin de bloques de funcin est ms cerca de la mentalidad del diseador del
sistema industrial, quien est familiarizado con la conexin fsica de dispositivos de diferentes
modos para proporcionar una solucin de sistema particular.
Los bloques de funciones comparten muchos de los beneficios del uso de objetos de software.
Cules son las caractersticas tiles de un objeto? Un objeto es un paquete de software independiente que tiene sus propios procedimientos (llamados mtodos) que manipulan los datos internos
del objeto. Algunos de los mtodos proporcionan una interfaz externa (llamada mtodos pblicos)
para la comunicacin con otros objetos. "La caracterstica esencial de un objeto es que provee una
fusin de la lgica del proceso con datos." - Ver Objetos Distribuidos para Negocios [9].
Los principales beneficios del uso de objetos pueden resumirse como:
Los objetos reflejan el mundo real
Al disear una aplicacin es ms natural e intuitivo representar entes del mundo real asociados con una aplicacin como objetos, por ejemplo, documentos, empleados y productos.
Los objetos son estables
Generalmente los objetos son elementos de software probados que no cambian significativamente. En muchos casos, los desarrolladores utilizan las mismas clases de objetos en una
amplia gama de aplicaciones. Por ejemplo, cuando un objeto que se ha creado representa
todo el comportamiento y las caractersticas de una entidad como "proveedor de productos,
esto podra ser utilizado en una amplia gama de aplicaciones de negocios relacionados con
los proveedores. Un objeto proveedor de productos tendra tpicamente detalles como el
nombre, la direccin, las gamas de productos, condiciones comerciales, etc, y los mtodos
para obtener y actualizar esta informacin.
Los objetos reducen la complejidad
Un desarrollador puede trabajar con un objeto sin entender realmente cmo funciona el
objeto internamente. Una aplicacin puede desarrollarse mediante la creacin y vinculacin
de objetos - en general no hay que entender internamente al objeto.
Los objetos son reutilizables
Una vez que un objeto ha sido desarrollado y probado puede convertirse en parte del repertorio de un desarrollador. En algunos casos, un objeto puede ser publicado en una biblioteca
en la que puede ser utilizado por los desarrolladores de forma local o incluso a nivel global.
Los bloques de funciones tambin comparten la mayora de estas caractersticas que se traducen
en algunos beneficios significativos para el desarrollador del sistema y del usuario final:
la cantidad de software de control a ser desarrollado para una aplicacin se reduce mediante
el uso de bloques de funciones
el tiempo necesario para desarrollar sistemas de control se reduce
los sistemas de control que utilizan el mismo tipo de bloque de funcin tendrn un comportamiento ms consistente
se mejorar la calidad de los sistemas de control.
1.5. VISIONES DE DISEO DEL SISTEMA

Caracterstica
Objetos
19
Bloques de
Funciones
Datos
encapsulados
Si
Si
Interfaz
externa
Si
Si
Invocacin
Los objetos
tienen mtodos
con argumentos y
valores devueltos
Los bloques de
funcin utilizan
variables y eventos
de entrada y de
salida
Herencia
Si
No
Polimorfismo
Si
Si
Una clase objeto

y un tipo bloque
de funcin son
sinnimos
Instancias de
bloques de
funciones son
definidas desde el
tipo bloque de
funciones
Instanciado de
una clase
Comentarios
Los objetos pueden contener
datos que tambin son
instancias de otros objetos.
Los bloques de funcin
pueden contener instancias
de otros bloques de funcin
En bloques de funciones IEC
61499 no hay distincin entre
las interfaces pblicas y
privadas
Con los bloques de funcin,
los datos se pueden
sincronizar con un evento
Actualmente en la norma
IEC 61499 no existe ningn
mecanismo para que un
bloque de funcin herede
comportamiento
La norma IEC 61499
presenta un nuevo concepto
de "adaptador" que permite a
los bloques de funcin
compartir interfaces comunes
Cuadro 1.1: Objetos y bloques de funcin en comparacin

La Tabla 1.1 resalta las principales similitudes y diferencias entre los objetos y bloques de funcin.
La notable deficiencia del modelo de IEC 61499 de bloques de funcin es que no existe ninguna
disposicin para la herencia. Sin embargo, las futuras ampliaciones de la norma pueden considerar
mecanismos que acerquen los bloques de funcin a objetos de software.
1.5. Visiones de Diseo del Sistema

El diseo del software para cualquier proyecto grande puede ser muy complejo. Cuando hay
tambin algunos aspectos de software ejecutando control distribuido en diferentes recursos de
procesamiento, los problemas de diseo pueden ser desalentadores. Hay una necesidad clara de
una serie de puntos de vista de diseo grfico que permitan que los diferentes aspectos de un
diseo puedan ser analizados y expresados. Algunos puntos expresarn los aspectos abstractos del
diseo, mientras que otros estn obligados a mostrar la estructura fsica del sistema o la forma en
20
Figura 1.11: El Modelo 4+1 de Puntos de Vista de desarrollo del sistema

que el software es organizado.
No importa lo mucho que la gente haya intentado, es imposible transmitir todos los aspectos
de diseo de un sistema con una sola metodologa. Hay muchas cuestiones de diseo a tener en
cuenta que no se pueden expresar en un solo tipo de notacin grfica; tales como:
Cul es la estructura de software de alto nivel?
Qu funcionalidad del sistema ofrece a sus usuarios finales?
Cmo es distribuida la funcionalidad a travs del sistema?
Cmo se conectan los componentes del sistema?
Cmo se manejan las bibliotecas de software y los componentes estndar? REVISAR
XXXXXXXXXXXXX
Cmo responde el sistema a determinados eventos crticos?
Muchos de los problemas de diseo del sistema son el resultado de tratar de utilizar muy pocas o
inapropiadas metodologas de diseo para representar todos los aspectos de diseo de un sistema.
Un punto de vista de diseo en particular puede ser capaz de mostrar cmo software para un sistema
es lgicamente conectado, pero no sera capaz de describir la forma en que el sistema responde a
los eventos.
De hecho, ahora se reconoce que los diseos de software ms complejos pueden requerir por
lo menos cuatro puntos de vista diferentes de diseo y una serie de escenarios - esto forma una
arquitectura conocida como Modelo 4 +1, propuesto por Kruchten [10] (Figura 1.11).
Aunque Kruchten ha considerado la aplicacin de estos puntos de vista de diseo en el mundo
del software orientado a objetos, los mismos puntos de vista de diseo son tambin aplicables al
diseo de sistemas de control distribuido.
1.5. VISIONES DE DISEO DEL SISTEMA
21
Punto de Vista Lgico

Este punto de vista de diseo se utiliza para representar los requisitos funcionales del sistema.
Se expresa la funcionalidad de software como lo requiere el usuario del sistema. En un diseo
de sistema distribuido, sera una muestra de los principales bloques de funciones de software y
las principales interfaces entre ellos. Cuestiones como la forma en que se distribuye y ejecuta la
funcionalidad del sistema no son abordadas.
Una metodologa como el lenguaje IEC 61131-3 de Diagrama de Bloque de Funcin podra ser
utilizado para definir algunos aspectos del punto de vista de diseo lgico, como se explic ms
arriba en este captulo.
Punto de Vista de Proceso

Este punto de vista se ocupa de muchos de los requisitos no funcionales de un sistema, que
incluyen el rendimiento, la distribucin y temas como la concurrencia del sistema. Kruchten define
el punto de vista de proceso como "las redes lgicas de los programas de comunicacin que se
distribuyen a travs de un conjunto de recursos de hardware".
Esto corresponde casi exactamente a los conceptos de la norma IEC 61499 de Bloques de Funcin, que proporciona una arquitectura para representar la vista de la implementacin de un sistema
distribuido como redes de bloques de funciones interconectadas.
Punto de Vista de Desarrollo

Este punto de vista representa cmo se organiza el software que se utiliza para construir un
sistema grande. La construccin de un sistema de control distribuido grande implicar numerosas
bibliotecas y mdulos de software. El punto de vista de desarrollo muestra las relaciones entre los
componentes de software, tales como bloques de funcin en trminos de facilidad de reutilizacin,
restricciones, tamao de los componentes y compatibilidad de la versin. Por ejemplo, considere
un bloque de funcin que se utiliza para el control de transporte, nos gustara indicar qu tipos de
dispositivos soporta y nos gustara mostrar todas las restricciones sobre otros bloques que tienen
que interactuar con l.
Actualmente no existe una metodologa estndar IEC que se ocupa de la visin de desarrollo
de un sistema de control distribuido.
Punto de Vista Fsico

En un sistema de control distribuido, la el punto de vista fsico es bien entendido. Representa
los dispositivos fsicos y controladores en un sistema y muestra los diferentes enlaces de comunicaciones de red entre ellos.
El punto de vista fsico suele considerar la configuracin fsica del sistema, muestrando la ubicacin de los dispositivos y los detalles en los enlaces de comunicaciones y buses.
Escenarios
El ltimo, pero no menos importante, punto de vista que complementa cualquier diseo de
sistema es lo Kruchten llama "Escenario". Un escenario representa las principales interacciones
entre las unidades de software para proporcionar la funcionalidad clave ms importante de un
sistema. Por ejemplo, en un sistema de control distribuido, algunos escenarios importantes a tener
22
en cuenta pueden ser: el inicio del sistema, deteccin y recuperacin de fallos de dispositivos, la
activacin de la receta (Revisar XXXXXX), y el cierre del sistema. Cada escenario debe considerar
las interacciones entre las diferentes partes funcionales del software. Un escenario podra mostrar
tanto los aspectos de los puntos de vista de diseo lgico y como de procesos.
Al describir los distintos escenarios, el diseador puede revisar y probar el diseo haciendo
una serie de preguntas del tipo "qu pasara si? (what if? questions) . El diseo no puede
ser considerado completo hasta que se hayan definido todos los escenarios clave. Actualmente no
existe una metodologa definida por ninguna norma IEC que se puede usar para definir escenarios
para los sistemas de control distribuidos.
De esta rpida visin general del Modelo de Arquitectura 4+1 de Puntos de Vista, es evidente
que la Norma IEC 61499 proporciona slo uno de los cinco puntos de vista de diseo requeridos
para los sistemas de control distribuido. Sin embargo, la norma IEC 61499 s representa un paso
importante hacia una arquitectura de diseo unificado. Los otros puntos de vista, sin duda, surgirn
en tanto los diseadores empiecen a enfrentar el desafo de la construccin de grandes sistemas
distribuidos.
1.6. El Futuro Ms All de la Norma IEC 61499

El modelo propuesto por la norma IEC 61499 ha sido criticado por no adoptar los conceptos
de la tecnologa de software orientado a objetos (OO). Por ejemplo, actualmente no existen los
conceptos de herencia; los bloques de funciones no son capaces de heredar el comportamiento de,
por ejemplo, una clase base de bloque. La norma se ha iniciado mediante el modelado de conceptos
de bloques de funciones industriales existentes pero las extensiones para avanzar hacia conceptos
OO, sin duda, tendrn que tenerse en cuenta en el futuro prximo.
Nuevos estndares industriales para las comunicaciones y componentes de software traern
claros beneficios al permitir que los dispositivos fsicos y de software puedan ser fcilmente conectados entre s. Sin embargo, antes de que podamos alcanzar los componentes de software realmente interoperables que puedan ser utilizados para implementar sistemas grandes, necesitamos
ponernos de acuerdo en los mtodos generales para la descripcin de requisitos tales como los
modelos de informacin y transformaciones de datos. Es la intencin de la norma IEC 61499, ser
capaz de solucionar este problema en el mbito de los sistemas de control industrial.
En los siguientes captulos vamos a revisar los conceptos de la norma IEC 61499 y ver cmo
este nuevo estndar se puede utilizar para modelar el diseo de sistemas de control distribuido.
Captulo 2
Modelos y Conceptos IEC 61499
Ahora revisaremos los principales modelos y conceptos definidos en la norma IEC 61499 para
obtener una visin general del bloque de funciones estndar. Es aconsejable tener algn conocimiento del material de este captulo antes de proceder a cualquiera de los siguientes captulos,
donde vamos a revisar las caractersticas especficas de la norma IEC 61499 en ms detalle.
Los temas tratados en este captulo incluyen:
los modelos de sistemas, dispositivos y recursos para los sistemas de control distribuido
modelos para la representacin de las aplicaciones distribuidas
caractersticas de los bloques de funcin y su ejecucin
especificaciones de tipo para diferentes formas de bloque de funciones
bloques de funcin de interfaz de servicio para proporcionar interfaces a los sistemas operativos y hardware
adaptadores para interfaces de los bloques compartidos
sintaxis textual para definir entes IEC 61499.
Antes de proceder a examinar en detalle los muchos modelos y conceptos introducidos por la
norma IEC 61499, vamos a reconsiderar el alcance de la norma IEC 61499 como se discuti por
primera vez en el captulo introductorio. Sorprendentemente, el objetivo principal de la norma IEC
61499 no es como una metodologa de programacin, sino como una arquitectura y un modelo
para los sistemas distribuidos. No hay intencin de que la norma, como se ha definido, sea utilizada
directamente por herramientas de programacin. En su lugar, IEC 61499 proporciona un conjunto
de modelos para la descripcin de los sistemas distribuidos que se han programado usando los
bloques de funcin. Esta distincin es importante y debe ser entendida para evitar muchos de los
malentendidos acerca de IEC 61499.
Si no le permite programar un sistema de control distribuido, cmo puede ser de alguna utilidad? La norma IEC 61499 proporciona terminologa, modelos y conceptos que permiten la implementacin de un sistema de control distribuido orientado a bloques de funcin que se describe de
manera inequvoca y formal. Tener un enfoque formal y estndar para los sistemas descriptos le
permitir a los mismos ser validados, comparados y comprendidos. Este es el primer paso hacia las
metodologas de programacin estndar para sistemas distribuidos. Los escritores de la norma IEC
61499 han considerado que no es posible disponer de una metodologa de programacin coherente
a menos que haya una arquitectura coherente que sustente lo que estamos tratando de programar.
No obstante, no hay dudas de que los futuros conceptos de la norma IEC 61499 tambin se podrn
usar como parte de la metodologa de diseo del sistema.
Ahora vamos a revisar los diferentes modelos introducidos por la norma IEC 61499 que en su
conjunto forman la arquitectura para un sistema distribuido orientado a bloques de funcin.
23
CAPTULO 2. MODELOS Y CONCEPTOS IEC 61499
24
Figura 2.1: Modelo del Sistema IEC 61499
2.1.
Modelo del Sistema
A nivel fsico, un sistema distribuido consta de un conjunto de dispositivos interconectados

por varias redes para formar un conjunto de aplicaciones co-operando. Una aplicacin, tal como
el control de una lnea de produccin, un tanque de un proceso, y un transportador, requerir la
interoperacin de software corriendo en varios dispositivos. Hasta hace muy poco, una aplicacin distribuida tpica implicaba un pequeo porcentaje de software corriendo en los dispositivos
remotos, tales como controladores de temperatura y de lazo, dado que todava tena la inteligencia principal en un dispositivo central tal como un PLC. Dado que los dispositivos tales como
sensores y actuadores inteligentes comienzan a proporcionar ms capacidad de procesamiento, la
funcionalidad de software puede llegar a ser verdaderamente distribuida a travs de muchos ms
dispositivos, a un punto en el que es difcil identificar a un dispositivo de control principal.
Vamos a empezar mirando el modelo del sistema de nivel superior definido en la norma IEC
61499. Esto define la relacin entre los dispositivos de comunicacin y aplicaciones. Una aplicacin puede existir en un solo dispositivo o tener una funcionalidad distribuida sobre varios dispositivos. Una aplicacin distribuida ser diseada como una red de bloques de funcin conectados.
Sin embargo, cuando se carga la aplicacin en un sistema, normalmente se carga como una serie de
fragmentos de la red de bloques de funcin que se encuentran en diferentes dispositivos. Los servicios de comunicacin proporcionados por cada dispositivo aseguran que los bloques de funciones
que forman parte de una aplicacin mantienen sus conexiones de datos y eventos.
Nota: El modelo de sistema IEC 61499 permite a los dispositivos la ejecucin de ms de una
aplicacin. La norma define un modelo de dispositivo en el que es posible cargar y descargar
aplicaciones distribuidas sin molestar a las aplicaciones existentes; esto se logra a travs del uso
de servicios de gestin en el dispositivo - sto debe ser examinado ms adelante en el captulo 4.
2.2.
Modelo del Dispositivo
El modelo de dispositivo que se muestra en la Figura 2.2 presenta algunos conceptos importantes. Un dispositivo es capaz de soportar uno o ms recursos. Un recurso IEC 61499 tiene propiedades similares al concepto de recurso definido en la norma IEC 61131-3 de Lenguajes de
2.3. MODELO DEL RECURSO
25
Figura 2.2: Modelo del Dispositivo

Programacin de PLC. Un recurso proporciona ejecucin y control independientes de las redes de
los bloques de funcin.
El modelo del dispositivo tiene una interfaz de proceso que proporciona los servicios que
permiten a los recursos el intercambio de datos con los puntos de entrada y salida (E/S) sobre el
dispositivo fsico. Tambin hay una interfaz de comunicaciones que proporciona servicios para
que los recursos puedan intercambiar datos a travs de redes externas con recursos en dispositivos
remotos.
La estructura interna y el comportamiento del proceso y las interfaces de comunicaciones no
estn dentro del alcance de la norma IEC 61499, pero se espera que proporcionen una gama de
servicios de apoyo a la ejecucin de los bloques de funcin dentro de los recursos.
El propsito del dispositivo es proporcionar una infraestructura para sostener uno o ms recursos. Los fragmentos de redes de bloques de funciones se distribuyen entre los recursos que existen
ya sea en el dispositivo local o en los recursos de los dispositivos remotos.
2.3. Modelo del Recurso

El recurso proporciona prestaciones y servicios de soporte a la ejecucin de uno o ms fragmentos de aplicacin de bloques de funcin. Los bloques de funcin de un sistema distribuido
sern asignados a los recursos dentro de los dispositivos interconectados. De hecho, el foco principal de la norma IEC 61499 es modelar el comportamiento de los bloques de funcin dentro de cada
recurso. El recurso proporciona interfaces para los sistemas de comunicacin y para el proceso
especfico del dispositivo, es decir, a los servicios externos y los subsistemas que estn estrechamente conectados con el dispositivo, como el dispositivo de E/S. Por ejemplo, cada recurso tendr
una interfaz con el sistema de comunicaciones para permitir que los bloques de funcin intercambien datos con los bloques en los recursos remotos y una interfaz para leer y escribir en las entradas
y salidas de dispositivos locales. Por consiguiente, el recurso se ocupa de la asignacin de los los
flujos de datos y eventos que pasan entre los bloques de funcin en el recurso local de bloques de
funcin de recursos remotos a travs de las interfaces de comunicacin de dispositivos. Del mismo
modo el recurso asigna todas las solicitudes de lectura y escritura en el dispositivo de E/S de las
interfaces de proceso.
26
Figura 2.3: Modelo del Recurso
Es claro que el recurso define el lmite importante que existe entre lo que est dentro del alcance
del modelo IEC 61499 y lo que es dispositivo y la funcionalidad especfica del sistema. Cuestiones
tales como diseo de sistemas operativos y protocolos de comunicaciones que son especficos a
los tipos de dispositivos y redes estn, por el momento, fuera del alcance de la norma.
La Figura 2.3 muestra las principales caractersticas de un recurso IEC 61499. Dentro del
recurso, se muestra una red de bloques de funcin interconectados por enlaces de flujo de datos
y eventos. Una funcin de programacin proporcionada por el recurso asegura que los algoritmos
dentro de los bloques de funciones se ejecutan en el orden correcto, es decir, como se requiere por
la llegada de los eventos en cada bloque de funcin. Los bloques de funciones de Interfaz de
servicio (SI - Service Interface) son una forma especial de bloque de funciones que proporcionan
un vnculo entre los bloques de funciones y las interfaces del recurso. Por ejemplo, un bloque
de comunicaciones SI se puede utilizar para leer o enviar datos a los bloques de funcin en los
recursos remotos. Una serie de diferentes tipos de bloques SI son identificados y definidos en la
norma IEC 61499 y son descriptos en detalle en el captulo 4.
Una caracterstica importante de un recurso es que permite el funcionamiento independiente.
Un recurso se puede cargar, configurar, iniciar y detener sin afectar a otros recursos en el mismo
dispositivo o red.
Sin embargo, es importante tener en cuenta que la gestin de una aplicacin distribuida puede
requerir el control coordinado de una serie de recursos, donde se cargan fragmentos de la red de
bloques de funcin, por ejemplo, cuando se cargan e inician los diversos fragmentos de red de
bloques de funciones que componen la aplicacin distribuida. Las prestaciones necesarias para
lograr dicha coordinacin componen un tema que an no est totalmente abordado por la norma
IEC 61499.
2.4. MODELO DE APLICACIN
27
Figura 2.4: Modelo de Aplicacin
2.4. Modelo de Aplicacin

Una aplicacin IEC 61499 es definida como una red de bloques de funciones interconectados,
unidos por los flujos de eventos y de datos. Una aplicacin puede ser fragmentada y distribuida en
muchos recursos. Dentro de una aplicacin, una descomposicin es posible utilizando subaplicaciones. Una subaplicacin tiene las caractersticas externas de un bloque de funcin, pero puede
contener redes de bloques de funciones que pueden, ellos mismos, ser distribuidos a travs de otros
recursos. La norma define una forma fractal de la descomposicin de una aplicacin que permite a subaplicaciones descomponerse an ms, dando lugar a subaplicaciones ms pequeas si es
necesario.
La aplicacin define las relaciones entre los eventos y los flujos de datos que se requieren
entre los diversos bloques. Los diferentes recursos sobre los que se distribuyen los bloques deben
asegurarse de que los eventos se utilicen para programar los algoritmos apropiados dentro de los
bloques en la prioridad y la hora correctas. Los recursos son los responsables de mantener los
valores de las variables dentro de los bloques de funciones entre invocaciones de algoritmos. Los
recursos se ocupan tambin de la propagacin de eventos y la transferencia de datos entre bloques
de funcin, ya sea en el mismo recurso o entre recursos.
Caractersticas del modelo de aplicacin IEC 61499 se muestran en la Figura 2.4.
En trminos prcticos, una aplicacin es todo el conjunto de bloques de funciones e interconexiones para resolver un problema de automatizacin en particular. Algunos ejemplos podran ser:
el conjunto de bloques de funcin necesarios para controlar una lnea de produccin, una extrusora
de plstico o un recipiente de fermentacin.
28
Tenga en cuenta que los bloques de funcin IEC 61499 contienen todos los algoritmos y los
valores de inicializacin para definir su comportamiento completo.
Por tanto, una aplicacin consiste de instancias y definiciones de interconexin de bloques de
funciones que, en algunos casos, incluyen varias instancias de bloques de funcin de determinados
tipos de bloques. Es un principio de la norma IEC 61499 que todo el comportamiento se define
en trminos de bloques de funcin. Como resultado, veremos que no hay variables globales o
locales en una aplicacin que pueda existir fuera de los bloques de funcin. Esta es una distincin
importante entre un programa de aplicacin creado para un PLC basado en IEC 61131-3 y una
aplicacin IEC 61499.
2.5.
Modelo de Bloque de Funcin
En el ncleo de la norma es el modelo de bloque de funcin el que sustenta toda la arquitectura

IEC 61499. Un bloque de funcin se describe como una unidad funcional del software que
tiene su propia estructura de datos la cual puede ser manipulada por uno o ms algoritmos. Una
definicin de tipo de bloque de funcin proporciona una descripcin formal de la estructura y los
algoritmos de datos que se aplicarn a los datos que existen dentro de las diferentes instancias.
Esto no es un concepto nuevo, pero est basado en la prctica industrial comn aplicada a
bloques de control reutilizables de diversas formas. Un buen ejemplo es el bloque proporcional,
integral y derivativo (PID) que se utiliza en muchos PLC y controladores. Los vendedores de
sistemas suelen suministrar una definicin de tipo de bloque PID. El programador puede entonces
crear varias instancias del bloque PID dentro del programa de control, cada uno de los cuales se
puede ejecutar de forma independiente. Cada instancia PID, tales como Lazo 1, Lazo 2, tendr
su propio conjunto de parmetros de inicializacin y variables de estado internas y sin embargo
compartirn el mismo algoritmo de actualizacin.
La norma IEC 61499 define varias formas de bloque de funciones, lo que vamos a revisar
en detalle en los captulos posteriores. Las principales caractersticas de un bloque de funcin se
resumen de la siguiente manera:
Cada tipo de bloque de funcin tiene un nombre de tipo y el nombre de instancia. Estos se
deben mostrar cuando el bloque se representa grficamente.
Cada bloque tiene un conjunto de entradas de eventos, que pueden recibir eventos de otros
bloques a travs de conexiones de eventos.
Hay una o ms salidas de eventos, que pueden ser utilizados para propagar eventos a otros
bloques.
Hay un conjunto de entradas de datos que permiten que sean transmitidos valores de datos
desde otros bloques.
Hay una serie de salidas de datos para pasar valores de datos producidos en el bloque de
funcin hacia otros bloques.
Cada bloque tendr una serie de variables internas que se utilizan para mantener los valores
retenidos entre invocaciones de algoritmos.
El comportamiento del bloque de funcin es definido en trminos de informacin de algoritmos y estados. Usando los estados y los cambios de estado de los bloques, pueden ser
modeladas varias estrategias para definir qu algoritmos son para ejecutar en respuesta a
eventos particulares.
2.5. MODELO DE BLOQUE DE FUNCIN
29
Figura 2.5: Caractersticas de un Bloque de Funcin

En la Figura 2.5 se muestran las principales caractersticas de un bloque de funcin IEC 61499.
La parte superior del bloque de funcin, llamada control de ejecucin, contiene una definicin,
en algunos casos, dada en trminos de una mquina de estados, para los eventos del mapa de los
algoritmos, es decir, define qu algoritmos definidos en la parte inferior del cuerpo se disparan
ante la llegada de varios eventos al control de ejecucin y cundo los eventos de salida son
disparados lo que la norma llama la relacin causal entre las entradas de evento, salidas de
evento y la ejecucin de algoritmos. La norma define una forma para mapear las relaciones entre
los eventos que llegan a las entradas, la ejecucin de algoritmos internos y el disparo de la salida
de eventos esto se discutir en secciones posteriores de este captulo. REVISAR XXXXXXXXX
La parte inferior del bloque de funcin contiene los algoritmos y los datos internos, ambos de
los cuales estn ocultos dentro del bloque. Un bloque de funcin es un tipo de componente de
software y, si est bien diseados, no debera haber ningn requisito para que un usuario tenga una
comprensin detallada de su diseo interno.
Un bloque de funcin se basa en el soporte de su recurso contenido para proveer facilidades
para programar algoritmos y peticiones de mapeo para las las interfaces de comunicaciones y
proceso. REVISAR XXXXXXXX
La norma establece que un recurso puede opcionalmente proporcionar caractersticas adicionales para posibilitar el acceso a la parte interna de un bloque de funcin. Es evidente que, por
30
ejemplo en un dispositivo Fieldbus, sera siempres til con fines de mantenimiento o puesta en
marcha para ser capaz de examinar las variables internas dentro de un bloque. As que puede haber
mtodos de puerta trasera para acceder a la parte interna del bloque de funciones, sin embargo,
desde el punto de vista de la arquitectura IEC 61499, las variables de control y los eventos son slo
trasladados por las interfaces expuestas al exterior.
2.6. Tipos de Bloques de Funcin

Un concepto importante en la norma IEC 61499 es la capacidad de definir un tipo de bloque
de funcin que define el comportamiento y las interfaces de las instancias de bloques de funciones
que se pueden crear desde el tipo. Esto es sinnimo de la forma en el software orientado al objeto
(OO) que el comportamiento de instancias de objeto se define por la definicin de clase de objeto
asociado.
Un tipo de bloque de funcin se define mediante un nombre, definiciones formales para la entrada y salida de eventos del bloque, y las definiciones para las variables de entrada y salida. La
definicin tambin incluye el comportamiento interno del bloque, pero esto se define de diferentes
maneras para diferentes formas de bloque.
Bloque de Funcin Bsico

El comportamiento de un bloque de funcin bsico se define en trminos de algoritmos que se
invocan en respuesta a los eventos de entrada. Como ejecutar algoritmos que provocan eventos de
salida para indicar que ciertos cambios de estado se han producido dentro del bloque. El mapeo de
los eventos en los algoritmos se expresa utilizando una notacin de transicin de estado especial
llamada Execution Control Chart (ECC).
Bloque de Funcin Compuesto

El comportamiento interno del bloque de funcin compuesto y subaplicaciones est definido
por una red de instancias de bloques de funcin. Por tanto, la definicin incluye conexiones de
datos y eventos que necesitan existir entre las instancias internas del bloque de funcin.
Bloque de Funcin de Interfaz de Servicio

Los bloques de funcin de Interfaz de Servicio (SI) proporcionan una interfaz entre el dominio
y los servicios externos del bloque de funcin, por ejemplo, para comunicarse con los bloques de
funcin en un dispositivo remoto o para leer el valor de un reloj de tiempo real de hardware. Debido a que un bloque de funcin de tipo SI se ocupa principalmente de las transacciones de datos,
es definido usando diagramas de secuencia temporal. Esta forma de diagrama es ms comnmente
utilizada para definir las transacciones a travs de interfaces de comunicacin. Diagramas de secuencia de tiempo se describen ms adelante en este captulo, en el apartado de bloques de interfaz
de servicio.
2.7. Modelo de Ejecucin de los Bloques de Funcin Bsicos

Un modelo de ejecucin especial se utiliza para definir el comportamiento de un bloque de funcin bsico. Esto se describe mejor con la ayuda de la Figura 2.6 para bloques de funcin bsicos.
2.7. MODELO DE EJECUCIN DE LOS BLOQUES DE FUNCIN BSICOS
31
Figura 2.6: Modelo de Ejecucin de los Bloques de Funcin Bsicos

Las caractersticas numeradas en el bloque de funcin indican el orden en que las diferentes partes
del bloque son manejadas por la funcin de programacin subyacente. El modelo supone que
el recurso en el que existe un bloque de funcin proporciona una funcin de programacin que se
asegura de que cada fase de ejecucin del bloque de funcin se produce en el orden correcto y en
la prioridad correcta.
Hay una serie de fases de tiempo discreto, cada uno de los cuales puede llevar un perodo
de tiempo que debe transcurrir, requerido por el bloque de funcin bsico a ejecutar; cada fase
depende de las interacciones definidas entre el bloque de funcin y la funcin de programacin
subyacente. La Figura 2.6 representa los ocho puntos de tiempo que deben ocurrir secuencialmente
para que el bloque de funcin bsica pueda operar; la terminacin de cada fase se define por un
punto de tiempo numerado en particular.
Tiempo 1 Los valores provenientes de bloques de funcin externos son estables a las entradas
del bloque de funcin
Tiempo 2 Un evento asociado con los valores de entrada llega a la entrada de eventos.
Tiempo 3 Las seales de control de ejecucin del bloque de funcin a la funcin de programacin que tiene valores de entrada y est listo para ejecutar su algoritmo.
Tiempo 4 Despus de un cierto perodo de tiempo, determinado por las caractersticas de carga y el rendimiento del recurso, la funcin de programacin comienza a ejecutar el
32

algoritmo del bloque de funcin.
Tiempo 5 El algoritmo procesa los valores de entrada y, en algunos casos, tambin procesa los
valores almacenados internamente para crear nuevos valores de salida que se escriben
en las salidas del bloque de funcin.
Tiempo 6 El algoritmo completa su ejecucin, y sealiza la funcin de programacin para indicar que los valores de salida estn estables y listos.
Tiempo 7 La funcin de programacin invoca el control de ejecucin del bloque de funcin para
generar un evento de salida. Diferentes eventos de salida se pueden generar en funcin
de los eventos de entrada que han llegado y el estado interno del control de ejecucin.
Tiempo 8 El control de ejecucin, a su vez crea un evento de salida correspondiente en la interfaz
de eventos de salida del bloque de funcin. El evento de salida es utilizado por los
bloques de funcin posteriores para indicar que ahora pueden utilizar los valores de
salida generados por este bloque.
Es importante tener en cuenta que hay una serie de restricciones sobre este modelo de ejecucin.
Estas fases temporales no pueden superponerse y deben aparecer en el orden prescrito para que el
bloque de funcin se ejecute correctamente. Sin embargo, en algunas implementaciones, algunas
fases pueden ser tan cortas en duracin como para ser consideradas como instantneas. La norma
IEC 61499 no define lmites en ninguno de estos tiempos. Sin embargo, deja en claro que en
cualquier modelo de bloque de funcin, debera ser posible definir la duracin de estas diferentes
fases con el fin de modelar con precisin las caractersticas de temporizacin de la red completa
de bloques de funcin.
La norma define las siguientes duraciones que sern importantes en la construccin de aplicaciones:
Tsetup = Tiempo 2 Tiempo 1 tiempo entre la recepcin de los valores de entrada y la llegada de
su evento de entrada asociado
Tstart = Tiempo 4 Tiempo 2 el tiempo entre la recepcin de un evento de entrada y ejecucin
del algoritmo; esta duracin puede depender de la carga de recursos, es decir, cmo
muchos otros bloques de funcin estn tambin pendientes en la cola de la funcin de
programacin
Talgorithm = Tiempo 6 Tiempo 4 el tiempo entre comenzar y completar el algoritmo del bloque
de funciones
Tfinish = Tiempo 8 Tiempo 6 tiempo desde que termina el algoritmo y se provoca el evento de
salida.
La relacin entre estos puntos temporales se representa en la Figura 2.7; los puntos en los que los
datos de entrada y salida de los bloques de funcin cambian tambin son mostrados. Cabe sealar
que la norma supone que los eventos se comportan como puntos discretos en el tiempo y no tienen
duracin. En un sistema fsico, los eventos pueden requerir la transferencia de alguna forma de
informacin de cambio de estado entre los bloques y pueden tener una duracin corta pero finita.
Es evidente que en diferentes implementaciones puede ser necesaria una variedad de mecanismos para asegurar que el bloque de funcin sea capaz de ejecutarse utilizando datos consistentes.
Por ejemplo, es importante que los valores de datos de entrada se mantiengan estables mientras
que un algoritmo se ejecuta. El algoritmo slo debe utilizar los valores de entrada que existen en el
momento del arribo del evento de entrada, es decir, el evento de entrada se puede utilizar como una
captura de los valores de entrada listos para la ejecucin del algoritmo. Tambin es muy importante
2.8. MODELO DE DISTRIBUCIN
33
Figura 2.7: Tiempos de Ejecucin

para la funcin de programacin subyacente detectar cuando un bloque de funcin recibe eventos
de entrada a un ritmo ms rpido del que puede ser manejado por el bloque.
El modelo de la norma IEC 61499 supone que no hay colas de eventos y datos en la entrada;
una implementacin puede proporcionar alguna forma de gestin de colas de entrada, pero esto no
est modelado explcitamente por la norma IEC 61499. Sin embargo, tal comportamiento puede
ser modelado mediante la creacin de bloques de funcin especiales incorporados desde las redes
de los bloques bsicos. El modelo permite a los recursos proporcionar servicios para que los algoritmos de los bloques de funcin del proceso utilicen multitarea. Con la priorizacin apropiada de
los eventos dentro de la funcin de programacin, es posible evitar la mayora de los problemas de
sobrecarga de eventos. Sin embargo, tenga en cuenta que las caractersticas y el comportamiento
interno de la funcin de programacin no estn actualmente en el alcance de esta norma.
2.8. Modelo de Distribucin

Hay una diferenciacin importante entre bloques de funcin y aplicaciones. Ambas aplicaciones y subaplicaciones pueden ser distribuidas, es decir, configuradas para ejecutarse en varios
recursos. Una aplicacin distribuida consistir en una red de bloques de funcin con fragmentos de
bloques corriendo en los recursos designados. Tenga en cuenta que la norma IEC 61499 considera
que la distribucin afecta a la disposicin de los bloques de funcin de los diferentes recursos.
Debido a que un dispositivo puede soportar mltiples recursos, es posible para una aplicacin
34
Bloque de
Funcin
Subaplicacin
Aplicacin
Distribuible
No
Si
Si
Temporizado
Depende slo del
dispositivo
Depende de los
dispositivos y
comunicaciones
Depende de los
dispositivos y
comunicaciones
Confiabilidad
Depende slo del
dispositivo
Depende de los
dispositivos y
comunicaciones
Depende de los
dispositivos y
comunicaciones
Replicacin
Como instancias
de tipo FB
Como copias de
tipo
subaplicacin
No
Cuadro 2.1: Caractersticas de Distribucin

distribuida ejecutarse en un nico dispositivo, es decir, el uso de recursos dentro del mismo dispositivo. A subaplicacin es una forma ms pequea de aplicacin que puede ser replicada, pero por
el resto tiene las mismas caractersticas de distribucin que una aplicacin.
La sincronizacin y el rendimiento de una aplicacin o subaplicacin dependern de los recursos sobre los que ha sido distribuida y las redes de comunicacin con que los conectan. Por
ejemplo, considere dos subaplicaciones idnticas, para el control de una lnea de transporte, que se
ejecuta en dos redes diferentes de controladores, una red utilizando enlaces de datos de fibra ptica
a 10 MBaud y el otro con un par trenzado de cobre de menor coste que funciona a 98 KBaud.
Debido a que las velocidades de datos de comunicaciones de las dos redes son tan diferentes, las
dos subaplicaciones tienen diferente rendimiento y tiempo de respuesta debido a latencias de la
red, a pesar de que sus algoritmos de software internos sern iguales.
Por el contrario, los bloques de funcin se asumen como atmicos y se ejecutan en un solo
recurso. En este sentido, el rendimiento de un bloque de funcin no se ve afectado por las caractersticas de las redes de comunicaciones. Sin embargo, el rendimiento puede en menor medida ser
afectado por el comportamiento y las caractersticas de los recursos y el dispositivo en el que el
bloque ha creado una instancia. Estas caractersticas de distribucin se resumen en la Tabla 2.1.
2.9.
Modelo de Gestin
Hemos visto que un recurso puede soportar fragmentos de redes de bloques de funciones que
forman parte de las aplicaciones o subaplicaciones distribuidas. Pero, cmo son estos fragmentos
de aplicaciones creados y gestionados? Para este propsito, la norma IEC 61499 define tambin una
forma especial de aplicacin llamada aplicacin de gestin, que es responsable de la creacin de
redes de bloques de funcin dentro de un recurso. La aplicacin de gestin, con una funcionalidad
ms privilegiada que las aplicaciones normales, puede construir parte de otras aplicaciones mediante la creacin de bloques de funciones y conexiones. Por lo general se conectar con agentes
externos, tales como estaciones de programacin remota a travs de enlaces de comunicaciones.
La funcionalidad de una aplicacin de gestin incluir lo siguiente:
crear instancias de bloques de funciones dentro de un recurso
asociar fragmentos de bloques de funcin con una aplicacin particular
crear conexiones de datos y eventos entre los bloques de funcin y los bloques de interfaz de
servicio
iniciar la ejecucin de los bloques de funcin como parte de una aplicacin distribuida
2.9. MODELO DE GESTIN
35
Figura 2.8: Gestin compartida de bloques de funcin

proporcionar servicios de apoyo a las consultas de los enlaces de comunicacin sobre el
estado de las instancias de bloques de funciones
eliminar instancias de bloques de funciones junto con sus conexiones de datos y eventos.
Una restriccin importante es que la aplicacin de gestin debe ser capaz de cargar fragmentos de
redes de bloques de funcin para diferentes aplicaciones sin afectar la ejecucin de otras aplicaciones que estn ejecutndose.
Por lo tanto, ahora puede preguntarse, cul es entonces el responsable de cargar las aplicaciones de gestin? Se supone que un dispositivo tendr un cierto nivel de funcionalidad de lnea base
dentro de la aplicacin de gestin con el fin de cargar el arranque de los bloques de funcin para
las principales aplicaciones. Es probable que parte de la aplicacin de gestin exista en una forma
no voltil en el dispositivo y siempre sea capaz de cargar las aplicaciones cuando el dispositivo
est encendido. REVISAR XXXXXXXXXXXXX
Tenga en cuenta que algunos dispositivos pueden tener todas sus redes de bloques de funcin
en una forma no voltil que no puede ser modificada a travs de las comunicaciones externas, en
cuyo caso la mayora de las funcionalidades de la aplicacin de gestin pueden no ser necesarias.
La norma propone dos esquemas para proporcionar aplicaciones de gestin. La Figura 2.8
muestra un dispositivo que tiene un Recurso de Gestin especial que contiene las aplicaciones
de gestin las cuales proporcionan funcionalidad para construir y mantener redes de bloques de
funcin de los recursos adyacentes provistos en el dispositivo.
En la Figura 2.9 se define una disposicin alternativa en la que cada recurso contiene una
aplicacin de gestin que es responsable de cargar las redes de bloques de funcin dentro del
mismo recurso.
Aplicaciones de gestin pueden ser modeladas exactamente de la misma manera que otras
aplicaciones utilizando redes de bloques de funciones y bloques de funcin de interfaz de servicio.
Es probable que una aplicacin de gestin requiera una serie de bloques de funcin de interfaz de
servicio para manejar la interfaz con enlaces de comunicaciones externos, por ejemplo, procesar
las solicitudes para crear instancias de bloques de funciones.
La funcionalidad de una aplicacin de gestin an no est definida en detalle en la norma IEC
36
Figura 2.9: Gestin distribuida de bloques de funcin

61499 pero es evidente que sta es un rea importante que necesita ser estandarizada antes de que
sea posible cargar y configurar dispositivos compatibles IEC 61499 de forma coherente.
2.10.
Modelo de Estado Operacional
Los grandes sistemas basados en redes de bloques de funciones IEC 61499 tpicamente se
desarrollan, encargan y ponen en funcionamiento en una serie de etapas. As que dentro de una
red de bloques de funciones, la norma IEC 61499 propone que el concepto de ciclo de vida se
modele y se aplique a las unidades funcionales, tales como dispositivos, recursos y aplicaciones.
Al igual que con todos los grandes sistemas basados en software, esto es necesario de manera que
sea posible gestionar y controlar los estados de las diferentes partes que lo componen.
El modelo de estado operacional no est todava completamente definido dentro de la norma,
pero se propone que cada unidad funcional tenga estados bien definidos, tales como:
DETENIDO - la unidad no est en funcionamiento
CARGADO - la unidad se ha cargado, por ejemplo, un dispositivo puede estar en un estado
cargado cuando todas las definiciones de bloques de funciones y las instancias de bloques
de funciones asociadas para una aplicacin se han cargado en un dispositivo
CONFIGURABLE - la unidad est cargada y lista para ser configurada antes de entrar
en funcionamiento; un dispositivo podra estar en un estado configurable cuando se han
cargado las instancias de bloques de funciones, pero an se esperan detalles de la conexin
de los bloques de funciones
OPERATIVO - la unidad ha sido cargada y configurada y est lista para iniciar la ejecucin
o apoyar la ejecucin de parte de una aplicacin cargada
FUNCIONANDO - la unidad se encuentra en pleno funcionamiento y se est ejecutando.
2.11. INTERFACES COMUNES UTILIZANDO ADAPTADORES
37
Para controlar y sincronizar la carga de una aplicacin distribuida, la norma propone que las estrategias se han desarrollado para garantizar un estado de funcionamiento consistente a travs de
sus componentes. Por ejemplo, una aplicacin distribuida puede requerir que los fragmentos de
redes de bloques de funciones se carguen en un serie de diferentes recursos que se encuentran en
una variedad de dispositivos diferentes y, en algunos casos, remotos. La carga y la configuracin
de los bloques de funciones que residen en los diferentes dispositivos pueden ocurrir en diferentes
momentos, sin embargo, el cambio entre los estados operativo y funcionando de todos los dispositivos y recursos asociados pueden necesitar ser sincronizado para una correcta aplicacin de
puesta en marcha.
La norma tambin contempla situaciones en las que ciertas unidades funcionales privilegiadas
puedan tomar el control de otras unidades funcionales. Por ejemplo, un bloque de funcin cargador de trabajo en el dispositivo A se puede utilizar para cargar nuevas definiciones de bloque de
funcin en los dispositivos remotos B y C con el fin de modificar una aplicacin para un determinado tipo de perfil por lotes. En tales casos, es un requisito para ser capaz de dar ciertos bloques,
tener los derechos para cargar, configurar y cambiar los estados de otros bloques. Los bloques de
funcin de aplicacin de gestin que ya se han introducido en este captulo necesitarn claramente
tener privilegios especiales para poder cargar e iniciar aplicaciones completas.
La gestin de aplicaciones y el control de los estados de funcionamiento de aplicaciones es un
rea que sigue en espera de desarrollo dentro de la norma IEC 61499 y probablemente se trate en
otras secciones de la norma.
2.11. Interfaces Comunes Utilizando Adaptadores

Una de las grandes fortalezas del software orientado a objetos (OO) es la posibilidad de tener
diferentes objetos compartiendo las mismas interfaces. Es una prctica general en el software OO
para los objetos que representan entidades con caractersticas bsicas similares, tener partes de
su interfaz externa en comn. Por ejemplo, en el diseo de interfaces grficas de usuario (GUI),
es tpico de las entidades grficas con caractersticas similares, como los objetos que representan
crculos y cuadrados, disponer de mtodos de interfaz comn. Por ejemplo, los objetos que representan elementos tales como cuadrados y crculos pueden tener numerosos mtodos en comn,
como por ejemplo cambiar el tamao, mover, copiar y color de relleno.
Compartir comportamiento se logra en software orientado a objetos a travs de una tcnica
llamada herencia. Esto permite nuevos objetos especializados para heredar, es decir, compartir
la misma interfaz y el comportamiento bsico de otro tipo ms genrico de objeto. Tener diferentes
tipos de objetos con interfaces comunes da beneficios significativos en diseo de software. Esto
significa que el software puede ser creado de manera ms flexible y se puede aplicar a una gama
ms amplia de objetos una tcnica poderosa que ahora se conoce como polimorfismo.
Se reconoce que alguna forma de comportamiento polimrfico tambin es til en el diseo
de bloques de funcin. Un buen ejemplo de esto son los bloques de funcin que manejan sensores
con caractersticas similares. Podramos imaginar bloques que manejan sensores analgicos, por
ejemplo la temperatura y la presin diferencial, que tienen algunas caractersticas comunes en sus
interfaces. Por ejemplo, tanto tendra que ser capaz de establecer los niveles de alarma alta y baja, y
detectar condiciones fuera de rango. Est claro que sera til ser capaz de tener el mismo software
para el manejo de los aspectos comunes de los bloques de funcin para los diferentes tipos de
sensores.
Para facilitar el apoyo a las interfaces comunes, la norma IEC 61499 define un concepto especial llamado interfaz adaptador. Esto permite que los bloques de funciones que tienen un comportamiento similar compartan la misma interfaz uniendo un tipo especial de bloque de funcin.
Este tipo de bloque de funcin se denomina adaptador. Es anlogo a un dispositivo electrnico
38
Figura 2.10: Interfaces Adaptadoras

Nota: Esta cifra representa el concepto adaptador; no representa cmo se muestran grficamente
utilizando adaptadores IEC 61499
que se puede conectar a otros dispositivos proporcionando el comportamiento especializado con
un enchufe y un tomacorriente. El concepto se representa grficamente en la Figura 2.10; el lado
izquierdo de esta figura muestra el bloque adaptador que es capaz de conectarse estrechamente con
un bloque especializado por encima de l, por el lado derecho, vemos que los dos bloques estn
unidos para formar un adaptador de conexin. REVISAR XXXXXXXXXXX
Para aclarar an ms los beneficios del uso de adaptadores, considere el diseo de bloques
de funciones de manejar las diversas formas de entrada analgica. Consideremos un bloque para
manejar una entrada de temperatura y otro para manejar una entrada de presin diferencial. Es evidente que cada bloque requerir sus propias entradas y salidas de interfaz especializadas. El bloque
de temperatura requerir entradas para definir rangos de termopar, desviaciones de calibracin, escala y as sucesivamente, mientras que la entrada de presin diferencial requerir entradas y salidas
especializadas para definir la presin de histresis, y las caractersticas del sensor de presin. Sin
embargo, ambos bloques tambin tienen una amplia gama de entradas y salidas que son comunes.
Basta pensar en los requisitos para la definicin y creacin de alarmas; est claro que sera ms
eficiente y consistente tener una implementacin estndar de gestin de alarmas encapsulado en un
bloque. La Figura 2.11 representa cmo el concepto adaptador se puede utilizar para proporcionar
un bloque comn para la gestin de alarma que puede ser conectado a los bloques especializados
que tienen el comportamiento y la interfaz especfica para diferentes tipos de sensores.
En la norma IEC 61499, bloques de funcin pueden ser configurados ya sea como adaptador proveedor o como aceptor. En nuestro ejemplo, el bloque de alarma se representa como
adaptador proveedor, mientras que los bloques de especializacin del sensor Temperature y
Diff_Pressure son un adaptador aceptor.
Tenga en cuenta que el comportamiento comn se puede modelar de diferentes maneras. Tambin sera posible en este ejemplo tener un bloque sensor comn adaptador aceptor que tiene todo
el comportamiento compartido y luego unir los bloques especializados adaptadores proveedores
para obtener el sensor de especializado.
2.12. SINTAXIS TEXTUAL PARA ENTES IEC 61499
39
Figura 2.11: Ejemplo de Adaptador
2.12. Sintaxis Textual para Entes IEC 61499

Una caracterstica significativa de la norma IEC 61499 es una rica sintaxis textual que permite
a los modelos de entidades tales como las aplicaciones y los bloques de funcin ser descriptas
en un lenguaje de texto. Las definiciones textuales se pueden utilizar para definir sin ambigedades modelos de manera que las representaciones grficas se pueden crear de forma automtica y
consistentemente. Por ejemplo, un bloque de funcin compuesto puede ser construido a partir de
una red de varios bloques ms pequeos con las conexiones de datos y eventos apropiadas. Todos
los aspectos del diseo interno del bloque compuesto se pueden representar mediante la sintaxis
textual IEC 61499.
Se prev que ser posible compilar las definiciones textuales como un medio para comprobar
la validez de un modelo en particular. El formato de texto es sin duda til para portar diseos de
modelos de una plataforma de estacin de trabajo a otra. En l se definen los aspectos semnticos
del modelo, pero no describen completamente los detalles grficos. Por ejemplo, un modelo en particular puede haber sido desarrollado mostrando bloques de funcin situados en ciertas posiciones
en un diagrama de red. La ubicacin actual y finos detalles grficos como el color y tipo de letra
no son parte de la sintaxis. Sin embargo, las conexiones lgicas entre los bloques estn definidas
con precisin.
Nota: En la Parte 2 de la norma IEC 61499, atributos grficos se pueden transferir mediante un
formato de intercambio de archivos basado en XML. Esto se examina en el captulo 7.
La norma contiene un extenso anexo en el que se describen las normas de produccin para todas las caractersticas de la sintaxis textual. Tenga en cuenta que algunos aspectos de esta sintaxis
se describen en este libro, pero para una definicin completa y exacta, es aconsejable ver el Anexo
B de la Parte 1 de la norma IEC 61499.
Ejemplo: 2 de cada 3 votantes

Un bloque de funcin simple se utiliza aqu para ilustrar algunas de las caractersticas de la
sintaxis textual. Muchas de las caractersticas de la sintaxis se describen con ms detalle en los
captulos posteriores.
40
Figura 2.12: Bloque de funciones de ejemplo de votantes

Considere la posibilidad de un bloque de funcin que se aplica a un algoritmo 2 de cada
3 votantes sobre tres entradas A, B y C. Esto puede ser modelado como un bloque de funcin
bsico como se muestra en la Figura 2.12. El bloque tiene dos entradas de evento, Reset y
Vote. El evento Reset desencadena un algoritmo para restablecer el estado interno almacenado del
votante. Cuando el algoritmo de reseteo se ha completado con xito, un evento se produce en la
salida Ready.
El evento Vote se utiliza para activar el principal algoritmo de votantes que comprueba el estado
de las tres entradas booleanas A, B y C. Si dos o ms entradas son verdaderas, la salida State se
establece en true y se mantiene as hasta que se ejecuta el algoritmo de reseteo. Cuando el algoritmo
de votantes se ha completado, un evento se produce en la salida de eventos Voted.
La sintaxis textual para describir el bloque de funcin Voter es la siguiente:
FUNCTION_BLOCK VOTER (* Voter FB *)
EVENT_INPUT
Reset; (* Reset event *)
Vote WITH A,B,C; (* Trigger Voter *)
END_EVENT
EVENT_OUTPUT
Ready;
Voted WITH State;
END_EVENT
VAR_INPUT
A : BOOL;
B : BOOL;
C : BOOL;
END_VAR
VAR_OUTPUT
State : BOOL;
END_VAR
EC_STATES
Ready : ResetAlg -> Ready;
Voted : VoteAlg -> Voted;
END_STATES
EC_TRANSITIONS
Ready TO Voted := Vote;
Voted TO Voted := Vote;
2.13. RESUMEN
41
Voted TO Ready := Reset;

END_TRANSITIONS
ALGORITHM ResetAlg IN ST; (* Reset Algorithm *)
State := 0; (* Reset the state output *)
END_ALGORITHM
ALGORITHM VoteAlg IN ST; (* Voter algorithm *)
IF State = 0 THEN
State := (A AND B) OR (A AND C) OR (B AND C);
END_IF;
END_ALGORITHM
END_FUNCTION_BLOCK
Los siguientes puntos se pueden observar a partir de este ejemplo:
La definicin textual incluye secciones EVENT_ y VAR_ para declarar todos los eventos y
datos de las interfaces de entrada y de salida del bloque.
Los estados internos del bloque se definen y se asocian con los eventos que disparan las transiciones entre estados; lo que es declarado en las secciones EC_STATES y EC_TRANSITIONS.
REVISAR XXXXXXX
Los algoritmos son disaparados por eventos cuando el bloque se encuentra en un estado
particular, tal como se define en la seccin EC_STATES de la definicin de bloque.
Cada algoritmo puede ser definido en un lenguaje textual en particular. En este ejemplo,
tanto el algoritmo ResetAlg como el VoteAlg se definen utilizando el lenguaje de Texto
Estructurado (ST); el cual es un lenguaje de alto nivel definido en la norma IEC 61131-3 de
lenguajes de programacin de PLC. Sin embargo, tenga en cuenta que la norma IEC 61499
no excluye el uso de otros lenguajes como Java o C para definir el contenido del algoritmo.
De hecho, sorprendentemente, IEC 61499 no define la sintaxis textual para la definicin de
algoritmo, pero permite que cualquier lenguaje textual estndar existente sea utilizado.
2.13. Resumen
Hemos revisado los principales conceptos introducidos por la norma IEC 61499 que proporcionan un marco y una arquitectura para modelar bloques de funcin orientados sistemas distribuidos. En resumen:
El modelo de sistema define un conjunto de dispositivos interconectados que pueden comunicarse a travs de conexiones de red.
El modelo de dispositivo es compatible con uno o ms recursos que proporcionan soporte
para la carga, la configuracin y la ejecucin de las redes de los bloques de funcin.
Una aplicacin puede residir en uno o ms recursos. Cada recurso puede apoyar la gestin y
ejecucin de parte de una aplicacin, con cada parte siendo distribuida como un fragmento
de una red de bloque de funcin.
Hay bloques de funciones bsicos y compuestos para hacer frente a las diferentes formas de
construccin del bloque y la jerarqua del bloque.
42

Bloques de interfaz de servicio proporcionan comunicaciones de redes y recursos de interfaz
de hardware. REVISAR XXXXXX
El concepto adaptador permite que los bloques de funcin compartan interfaces genricas.
La sintaxis textual IEC 61499 ofrece una forma concisa y compilable para portar y crear
definiciones de entidades tales como bloques de funciones y aplicaciones.
Captulo 3
Definicin de Tipo Bloque de Funciones y
Subaplicacin
En este captulo vamos a revisar cmo crear definiciones de tipos para bloques de funciones y
subaplicaciones y mostrar cmo estos pueden ser utilizados para crear instancias de bloques de
funcin y copias de subaplicaciones.
Concretamente vamos a:
revisar las diferentes formas de definicin de bloque funcin
mostrar cmo se pueden definir eventos e interfaces de datos
examinar cmo se construyen algoritmos y se vinculan a la ejecucin del evento
considerar cmo se comportan las instancias de bloques de funciones
revisar dnde se pueden utilizar subaplicaciones y comparar su comportamiento y propiedades con los bloques de funcin compuestos.
3.1. Tipos e Instancias

Antes de proceder a definir los mecanismos previstos en la norma IEC 61499 para definir los
tipos de bloques de funciones con cierto detalle, recordemos el papel de los tipos e instancias de
bloques de funciones. Una definicin de tipo de bloque de funcin describe la interfaz externa y
el comportamiento interno de un tipo particular de bloque de funcin. Sin embargo, una instancia
del bloque de funcin es, en efecto, una copia de trabajo del mdulo de funcin creado usando la
definicin de tipo de bloque de funcin. En un sistema grande es probable que las definiciones de
tipos de bloque de funcin se lleven a cabo en varias bibliotecas, para fines tales como: algoritmos
de control, gestin de alarmas, sensores de entrada y as sucesivamente. La configuracin de
un sistema grande basado en bloques de funcin requerir la seleccin de bibliotecas de tipos
de bloques de funciones apropiadas y luego la declaracin de instancias de bloques de funcin
sobre la base de tipos de bloques de funcin seleccionados. Definiciones claras, precisas y sin
ambigedades de los tipos de bloques de funcin son, por lo tanto, pertinentes a la utilizacin
eficaz de la norma IEC 61499.
3.2. Diferentes Formas de Bloque de Funcin

La norma establece las definiciones de tipo de tres formas diferentes de bloques de funcin,
cada forma tiene sus propias propiedades y usos particulares, como se indica en la Tabla 3.1.
43
44
CAPTULO 3. DEFINICIN DE TIPO BLOQUE DE FUNCIONES Y SUBAPLICACIN

Forma
Bloque de Funcin
Bsico
Distribuible
No
Definicin
Estados definidos
usando la Tabla de
control de ejecucin
(ECC). Algoritmos
definidos usando un
lenguaje apropiado, por
ejemplo, Texto
Estructurado, Java.
Bloque de Funcin
Compuesto
No
Subaplicacin
Si
Construido a partir de
una red de bloques de
funcin bsicos y
compuestos. La
definicin se da en
trminos de las
conexiones de datos y
eventos entre los
bloques de funcin.
Construido a partir de
redes de bloques de
funcin bsicos y
compuestos. Una
subaplicacin puede
contener a su vez
copias de
subaplicaciones
pequeas.
Comentarios
Un bloque de funcin
bsico no puede ser
distribuido, solamente
se puede ejecutar en un
solo recurso. Bloques
de funciones bsicos
definen los bloques
fundamentales desde
los cuales grandes
bloques compuestos
pueden ser construidos.
Un bloque de funcin
compuesto es
construido a partir de
una red de bloques de
funcin de nivel
inferior. stos pueden
ser bloques bsicos o
bien compuestos de
nivel inferior.
Este tipo de bloque est
destinado a
proporcionar una parte
reutilizable de una
aplicacin que puede
ser distribuida a travs
de muchos recursos.
Cuadro 3.1: Diferentes formas de bloques de funcin

Las principales caractersticas de estas tres formas se muestran en la Figura 3.1. Debe tenerse
en cuenta que los bloques de funcin bsicos y compuestos siempre residen en un solo recurso
y proporcionan variables en sus entradas y salidas para mantener los valores de datos. Bloques
bsicos tambin requieren almacenamiento interno para la mquina de estado de control de ejecucin. Sin embargo, a diferencia de un subaplicacin no tiene especficamente almacenamiento
para entradas, salidas y eventos. Con subaplicaciones, tal almacenamiento es proporcionado por
los bloques de funciones internos que existen dentro del cuerpo de la subaplicacin.
3.3.
Definiendo Bloques de Funcin Bsicos
Bloques de funciones bsicos se pueden describir tanto textualmente utilizando la sintaxis textual IEC 61499 como grficamente. Hay dos representaciones grficas que juntas representan las
propiedades y el comportamiento de un bloque de funcin bsico: (i) la declaracin de interfaz
externa y (ii) la tabla de control de ejecucin (ECC) que define las relaciones entre la ejecucin de
eventos, estados y algoritmos.
3.3. DEFINIENDO BLOQUES DE FUNCIN BSICOS
45
Figura 3.1: Diferentes formas de bloques de funcin
Declaracin de Interfaz Externa

La declaracin de interfaz externa, como se muestra en la Figura 3.2 tiene las siguientes caractersticas:
El nombre del tipo de bloque de funcin debe ser colocado en el centro del bloque principal,
como se muestra en Ramp en la Figura 3.2. Las entradas al bloque siempre se muestran
en el lado izquierdo del bloque; las salidas se muestran viniendo desde el lado derecho del
bloque.
Los eventos de entrada se representan entrando por el lado izquierdo de la parte superior del
bloque, los eventos de salida se muestran viniendo desde la derecha.
Los nombres de variables de entrada y de salida se muestran dentro del bloque junto a sus
conectores grficos asociados.
Los tipos de datos de entradas y salidas se muestran al final de la mano izquierda y al final
de la mano derecha de los conectores grficos respectivamente.
La representacin grfica proporciona informacin suficiente para ser utilizada como una declaracin de tipo formal. De hecho, un objetivo principal de la norma IEC 61499 es que las repre-
46
Figura 3.2: Declaracin grfica de tipo de bloque de funcin

sentaciones grficas siempre tengan una representacin textual precisa. Se prev que las herramientas de modelado grfico siempre sern capaces de convertir las formas grficas en representaciones
textuales y vice-versa.
Los eventos de entrada, tales como el evento E_Init representado en la Figura 3.2 que se muestra entrando por el encabezado del bloque de funcin, pueden, si es necesario, estar asociados
con una o ms entradas. Esto suele ser necesario cuando el bloque tiene que probar los valores
de entrada antes de ejecutar un algoritmo interno. En el ejemplo de bloque de funcin Ramp, las
entradas X0, X1, Cycle y Duration deben ser estables siempre que se produce un evento E_Init,
es decir, en el instante en que se inicializa el bloque. Del mismo modo, el valor del PV de entrada
ser muestreado cuando se produce el evento E_Run.
La asociacin de los eventos de entrada con los datos de entrada utiliza una construccin que
IEC 61499 indica como calificador WITH. En la representacin grfica esto se muestra usando
pequeos conectores cuadrados que unen el evento con sus datos asociados.
Tambin es posible asociar eventos de salida con ciertas variables de salida. Esto se utiliza para
caracterizar aquellas variables de salida que se han actualizado por un algoritmo interno y estn
listas en el instante en que el evento de salida se dispara. En el ejemplo de la funcin bsica de la
Figura 3.2, el evento de salida E_Ex0 se produce cuando el algoritmo Ramp interno ha actualizado
las salidas Out y Hold.
El mismo calificador textual WITH y la representacin grfica se utilizan para mostrar la asociacin entre los eventos de salida y sus datos de salida.
Los eventos pueden ser definidos para tener un tipo de evento opcional. Esto se proporciona
para que los bloques de funcin puedan ser diseados para aceptar slo ciertos tipos de eventos en
sus entradas de evento. Los tipos de eventos proporcionan una mayor robustez en el diseo. Esta es
una extensin lgica de la forma en que se utilizan los tipos de datos para aumentar la integridad
del diseo, permitindose slo la conexin de entradas y salidas que transportan datos compatibles.
En el ejemplo de la figura, la entrada E_Init slo puede aceptar eventos de inicializacin de tipo
Init_Event, por ejemplo, no sera posible conectar un evento de cierre de tipo E_stop a esta entrada
de evento.
Si a la entrada o salida de eventos del bloque no se le da un tipo de evento, se aplica por defecto
el tipo EVENT. Eventos de este tipo genrico EVENT se pueden conectar a cualquier otra entrada
de evento de tipo EVENT. Por el contrario, una entrada de evento de tipo EVENT puede recibir
eventos de cualquier tipo.
Tenga en cuenta que cada entrada y salida de un bloque de funcin bsico debe estar asociada
con al menos una entrada o salida de evento, respectivamente. Esto es porque siempre se requiere
al menos un evento para indicar cuando un valor de entrada es muestreado o cuando un valor de
salida ha cambiado. Otra forma de ver esto es considerar el suceso y sus datos asociados como un
47
tipo de mensaje que permite que un evento y sus datos sean pasados entre los bloques como un
conjunto coherente.
Una consecuencia de esta caracterstica es la implicacin de que el bloque debe tener un almacenamiento para mantener los valores de las entradas entre las muestras de eventos. Asimismo,
cuenta con almacenamiento para guardar los valores de las salidas entre los tiempos cuando se
disparan los eventos de salida. Existe siempre, por supuesto, la posibilidad de que un bloque pueda recibir eventos con los datos a una velocidad que es ms rpida que lo que el bloque puede
almacenar y luego procesar. La norma establece que, en tales casos, la funcin de programacin
subyacente debe priorizar la ejecucin del algoritmo del bloque de funcin de una manera que
asegure que tales situaciones de sobrecarga no se producirn.
Comportamiento Interno
Hay dos aspectos para la descripcin del comportamiento interno de un bloque de funcin
bsico: cuerpo del algoritmo y control de ejecucin del algoritmo. El bloque bsico contendr
generalmente uno o ms algoritmos. Cada algoritmo se invoca por la funcin de programacin de
recursos en respuesta a los eventos de entrada particulares que llegan a la interfaz de bloque. Al
ejecutarse el algoritmo, se procesan los datos de entrada y las variables internas para crear nuevos
valores para las variables internas y de salida. Cuando el algoritmo ha completado ciertas fases de
su ejecucin se pueden disparar eventos de salida para indicar que los datos de salida estn listo
y se pueden consumir por otros bloques. Cada algoritmo debe disparar al menos un evento de
salida para indicar que ha finalizado su ejecucin.
La norma IEC 61499 no define un lenguaje que se debe utilizar para las definiciones de algoritmos. Cualquier lenguaje de alto nivel se puede utilizar siempre y cuando un mapeo pueda ser
definido entre las variables de entrada y salida de datos, sus tipos de datos y las variables dentro del
lenguaje del algoritmo. Veremos ms adelante que el Texto Estructurado (ST) tal como se define
en la Norma IEC 61131-3 de lenguajes para PLC, y Java, son dos buenos ejemplos de lenguajes
de alto nivel que pueden ser usados para expresar el comportamiento de los algoritmos de bloques
de funcin.
Un aspecto importante del comportamiento de un bloque de funcin bsico se refiere a modelar
la relacin entre la ejecucin de eventos y de algoritmos. Esto se logra usando un concepto llamado
Tabla de Control de Ejecucin (ECC - Execution Control Chart). Al igual que otras caractersticas
del bloque, la ECC se puede definir grfica o textualmente.
Cada bloque de funcin bsico exige una ECC para definir lo siguiente:
los principales estados internos del bloque
cmo el bloque responder a cada tipo de evento de entrada
cules algoritmos se activan en respuesta a los eventos de entrada
cules eventos de salida se activan cuando se ejecutan los algoritmos.
La ECC es una forma de diagrama de transicin de estado que tiene muchas similitudes con la
grfica de Diagrama de Funcin Secuencial (SFC) de la norma IEC 61131-3. Sin embargo, como
tcnica de modelado de estado, su propsito es muy diferente y no se debe confundir con lenguajes
de programacin grfica como SFC.
En la Figura 3.3 se muestra un ejemplo de un ECC adecuado para el bloque de funcin Ramp
como se discuti anteriormente (vase la Figura 3.2). En este caso, la ECC muestra tres estados,
START, INIT y RAMP que corresponden a los tres estados principales del bloque. El estado START representa el estado de reposo del bloque cuando se est esperando para recibir
48
Figura 3.3: Tabla de Control de Ejecucin

Desde
START
INIT
START
RAMP
Hacia
INIT
START
RAMP
START
Transicin
E_Init (Evento)
1 (Siempre verdadero)
E_Run (Evento)
1 (Siempre verdadero)
Cuadro 3.2: Transiciones en el ECC de ejemplo

eventos. El estado INIT se produce mientras el bloque est ejecutando el algoritmo de inicializacin ALG_INIT. El estado RAMP existe mientras el algoritmo principal de rampa est en
ejecucin, es decir, ALG_RAMP.
La transicin entre estados se representa mediante expresiones booleanas que contienen variables de eventos y variables booleanas que son declaradas dentro del cuerpo del bloque de funcin.
Las variables de eventos proporcionan representaciones internas de los eventos de entrada y se
utilizan para describir las transiciones entre los estados. La Tabla 3.2 enumera las condiciones de
transicin para este ECC de ejemplo.
En este ejemplo, INIT y RAMP son estados transitorios que slo existen mientras se est
ejecutando un algoritmo. En bloques ms complejos, es posible que los estados representen modos
o estados fundamentales del bloque.
Caractersticas de la Tabla de Control de Ejecucin

La norma define una serie de caractersticas y reglas que se aplican al uso de grficos de control
de ejecucin (ECCs), que se resumen a continuacin:
Un bloque de funcin bsico siempre tendr exactamente un grfico de control de ejecucin,
que se define utilizando la sintaxis textual en la seccin de bloque de control de ejecucin de
la definicin de tipo de bloque de funcin.
Cada ECC debe tener un estado inicial que siempre se representa con una forma de doble
49
contorno.
Cualquiera de las formas redondas o rectangulares pueden ser utilizadas para representar los
estados dentro de la ECC. Nota: en este libro, las formas rectangulares se han utilizado para
representar estados ECC.
La ECC puede utilizar las entradas de evento representadas como variables de evento. Por
lo general, las transiciones entre estados se definen por expresiones lgicas utilizando las
variables de entrada de eventos.
La ECC tambin puede comprobar o modificar las salidas de eventos, una vez ms representadas en la ECC como variables booleanas de salida de eventos.
La ECC tambin puede probar, pero no modificar las variables booleanas declaradas dentro
del cuerpo del bloque de funcin. Esto permite al comportamiento de ECC para ser modificado en funcin de los estados internos del cuerpo del bloque de funcin.
Por ejemplo, un bloque de funcin puede tener dos modos principales tales como Manual
y Auto definidos por una variable booleana interna llamada ManualFlag. Ante la llegada
de un evento de entrada particular, la ECC podra poner a prueba ManualFlag e ir a los
estados correspondientes para invocar ya sea algoritmos manuales o automticos.
Expresiones de transicin que provocan un cambio de estado dentro del ECC normalmente
involucran variables de eventos de entrada. Sin embargo, estas expresiones tambin pueden
incluir variables que representan eventos de salida, los estados internos del bloque de funcin, y expresiones condicionales basadas en los valores de las variables de entrada y salida
principales del bloque.
Cada estado ECC puede tener cero o ms acciones. A modo de ejemplo, la Figura 3.4 muestra un estado MAIN que tiene dos acciones para llamar algoritmos CALC y FILTER;
los eventos de salida de disparo ExO_1 y ExO_2, respectivamente, cuando la ejecucin
se completa. Cada accin es normalmente asociada con un algoritmo y un evento de salida.
Cuando el estado est activo, se ejecutan todas las acciones definidas para el estado. Sin embargo, una accin puede tener un algoritmo nulo donde slo es necesario para desencadenar
un evento de salida. Tambin es posible tener acciones sin eventos de salida. Normalmente,
un estado tendr al menos una accin que tiene un evento de salida para sealar al mundo
externo de que ciertas salidas se han actualizado.
Es importante tener en cuenta que las condiciones de transicin dentro de un ECC no se prueban hasta que el estado anterior a la transicin est activo. As, a pesar de que un bloque de funcin
puede tener un muy complejo ECC con un gran nmero de transiciones entre los estados, la sobrecarga implicada en las transiciones de prueba puede ser pequea porque en cualquier momento
slo un estado estar activo.
Cabe destacar que el ECC est pensado principalmente para representar las relaciones entre los
eventos de entrada, ejecucin de algoritmo y el disparo de eventos de salida. No debe ser utilizado
para modelar el comportamiento de estado de aplicacin, por ejemplo, para modelar diversos modos de control. Los estados de aplicacin y el comportamiento relacionado deben definirse dentro
de los bloques de funcin propios algoritmos. Para una gran mayora de los bloques de funcin
bastante complejos, la ECC debe ser relativamente simple, con tan slo cuatro o cinco estados.
Ejemplo de Sintaxis Textual
50
Figura 3.4: Ejemplo de estado ECC

Consideremos el comportamiento requerido para un muy simple bloque de funcin Ramp, que
se utiliza para demostrar cmo el comportamiento puede ser modelado utilizando IEC 61499. Este
bloque de funcin Ramp mueve una salida OUT de un valor inicial dado por la entrada X0
a un valor objetivo X1 durante un momento dado en la entrada Duration. La entrada Cycle
define el tiempo transcurrido entre actualizaciones de la salida de Ramp. El bloque tambin comprueba si la salida supera el PV de entrada, en cuyo caso, la salida Hold se establece en true.
Se supone que el bloque Ramp se llama varias veces y a una tasa de actualizacin propuesta por el
tiempo Cycle, por ejemplo, puede estar configurado para ejecutarse cada 200 milisegundos.
Ya hemos revisado las dos vistas grficas de este bloque de funcin bsico: (i) la declaracin de
tipo de bloque de funcin grfico (ver Figura 3.2) y (ii) el Plan de Control de Ejecucin (vase la
Figura 3.3). La informacin que se muestra en estas dos figuras tambin se puede representar textualmente usando la sintaxis textual IEC 61499 que, junto con los algoritmos expresados mediante
el lenguaje de texto estructurado IEC 61131-3 (ST) proporcionan la definicin textual completa
del bloque Ramp de la siguiente manera:
Nota: se recomienda al lector que consulte la norma IEC 61499 PAS para una especificacin
completa de la sintaxis textual.
FUNCTION_BLOCK Ramp
(* Ramp function block type definition *)
EVENT_INPUT
E_Init WITH X0,X1,Cycle,Duration;
E_Run WITH PV;
END_EVENT
EVENT_OUTPUT
E_Rdy;
E_Ex0 WITH Out,Hold;
END_EVENT
EC_STATE
START; (* Initial state *)
INIT: ALG_INIT -> E_Rdy;
RAMP: ALG_RAMP -> E_Ex0;
51
END_STATES
EC_TRANSITIONS
START TO INIT
INIT TO START
START TO RAMP
RAMP TO START
END_TRANSITIONS
:=
:=
:=
:=
E_Init;
1;
E_Run;
1;
VAR_INPUT
X0 : REAL;
X1 : REAL;
Cycle : TIME;
Duration : TIME;
PV : REAL;
END_VAR
VAR_OUTPUT
Out : REAL;
Hold : BOOL
END_VAR
VAR
T : TIME; (* Time into Ramp *)
END_VAR
(* Algorithm definitions *)
ALGORITHM ALG_INIT IN ST:
T := T#0s;
END_ALGORITHM
ALGORITHM ALG_RAMP IN ST:
IF T < Duration THEN
OUT := X0 + (X1-X0)*
TIME_TO_REAL(T)/TIME_TO_REAL(Duration);
T := T + Cycle;
Hold := PV > Out;
END_IF;
END_ALGORITHM
END_FUNCTION_BLOCK
El comportamiento del bloque de funcin Ramp est completamente definido en esta declaracin de tipo. A la entrada del evento de inicializacin E_Init, los valores de entrada que caracterizan el comportamiento de Ramp, es decir, X0, X1, Duration y Cycle, son almacenados.
El estado INIT se activa causando que el algoritmo de inicializacin ALG_INIT sea invocado. Esto restablece la variable de temporizador interno T. El evento de salida E_rdy se
activa cuando el algoritmo de inicializacin ha terminado, tal como se define en las declaraciones
EC_STATE.
52
Del mismo modo, cuando se recibe el evento de de ejecucin E_Run, una transicin de estado RAMP se produce haciendo que el algoritmo ALG_RAMP se ejecute. Esto calcula el
nuevo valor de salida para OUT en base a los valores de X0, X1, Cycle y Duration y el tiempo
T de Ramp. El algoritmo tambin comprueba si la salida supera el valor de entrada de PV, en
cuyo caso la salida Hold se establece en true.
Comportamiento de Instancias de Bloques de Funcin Bsicos

Usando cualquiera de las declaraciones textuales o grficas, es posible definir instancias, es
decir, copias de bloques de funciones bsicos, creados a partir de definiciones de tipo de bloque
de funcin bsicos. Una instancia de un tipo de funcin bsico tendr un comportamiento que
se define por su definicin de tipo, pero tendr su propio almacenamiento para sus variables de
entrada y salida, variables de evento y para mantener el estado de la ECC. En otras palabras, el
estado de cada instancia de funcin bsica es totalmente independiente de las otras instancias.
El recurso, en el cual un bloque de funcin bsico ha sido declarado, inicializar cada instancia de funcin bsica antes de activar el bloque por primera vez. Esta inicializacin incluye lo
siguiente:
El valor de cada variable de entrada, de salida e interna, se establece en un valor inicial tal
como se define en la declaracin que figura en la definicin de tipo bloque. Cuando no se
haya determinado un valor de inicializacin, se tomarn los valores por defecto para el tipo
de datos particular. Por ejemplo, las entradas booleanas que no tienen un valor inicial definido siempre se inicializarn con FALSE, que es el valor inicial por defecto para variables
booleanas (BOOL).
Todas las variables de entrada y salida de eventos, tal como se utilizan dentro del ECC, se
inicializarn con FALSE.
Se inicializan los estados internos del algoritmo. Por ejemplo, si un algoritmo se ha definido
utilizando el lenguaje grfico de funcin secuencial (SFC) de la norma IEC 61131-3, el
algoritmo se resetear modo que iniciar en el paso inicial de SFC.
El estado inicial de la instancia de ECC se establecer activo; todos los otros estados dentro
de la ECC estarn inactivos.
Ejecucin de Algoritmos
La norma define de manera muy precisa la manera en que los eventos que llegan a las entradas
de evento de los bloques de funcin desencadenan cambios de estado dentro del ECC que luego, a
su vez, causan la programacin de algoritmos de bloque de funcin por el recurso. Los principales
aspectos de este comportamiento se resumen de la siguiente manera:
Las variables que almacenan recursos y actualizan eventos para registrar la llegada de los
eventos de entrada en la interfaz de la instancia de bloque de funcin. REVISAR XXXXXXX
El recurso a continuacin slo permite un cambio de estado dentro del ECC si: (a) que se
hayan recibido eventos de entrada, (b) la condicin de transicin que va desde el estado
activo actual (es decir, del Estado predecesor de la transicin) se ha cumplido y (c) todos los
algoritmos invocados por las acciones en el estado actual han cesado la ejecucin.
53
Figura 3.5: Mquina de Estados Operacional ECC

Una consecuencia de este modelo IEC 61499 de ejecucin del algoritmo es que si hay mltiples
apariciones de un evento de entrada antes o durante la ejecucin del algoritmo, los eventos se
pueden perder. Por esta razn, en la norma se indica que el recurso debe proporcionar medios para
detectar cuando existen tales condiciones de sobrecarga y tomar las medidas apropiadas para la
recuperacin de errores.
Tenga en cuenta que debe ser siempre posible, por diversos medios, crear un modelo en el que
se evitan las sobrecargas de eventos, por ejemplo, mediante la creacin de bloques para proporcionar colas de eventos y datos, o por la realimentacin de la carga de informacin a los bloques de
ms arriba para modificar las tasas de generacin de salida de eventos.
El grfico de control de ejecucin (ECC) de una instancia de bloque de funcin bsico puede
en todo momento estar en uno de tres estados primarios con respecto a su relacin con la funcin
de programacin de recursos. Estos forman una mquina de estados simple como se muestra en la
Figura 3.5 y se describe en la Tabla 3.3.
La funcin de programacin de recursos lleva a cabo las siguientes operaciones sobre transiciones asociadas con el cambio entre estos estados: REVISAR XXXX
s0 a s1 Las variables de eventos de entrada asociadas con los eventos de entrada que estn
llegando se establecen en true y las variables de entrada asociadas con los eventos que
utilizan el constructor WITH se muestrean y se almacenan dentro del bloque.
s1 a s2 Los recursos programan los algoritmos del bloque a ejecutar, es decir, el recurso
comienza a ejecutar algoritmos asociados al nuevo estado ECC activo. Durante la ejecucin
del algoritmo, diversas variables de evento de salida pueden establecerse en true. Durante
este tiempo, el algoritmo tpicamente actualizar los valores de diversas variables de salida.
REVISAR XXXX
s2 a s1 El recurso detecta que el/los algoritmo/s ha/n completado su ejecucin.
s1 a s0 El recurso dispara eventos de salida asociados a variables de evento de salida segn
lo establecido durante la ejecucin del algoritmo. Todas las variables de salida que se han
definido como WITH un evento de salida determinado ya est listo para ser muestreado por
los bloques conectados externamente. Variables de evento de entrada tambin se borran al
volver al estado de reposo s0, listo para la llegada de los nuevos eventos. REVISAR XXXX
54

Estado
s0
Condicin
Libre
s1
Programando
algoritmos
s2
Esperando que se
completen los
algoritmos
Notas
En este estado, nada en el bloque
se est ya sea ejecutando o
pendiente de ejecucin. El bloque
est a la espera de la llegada de los
eventos de entrada.
Durante el estado S1, el recurso ha
detectado que un evento de entrada
ha llegado y va a programar el/los
algoritmo/s del bloque cuando
otros algoritmos activos o de
mayor prioridad de otros bloques
hayan terminado.
El recurso ha iniciado la ejecucin
del/de los algoritmo/s
seleccionado/s del bloque y ahora
espera hasta que el/los algoritmo/s
haya/n terminado.
Cuadro 3.3: Estados primarios ECC

La manera en la que un recurso realmente ejecuta un algoritmo particular de un bloque de funcin
bsico es en cierta medida dependiente de la implementacin. Como se dijo anteriormente, un
algoritmo puede ser expresado usando una variedad de lenguajes y por lo tanto su comportamiento
no se considera dentro del alcance de la norma IEC 61499. Sin embargo, la implementacin del
algoritmo debe tener las siguientes caractersticas:
Variables de entrada y de salida y variables de eventos deben asignarse con precisin y sin
ambigedades a las variables dentro del algoritmo.
El algoritmo debe ser tan encapsulado que slo puede leer y escribir variables dentro del
cuerpo del bloque de funcin.
El tiempo de ejecucin del algoritmo debe ser corto en relacin con la tasa esperada de llegada de eventos que activarn su ejecucin. Es evidente que si un algoritmo est diseado
para ejecutar cada 100 milisegundos y va a ser activado utilizando un evento de 100 milisegundos de reloj, su duracin de ejecucin, en el peor caso, debe ser muy por debajo de 100
milisegundos para permitir que otros algoritmos se ejecuten.
El algoritmo debe tener un estado inicial bien definido, el cual puede entrar cuando el bloque
est listo primero para su ejecucin por el recurso. REVISAR XXXX
3.4.
Definiciones Para Bloques de Funcin Compuestos
Los bloques de funcin compuestos proporcionan un medio para la construccin de bloques

ms complejos a partir de bloques compuestos bsicos y otros ms pequeos en forma jerrquica. La definicin de tipo de bloque de funcin compuesto contiene declaraciones de instancias
de bloques de funcin de los tipos seleccionados que estn conectados por conexiones de datos
y eventos. Lo que respecta a los bloques estndar que se utilizan dentro de un bloque compuesto
como bloques de funcin de componentes. Las conexiones de datos entre los bloques de componentes definen la transferencia de valores de datos entre salidas de los bloques a las entradas,
3.4. DEFINICIONES PARA BLOQUES DE FUNCIN COMPUESTOS
55
mientras que las conexiones de eventos definen el orden de ejecucin de los algoritmos dentro de
los bloques. REVISAR XXXXX
Reglas para la Especificacin de Tipo de Bloque Compuesto

Hay una serie de reglas y restricciones respecto a la especificacin de las definiciones de tipos de bloques de funcin compuestos, particularmente con respecto a la conexin de las entradas
y salidas externas de eventos y datos con los bloques de los componentes internos. Estas reglas
surgen porque los eventos no pueden ser lanzados directamente, es decir, debe haber una relacin
uno a uno entre una salida de evento y una entrada de evento. Es posible hacer que un evento
genere mltiples eventos simultneos mediante un bloque de funcin E_SPLIT; lo que es uno de
los bloques de funcin de eventos especiales de la norma IEC 61499 discutidos en el Captulo 5.
Por el contrario, las entradas de datos se pueden lanzar permitiendo una salida de datos nica para
impulsar muchas entradas de datos diferentes.
Reglas para las Conexiones de Eventos

1. Cada entrada de evento compuesto debe estar conectado a exactamente un evento de entrada
de un bloque de funcin componente interno o debe ser enrutado a una salida de evento
de bloque compuesto. Es decir, no es posible que una entrada de evento sea conectada directamente a mltiples entradas de eventos en diferentes bloques de componentes. REVISAR
XXXX
Nota: los bloques de funcin de eventos tales como E_SPLIT se pueden utilizar para crear
eventos fan-out de un nico evento de entrada si es necesario, vase el captulo 5. REVISAR
XXXX
2. Cada entrada de evento componente debe estar conectado a exactamente un evento de salida
de componente o a una entrada de evento de bloque compuesto.
3. Del mismo modo, cada salida caso de un bloque de funcin del componente slo puede ser
conectado a exactamente un evento de entrada de componente o a una salida de eventos
compuestos.
4. Cada evento de salida del bloque compuesto debe estar conectado a exactamente un evento
de salida de un bloque funcin componente o venir directamente de un evento de entrada
compuesto.
Nota: Algunos eventos de entrada y salida de bloque componente pueden permanecer desconectados. En tales casos, no se ejecutarn los algoritmos asociados exclusivamente con los
eventos de entrada no conectados.
Reglas para las Conexiones de Datos

Las siguientes reglas se aplican a las conexiones entre las entradas y salidas de datos compuestos y las entradas y salidas componentes.
1. Cada entrada de datos del bloque compuesto puede ser (a) conectada a una o varias entradas
de datos de bloques de componentes internos, o (b) conectada directamente a travs de una
o ms salidas de los bloques de funcin compuestos o ambas.
56

2. Cada entrada de datos de bloque componente puede ser o bien (a) no conectada, o (b) conectada a una salida de otro bloque de componente, o (c) conectada a la entrada de datos de
bloque compuesto. Es evidente que la norma no permite una entrada de bloque componente
que se conecte a varias salidas debido a que la entrada tendr entonces un valor indeterminado.
3. Cada salida de datos de bloque componente puede ser (a) no conectada, o (b) conectada a
una o ms entradas de datos de los componentes, o tambin (c) conectada a una o ms salidas
de datos compuestos.
4. Cada salida de datos compuesta debe estar conectada o bien a (a) una salida de datos componente, o (b) enrutada a una entrada de datos compuesta.
Ejemplo de Bloque Compuesto

Considere el ejemplo de bloque de funcin representado en la Figura 3.6 que se ha elegido
para demostrar muchas de las caractersticas de bloques de funcin compuesto. La figura muestra
el cuerpo grfico de un bloque compuesto representado como una red de bloques de funcin unidos
entre s para formar un nuevo bloque. En este caso, un bloque de funcin componente adicional
del tipo Compare, y el bloque de funcin Event E_MERGE, se han utilizado para extender la
funcionalidad del bloque de funcin Ramp para formar un generador de diente de sierra.
Tenga en cuenta que Ramp1 es una instancia del bloque bsico Ramp como se describi en
la seccin anterior de este captulo. El nombre de la instancia de cada bloque de componente se
muestra justo encima del contorno de cada bloque en el cuerpo grfico.
La interfaz externa de este nuevo bloque se muestra en la Figura 3.7. Tenga en cuenta que tiene
el mismo aspecto que un bloque de funcin bsico. De hecho, desde un punto de vista externo,
no es posible distinguir entre un bloque bsico y uno compuesto slo desde la interfaz externa del
bloque.
Ahora vamos a revisar el comportamiento de este bloque y mostrar cmo se ha modelado como
un bloque de funcin compuesto. El propsito de este bloque es proporcionar un valor de salida
que sigue un perfil diente de sierra como se muestra en la Figura 3.8, es decir, la salida aumenta
repetidamente desde 0 a un valor objetivo y, a continuacin, restablece y se inicia de nuevo desde
0.
El bloque se inicializa utilizando un evento de inicializacin en el evento de entrada E_Init en
este punto, los valores de entrada para las entradas X0, X1, Cycle, y Duration se almacenan dentro
de las variables de entrada de RAMP1. En este ejemplo, X0 y X1 se fijan en los valores de 0 y
1000 por constantes definidas dentro del cuerpo del bloque compuesto, estableciendo efectivamente los lmites para la salida Out de Ramp. Los valores Duration y Cycle provienen de los valores
proporcionados en la interfaz externa del bloque y definen las caractersticas de temporizacin de
la forma de onda diente de sierra.
Despus de la inicializacin, el bloque est listo para recibir un flujo regular de eventos en
la entrada de evento E_Run. Cada evento en la entrada E_Run dispara el bloque RAMP1 para
incrementar su salida Out hasta el lmite superior establecido por X1. Cada vez que el algoritmo
interno RAMP1 completa su ejecucin, un evento de salida E_ExO se pasa al bloque Compare1
que luego comprueba el valor de Out contra el valor de Target, es decir, que compara las
entradas X e Y. Despus de la ejecucin, el bloque Compare entrega el valor de X en la salida XO
y temas de evento E_Ex0 (REVISAR XXXX). Finalmente, cuando el valor Ramp1.Out alcanza el
valor Target del bloque Compare, detecta que la entrada X es mayor que la entrada Y, y activa
su evento de salida E_GT. Este evento se realimenta al bloque Merge1, que produce un nuevo
evento de inicializacin para el bloque RAMP1. El bloque RAMP1 se re-inicializa y la salida se
57
Figura 3.6: Bloque de Funcin Compuesto Cuerpo Grfico

restablece a 0. Mientras el bloque contina recibiendo eventos en su entrada de evento E_Run,
continuar para generar la forma de onda de diente de sierra.
La pendiente del perfil diente de sierra se puede cambiar por la reinicializacin del bloque
con un evento de inicializacin en la entrada de evento E_Init emitida con un valor de duracin
diferente. Merge1 es una instancia de uno de los bloques de funcin de eventos estndar que se
describen en el captulo 5 y proporciona un medio para mltiples eventos que se fusionaron en una
nueva corriente de eventos. En este caso Merge se utiliza para permitir que el bloque Ramp sea
inicializado ya sea por un evento externo en la entrada de evento E_Init o desde un evento generado
internamente procedente del bloque Compare.
Uso del Constructor WITH

Es posible mostrar grficamente que las entradas y salidas de datos estn asociadas con eventos
de entrada y de salida particulares, respectivamente, mediante el uso del constructor WITH. Por
ejemplo, en la Figura 3.7, se muestra el evento de inicializacin E_Init asociado con las entradas
Cycle y Duration. Sin embargo, a diferencia del comportamiento del bloque de funcin bsico, el
constructor WITH no indica que las entradas se almacenan en variables que forman parte de la
interfaz del bloque. Con bloques compuestos, WITH es un medio para mostrar que se requieren
entradas para estar listo cuando se produce un evento de entrada particular. Los valores de entrada
son en realidad muestreados y almacenados en las variables de entrada de bloques de los compo-
58
Figura 3.7: Bloque de Funcin Compuesto Interfaz Externa
Figura 3.8: Perfil Diente de Sierra

nentes internos. Del mismo modo, con eventos de salida, el uso del constructor WITH muestra que
los valores de salida estn listos cuando se produce un evento en particular, por ejemplo, en la Figura 3.7, la salida de datos Out est lista cuando se produce el evento de salida E_Ex0. REVISAR
XXXX
Tenga en cuenta que la norma estipula que todos los datos de entrada y de salida de la declaracin de un bloque de funcin compuesto son requeridos para ser asociado con al menos un
constructor WITH. Para las entradas, esto asegura que su valor es muestreado por al menos un
evento; para las salidas se asegura de que hay un punto claro en el tiempo cuando la salida se
actualiza.
Ejecucin de Bloques de Funcin Compuestos

Las instancias de bloques compuestos se pueden crear como parte de las redes de bloques
de funciones existentes en un recurso y pueden existir en el nivel superior o ser utilizados en la
definicin de otros bloques de funciones compuestos ms grandes. En todas las situaciones, la
ejecucin del bloque compuesto est determinada por la llegada de eventos en sus entradas de
evento. La norma define las siguientes reglas que determinan cmo se manejan los eventos:
1. Si un evento de entrada del bloque compuesto se enruta a travs de directamente a una salida
59
de evento bloque compuesto, a continuacin, una aparicin de un evento en la entrada de

evento va a generar un evento en la salida de eventos del bloque. REVISAR XXXXXX
2. Si un evento de entrada est conectado a un bloque de funcin de componente interno, a
continuacin, la aparicin de un evento de entrada dar lugar a un evento llegando al componente de entrada de evento. El bloque componentes, a continuacin, programar para la
ejecucin por la funcin de programacin de los recursos.
3. Del mismo modo, si un evento de salida de un bloque componente est conectado con el
evento de entrada de otro bloque componente, entonces, un evento de salida del primero
har que el segundo bloque sea programado para su ejecucin.
4. Si un evento de salida compuesto est conectado a un evento de salida del bloque de componente entonces se generar el evento de salida compuesto cuando el bloque componente
produce un evento de salida.
Estas sencillas normas proporcionan una asociacin intuitiva y lgica entre eventos y la ejecucin
del bloque. En esencia, los eventos se propagan a travs de la red de bloques de funcin componentes que progresan desde la entrada hacia la salida del bloque compuesto.
Ejemplo de Sintaxis Textual de Bloque de Funcin Compuesto

Hasta ahora nos hemos concentrado en la representacin grfica de un bloque de funcin compuesto. Al igual que con bloques de funcin bsicos, la norma Sintaxis Textual IEC 61499 tambin se puede utilizar para describir la estructura y redes internas que forman bloques de funcin
compuesto. Por ejemplo, el bloque diente de sierra como se muestra en la Figura 3.6 se puede
representar por la siguiente descripcin textual:
FUNCTION_BLOCK SAWTOOTH
(* Event definitions *)
EVENT_INPUT
E_RUN WITH TARGET;
E_INIT WITH CYCLE, DURATION;
END_EVENT
EVENT_OUTPUT
E_RDY;
E_ExO WITH OUT;
END_EVENT
(* Variable definitions *)
VAR_INPUT
CYCLE : TIME;
DURATION : TIME;
TARGET : REAL;
END_VAR
VAR_OUTPUT
OUT : REAL;
END_VAR
(* Function blocks *)
FBS
RAMP1 : RAMP;
COMPARE1 : COMPARE;
60
MERGE1 : E_MERGE;
END_FBS
(* Event connections *)
EVENT_CONNECTIONS
E_RUN TO RAMP1.E_RUN;
E_INIT TO MERGE1.EI1;
MERGE1.EO TO RAMP1.E_INIT;
RAMP1.E_Rdy TO E_Rdy;
RAMP1.E_ExO TO E_ExO;
COMPARE.E_GT TO MERGE1.EI2;
END_CONNECTIONS
(* Data connections *)
DATA_CONNECTIONS
0.0 TO RAMP1.X0;
1000.0 TO RAMP1.X1;
CYCLE TO RAMP1.CYCLE;
DURATION TO RAMP1.DURATION;
RAMP1.OUT TO COMPARE1.X;
TARGET TO COMPARE1.Y;
Compare1.X0 TO OUT;
END_CONNECTIONS
END_FUNCTION_BLOCK;
El formato de texto es ms bien como una lista para construir un circuito electrnico. En l
se describen todas las entradas y salidas de eventos y datos, los bloques de funcin internos y las
conexiones de eventos y datos. Cada parte de la definicin es introducida por una palabra clave de
bloque, por ejemplo, EVENT_INPUT ... END_EVENT define todos los eventos de entrada para
el bloque, de manera similar DATA_CONNECTIONS ... END_CONNECTIONS define todas las
conexiones de datos entre la interfaz externa y bloques internos.
La Sintaxis Textual ha sido desarrollada para formar un formato genrico y portable que se
puede utilizar para expresar la estructura de un bloque compuesto. No expresa directamente los aspectos algortmicos de la conducta del bloque, pero s define sin ambigedades cmo se construye
el bloque desde el cual su comportamiento puede ser deducido. De hecho, actualmente se estn
desarrollando herramientas de software que puede traducir automticamente entre las representaciones grficas y textuales.
3.5.
Definiendo Subaplicaciones
Una subaplicacin puede considerarse como una forma especial de bloque de funcin compuesto que est diseado para ser distribuido. Es decir, puede correr opcionalmente en ms de
un recurso. Tiene una estructura similar a un bloque compuesto, pero algunas de las normas relativas al uso de los datos y eventos son relajadas. Un tipo de bloque de funcin subaplicacin slo
se puede utilizar dentro del cuerpo de otras subaplicaciones ms grandes y dentro de aplicaciones
completas. Sin embargo, un tipo subaplicacin s puede ser definido mediante bloques de funcin
compuestos, bsicos y otras subaplicaciones.
La principal caracterstica de contraste de una subaplicacin en comparacin con un bloque de
funcin compuesto es que opcionalmente se puede ejecutar en mltiples recursos. Recuerde que
los bloques bsicos y compuestos slo se pueden ejecutar en el mismo recurso, es decir, no es
posible dividirlas en partes que pueden funcionar con diferentes recursos. Una subaplicacin, sin
3.5. DEFINIENDO SUBAPLICACIONES
61
embargo, puede funcionar por un recurso o ser distribuido de manera que las diferentes partes se
ejecutan en diferentes recursos, en otras palabras, es distribuible.
Una forma de considerar una subaplicacin es que sta representa una seccin de red de bloques
de funcin reutilizable. Sera tpicamente utilizado para definir un arreglo de bloques de funcin
y las conexiones que se pueden volver a utilizar en diferentes configuraciones de red. En muchos
sentidos una definicin de tipo subaplicacin se asemeja a una macro de software, ya que permite
una solucin particular en forma de una red de bloque de funcin para ser fcilmente copiado.
REVISAR XXXXXXX
Por ejemplo, considere un bloque subaplicacin que proporciona un lazo de control de temperatura que consiste en un bloque de entrada analgica, un bloque de control PID y un bloque de
salida analgica tal como se muestra en la Figura 3.9a. Tpicamente, esto se puede utilizar para
controlar la temperatura de un dispositivo, por ejemplo, un recipiente de calentamiento u horno.
La funcin principal de este lazo de control es para (i) medir la temperatura actual, (ii) comparar
su valor con respecto al setpoint o temperatura deseada y luego (iii) ajustar un valor de salida que
acciona un dispositivo de calentamiento para corregir la temperatura. Estas tres funciones son mapeadas a tres bloques de funciones componentes que forman la subaplicacin. El bloque Input1
lee el valor actual de un sensor externo. El bloque PID1 proporciona un algoritmo a PID2 para
comparar la medida (PV) y los valores de setpoint y crear el valor de salida. El bloque Output1
toma el valor creado por el bloque PID y lo transfiere al actuador externo.
Input1 y Output1 se construirn como bloques de funcin compuestos y cada uno requiere
por lo menos un bloque de funcin de interfaz de servicio para proporcionar una interfaz con el
controlador subyacente con el fin de leer los valores de entrada y salida (E/S) del hardware del
controlador. Los bloques de funcin de interfaz de servicio son una forma especial de bloque que
proporciona diferentes interfaces con el dispositivo fsico o el sistema de comunicaciones y se
discuten en el captulo 4.
La Figura 3.9b muestra cmo la subaplicacin TempControl podra ser ejecutada dentro de
un simple controlador para proporcionar control de temperatura de lazo cerrado de un recipiente
calentado usando una camisa de vapor. La entrada a la subaplicacin TempControl es un valor de
temperatura que se lee desde un sensor tal como un termopar; la salida de la subaplicacin acciona
algn tipo de actuador, tal como una vlvula de vapor, para modificar el calentamiento.
Note que en este ejemplo, la subaplicacin TempControl es en realidad parte de una aplicacin
Single_Vessel_Control que ha sido declarada dentro de un solo recurso IEC 61499, es decir, todos
sus bloques de funcin se ejecutan en el mismo recurso.
Esta subaplicacin tiene dos entradas de evento, E_Init y E_Run. E_Init se utiliza para inicializar los bloques componentes internos. Se dispara el bloque PID para ejecutar y leer las variables
de entrada, es decir, el valor de la entrada Setpoint que se lee y se almacena en el PID. Esto define
la temperatura deseada a la que el lazo de control se estabilizar. En general, un algoritmo PID requerir un gran nmero de parmetros, tales como constantes de tiempo para las acciones integral
y derivativa. Estos no se muestran con el fin de mantener el ejemplo sencillo pero se inicializan en
la misma forma que el Setpoint. El evento E_Run se propaga a travs de la subaplicacin y hace
que el lazo de control actualice su salida externa de acuerdo con el valor calculado por el algoritmo
PID. En este ejemplo, podemos suponer que otro bloque de funcin de temporizacin dentro de
la aplicacin proporciona un flujo regular de eventos, a decir intervalos de 100 milisegundos en la
entrada de evento E_Run, para asegurar que el bloque TEMPCONTROL se invoque regularmente. Esto asegurar que la temperatura se mide a una tasa de barrido dada y su valor propagado a
la PID1, que a su vez crea un nuevo valor de salida para modular la salida de calor. REVISAR
XXXXXXX
62
(a) Definicin de subaplicacin para control de temperatura
(b) Aplicacin para control de temperatura
Figura 3.9: Ejemplo de Subaplicacin
Reglas para la Especificacin de Tipo Subaplicacin

Las reglas para la construccin de una subaplicacin son las siguientes:
1. Una instancia de una subaplicacin slo puede ser declarada dentro de otras definiciones de
tipo subaplicacin o con una aplicacin.
2. El constructor WITH no se utiliza en las definiciones de tipo subaplicacin porque la asociacin entre los eventos y los datos depender de cmo se distribuye la subaplicacin entre
los recursos.
3. En la sintaxis textual, las variables de entrada y salida a subaplicaciones se declaran usando
los constructores VAR_INPUT y VAR_OUTPUT pero, como con los bloques de funcin
compuestos, esto no implica que el almacenamiento se haya creado para estas variables. Todos los valores de las entradas y salidas a subaplicaciones se almacenan en las interfaces
63
internas de los bloques componentes.
Reglas para la Ejecucin de Subaplicacin

Las instancias de subaplicaciones pueden ser declaradas dentro de las aplicaciones y tambin
dentro de otras subaplicaciones. Sin embargo, una instancia de una subaplicacin es bastante diferente a una instancia de un bloque de funcin compuesto en que lo que realmente representa una
copia de un conjunto de bloques de funcin y sus interconexiones. En este sentido, una subaplicacin puede ser comparada con una macro de software o un patrn grfico.
La norma define las siguientes reglas sobre cmo ejecutar subaplicaciones:
1. Los eventos pueden ser enrutados directamente a travs de la subaplicacin, de modo que un
evento llegando a una entrada de evento activar inmediatamente un evento en la salida de
evento.
2. Cada entrada de evento que no se enruta directamente debe estar conectada a una entrada
de evento de un bloque componente interno. En este caso, cuando el evento llega a la entrada de evento de la subaplicacin el bloque componente interno recibir un evento y ser
programado para su ejecucin.
3. Como un bloque componente se ejecuta va a producir uno o ms eventos de salida. Estos, a
su vez disparan la ejecucin de otros bloques componentes a los que estn conectados en la
subaplicacin.
4. Las salidas de eventos de subaplicacin que no se enrutan directamente desde las entradas
de evento deben estar conectada a un evento de salida de un bloque de componente. Cuando
el bloque componente asociado se ejecuta y genera un evento de salida, el evento se propaga
a travs de la salida de evento de subaplicacin.
Ejemplo de Subaplicacin Distribuida

Hasta ahora hemos considerado subaplicaciones que se ejecutan en un solo recurso. Una caracterstica significativa de la norma IEC 61499 es la capacidad de reordenar aplicaciones y subaplicaciones para que puedan proporcionar la misma funcionalidad y, sin embargo, ejecutarse sobre
diferentes recursos en diferentes arreglos de distribucin. Subaplicaciones tales como TEMPCONTROL, como se muestra en la Figura 3.9, se pueden dividir en fragmentos de red de bloques de
funcin ms pequeos que se ejecutan en diferentes recursos. En el caso de TEMPCONTROL las
siguientes disposiciones podran ser consideradas:
1. todos los bloques se ejecutan en un recurso, es decir, una configuracin no distribuida
2. los bloques Input1, PID1 y Output1 se ejecutan en diferentes recursos, es decir, una configuracin totalmente distribuida
3. Input1 se ejecuta en un recurso, mientras que los bloques PID1, Output1 se ejecutan en un
segundo recurso, es decir, una configuracin de recursos divididos
4. los bloques Input1, PID1 se ejecutan en un recurso mientras que Output1 se ejecuta en un
segundo recurso, es decir, una configuracin alternativa de recursos divididos.
64
Figura 3.10: Ejemplo de Subaplicacin Distribuida
La Figura 3.10 muestra el cuarto arreglo de distribucin donde los bloques Input1 y PID1 para la
entrada analgica y el algoritmo PID se ejecutan sobre un recurso Resource1 y la salida analgica Output1 se ejecuta en un segundo recurso Output1. En la prctica, esta disposicin significa
que la subaplicacin TEMPCONTROL se puede ejecutar en dos recursos independientes ubicados
en diferentes controladores. La Figura 3.10 muestra una posible configuracin fsica del sistema
que podra ser considerada. Se muestran dos controladores A y B unidos por algn tipo de sistema
de comunicaciones, por ejemplo utilizando una red Fieldbus o Ethernet. La entrada analgica se
conecta al controlador A, mientras que el actuador est conducido desde el otro controlador B.
La subaplicacin est distribuida en dos controladores, pero la funcionalidad interna est siendo
determinada por los bloques de funcin definidos en la definicin de tipo subaplicacin TEMPCONTROL original.
Se contempla que un diseador del sistema tendr libertad para seleccionar la disposicin de
distribucin apropiada para una subaplicacin de acuerdo con los requisitos de diseo del sistema. La disposicin de distribucin seleccionada por un diseador depender de muchos factores,
65
Figura 3.11: Aplicacin distribuida de control de temperatura

incluyendo: (i) si un recurso es capaz de soportar tipos particulares de bloques de funcin, (ii) la
carga y el desempeo de un recurso en particular, y (iii) la latencia y fiabilidad de servicios de
comunicaciones entre los recursos.
Cabe sealar que algunos bloques de funcin adicionales Pub1 y Sub1 se han aadido a la
subaplicacin TempControl distribuida como se muestra en la Figura 3.11. Estos son otros ejemplos de bloques de funcin de interfaz de servicio que se describen con ms detalle en el captulo 4
y proporcionan una interfaz entre bloques de funcin dentro de un recurso y el sistema de comunicaciones del recurso. Pub1 es un bloque de funcin Publicador que se utiliza para transmitir uno o
ms valores de datos a travs de un enlace de comunicaciones a uno o ms recursos externos dentro
de otros controladores. Simplemente enva valores utilizando una direccin de identificacin dada.
SUB1, un bloque de funcin Suscriptor, se utiliza dentro del segundo recurso para recibir los valores enviados por Pub1. En este caso slo hay un suscriptor, pero es posible tener configuraciones
en las que haya mltiples suscriptores.
El ejemplo ha utilizado bloques de interfaz de servicio Publicador/Suscriptor pero otros bloques
que ofrecen diferentes tipos de modelos de comunicacin como Solicitante/Respuesta tambin se
discuten en la norma. En este ejemplo en particular, el modelo de Publicador/Suscriptor se ha usado
porque no hay ningn requisito en este diseo simple para cualquier retroalimentacin al bloque
PID1 en cuanto a si la transmisin del valor de la salida analgica ha sido exitosa. El bloque
PID1 continuar para emitir nuevos valores a su salida, independientemente de los problemas
de comunicacin ms abajo. Es evidente que en un diseo completo habra un requerimiento de
control de las comunicaciones y comprobacin de si lazo completo de control est funcionando
correctamente. Esto se puede lograr mediante el uso de, por ejemplo, una solicitud y modelo de
comunicacin de respuesta o retroalimentacin de la seal del bloque Output1.
Tenga en cuenta que cuando una subaplicacin se re-dispone para funcionar en diferentes recursos, generalmente se necesitan parmetros adicionales para el sistema de comunicaciones. Esto
normalmente incluye detalles tales como direcciones de recursos y parmetros de enrutamiento de
red. Esta informacin generalmente se pasa como parmetros a los bloques de funcin de interfaz
66
de servicio que estn manejando las comunicaciones entre los recursos. Cabe destacar que la norma IEC 61499 no define protocolos de comunicacin o direccionamiento estndar o parmetros
relacionados con las comunicaciones. Pero s proporciona un marco y una arquitectura para la definicin de los servicios como las comunicaciones con bloques de funcin de interfaz de servicio.
3.6. Resumen
En este captulo hemos cubierto los aspectos ms importantes de la definicin de tipo de bloque de funcin. Hemos examinado cmo las definiciones de tipo se pueden utilizar para crear
instancias de bloques de funcin. A su vez, hemos visto cmo Instancias de Bloques de Funcin
pueden ser utilizadas en nuevas definiciones de tipos para construir jerrquicamente bloques de
funcin de funcionalidad an mayor. Aunque los diseos se pueden crear grficamente, hemos
observado que la norma tambin define una sintaxis textual formal que puede ser utilizada como
una representacin alternativa.
Para resumir:
Hay tres categoras de bloque de funcin: (i) bsico, (ii) compuesto y (iii) subaplicacin.
El comportamiento de un bloque de funcin bsico se define en trminos de un grfico de
control de ejecucin (ECC) y uno o ms algoritmos.
Bloques de funcin compuestos se definen en trminos de una red de bloques de funcin
componentes.
Bloques subaplicacin son similares a los bloques de funcin compuestos pero tambin tienen la caracterstica flexible que pueden ser distribuidos para funcionar en ms de un recurso.
Bloques de funcin de interfaz de servicio proporcionan un medio para modelar la interaccin entre los recursos, el hardware subyacente y los sistemas de comunicacin.
Todas las definiciones de tipo de bloque de funcin se pueden definir grfica o textualmente.
Las representaciones grficas y textuales son intercambiables.
3.7.
Notas
1. SFC - Lenguaje Grfico de Funcin Secuencia definido en la Norma IEC 61131-3 de Lenguaje de Programacin PLC, y se utiliza para programar el comportamiento secuencial en
trminos de etapas y transiciones.
2. PID - Algoritmo de control proporcional, integral y derivativo comnmente utilizado para
proporcionar un control de lazo cerrado estable para la temperatura y la presin.
Captulo 4
Bloques de Funcin de Interfaz de Servicio
Este captulo revisa una forma especial de bloque de funcin que proporciona interfaces a los
sistemas de comunicaciones y recursos subyacentes.
Especficamente vamos a:
discutir por qu se requieren bloques de funcin de Interfaz de Servicio y mostrar dnde se
pueden utilizar
revisar las variables estndar de datos y eventos de entrada y salida requeridas en definiciones de tipo bloque de funcin de Interfaz de Servicio
revisar la notacin especial que se utiliza para describir la secuencia de interacciones externas con bloques de funcin de Interfaz de Servicio
considerar algunos ejemplos de bloques de funcin de Interfaz de Servicio y ver donde
podran aplicarse
finalmente, vamos a revisar los bloques de funcin de Gestin, que son una forma especializada adicional del bloque de Interfaz de Servicio para controlar la creacin y gestin de
bloques de funcin dentro de recursos y dispositivos.
4.1. Descripcin General

Hasta ahora nos hemos centrado en los bloques de funcin utilizados para modelar el comportamiento interno de un recurso. Al final del captulo 3, examinamos la creacin de una aplicacin
distribuida simple y demostramos que esto slo era posible si se proporcionan bloques de funcin
de Interfaz de Servicio (SI) adicionales para comunicar los valores de datos y eventos entre los
recursos. De hecho, siempre que se requiera cualquier forma de interaccin entre los bloques de
funcin dentro de los recursos y el mundo exterior, hay un requisito para un bloque de funcin SI.
La norma IEC 61499 no establece estndares para tipos particulares de bloques de funcin SI, pero
s estipula que estas formas de bloque de funcin deben definirse utilizando un conjunto estndar
de variables de entrada y salida y eventos de entrada y salida. Tambin hay una notacin especial
que se utiliza para describir la secuencia de interacciones, tales como el envo de una solicitud y
la espera de una respuesta, que se producen externamente durante la ejecucin de un bloque de
funcin SI.
Ahora vamos a considerar dnde es posible que necesitemos los bloques de funcin SI. En
un controlador industrial hay claramente un requisito para leer los valores de las entradas fsicas,
tales como los sensores de presin y temperatura y tambin para escribir los valores de salida a
los actuadores, por ejemplo, para manejar dispositivos tales como vlvulas, bombas, motores y
ms. Tambin hay requisitos para transmitir valores a travs de enlaces de comunicaciones serie,
67
CAPTULO 4. BLOQUES DE FUNCIN DE INTERFAZ DE SERVICIO
68
Nombre de
tipo
IO_Writer
IO_Reader
Publisher
Subscriber
Servicio proporcionado
Aplicacin ejemplo
Permite un recurso para transmitir

uno o ms valores hacia
dispositivo/s de E/S conectado/s
localmente. Nota: la norma IEC
61499 supone que el sub-sistema
controlador de E/S se encuentra
fuera del recurso, pero se puede
acceder usando bloques de interfaz
de servicio.
Permite a un recurso recibir el
ltimo valor de lectura desde uno o
ms dispositivos.
Se utiliza para actualizar el valor

de actuadores manejando
dispositivos fsicos, tales como
vlvulas, bombas o calentadores.
Transmite el/los valor/es de una o

ms variables hacia uno o ms
recursos externos que soportan un
servicio de Suscriptor.
Recibe uno o ms valores desde un
recurso externo que ofrece el
servicio publisher. Nota: El
publicador y el suscriptor
identificarn un conjunto particular
de valores por una nica direccin
de red especfica o identificador de
servicio. Puede haber muchos
suscriptores que reciben datos de
un solo publicador.
Lee los ltimos valores de las

posiciones de los dispositivos de
entrada, por ejemplo,
micro-interruptores sobre un
mecanismo de colocacin robtica.
Para transmitir continuamente los
valores de salida a un nmero de
controladores remotos para
manejar los actuadores.
Para recibir regularmente una
corriente de valores de un recurso
externo dado, por ejemplo, para
actualizar un conjunto de pantallas
HMI.
Cuadro 4.1: Ejemplos de bloques de funcin SI

para enviar copias de los datos a los controladores externos, manejar pantallas y leer entradas de
paneles de pantalla y otros dispositivos HMI. De hecho, todos estos son ejemplos de interacciones
externas con un recurso que puede ser modelado utilizando diferentes tipos de bloques de funcin
SI. REVISAR XXXXXXXXXX
Algunos ejemplos de bloques de funcin SI que podran ser utilizados para modelar un sistema
de control industrial se exponen en la Tabla 4.1.
Estos son slo algunos ejemplos tpicos de los tipos de bloques de funcin SI que podran
ser necesarios. Debe tenerse en cuenta que la norma no trata de definir bloques SI especficos, ya
que est claro que cada sistema tiene sus propios requisitos especiales particulares. Sin embargo,
veremos que la norma IEC 61499 normaliza algunos aspectos importantes de la interfaz de bloque
de funcin SI, incluyendo lo parmetros de entrada y salida principales.
4.2.
Definiciones de Tipo
La norma IEC 61499 especifica en trminos generales la forma en que se define una interfaz
para un bloque de funcin SI. Cada bloque de funcin SI ofrece algn tipo de servicio, como
4.2. DEFINICIONES DE TIPO
69
Lectura de E/S, Publicacin de valores en una red y as sucesivamente. Por lo tanto, se propone que
el nombre dado a cada tipo de bloque de funcin SI refleja el nombre del servicio que proporciona
el bloque, por ejemplo, ValvePositioner, HMIWriter.
Cabe sealar que un bloque SI puede iniciar un servicio en respuesta a un estmulo de una
aplicacin. Alternativamente, el bloque SI puede responder a una solicitud externa, tal como una
seal de un panel HMI, para obtener un valor desde una aplicacin. Los bloques de funcin SI
pueden ser modelados para soportar ambos tipos de comportamiento.
Entradas y Salidas Estndar para Bloques de Funcin SI

Cada bloque de funcin SI debe utilizar las siguientes entradas y salidas estndar, aunque no
todas ellas se utilizarn necesariamente en cada definicin de tipo SI:
Eventos de entrada
INIT
Este evento de entrada se utiliza para inicializar un servicio particular que ha sido proporcionado por el bloque. Por ejemplo, se podra iniciar un servicio para proporcionar
la transmisin de datos a travs de un enlace serie. Este evento se enva tpicamente
con un nmero de parmetros de entrada para caracterizar el tipo de servicio, tales
como la direccin de red y la tasa de transmisin.
REQ
Este evento inicia una peticin para obtener datos de un agente externo. Por ejemplo,
este evento podra ser usado para iniciar una transmisin de una peticin para obtener
datos desde un dispositivo externo.
RSP
Este evento inicia la transmisin de una respuesta hacia un agente externo. Por ejemplo, se podra enviar datos a un dispositivo HMI remoto en respuesta a una peticin de
datos.
Eventos de salida
INITO
Estos eventos de salida sealan que el bloque de funcin SI ha completado su inicializacin, es decir, como resultado de recibir un evento INIT. No significa necesariamente
que el servicio se ha iniciado con xito; una salida de estado se proporciona para este
propsito.
CNF
El evento de confirmacin se emite cuando el bloque ha finalizado la transmisin
de una solicitud a un agente externo. Por ejemplo, se debe utilizar para indicar que
una peticin de lectura de un punto fsico particular de E/S ha sido procesado por el
sub-sistema de controlador de E/S.
IND
70
El evento indicacin se emite cuando el bloque de interfaz de servicio ha recibido

una respuesta de un agente externo. Por ejemplo, un evento IND se producira cuando
una E/S leda del subsistema controlador E/S ha obtenido el valor del sensor seleccionado.
Datos de entrada
QI: BOOL
La entrada de datos QI se utiliza con el evento de entrada INIT como un simple calificador. Cuando es true, indica que el servicio prestado por el bloque debe ser
iniciado. Cuando se tiene el valor false con un evento INIT, indica que el servicio
debe ser terminado.
PARAMS: ANY
Esta entrada representa una estructura de datos que contiene un conjunto de valores
que se asocian con el servicio SI y definen sus caractersticas particulares. Los tipos
de datos y el nmero de valores dentro de la estructura sern especficos para el tipo
de servicio proporcionado por el bloque de funcin. Definicin de tipo de bloque de
funcin SI definir la estructura PARAMS y los valores por defecto de los parmetros
dentro de ella. Esta entrada slo se utiliza con el evento INIT y se utiliza para la
inicializacin del servicio.
Por ejemplo, una entrada PARAMS para un bloque de funcin SI de comunicaciones contendra la informacin de direccionamiento de red y otras caractersticas de
comunicaciones.
SD_1, ... SD_N: ANY
Estas entradas de datos se utilizan para enviar datos con las solicitudes y las respuestas.
El nmero de entradas y sus tipos de datos sern especficos para el tipo de servicio
prestado por el bloque de funcin, lo que se muestra en la notacin SD_1, ... SD_N.
Por ejemplo, en la escritura de valores a los dispositivos de salida, estos parmetros contendrn las direcciones de hardware (por ejemplo, rack, mdulo, canal) y los
valores de salida.
Datos de salida
QO: BOOL
Esta salida de clasificacin se usa para indicar si el servicio se ha completado con xito
por cualquier evento de entrada. Por ejemplo, despus de un evento de inicializacin
INIT, un valor true indicara una exitosa puesta en marcha, false indicara que el
servicio no ha podido ser inicializado.
STATUS: ANY
Esta salida se puede configurar con cualquiera de los eventos de entrada y se utiliza
para proporcionar el estado de procesamiento del ltimo evento de entrada. Por ejemplo, Status se establecer cuando un servicio se inicializa utilizando el evento INIT y
no ha tenido xito. Del mismo modo, cuando un evento REQ utilizado para transmitir
los valores a un dispositivo remoto se procesa y posteriormente falla, Status se utiliza
para mantener la razn del fallo.
4.2. DEFINICIONES DE TIPO
71
Figura 4.1: Bloques de funcin SI Requester y Responder

RD_1, ..., RD_N: ANY
Estas salidas se utilizan para transportar los datos recibidos de confirmaciones y de
indicaciones. Al igual que con las entradas SD_1 ... SD_N, el nmero de estas salidas
y sus tipos de datos sern especficos para el tipo de servicio prestado. Por ejemplo,
considere cuando se ha hecho una solicitud para leer, por ejemplo, los valores de un
conjunto de 10 puntos de entrada un evento de indicacin IND se producir cuando
el servicio haya recibido los valores del subsistema E/S, y sus valores estarn disponibles en un conjunto de salidas RD_1 ... RD_10.
La Figura 4.1 muestra dos bloques de funcin SI que se dan como ejemplo en la norma IEC
61499. Estos bloques son todava genricos en el sentido de que no se les ha dado un nmero
determinado de entradas y salidas. Los tipos de datos de entradas y salidas tambin se definen
usando la palabra clave ANY. En otras palabras, se trata de plantillas de marco para las definiciones
de tipo. Otros detalles y tipos de datos especficos tendrn que utilizar estos en un dominio de
aplicacin particular. REVISAR XXXXXXXXXxx
El bloque de funcin SI Requester proporciona un servicio de comunicaciones para obtener
datos desde un recurso remoto. La entrada PARAMS se utiliza para especificar la direccin de
comunicaciones y otros detalles; las entradas SD_1 a SD_m proporcionan parmetros para una peticin, por ejemplo, mediante el envo de una cadena y los argumentos de comando de peticin . Las
salidas RD_1 a RD_n se utilizan para los datos de respuesta recibidos del recurso remoto y llegarn
cuando el bloque atienda un evento de salida CNF de confirmacin. REVISAR XXXXXXXx
El bloque de funcin SI Responder, en efecto, proporciona el otro extremo de las comunicaciones. Recibe peticiones que llegan de un recurso remoto y crea un evento IND de indicacin y
datos de salida en RD_1 a RD_n para indicar que una solicitud de datos remota se ha recibido. La
72
Figura 4.2: Bloques de funcin SI IO_Writer; IO_Reader
respuesta a la solicitud puede ser devuelta, al escribir los datos a las entradas Responder SD_1 a
SD_m y disparando un evento en la entrada de evento RSP de respuesta. Estos datos se enviarn
por el sistema de comunicaciones de vuelta al bloque Requester originario donde ser recibido
y a su vez desencadenan un evento de salida CNF de confirmacin con datos, como ya hemos
comentado. REVISAR XXXX
Juntos, los bloques de funcin SI Requester y Responder pueden utilizarse para intercambiar
datos entre dos recursos vinculados por algn tipo de comunicacin o instalacin de red. El bloque Requester proporciona un servicio para que la norma IEC 61499 llame una interaccin de
aplicacin iniciada, en otras palabras, la solicitud de datos externos se desencadena por un evento
generado dentro de una aplicacin. REVISAR XXXXXXXXX
En contraste, el bloque Responder proporciona un servicio para una interaccin de recurso
iniciada. La solicitud de datos llega desde un recurso externo y los resultados en un evento de
indicacin IND siendo producido. En este caso, la aplicacin ser necesaria para reaccionar a los
eventos que pueden ocurrir en cualquier momento. REVISAR XXXXXXX
La Figura 4.2 muestra dos ejemplos ms de los bloques de funcin SI; IO_Writer se utiliza para
escribir valores en las salidas fsicas mientras IO_Reader se proporciona para leer los valores de las
entradas fsicas seleccionadas. Ambas funciones de una manera similar. REVISAR XXXXXXX
Vamos a considerar cmo podra utilizarse el bloque IO_Writer. La solicitud requerir por lo
menos una instancia de este bloque para escribir los valores a las salidas fsicas. Para configurar el
servicio, la aplicacin debe primero enviar un evento INIT con entrada QI en true y la entrada
PARAMS establecida para identificar las caractersticas del servicio. La entrada PARAMS podra
contener los detalles, tales como escribir las tasas de actualizacin, el nmero de reintentos en
4.3. COMPORTAMIENTO DE BLOQUES DE FUNCIN DE INTERFAZ DE SERVICIO
73
caso de fallo, etc. A partir de entonces, los datos pueden ser enviados a la salida seleccionada
mediante el establecimiento de la entrada SD_1 a una direccin de salida, por ejemplo, punto de
rack, canales de E/S y el establecimiento del nuevo valor a la entrada SD_2. La escritura se inicia
con un evento en la entrada de evento REQ. REVISAR XXXXXXXX
Algn tiempo ms tarde, cuando el sistema de E/S de hardware ha completado la operacin de
escritura, un evento CNF de salida se producir para confirmar que la escritura se ha completado.
La salida STATUS proporciona una indicacin de si la operacin ha sido un xito. Si la operacin
ha fallado, STATUS contendr un cdigo de error apropiado. La salida RD_1 proporciona una
retroalimentacin del valor como lectura desde el dispositivo de salida. Esto se puede utilizar para
confirmar que la escritura ha sido exitosa. REVISAR XXXXXXXX
El bloque IO_Reader se lleva a cabo de una manera muy similar. Despus de inicializar el
servicio mediante el evento INIT, con las entradas QI y PARAMS, el valor de cualquier entrada
fsica se puede leer mediante el establecimiento de la direccin de IO en la entrada SD_1 y enviar
un evento a la entrada de evento REQ. Algn tiempo despus, cuando los datos se han ledo del
sensor de entrada, un evento de confirmacin tendr lugar en el evento de salida CNF. El xito de
la operacin de lectura se indica con el valor de salida STATUS y, si tiene xito, el valor ledo de
la entrada estar disponible en la salida RD_1. REVISAR XXXXXX
IO_WRITER e IO_READER son formas muy simples de bloques SI para acceder a hardware
de E/S. Sin embargo, bloques ms complejos podran ser considerados para modelar servicios para
leer y escribir, por ejemplo, varios valores para muchos puntos de E/S en una sola operacin.
Tenga en cuenta que el tiempo transcurrido entre la emisin de una solicitud mediante la activacin de un evento REQ y la recepcin del evento CNF de confirmacin depender de muchos
factores tales como:
la carga del sistema de planificacin de recursos
la velocidad del sistema operativo del dispositivo en respuesta a la peticin del recurso
el tiempo para transmitir una solicitud al punto fsico de E/S.
4.3. Comportamiento de Bloques de Funcin de Interfaz de

Servicio
Al igual que con otras formas de bloque de funcin, el comportamiento de un bloque de funcin
SI est definido por una especificacin de tipo de bloque de funcin. Sin embargo, ya que un
bloque de funcin SI se ocupa principalmente de las transacciones externas, la norma especifica
una notacin adicional, llamada diagrama de tiempo de secuencia, desde el Informe Tcnico de
la ISO 8509. Estos pueden ser usados para mostrar las relaciones temporales y secuenciales entre
diversas interacciones con el bloque de funcin. De hecho, los diagramas de secuencia de tiempo
se utilizan comnmente en las normas de comunicaciones y proporcionan una manera eficaz de
visualizar el orden en el que se producen varios mensajes o eventos.
La Figura 4.3 muestra parte del diagrama de secuencia temporal para describir el comportamiento del bloque de funcin Requester como se muestra anteriormente en la Figura 4.1. El diagrama de secuencia temporal representa tres operaciones: (i) Normal_initialisation que se aplica
cuando la aplicacin inicia el servicio Requester, (ii) Normal_data_transfer que representa el envo
de una solicitud a un recurso remoto y (iii) Normal_termination que representa la terminacin del
servicio por la aplicacin.
Echemos un vistazo ms de cerca a las caractersticas del diagrama de secuencia temporal. En
primer lugar, el diagrama muestra tiempo crecientes hacia abajo. Por ejemplo, en la Figura 4.3, el
evento INIT+ se produce antes de INITO+, porque INITO es un evento de salida que se produce
74
Figura 4.3: Diagrama de secuencia temporal Interacciones de aplicacin iniciada

como respuesta a un evento de entrada INIT pero se produce algn tiempo ms tarde. Adems, los
eventos que estn estrechamente relacionados, como INIT y INITO, siempre se muestran con una
lnea de conexin vertical dentro de las barras verticales. Tenga en cuenta que los nombres de los
eventos de entrada y salida del bloque de funcin involucrado en las operaciones se representan en
el diagrama de secuencia temporal.
Las dos barras verticales representadas en cada diagrama de secuencia temporal separan los
dos dominios diferentes en los que se producen las operaciones. La Figura 4.3 muestra ejemplos
de las transacciones de aplicacin iniciada, en cuyo caso la convencin es colocar el nombre del
tipo de bloque de funcin en el lado izquierdo de las dos barras verticales y el recurso a la derecha.
Los eventos que ocurren en el dominio bloque de funcin siempre se representan al lado con el
tipo de nombre de bloque de funcin nombre de tipo.
La Figura 4.4 muestra algunos ejemplos de transacciones para el bloque de funcin Responder,
que tambin se ha descrito anteriormente en este captulo. En este caso, debido a que las principales interacciones son iniciadas por el recurso y no la aplicacin, la convencin es representar el
Recurso en el lado izquierdo de las barras verticales.
Tenga en cuenta que slo la transaccin Normal_data_transfer es iniciada por el recurso con
la indicacin de la llegada de un evento IND. En este ejemplo, la aplicacin procesa los datos
de indicacin y devuelve una respuesta positiva RSP +. Las transacciones Normal_initialisation y
Normal_termination para establecer y liberar el servicio son iniciados por la aplicacin.
El sufijo + en el nombre del evento indica si el evento est asociado con una transaccin exi-
75
Figura 4.4: Interacciones iniciadas por recurso Diagrama de secuencia temporal

tosa (o normal), mientras que el sufijo - est asociado con una transaccin sin xito (o anormal).
Con los eventos de entrada, el sufijo + indica que el valor de entrada de QI que se setea con el
evento ser TRUE. Por el contrario, el sufijo - implica que la entrada QI se setear en FALSE.
Por ejemplo, el evento INIT+ indica que ser enviado con QI establecido en TRUE e implica el servicio ser inicializado. Por el contrario, INIT- indica que el evento ser enviado con QI
establecido en FALSE y seala que el servicio debera ser terminado.
Similarmente con eventos de salida, el sufijo + indica un evento exitoso o positivo, mientras
que el sufijo - indica que el evento est asociado con una transaccin sin xito o negativa. Con
eventos de salida, un sufijo + indica que el valor de la salida QO ser establecido en TRUE,
mientras que un sufijo - indica que QO se establecer en FALSE.
Por ejemplo, IND- sera una indicacin negativa e implicara que la transaccin ha sido de
alguna manera infructuosa. Si esto ocurre con el bloque de funcin Responder, puede implicar que
los datos enviados desde un recurso remoto es incorrecto tal vez los datos han sido formateados
incorrectamente. La aplicacin debe responder mediante la emisin de una respuesta negativa, es
decir, RSP- como se muestra en la Figura 4.5.
Es evidente que, con los bloques de funcin SI complejos deben considerarse todas las diversas
combinaciones y formas de las transacciones normales y anormales.
Hay definiciones para el significado, es decir, semntica de las formas positivas y negativas
de todos los eventos estndar compatibles con las funciones SI. La norma IEC 61499 define las
76
Figura 4.5: Indicacin negativa

diferentes formas de eventos como primitivas de servicio. La Tabla 4.2 tiene dos columnas que
corresponden a los servicios de comunicaciones y servicios de propsito general, respectivamente,
y proporcionan definiciones para las primitivas de servicio estndar.
Sintaxis Textual Ejemplo de Bloque de Funcin SI

La norma IEC 61499 especifica una sintaxis textual adicional para especificaciones de tipo
de bloque de funcin SI que permite a las distintas transacciones de servicios ser definidas. Esto puede ser mejor demostrado mediante la revisin de la definicin de tipo textual para el bloque
de funcin IO_Writer que se describi anteriormente en este captulo y se muestra en la Figura 4.2.
FUNCTION_BLOCK IO_WRITER
(* IO_Writer Service Interface *)
EVENT_INPUT
INIT WITH QI, PARAMS;
REQ WITH QI, SD_1, SD_2;
END_EVENT
EVENT_OUTPUT
INIT0 WITH QO, STATUS;
CNF WITH QO, STATUS, RD_1;
END_EVENT
VAR_INPUT
QI : BOOL; (* Event input qualifier *)
PARAMS : IO_PARAMS; (* Service parameters *)
SD_1 : IO_ADDR; (* Output address *)
SD_2 : IO_VALUE; (* Output value *)
END_VAR
VAR_OUTPUT
QO : BOOL; (* Event output qualifier *)
STATUS : ANY; (* Service status *)
RD_1 : IO_VALUE (* Returned value *)
END_VAR
SERVICE REQUESTER/RESOURCE

Primitivas de
servicio
INIT+
INITINITO+
INITO-
REQ+
REQCNF+
CNF-
IND+
INDRSP+
RSP-
Semntica cuando se utiliza en los

servicios de comunicaciones
Solicitar al inicializar el servicio de
comunicaciones.
Solicitud para terminar el servicio
de comunicaciones.
Indicacin de que el servicio de
comunicaciones se ha inicializado.
Indicacin de que tanto un servicio
de comunicaciones no puede ser
inicializado o se ha terminado con
xito.
Solicitud normal para transferir
datos.
Desactivar la solicitud de
transferencia de datos.
Confirmacin de la transferencia
de datos con xito.
Confirmacin de que la
transferencia se ha realizado
correctamente.
Indicacin de la llegada de datos
con xito.
Indicacin de la llegada de datos
sin xito.
Respuesta de la aplicacin de la
llegada de datos con xito.
Respuesta de la aplicacin de la
llegada de datos sin xito.
77
Semntica cuando se utilizan en los

servicios generales
Solicitar al inicializar el servicio.
Solicitud para terminar el servicio.
Indicacin de que el servicio se ha
iniciado.
Indicacin de que el servicio no se
ha iniciado o ha finalizado con
xito.
Solicitud normal de servicio.
Desactivar la solicitud de servicio.
Confirmacin normal del servicio.
Confirmacin de que solicitud de
servicio no tuvo xito.
Indicacin de la llegada el servicio
normal.
Indicacin de la llegada el servicio
sin xito.
Respuesta mediante la aplicacin
de un servicio de xito.
Respuesta de la aplicacin de un
servicio de anormal o sin xito.
Cuadro 4.2: Indicacin negativa

SEQUENCE normal_initialisation
REQUESTER.INIT+(PARAMS)->REQUESTER.INITO+();
END_SEQUENCE
SEQUENCE abnormal_initialisation
REQUESTER.INIT+(PARAMS)->REQUESTER.INITO-();
END_SEQUENCE
SEQUENCE normal_data_transfer
REQUESTER.REQ+(SD_1,SD_2)->REQUESTER.CNF+(RD_1);
END_SEQUENCE
SEQUENCE abnormal_data_transfer
REQUESTER.REQ+(SD_1,SD_2)->REQUESTER.CNF-(STATUS);
END_SEQUENCE
SEQUENCE normal_termination
REQUESTER.INIT-()->REQUESTER.INITO-();
END_SEQUENCE
SEQUENCE abnormal_termination
REQUESTER.INIT-()->REQUESTER.INITO-(STATUS);
78
END_SEQUENCE
SEQUENCE resource_initiated_termination
-> REQUESTER.INITO-(STATUS)
END_SEQUENCE
END_SERVICE
END_FUNCTION_BLOCK
Nuevas palabras clave SERVICE y END_SERVICE se proporcionan para contener las definiciones de la secuencia de servicio. Cada secuencia de servicio es introducida con la palabra clave
SEQUENCE y se cierra con la palabra clave END_SEQUENCE. La definicin de secuencia define los parmetros de las primitivas de servicio y asociadas que inician la transaccin. El operador
-> implica dos cosas: (i) que puede haber una demora de tiempo debida al procesamiento externo o latencia de comunicaciones y (ii) que el servicio primitivo resultante, como se indica a la
derecha de este operador, se producir como consecuencia de la primitiva de servicio en el lado
izquierdo. Los nombres de las secuencias deben asignarse uno-a-uno con los nombres que figuran
en los diagramas de secuencia temporal. Los nombres de las entradas, que deberan ser vlidos
cuando se inicia el servicio, se incluyen entre parntesis despus de la primitiva de servicio. Del
mismo modo, los nombres de las salidas, que se establecen para el servicio que resulta primitivo,
se muestran a la derecha.
Tenga en cuenta que en la ltima definicin de secuencia para resource_initiated_termination
no hay ningn componente para la transaccin dada a la izquierda del smbolo ->. Esto se debe
a que, en este caso, la transaccin se produce por algn agente desconocido fuera del recurso.
Por ejemplo, esto puede ocurrir cuando hay un fallo de suministro de energa inminente y por lo
tanto el dispositivo enva una transaccin no solicitada a travs de la interfaz de los recursos para
terminar el servicio IO_WRITER.
Cualquier comportamiento adicional del bloque de funcin SI, por ejemplo, para comprobar
la validez de determinadas entradas antes de iniciar un servicio, puede ser modelado mediante la
encapsulacin del bloque SI dentro de un bloque compuesto como se discute en el captulo 3.
Bloques de funcin adicionales podran ser aadidos para filtrar los datos de entrada y verificar los
datos de respuesta.
Cabe sealar que la definicin de tipo de bloque de funcin SI slo contiene definiciones de
comportamiento que se produce dentro del dominio de bloque de funcin, es decir, dentro del
recurso. No define el comportamiento fuera del Recurso que es proporcionado por el sistema operativo del dispositivo, hardware o sistemas de comunicaciones. Todo esto est fuera del alcance de
la norma IEC 61499.
4.4. Bloques de Funcin de Interfaz de Servicio Asociado

Hay situaciones en las que se utilizan bloques de funcin SI para proporcionar e intercambiar
informacin entre los diferentes recursos. Por ejemplo, una aplicacin puede ser distribuida entre
dos recursos A y B, y es un requisito para enviar datos de peticin desde A y recibir una respuesta
de B. Sin embargo, ambas partes de la aplicacin que residen en A y B deben ser capaces de
detectar si el intercambio de datos ha sido un xito. Una solucin a esto es proporcionar bloques
de funcin SI Cliente y Servidor que son capaces de transferencia de datos bidireccional. El bloque
Cliente en el recurso A enva la solicitud al bloque Servidor en el recurso B; el Servidor responde
y enva los datos de respuesta de vuelta al bloque Cliente en A.
Para modelar esto, la norma especifica que los diagramas de secuencia temporal pueden mostrar
las transacciones para ambos socios. Considere los bloques de funcin Cliente y Servidor, como
se muestra en la Figura 4.6, y se supone que estos proporcionan un servicio de intercambio de
4.4. BLOQUES DE FUNCIN DE INTERFAZ DE SERVICIO ASOCIADO
79
Figura 4.6: Bloques de funcin SI Cliente y Servidor
Figura 4.7: Transferencia de datos bidireccional

datos enclavado. Cuando el Cliente emite una solicitud, el Servidor responde. Parte del diagrama
de secuencia temporal para esto se muestra en la Figura 4.7, en este caso las dos barras verticales
representan el procesamiento y los retardos de tiempo que se producen para transferir un mensaje
entre Cliente y Servidor.
La sintaxis textual para secuencias servicio puede incluir definiciones de ambos extremos de la
transaccin. Por ejemplo, las definiciones de tipo para Servidor pueden incluir la respuesta esperada desde el otro Cliente. Para ilustrar esto, la siguiente sintaxis textual sera definir la secuencia
servicio de transferencia de datos bidireccional, como parte de la definicin de tipo del Servidor,
es decir, describe el diagrama de secuencia temporal que se muestra en la Figura 4.7.
SEQUENCE normal_data_transfer
CLIENT.REQ+(SD_1,...,SD_m) ->SERVER.IND+(RD_1,...,RD_m);
SERVER.RSP+(SD_1,...,SD_n) ->CLIENT.CNF+(RD_1,...,RD_n);
END_SEQUENCE
Tenga en cuenta que la definicin de Cliente simplemente se refiere al Servidor para la definicin de transaccin completa. Tenga en cuenta tambin que en este ejemplo la notacin ...,
SD_m slo indica que los bloques Cliente/Servidor son de uso general y puede ser adaptado a
las aplicaciones particulares. En un sistema real, cada par Cliente/Servidor sera especificado para
enviar y recibir un nmero fijo de elementos de datos de un tipo de datos determinado.
Un par Cliente y Servidor en efecto proporciona un mecanismo para crear un Proxy local
de un bloque de funcin remoto. Pueden proporcionar un conjunto local de entradas y salidas que
imitan a los disponibles en el bloque de funcin remoto. Se prev que las herramientas de soporte
80
Figura 4.8: Bloque de Funcin de Gestin

de ingeniera podrn insertar automticamente pares Cliente/Servidor cuando una aplicacin se
divide entre los recursos.
4.5.
Bloques de Funcin de Gestin
La ltima forma de bloque de funcin SI que se define en la norma concierne los servicios
para carga, comienzo e inicio de la ejecucin del bloque de funcin. La norma define una forma
genrica de bloque de funcin de Gestin como se muestra en la Figura 4.8 que puede ser utilizado
para iniciar una serie de funciones de servicio que utilizan diferentes definiciones de comandos.
Las descripciones de estos servicios y su funcionamiento slo se dan en lneas generales en la
norma. Esta es un rea que es particularmente difcil de modelar porque los sistemas tienden a
tener mecanismos completamente diferentes para la carga y la creacin de redes de bloques de
funcin y para comenzar la ejecucin de las aplicaciones cargadas. En el futuro, es probable que
ms detalles sobre estos servicios se incluyan en otras partes de la norma, pero es un gran tema
que ser difcil de modelar de una manera general.
En un extremo, para iniciar una aplicacin, un sistema puede requerir que todos los bloques de
funcin y bibliotecas de recursos de soporte se compilen en un formato binario y se descarguen
en dispositivos separados. En el otro extremo, los dispositivos pueden tener grandes bibliotecas
de bloques de funcin pre-cargadas, por ejemplo, las definiciones de bloques de funcin podran
ser todas parte del firmware del dispositivo. En este caso, una aplicacin puede ser creada con
slo descargar las definiciones de las conexiones que se requieren para crear redes de bloques
de funcin de la aplicacin en los diferentes dispositivos. Tambin puede haber sistemas hbridos
donde algunos bloques de funcin estn en el firmware, mientras que otros son descargados.
Los servicios que son compatibles con el bloque de funcin de Gestin se aplican tanto a nivel
de recursos como de dispositivos, tal como se muestra en la Tabla 4.3 y en la Tabla 4.4.
El bloque de funcin de Gestin puede usarse especificando valores diferentes para la entrada
CMD para iniciar las diversas funciones de servicio. La respuesta a cada forma de funcin de
servicio est dada por el valor devuelto en la salida Status. La funcin de servicio se caracteriza
adems por el valor de la entrada CMD_PARAMS.
Ejemplos:
CMD = CREATE
CMD_PARAMS = fb_instance_definition
4.5. BLOQUES DE FUNCIN DE GESTIN

Funcin de Servicio
Create
Initialise
Start
Stop
Delete
Query
81
Descripcin
Crea definiciones de tipos de datos, tipos de
bloques de funcin e instancias y las
conexiones entre los bloques de funcin. Esto
implicar descarga de definiciones de una
fuente, por ejemplo, copiado a travs de una
red, copiado desde una tarjeta de memoria
inteligente.
Inicializar tipos de datos, tipos de bloques de
funcin e instancias y las conexiones. Esto
concierne la creacin de los bloques de funcin
y las conexiones en un estado ejecutable e
incluir restablecer las variables a sus valores
predeterminados iniciales.
La funcin Start provoca la ejecucin de las
redes de bloques de funcin dentro de un
recurso. Por lo general comenzar la funcin
de planificacin de los recursos y empieza a
ejecutar los bloques de funcin SI que generan
eventos temporales. Estos, a su vez, disparan
cadenas de eventos que causan la ejecucin del
bloque de funcin.
El servicio Stop hace que toda la ejecucin
cese suspendiendo la funcin de planificacin
de los recursos.
El servicio Delete se puede utilizar para
suprimir la definicin de cualquier tipo de
datos, bloques de funcin o conexin.
El servicio Query proporciona un medio para
acceder a la informacin sobre el estado, los
atributos y la existencia de tipos de datos,
bloques de funcin y conexiones.
Cuadro 4.3: Funciones de servicio de gestin a nivel de recursos

PARAMS = fb instance definition data
RESULT = fb instance reference
Esto inicia la funcin de servicio para crear una definicin de instancia de bloque de funcin.
CMD = QUERY
CMD_PARAMS = connection_start_point
PARAMS = connection start point definition
RESULT = connection end point definition
Esto muestra un ejemplo de la funcin de servicio de gestin Query para encontrar la referencia
del final de conexin para un inicio de conexin dado.
Nota: En estos dos ejemplos los tipos de datos para los valores que aparecen en cursiva no
estn definidos en la norma IEC 61499 y son considerados como especficos de implementacin.
Sin embargo, la norma ha definido un formato de intercambio de datos para portar definiciones de
bloques de funcin basada en XML vase el captulo 7 y el Anexo B.
Como comentario general, bloques de funcin son muy efectivos para modelar sistemas donde
el comportamiento se basa principalmente en los datos y los flujos de eventos. Cabe preguntarse
82

Funcin de Servicio
Create
Initialise
Start
Stop
Delete
Query
Descripcin
Crea y establece un recurso dentro de un
dispositivo. Esto establece las caractersticas y
atributos de un recurso en un dispositivo.
Inicializa el recurso para estar listo para cargar
y ejecutar los bloques de funcin.
Inicia el recurso para permitir la ejecucin de
bloques de funcin.
Detiene la ejecucin de los recursos de los
bloques de funcin.
Borra los recursos desde el dispositivo de
manera que ya no se pueda acceder para cargar
y ejecutar los bloques de funcin.
Consulta el dispositivo para obtener
informacin sobre el estado, los atributos y la
existencia de recurso/s en el dispositivo.
Cuadro 4.4: Funciones de servicio de gestin a nivel de dispositivo

si las operaciones de gestin para la carga y la creacin de bloques de funcin para formar aplicaciones que se distribuyen a travs de los dispositivos pueden ser descritos mejor con el mismo
modelo. Este tipo de comportamiento puede requerir un tipo diferente de modelo, ya que se ocupa
principalmente de los problemas de gestin de datos. REVISAR XXXXXXXXXXXXXx
Bloques de Funcin Gestionados

Los bloques de funcin que pueden ser cargados y accedidos por los bloques de funciones
de gestin se llaman bloques de funcin gestionados. Esto est en contraste con los bloques de
funcin no gestionados; stos incluiran bloques que forman parte de firmware del dispositivo y
por lo tanto tendran un cierto grado de funcionalidad fija.
Los bloques de funcin gestionados pueden tener una serie de estados como se define en la Tabla 4.5. El estado de un bloque de funcin gestionado se puede cambiar si se asocia con un bloque
de funcin Gestor. El concepto es que un recurso puede cambiar dinmicamente la configuracin
de los bloques de funcin mediante la emisin de solicitudes a los bloques de funcin Gestores.
La forma en que esto ocurre en realidad es an muy incompleta en la norma pero puede ser tratada
con ms detalle en la segunda parte de la norma IEC 61499.
Nota: Esto es slo un resumen de los principales estados de los bloques de funcin gestionados.
Para ms informacin, el lector debe referirse a la seccin Comportamiento de los bloques de
funcin gestionados de la Parte 1 de la norma IEC 61499 donde hay ms detalles sobre la mquina
de estado de un bloque de funcin gestionado y tambin las descripciones de las transiciones
asociadas entre los diferentes estados.
4.6.
Resumen
Ahora hemos cubierto los aspectos importantes de las funciones de Interfaz de Servicio de la
norma IEC 61499. Para recapitular, se proporcionan bloques de funcin de Interfaz de Servicio
(SI) para dar una interfaz entre los bloques de funcin que se ejecutan en los recursos y los
servicios proporcionados fuera del recurso. Una definicin de tipo de bloque de funcin SI slo
4.6. RESUMEN
Estado
THAWED
RETAINED
IDLE
RUNNING
STOPPED
KILLED
83
Significado
La informacin de estado interno del bloque de funcin est
disponible y el bloque de funcin est listo para iniciar la
ejecucin. Este estado existe cuando el dispositivo que contiene
el bloque de funcin est siendo encendido.
Un bloque de funcin es considerado en este estado cuando el
dispositivo que lo contiene est completamente apagado.
El bloque de funcin se encuentra en un estado inicializado. El
grfico de control de ejecucin del bloque se encuentra en su
estado inicial, las variables de entrada y salida tienen sus valores
iniciales.
En este estado, el bloque de funcin se considera disponible para
la recepcin de eventos de entrada. Cualquier evento de entrada
se har por medio de la funcin de programacin de recursos.
Todo el procesamiento de los algoritmos y eventos de entrada se
termina mediante la funcin de programacin.
La operacin de todos los procesos eventos y algoritmos de
entrada se inhiben.
Cuadro 4.5: Estados principales de un bloque de funcin gestionado

define la interfaz en el servicio y su respuesta; no define el comportamiento del servicio fuera del
recurso. Una notacin especial, el diagrama de secuencia temporal, se utiliza para mostrar las
relaciones de temporizacin entre eventos en el lado de entrada y de salida de bloques SI. Los
bloques de funcin SI se pueden utilizar para:
leer y escribir en los puntos de E/S accedidos a travs del subsistema de E/S del dispositivo
solicitar datos de recursos externos o responder a las solicitudes de datos de recursos externos
instalar intercambios de datos entrelazados con recursos externos, por ejemplo, utilizando
bloques Cliente y Servidor
gestionar la creacin y ejecucin de bloques de funcin en un recurso.
84
Captulo 5
Bloques de Funcin de Evento
Como se ha expuesto en los captulos 1 y 2, una propiedad fundamental de las redes de bloques
de funcin IEC 61499 es que la ejecucin de todos los programas dentro de cada bloque de funcin
es, de alguna manera, disparado por evento. En este captulo vamos a revisar un conjunto especial
de bloques de funcin estndar que se proporcionan para el comportamiento de eventos. Estos
bloques de funcin pueden ser utilizados para modelar el control, la generacin y la deteccin de
eventos.
En este captulo se describirn los bloques de funcin de eventos estndar que:
permiten que los eventos se dividan para producir nuevos eventos
permiten que los eventos se combinen
permiten la propagacin de eventos particulares
seleccionan entre dos o ms eventos
retrasan un evento por un perodo determinado
generan flujos de eventos
crean eventos de deteccin de flancos Booleanos.
5.1. Descripcin General

En los captulos anteriores hemos revisado varias maneras diferentes de crear definiciones de
tipo de bloques de funcin, es decir, para los bloques de funcin bsicos, compuestos y de interfaz
de servicio. En este captulo, vamos a revisar un conjunto especial de tipos de bloques de funcin
que se definen en la norma IEC 61499 especficamente para manejar eventos. La mayora de estos
bloques de funcin se definen como bloques bsicas. Un par de bloques son definidos como
una forma de interfaz de servicio, ya que requieren algn tipo de interaccin con el recurso
que contienen. Tambin hay algunos bloques de eventos ms complejos que se construyen como
compuestos desde los bloques de eventos elementales. REVISAR XXXXXXXXXX
Todos los bloques de funcin estndar de eventos estn diseados para ser utilizados dentro
de las definiciones de los grandes bloques de funcin compuestos de usuario y las aplicaciones y
proporcionar muchas de las operaciones comunes que se requieren cuando se modelan los comportamientos de eventos. REVISAR XXXXXXXXX
En cualquier sistema orientado a eventos siempre hay una necesidad de ser capaz de generar
el evento inicial que provoca la ejecucin del primer elemento de software. Del mismo modo, en
la especificacin de redes de bloques de funcin IEC 61499, se necesita un evento para activar el
85
86
CAPTULO 5. BLOQUES DE FUNCIN DE EVENTO
Figura 5.1: Ejemplo de cadena de eventos
primer bloque de funcin en cada cadena de bloques de funcin. Los sistemas de control tpicamente tambin tendrn otros requerimientos tales como una necesidad de dividir los eventos para
activar simultneamente mltiples cadenas de bloques o para crear trenes de eventos para que los
bloques sean regularmente re-ejecutados, por ejemplo, cuando se modela un sistema que escanea
E/S. REVISAR XXXXXXX
La Figura 5.1 muestra un ejemplo sencillo de un sistema de control que inicia la ejecucin
cuando el sistema est inicialmente encendido, es decir, arranca en fro y luego contina con
la ejecucin de dos cadenas de bloques de funcin en paralelo. Un evento de arranque en fro
es claramente necesario para iniciar el primer bloque de funcin en la cadena. Cuando el primer
bloque FB1 ha completado su ejecucin, hay un requisito para ejecutar dos cadenas separadas de
bloques de funcin. Esto se demuestra por los bloques FB2a y FB3a divisores y disparadores de
evento. Cuando FB2b y FB3b han completado ambos su ejecucin, los eventos de los dos bloques
se unen utilizando un punto de encuentro para crear un evento simple que luego, a su vez, dispara
el ltimo bloque de funcin FB4.
En este primer ejemplo, los bloques de funcin slo se ejecutan una vez cuando el sistema
arranca en fro, porque slo es generado un evento inicial. Sin embargo, por lo general un sistema
de control requerir comportamiento escaneado donde los bloques de funcin se necesitan ejecutar
varias veces para supervisar estados de la planta, actualizaciones de actuadores y as sucesivamente. Esto puede lograrse haciendo pasar un tren de eventos en el primer bloque de funcin, como se
muestra en la Figura 5.2. Supongamos que el tren de eventos consta de un flujo regular de eventos
enviados a intervalos regulares, por ejemplo cada 100 milisegundos. Ahora todos los bloques de
funcin en los dos caminos paralelos sern continuamente re-ejecutados cada 100 milisegundos
despus del arranque en fro.
En las Figuras 5.1 y 5.2, cada crculo sombreado representa alguna forma de comportamiento
de los eventos. De hecho, veremos que cada crculo puede ser sustituido por uno de los bloques de
funcin de evento IEC 61499. El diagrama de tiempos que se muestra abajo de la red bloque de
funcin en la Figura 5.2 describe el flujo de eventos que entran en la cabecera de control de eventos
del bloque de funcin FB1. Tambin se muestra la secuencia de eventos que salen del evento punto
de encuentro. Tenga en cuenta que aqu los eventos estn ligeramente retrasados debido al tiempo
para ejecutar algoritmos en las redes de bloques de funcin paralelas y debido a los retrasos en la
programacin de recursos. El perodo entre los eventos tambin vara ligeramente debido a retrasos
en la ejecucin que pueden variar, por ejemplo, un algoritmo puede no necesariamente siempre
toma el mismo perodo de tiempo para ejecutarse ya que esto puede depender de los valores de
entrada y de variables internas.
5.2. TIPOS DE BLOQUE DE FUNCIN DE EVENTO ESTNDAR
87
Figura 5.2: Ejemplo de cadena de eventos Cclica
5.2. Tipos de Bloque de Funcin de Evento Estndar

Ahora vamos a revisar el rico repertorio de tipos de bloques de funcin de eventos estndar definidos en la norma IEC 61499, que permiten una amplia gama de escenarios de eventos a modelar.
En las siguientes descripciones de cada figura se muestra la plantilla externa del tipo de bloque de
funcin en el lado izquierdo de la figura y su correspondiente especificacin de tipo a la derecha.
Muchos de estos bloques de funcin de eventos son de la forma bsica y pueden ser definidos
mediante un grfico de control de ejecucin (ECC), algunos requieren interacciones con el recurso y, por tanto, se definen mediante diagramas de secuencia temporal. Hay unos pocos bloques
de funcin de eventos complejos, como el Boolean Rising Detector Edge, que se definen como
bloques compuestos formados a partir de bloques de eventos simples.
Tenga en cuenta que en las declaraciones de tipo bloque que se muestran en las siguientes
figuras, el nombre de tipo de bloque de funcin IEC 61499 formal se muestra dentro de la plantilla
de bloque. Cuando se requieren algoritmos asociados, stos se muestran debajo de la ECC en la
especificacin de tipo de bloque. En algunos casos, diagramas de temporizacin tambin se representan por debajo de algunos de los bloques para aclarar las relaciones de temporizacin entre
eventos de entrada y de salida.
Es sorprendente que para muchos de estos bloques el comportamiento interno puede ser completamente descrito slo por el uso de un grfico de control de ejecucin (ECC). Como una ayuda
para la comprensin de los siguientes ECCs, los puntos tal como se muestran en la Figura 5.3
resumen los principales aspectos de la notacin ECC que se describe en detalle en el Captulo 3.
En algunas de las siguientes definiciones como para el Evento Merger, el nmero de entradas y
salidas puede variar. Por ejemplo, el bloque de Evento Merger puede combinar dos o ms eventos.
En tales casos, se prev que las herramientas de software automticamente dimensionarn instancias de bloques de funcin que tengan el nmero requerido de entradas y salidas.
88
Figura 5.3: Entendiendo la notacin ECC
Evento Splitter
El Evento Splitter produce dos o ms eventos de salida simultneos sobre la recepcin de un
solo evento de entrada, como se muestra en el diagrama de temporizacin (Figura 5.4).
Evento Merger
El Evento Merger produce un nico flujo de eventos de salida mediante la fusin de los eventos
entrantes en las entradas de evento EI1 a EIn . Esto puede ser utilizado para combinar dos o ms
eventos (Figura 5.5).
Encuentro de Dos Eventos

El Encuentro de Dos Eventos espera la recepcin de un evento en ambas entradas EI1 y EI2 y
produce un nico evento de salida en EO. Si el bloque recibe un evento ms sencillo tanto en EI1
como en EI2, se producir un evento de salida en EO (Figura 5.6). Revisar XXXXXX
Tenga en cuenta que si en algn momento el bloque recibe un evento de restablecimiento en
la entrada R, un evento simple tanto en EI1 como en EI2 es siempre requerido antes de que un
evento de salida sea producido sobre EO, como se muestra en el diagrama de temporizacin. En
otras palabras, el reinicio se puede utilizar para volver a sincronizar el punto de reunin de los dos
flujos de eventos.
Bloques de Encuentro de Eventos que manejan otros nmeros ms grandes de eventos de entrada se pueden definir utilizando diseos similares.
89
Figura 5.4: Evento Splitter
Evento Propagador Permisivo

El Evento Propagador Permisivo controla el flujo de los eventos desde la entrada EI hasta EO
en funcin del valor de la entrada PERMIT. Un valor true es necesario para permitir que los eventos fluyan a travs del bloque (Figura 5.7).
Evento Selector
El Evento Selector permite que el flujo de eventos de salida sea seleccionado desde cualquier
entrada de evento EI0 o EI1 dependiendo de si G tiene valor false o true, respectivamente
(Figura 5.8).
Evento Switch
El Evento Switch puede ser utilizado para dirigir el flujo de eventos entrante sobre la EI para
ir a la salida EO0 o EO1. G establecido en false conmuta los eventos hacia laa salida EO0, G
seteado en true enva los eventos hacia la salida EO1 (Figura 5.9).
Evento Propagador Retardado

El Evento Propagador Retardado proporciona un medio para retrasar un evento que est llegando a la entrada START por un perodo definido dado por la entrada DT. Por ejemplo, si DT
se establece en 100 milisegundos, luego un evento en la salida EO se producir 100 milisegundos
90
Figura 5.5: Evento Merger

despus de cada evento que llega a la entrada START, siempre que los eventos de entrada tengan
por lo menos 100 milisegundos de diferencia.
Sin embargo, si ms eventos llegan a la entrada START antes de que se haya producido el
evento de salida en EO, stos sern ignorados porque no hay una cola de eventos de entrada. Si se
recibe un evento STOP mientras un evento de entrada se est retrasando, ser cancelado y no se
producir ningn evento de salida.
Tenga en cuenta que este bloque requiere interacciones con los recursos subyacentes y as se
describe mediante un diagrama de secuencia temporal simple. En general, el temporizado slo se
puede lograr por alguna forma de interaccin fuera del recurso, por ejemplo, mediante el uso de
un circuito temporizador en el dispositivo de sub-sistema (Figura 5.10).
Generador de Evento Restart

El Generador de Eventos Restart proporciona eventos simples cuando el recurso arranc en
fro y caliente y tambin cuando el recurso se detiene por algn agente externo. Es probable que la
mayora de las aplicaciones requieran al menos una instancia de este bloque para iniciar el evento
disparador que inicia la ejecucin de una cadena de bloques de funcin en una red, como se muestra
en la Figura 5.1 y Figura 5.2.
Este bloque requiere interacciones con los recursos y es, por lo tanto, descrito mediante el uso
de un diagrama de secuencia temporal (Figura 5.11).
Generador de Evento Cclico

El Generador de Evento Cclico es usado para producir un flujo de eventos a intervalos regulares. La secuencia de eventos se inicia cuando un evento llega a la entrada START y se detiene
cuando un evento llega a la entrada STOP. El perodo entre los eventos de salida est seteado por
el valor de DT.
91
Figura 5.6: Encuentro de Dos Eventos

Este bloque es descrito como un bloque compuesto utilizando una instancia de Evento Propagador Retardado E_DELAY. El camino de realimentacin de EO a START asegura que un nuevo
evento se retrasa despus del evento de arranque inicial, y posteriormente despus de cada evento
de salida (Figura 5.12).
Generador de Tren de Evento

El Generador de Tren de Evento produce un tren de eventos en la salida EO de cada uno
separado por un intervalo dado. El nmero de eventos es establecido por el valor de la entrada N
y el intervalo se define por el valor de la entrada DT. El recuento del nmero de eventos de salida
que se han producido est dado en la salida CV.
Si un evento de entrada se recibe en la entrada STOP, el tren de eventos de salida cesar. Un
evento START adems provocar que un nuevo tren de eventos de salida sea producido (Figura
5.13).
Este bloque se define como un bloque compuesto que utiliza instancias de bloques de funcin
del Evento Driven Up Counter, el Evento Switch y el Evento Propagador Retardado, los cuales se
describen en este captulo.
Evento Train Table-driven Generator

El Evento Train Table-driven Generator proporciona un tren de eventos en la salida EO donde
se puede especificar el nmero de eventos y los intervalos entre los eventos. El nmero de eventos
92
Figura 5.7: Evento Propagador Permisivo
Figura 5.8: Evento Selector

est dado por la entrada N, el arreglo TIME dado en la entrada DT define el intervalo entre cada
evento de salida secuencial. Por ejemplo, si DT se establece en el valor de una matriz de tiempo
de tamao 4, es decir, TIME [4], a continuacin, el intervalo entre el primer y el segundo evento
ser el valor de TIME [0], entre el segundo y el tercero el valor de TIME [1], y as sucesivamente
(Figura 5.14).
Tenga en cuenta que si el tamao del arreglo es m, entonces el valor de N debe ser m + 1. Por
ejemplo, si hay cinco eventos de salida en el tren, a continuacin, se requieren cuatro intervalos de
tiempo en la matriz.
Este bloque se define como un compuesto que usa las instancias del bloque Table Control,
E_TABLE_CNTL y del Evento Propagador Retardado, E_DELAY. El E_TABLE_CNTL es un
bloque de soporte especial que se utiliza para seleccionar el tiempo de retardo desde el arreglo
TIME [4] como los eventos de salida se cuentan. (REVISAR XXXXXXXXXX) En este caso,
est diseado para un arreglo de tamao 4, pero podra ser utilizado para arreglos de cualquier
tamao mediante el cambio de las constantes en las expresiones donde se prueba CV. REVISAR
XXXXXXx
Evento Independiente Train Table-driven Generator

El Evento Independiente Train Table-driven Generator se utiliza para producir eventos individuales en cada una de las salidas de eventos, con cada evento separado por un intervalo definido.
El nmero de eventos se define por la entrada N y el intervalo de tiempo entre los eventos de salida
93
Figura 5.9: Evento Switch
Figura 5.10: Evento Propagador Retardado

viene dado por el arreglo TIME establecido en la entrada de DT (Figura 5.15).
Por ejemplo, suponga que la entrada a DT es un arreglo TIME de tamao 4, es decir, TIEMPO
[4], y la entrada N se establece en 4 y el bloque est definido para tener 4 eventos de salida. Luego,
cuando llega un evento en la entrada START, un evento de salida en EO0 se producir despus de
un perodo TIME [0], otro evento de salida se producir en la salida EO1 despus de un perodo
TIME [1], y as sucesivamente hasta que todos los 4 eventos de salida hayan sido disparados una
vez.
Si un evento es recibido en la entrada STOP, la generacin de eventos de salida cesa. Un evento
START posterior puede entonces desencadenar un nuevo conjunto de eventos de salida.
Este bloque se define como un compuesto que usa las instancias del Evento Train Table-driven
Generator y un Evento De-multiplexor.
Evento Impulsado Bistable (Set Dominante)

El Evento Impulsado Bistable (Set dominante) proporciona un medio para latchear la llegada
de un evento. Su salida Q se establece en true cuando un evento llega a la entrada S. La salida Q
se pone en false cuando un evento llega a la entrada R. Si los eventos llegan simultneamente a
ambas entradas S y R, entonces la entrada de evento S es dominante y la salida Q se establece en
true (Figura 5.16).
Evento Impulsado Bistable (Reset Dominante)
94
Figura 5.11: Generador de Evento Restart
Figura 5.12: Generador de Evento Cclico

El Evento Impulsado Bistable (Reset dominante) tambin proporciona un medio para latchear
la llegada de un evento. Su salida Q se establece en true cuando un evento llega a la entrada S. La
salida Q se pone en false si un evento llega a la entrada R. A diferencia del biestable (Set dominante), si los eventos llegan simultneamente en ambas entradas S y R entonces la entrada R es
dominante y la salida Q se establece en false (Figura 5.17).
D (Data Latch) Bistable

El Data Latch Bistable almacena el estado de una entrada booleana D sobre la llegada de un
evento de entrada de reloj (CLK). Si el estado de la entrada ha sido invertido, se produce un evento
de salida EO; el estado del booleano almacenado se proporciona en la salida Q (Figura 5.18).
Detector de Flanco Ascendente Booleano

El Detector de Flanco Ascendente Booleano produce un evento de salida EO cuando la entrada
de datos QI ha cambiado de false a true mientras se testea con evento de entrada E1. Esto se
describe mejor por el diagrama de temporizacin en la Figura 5.19.
Este es un bloque de funcin compuesto que utiliza la funcionalidad de los bloques Data Latch
95
Figura 5.13: Generador de Tren de Evento
y Event Switch. Debido a que el Data Latch slo produce un evento de salida cuando la entrada
cambia de estado, un evento slo se produce cuando hay un cambio de false a true. El Evento
Switch asegura que slo se selecciona el evento para una transicin positiva.
Detector de Flanco Descendente Booleano

El Detector de Flanco Descendente Booleano produce un evento de salida EO cuando la entrada
de datos QI ha cambiado de true a false mientras se testea con evento de entrada E1. Esto se
describe mejor por el diagrama de temporizacin en la Figura 5.20.
El Detector de Flanco Descendente Booleano tiene un diseo similar al Detector de Flanco
Ascendente Booleano.
Contador de Eventos Impulsados

El Contador de Eventos Impuslados cuenta el nmero de eventos de entrada que llegan a la
entrada CU. Un evento de salida CUO se produce despus de que cada evento de entrada ha sido
contado. El recuento del nmero de eventos tambin se proporciona en la salida CV. Cuando la
cuenta ha alcanzado el valor de PV, no se producen ms eventos de salida y CV se mantiene en
el valor de PV, la salida Q se pone entonces en true, indicando que la cuenta de eventos est
completa (Figura 5.21).
El contador se puede resetear en cualquier momento por un evento de reinicio en R. La salida
Q se restablece a false, el contador CV se pone en cero y se produce un evento de salida RO.
96
Figura 5.14: Evento Train Table-driven Generator
5.3.
Usando Bloques de Funcin de Evento
Est previsto que las herramientas de software proporcionarn definiciones de estos bloques de
funcin de eventos en sus bibliotecas de bloques de funcin estndar. Ahora podemos examinar el
ejemplo de la cadena de eventos cclicos como se muestra en la Figura 5.2 y ver cmo los eventos
pueden ser modelados usando los bloques de funcin de eventos estndar. La Figura XXX muestra
cmo el esquema de eventos tal como se representa en la Figura 5.2 se puede crear mediante la
insercin de bloques de funcin de eventos estndar.
El evento de arranque en fro es proporcionado por una instancia del generador de eventos de
reinicio (ver FB_E3). El tren de eventos necesario para mantener la ejecucin cclica de las dos
cadenas de bloques de funcin es proporcionado por un Generador de Evento Cclico (ver FB_E4).
El evento de arranque en fro y el tren de eventos se fusionan con un Evento Merger (ver FB_E5).
La secuencia de eventos fusionada resultante se utiliza para desencadenar la ejecucin de FB1. La
secuencia de eventos que emerge de FB1 se divide en dos flujos de eventos para ejecutar las dos
cadenas de bloques de funcin por medio de un Evento Splitter (ver FB_E1).
Los flujos de eventos finales de las dos cadenas de bloques de funcin, es decir, de FB2b y
FB3b, pasan luego por un bloque de Encuentro de Dos Eventos (ver FB_E2). Esto asegura que la
ejecucin de ambas cadenas de bloques de funcin est completa antes de la ejecucin del bloque
final FB4.
5.4. RESUMEN
97
Figura 5.15: Evento Independiente Train Table-driven Generator

Se puede argumentar que la adicin de los bloques de funcin de eventos agrega detalles adicionales que hacen las redes de bloques de funcin demasiado complejas. Sin embargo, cabe sealar
que el diagrama resultante es ahora un modelo formal que define el orden de ejecucin del bloque
de forma precisa y sin ambigedades.
Para simplificar los diagramas de bloques de funcin, los estados estndar que algunos eventos
de uso comn construyen pueden estar representados por una notacin abreviada grfica. La Figura
5.23 muestra cmo conectores grficos simples se pueden utilizar en lugar de bloques de Eventos
Splitter y Merger.
Nota: Si se utilizan conectores grficos de esta manera, las herramientas de software deben
registrar que cada conector representa un tipo particular de Bloque de Funcin de Evento. Esto es
particularmente importante si el diagrama se convierte en una forma textual.
5.4. Resumen
Ahora hemos cubierto todos los bloques de funcin de eventos estndar definidos en la norma
IEC 61499 y visto que estos pueden ser utilizados para modelar una amplia gama de diferentes
esquemas de eventos, por ejemplo, desde redes en las que los bloques de funcin slo estn obligados a ejecutarse una vez, por ejemplo como respuesta a un arranque en fro del sistema, hasta
redes complejas donde hay cadenas paralelas de bloques que requieren ejecucin cclica.
En resumen:
Bloques de funcin de eventos proporcionan una definicin precisa del comportamiento del
evento.
98
Figura 5.16: Evento Impulsado Bistable (Set Dominante)
Figura 5.17: Evento Impulsado Bistable (Reset Dominante)

Los eventos pueden ser creados para situaciones comunes, tales como el sistema de arranque en fro y reinicio caliente.
Trenes de eventos pueden ser creados donde se producen eventos a intervalos regulares.
Los eventos pueden ser combinados y encontrados.
Los eventos pueden ser producidos cuando Booleanos cambian de estado.
Conectores grficos simples pueden ser usados para representar bloques de eventos comunes.
5.4. RESUMEN
99
Figura 5.18: D (Data Latch) Bistable
Figura 5.19: Detector de Flanco Ascendente Booleano
100
Figura 5.20: Detector de Flanco Descendente Booleano
Figura 5.21: Contador de Eventos Impulsados
5.4. RESUMEN
101
Figura 5.22: Usando Bloques de Funcin de Evento
Figura 5.23: Notacin Abreviada Grfica

Modelling Control Systems en Español

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Modelling Control Systems en Español

Uploaded by

Copyright:

Available Formats

Modelling Control Systems using IEC 61499

2. Modelos y Conceptos IEC 61499

3. Definicin de Tipo Bloque de Funciones y Subaplicacin

4. Bloques de Funcin de Interfaz de Servicio

Figura 1.1: Sistema de control distribuido

Figura 1.2: Sistema de control por PLC

lenguaje de programacin y se ejecutan en la misma mquina. El tiempo de desarrollo significativo

Figura 1.3: Funcionalidad distribuida avanzada

1.1. BLOQUE DE FUNCIN ESTNDAR IEC 61499

permiten a todos "integracin tcnica" de componentes distribuidos, pero el siguiente obstculo

Bloque de Funcin Estndar IEC 61499

La Comisin Electrotcnica Internacional (IEC) ha desarrollado un nuevo estndar IEC 61499

Fase de Diseo Funcional

Figura 1.4: Aplicacin de la norma IEC 61499

Fase de Distribucin Funcional

1.1. BLOQUE DE FUNCIN ESTNDAR IEC 61499

Figura 1.5: Flujo de datos y eventos en bloques de funcin

Figura 1.6: Desarrollo de la tecnologa de control industrial

Desarrollo del Concepto de Bloque de Funciones tras la

(a) Red de bloques de funcin

(b) Red con Realimentacin

Figura 1.7: Bloques de funcin usando la norma IEC 61131-3

Figura 1.8: Seales EN y ENO usando la norma IEC 61131-3

Figura 1.9: Modelo de software IEC 61131-3

Comunicaciones de los Bloques de Control

1.3. IEC 61499 - UNA NORMA EN DESARROLLO

1.3. IEC 61499 - Una norma en Desarrollo

Figura 1.10: Estructura del Grupo de Trabajo IEC

1.4. POR QU USAR BLOQUES DE FUNCIN?

1.4. Por qu Usar Bloques de Funcin?

1.5. VISIONES DE DISEO DEL SISTEMA

Una clase objeto

Cuadro 1.1: Objetos y bloques de funcin en comparacin

1.5. Visiones de Diseo del Sistema

Figura 1.11: El Modelo 4+1 de Puntos de Vista de desarrollo del sistema

1.5. VISIONES DE DISEO DEL SISTEMA

Punto de Vista Lgico

Punto de Vista de Proceso

Punto de Vista de Desarrollo

Punto de Vista Fsico

1.6. El Futuro Ms All de la Norma IEC 61499

CAPTULO 2. MODELOS Y CONCEPTOS IEC 61499

Figura 2.1: Modelo del Sistema IEC 61499

Modelo del Sistema

A nivel fsico, un sistema distribuido consta de un conjunto de dispositivos interconectados

Modelo del Dispositivo

2.3. MODELO DEL RECURSO

Figura 2.2: Modelo del Dispositivo

2.3. Modelo del Recurso

CAPTULO 2. MODELOS Y CONCEPTOS IEC 61499

Figura 2.3: Modelo del Recurso

2.4. MODELO DE APLICACIN

Figura 2.4: Modelo de Aplicacin

2.4. Modelo de Aplicacin

CAPTULO 2. MODELOS Y CONCEPTOS IEC 61499

Modelo de Bloque de Funcin

En el ncleo de la norma es el modelo de bloque de funcin el que sustenta toda la arquitectura

2.5. MODELO DE BLOQUE DE FUNCIN

Figura 2.5: Caractersticas de un Bloque de Funcin

CAPTULO 2. MODELOS Y CONCEPTOS IEC 61499

2.6. Tipos de Bloques de Funcin

Bloque de Funcin Bsico

Bloque de Funcin Compuesto