Post on 27-Sep-2018
Máster en Ingeniería de Control, Automatización y Robótica
Trabajo Fin de Máster
II mmpplleemmeennttaacciióónn ddee SSiisstteemmaass EEmmppoottrr aaddooss ddee CCoonnttrr ooll DDiissttrr iibbuuiiddooss bbaajj oo eell EEssttáánnddaarr
II EECC--6611449999
Alumno: Ing. Marcelo Vladimir García Sánchez Director: Dr. Federico Pérez González Fecha: 16/09/2013
2
TABLA DE CONTENIDO
1. MOTIVACIÓN Y OBJETIVOS ......................................................................................................................... 3
1.1. MOTIVACIÓN ................................................................................................................................................. 3 1.2. OBJETIVOS ..................................................................................................................................................... 5
2. ESTADO DEL ARTE ....................................................................................................................................... 6
2.1. ESTÁNDAR IEC-61131 .................................................................................................................................... 6 2.1.1. Modelo de Software IEC-61131 ............................................................................................................................ 8 2.1.2. Justificación de un nuevo Estándar ...................................................................................................................... 9
2.2. ESTÁNDAR IEC-61499 .................................................................................................................................. 10 2.2.1. Especificaciones IEC -61499................................................................................................................................ 11 2.2.2. Arquitectura ....................................................................................................................................................... 11
• Modelo de Bloque Funcional (FB) ................................................................................................................ 12 • Modelo de Recurso ...................................................................................................................................... 13 • Modelo de Dispositivo .................................................................................................................................. 14 • Modelo de Sistema ....................................................................................................................................... 15
• Modelo de Aplicación ................................................................................................................................... 15 • Modelo de Distribución ................................................................................................................................ 16 • Modelo de Gestión ....................................................................................................................................... 17
2.2.3. Ambigüedades en la Semántica de IEC-61499 ................................................................................................... 18 2.3. ENTORNOS DE DESARROLLO Y DE EJECUCIÓN DE LA NORMA IEC-61499 ................................................................. 20
2.3.1 FBDK / FBRT ......................................................................................................................................................... 23 2.3.2 4DIAC-IDE / FORTE .............................................................................................................................................. 24 2.3.3 Próximos Pasos en los entornos de desarrollo .................................................................................................... 26
3. SOLUCIÓN PROPUESTA ............................................................................................................................. 28
3.1 RASPBERRY PI ............................................................................................................................................... 28 3.1.1. Hardware de Raspberry PI .................................................................................................................................. 28 3.1.2. Software para Raspberry PI ................................................................................................................................ 29 3.1.3. GPIO y Placa de expansión GERTBOARD ............................................................................................................ 30
3.2. GENERACIÓN DE BLOQUES FUNCIONALES DE INTERFAZ DE SERVICIO (SIFB) ............................................................... 32 3.2.1. Elementos básicos de un SIFB ............................................................................................................................ 32 3.2.2 Especificaciones del SIFB ..................................................................................................................................... 34
3.3. METODOLOGÍA DE DISEÑO DE FBS ................................................................................................................... 37 3.4 FBS DESARROLLADOS ..................................................................................................................................... 39
3.4.1 FB GERTBOARD_OUT........................................................................................................................................... 40 3.4.2 FB GERTBOARD_IN .............................................................................................................................................. 41
4. CASO DE USO ............................................................................................................................................ 42
4.1 FB MAQUETA_CINTA .............................................................................................................................................. 43 4.2 FB MAQUETA_MANIPULADOR ............................................................................................................................... 44 4.3 Diseño de la Aplicación de Control ......................................................................................................................... 45 4.4 Diseño de la Configuración del Sistema ................................................................................................................. 47
4.4.1 Configuración del recurso HMI ...................................................................................................................... 47 4.4.2 Configuración del recurso RPI_CINTA ............................................................................................................ 49 4.4.3 Configuración del recurso RPI_MANIPULADOR ............................................................................................. 50
4.5. Diseño etapa de Acondicionamiento de señal para Raspberry PI ......................................................................... 51
5. CONCLUSIONES Y LÍNEAS FUTURAS .......................................................................................................... 54
6. BIBIOGRAFÍA ............................................................................................................................................. 55
Marcelo García: Implementación de Sistemas Empotrados de Control Distribuidos bajo el Estándar IEC-
61499
Máster en Ingeniería de Control, Automatización y Robótica 3
1. MOTIVACIÓN Y OBJETIVOS
1.1. Motivación
Los procesos de fabricación y producción se realizan cada vez más por sistemas y
soluciones automatizadas y en consecuencia, el nivel de automatización en las fábricas
y plantas aumenta de manera constante [1]. A medida que el nivel absoluto de
automatización aumenta, también lo hace la complejidad, por el creciente número de
sensores, actuadores, controladores o PLCs de diferentes fabricantes que se utilizan en
las plantas y sistemas de fabricación, por lo tanto, requisitos de interoperabilidad,
capacidad de configuración y portabilidad son difíciles de alcanzar en los sistemas
constituidos por elementos tan diversos.
Otra tendencia importante en la automatización industrial es la creciente necesidad de
plantas personalizadas e individualizadas, lo que significa que las líneas de producción
tendrán que ser construidas y adaptadas a los nuevos procesos lo más rápidamente
posible [2].
Durante varios años el estándar IEC-61131 ha sido la principal norma en el ámbito de la
automatización industrial, creada y adoptada en 1992 con el fin de estandarizar los
lenguajes de programación en este campo y ha permitido diseñar e implemetar sistemas
de producción más flexibles y reconfigurables [3]. Con el desarrollo de nuevas
tecnologías presenta dificultades en su aplicación. Es por esto que en el año 2005 la
Comisión Electrotécnica Internacional (IEC) lanzó la norma internacional IEC-61449
que actualmente aún se encuentra en proceso de consolidación. Esta norma proporciona
más funcionalidades, solventando algunas de las limitaciones de su norma predecesora.
Es desarrollado como una metodología para modelar Sistemas de Control y Medida de
Procesos Industriales (IPMCS)[4] distribuidos y abiertos. El objetivo es obtener una
aplicación y configuración de hardware independiente del proveedor con el fin de
gestionar la creciente complejidad de los sistemas de automatización de última
generación.
El elemento central de la norma IEC-61499 es el Bloque de Función (FB) que permite
la encapsulación de software de control. Los FBs pueden ser posteriormente enviados a
los dispositivos de campo inteligentes [5]. El FB básico encapsula cierta funcionalidad
Marcelo García: Implementación de Sistemas Empotrados de Control Distribuidos bajo el Estándar IEC-
61499
Máster en Ingeniería de Control, Automatización y Robótica 4
tales como: control, operaciones matemáticas, comunicación, etc, por medio de
algoritmos. Para crear dichos algoritmos de control se pueden utilizar lenguajes de
programación de alto nivel tales como C, C++, o los lenguajes estandarizados bajo la
norma IEC 61131.
La herramienta software a utilizar para modelar un sistema de control distribuido
basado en el estándar IEC-61499 se denomina 4DIAC-IDE (Framework for Distributed
Industrial Automation and Control), el cual, contribuye en el desarrollo e investigación
del estándar y sirve de estímulo en la cooperación entre la industria y los institutos de
investigación. El objetivo de 4DIAC es la obtención de un entorno abierto de
automatización y control basado en el estándar IEC-61449 proporcionando las
siguientes características [6]:
• Portabilidad : soporta e interpretar correctamente configuraciones y componentes
software creadas por otras herramientas software.
• Interoperabilidad : los distintos dispositivos integrados pueden funcionar
conjuntamente para llevar a cabo las funciones propias de las aplicaciones
distribuidas.
• Configurabilidad : cualquier dispositivo y sus componentes software pueden ser
configurados por herramientas de software de múltiples proveedores.
• Reconfigurabilidad: es la habilidad para adaptar el hardware y software de control
durante la operación del proceso.
• Distribución : la habilidad para distribuir componentes software en diferentes
dispositivos hardware sin importar el proveedor, el cual, es un requisito necesario
dado por la industria de la automatización.
El runtime de 4DIAC es 4DIAC-RTE (FORTE), que es una implementación conforme a
IEC-61499 enfocado a pequeños dispositivos de control empotrados (16/32Bit) está
implementado en C++ y puede ser aplicado sobre múltiples plataformas.
Mediante la utilización de 4DIAC se van a desarrollar nuevos FBs que junto con los ya
existentes en el estándar se creará la aplicación de control deseada que posteriormente
se mapeara en los diferentes recursos dentro del mismo dispositivo con una parte
localizada en dos dispositivos remotos formando un sistema de control distribuido.
Marcelo García: Implementación de Sistemas Empotrados de Control Distribuidos bajo el Estándar IEC-
61499
Máster en Ingeniería de Control, Automatización y Robótica 5
A pesar de que durante los últimos años muchos investigadores han estado trabajando
en el desarrollo y evolución del estándar IEC-61499 aún queda un largo camino por
recorrer para su adopción por la industria ya que, son necesarias aún más
modificaciones y ampliaciones a la norma con el fin de ser utilizado con eficacia en el
contexto de los sistemas de control distribuidos de automatización industrial.
El objetivo de este documento es proponer la integración de una plataforma de control
distribuido bajo el estándar IEC-61499 utilizando el runtime FORTE en dispositivos
embebidos de bajo costo, centrándonos en la Raspberry PI la cual es muy utilizada en el
ámbito de la investigación académica pero con aplicaciones industriales es poco
conocido su uso.
1.2. Objetivos
• Integrar la plataforma IEC-61499 utilizando el runtime 4DIAC-FORTE en un
sistema empotrado de bajas prestaciones y un entorno de desarrollo de libre
distribución como Raspberry PI.
• Diseñar Bloques de Funciones bajo el estándar IEC-61499 para manipular las
entradas y salidas digitales y analógicas del Raspberry PI desde un entorno
4DIAC-IDE .
• Implementar una aplicación de control distribuido que utilice el sistema
empotrado Raspberry PI bajo el entorno 4DIAC-IDE
Marcelo García: Implementación de Sistemas Empotrados de Control Distribuidos bajo el Estándar IEC-
61499
Máster en Ingeniería de Control, Automatización y Robótica 6
2. ESTADO DEL ARTE
En el desarrollo de este capítulo se describirá los antecedentes, la evolución y el estado
actual del estándar IEC-61499.
En la primera parte del capítulo se describe los principios básicos del estándar IEC-
61131 el cual es la normal principal en los procesos de automatización industrial, siendo
este el punto de partida para el desarrollo del estándar IEC-61499 el cual se encuentra
en proceso de consolidación y estudio.
Posteriormente se procede a describir los principios, conceptos básicos, modelos de
referencia de la arquitectura y semántica de ejecución del estándar IEC-61499 para lo
cual se usará como fuente de referencia los distintos trabajos de estado del arte
relacionados con este apartado.
Finalmente se realizará un pequeño resumen de las características principales de los
diferentes sistemas de desarrollo y entornos de ejecución del estándar IEC-61499 que se
están utilizando a nivel académico y de la industria.
2.1. Estándar IEC-61131
IEC-61131 es el primer paso en la estandarización de los autómatas programables y sus
periféricos, incluyendo los lenguajes de programación que se deben utilizar. El objetivo
básico de esta norma durante varios años fue la creación de lenguajes de programación
estándar para aplicaciones de automatización industrial, el cual, fuera fácil de usar por
el promedio de ingenieros, aun cuando no posean el conocimiento especializado sobre
los dispositivos de control y automatización a ser programados. Este esfuerzo fue
necesario porque, desde la invención del Controlador Lógico Programable (PLC) hace
50 años aproximadamente, un gran número de lenguajes de programación y dispositivos
han sido creados y vendidos por varios fabricantes a nivel mundial. Se alcanzó este
difícil objetivo, gracias al compromiso de los fabricantes y estudios de varios grupos de
investigación académicos especializados, entre ellos el que más ha realizado estudios
sobre esta norma es PLCopen.
Marcelo García: Implementación de Sistemas Empotrados de Control Distribuidos bajo el Estándar IEC-
61499
Máster en Ingeniería de Control, Automatización y Robótica 7
Esta norma se divide en cinco partes:
• Parte 1: Vista general.
• Parte 2: Hardware.
• Parte 3: Lenguaje de programación.
• Parte 4: Guías de usuario.
• Parte 5: Comunicación.
Hay muchas maneras de describir el trabajo desarrollado en la tercera parte de esta
norma, indicaremos algunas de ellas: IEC 61131-3 es el resultado del gran esfuerzo
realizado por 7 multinacionales a los que se añaden muchos años de experiencia en el
campo de la automatización industrial. Incluye 200 páginas de texto aproximadamente,
con más de 60 tablas. IEC 61131-3 son las especificaciones de la sintaxis y semántica
de un lenguaje de programación, incluyendo el modelo de software y la estructura del
lenguaje.
IEC 61131-3 estandariza los lenguajes de programación en la automatización industrial,
haciendo el trabajo independiente de cualquier compañía. IEC-61131 define 5 lenguajes
de programación de los cuales 2 son textuales y 3 son gráficos siendo los siguientes [7]:
Lenguajes Textuales:
• Lista de Instrucciones (IL, Instruction List)
• Texto Estructurado (ST, Structured Text)
Lenguajes Gráficos:
• Diagrama de contactos (LD, Ladder Diagram)
• Diagrama de Bloques de funcionales (FBD, Function Block Diagram)
• Gráfica de función secuencial (SFC, Sequential Function Chart)
Sin embargo, la semántica de estos lenguajes no está definida estrictamente, por lo que
esto conlleva a la incompatibilidad del software de control entre los diferentes
fabricantes.
Marcelo García: Implementación de Sistemas Empotrados de Control Distribuidos bajo el Estándar IEC-
61499
Máster en Ingeniería de Control, Automatización y Robótica 8
2.1.1. Modelo de Software IEC-61131
El modelo software de este estándar está representado en capas, cada capa posee varias
características. A continuación se detallan los elementos necesarios para proporcionar el
entorno software de PLC [8].
• Configuración. Es un elemento de lenguaje que corresponde al sistema del
autómata programable en el cual se encuentra el software específico para un
problema de control particular.
• Recurso. El recurso proporciona un soporte para la ejecución de programas. El
recurso puede declarar variables globales, tareas y programas asociados a las
tareas, el cual, puede ser asociado a un procesador determinado.
• Tarea. La tarea es el elemento que controla la ejecución de programas y de
bloques funcionales.
• Unidades de organización de programa (POU): funciones, bloques
funcionales y programas. Las funciones son similares a las usadas en otros
lenguajes, aceptando entradas y devolviendo un valor. El cuerpo del bloque
funcional es un algoritmo que procesa los datos y está escrito en alguno de los
lenguajes IEC-61131.
• Variables globales y locales. Pueden ser declaradas en configuraciones,
recursos o programas. Esto permite su uso dentro de programas o FBs
Fig. 1: Modelo Software IEC-61131-3
Marcelo García: Implementación de Sistemas Empotrados de Control Distribuidos bajo el Estándar IEC-
61499
Máster en Ingeniería de Control, Automatización y Robótica 9
Al más alto nivel, el elemento software requerido para solucionar un problema de
control particular puede ser formulado como una configuración. Una configuración es
específica para un tipo de sistema de control, incluyendo las características del
hardware: procesadores, direccionamiento de la memoria para los canales de I/O y otras
capacidades del sistema.
Dentro de una configuración, se pueden definir uno o más recursos. Se puede entender
el recurso como un procesador capaz de ejecutar programas IEC-61131.
Con un recurso, pueden estar definidas una o más tareas. Las tareas controlan la
ejecución de un conjunto de programas y/o bloques de función. Cada una de ellos puede
ser ejecutada periódicamente o por una señal de disparo especificada, como el cambio
de estado de una variable.
Los programas están diseñados a partir de un diferente número de elementos de
software, escrito en algunos de los distintos lenguajes definidos en IEC 61131-3.
Típicamente, un programa es una interacción de Funciones y Bloques Funcionales, con
capacidad para intercambiar datos. Funciones y bloques funcionales son las partes
básicas de construcción de un programa, que contienen una declaración de datos y
variables y un conjunto de instrucciones.
Comparado esto con un PLC convencional, éste contiene un solo recurso, ejecutando
una tarea que controla un único programa de manera cíclica. IEC 61131-3 incluye la
posibilidad de disponer de estructuras más complejas.
2.1.2. Justificación de un nuevo Estándar
A pesar de que los conceptos y las sintaxis es la misma para todas las herramientas de
programación IEC-61131, sin embargo, la semántica de los elementos del lenguaje
están definido de manera ambigua en el apartado IEC 61131-3. Es por esto, que las
herramientas de software interpretan el estándar de manera distinta lo que resulta en una
ejecución completamente diferente usando el mismo código. Por lo tanto no es posible
transferir la configuración de una herramienta a otra y de esta manera preservar toda la
información requerida para una ejecución correcta del algoritmo de control.
Adicional en el aspecto de la reconfigurabilidad, el cual, es un problema de las
Marcelo García: Implementación de Sistemas Empotrados de Control Distribuidos bajo el Estándar IEC-
61499
Máster en Ingeniería de Control, Automatización y Robótica 10
herramientas más no del estándar, IEC-61131 no define los medios para crear
dinámicamente nuevos recursos en una configuración, así como no hay definiciones
para el intercambio de algoritmos sobre la marcha. Sin embargo, como existe la
necesidad de reconfiguración, en función del controlador y/o de la herramienta, se han
previsto diferentes soluciones. Los controladores de gama media y baja tienden a
carecer de esta funcionalidad, en la mayoría de los casos, simplemente porque no se
requiere o no existe una demanda real de los usuarios. Para grandes controladores, la
reconfiguración suele ser plenamente compatible con los recursos.
Otro aspecto importante es la distribución, que en esta norma se reduce principalmente
al apoyo a la comunicación. IEC 61131-5 define conceptos y FBs para la comunicación
entre PLCs, y éstas son implementadas por muchos vendedores de herramientas IEC
61131-3.
Por los motivos mencionados anteriormente, es necesaria la implementación de un
nuevo estándar el cual ofrezca una vista complementaria y una solución eficaz a
problemas similares o más complejos de los que la norma IEC-61131 podría resolver.
2.2. Estándar IEC-61499
Fue creado para sistemas de control distribuido, incluyendo su arquitectura y los
requisitos de herramientas de software. Se desarrolló como consecuencia del creciente
interés en las nuevas tecnologías y arquitecturas para crear la próxima generación de
sistemas industriales y teniendo como base el estándar IEC-61131. Diseñado por el
comité técnico TC 65 de medida, control y automatización de procesos industriales (TC,
Technical Committee), que pertenece a la IEC, siendo aprobada la primera versión en
Agosto de 2005 [9]. Define una arquitectura genérica y una guía para el uso del Bloque
Funcional (FB) en Sistemas de Control y Medición de Procesos Industriales
Distribuidos (IPMCSs).
Uno de los principales objetivos de IEC-61499, es promover el desarrollo de sistemas
heterogéneos compuestos de dispositivos de control de diferentes fabricantes y
adicional permitiendo la reconfiguración dinámica, es decir, cambiar la configuración
de un sistema mientras la aplicación de control continúa ejecutándose.
Marcelo García: Implementación de Sistemas Empotrados de Control Distribuidos bajo el Estándar IEC-
61499
Máster en Ingeniería de Control, Automatización y Robótica 11
IEC-61499, es visto como la siguiente generación de estándares en sistemas de
automatización y está diseñado para cubrir interoperabilidad, portabilidad y
reconfigurabilidad, que no están contemplados en IEC-61131-3. Por el momento, en la
práctica industrial son pocos los sistemas basados en IEC-61499, pero actualmente, una
gran cantidad de trabajos de investigación aceptan y utilizan los conceptos básicos del
estándar.
2.2.1. Especificaciones IEC -61499
El estándar IEC-61499 se divide en los siguientes 4 apartados [10]:
a) Arquitectura . IEC 61499-1, contiene requisitos generales, definiciones y modelos
de referencia. Reglas para la declaración de tipos de FBs y reglas para su
comportamiento.
b) Requisitos de herramienta software. IEC 61499-2, define requisitos de
herramientas software, que soportan la ejecución de las tareas de ingeniería de
sistemas y especificación de tipos de FBs.
c) Manual Informativo . IEC 61499-3, contiene la información para el entendimiento,
la aceptación y la aplicabilidad, tanto de la arquitectura IPMCS, como de
herramientas software que cumplan con las especificaciones del estándar.
d) Reglas y Perfiles de Conformidad. IEC 61499-4, contiene la definición de las
reglas para el desarrollo de perfiles de conformidad, las cuales especifican las
características para implementar los apartados 1 y 2.
2.2.2. Arquitectura
IEC-61499 define una arquitectura genérica y jerárquica de modelos, permitiendo
entender la organización del sistema y sus componentes. Desarrolla una nueva
estructura para aplicaciones de control distribuido. Los modelos son genéricos,
independientes del dominio y extensibles con la definición y uso de FBs. Los modelos
son:
Marcelo García: Implementación de Sistemas Empotrados de Control Distribuidos bajo el Estándar IEC-
61499
Máster en Ingeniería de Control, Automatización y Robótica 12
• Modelo de Bloque Funcional (FB)
Es el elemento más pequeño en un sistema de control distribuido. El FB consiste en una
cabeza que está conectada al flujo de eventos. Acepta entrada de eventos y genera salida
de eventos, como se representa en la Figura 2. El cuerpo está conectado al flujo de
datos, acepta datos de entrada y genera datos de salida. El comportamiento dinámico del
FB está definido por la Gráfica de Control de ejecución (siglas en inlglés: ECC,
Execution Control Chart) que procesa entrada de eventos y genera salida de eventos
[11]
Un FB en el IEC 61499-1, se mantiene pasivo hasta que es disparado por una entrada de
evento, es decir, es decir, estos eventos son usados para activar un bloque funcional. El
FB ejecuta y produce eventos y datos de salida como se representa en la Figura 2.
El ECC describe el comportamiento interno de las instancias de los FBs básicos. Ayuda
al programador a descomponer el comportamiento complejo en pequeñas partes
llamados estados. Cada estado es válido bajo un cierto conjunto de condiciones. Los
estados son asociados con uno o más algoritmos y/o con eventos de salida. La
activación del estado implica la ejecución de los algoritmos adjuntos.
Fig. 2: Modelo de Bloque Funcional
La funcionalidad del FB esta proporcionada por medio de algoritmos. Un algoritmo
puede ser escrito en cualquiera de los 5 lenguajes que menciona el IEC 61131-3: IL, ST,
LD, FBD y SFC. También en otros lenguajes de alto nivel como: C, C++, Java y Delphi
Marcelo García: Implementación de Sistemas Empotrados de Control Distribuidos bajo el Estándar IEC-
61499
Máster en Ingeniería de Control, Automatización y Robótica 13
El algoritmo procesa entradas y datos internos, generando datos de salida. Las variables
internas o información de estado no son accesibles por el flujo de datos.
Define tres diferentes tipos de bloques funcionales [12]:
• FB Básico: Unidad más pequeña de programación. Consta de dos partes: ECC y
algoritmos.
• FB Compuesto: Compuesto por una red de instancias de FBs interconectados.
• FB Interfaz de Servicio: Proporciona servicios a una aplicación, como
interacción entre aplicación y recursos.
• Modelo de Recurso
Considerado una unidad funcional con control independiente de operación, que
proporciona servicio a las aplicaciones, incluyendo planificación y ejecución de
algoritmos [12]. Las funciones son:
• Aceptar los eventos y/o los datos de las interfaces de proceso y comunicaciones.
• Procesar los eventos y/o los datos, regresar los eventos y/o los datos a las
interfaces de proceso y comunicaciones, como se indican en la Figura 3.
Fig. 3: Modelo de recurso
El recurso en esta norma está modelado por tres elementos:
• Aplicación Local (o parte local de aplicación distribuida): Posee variables y
eventos de entrada y salida de los diferentes bloques funcionales que ejecutan
las operaciones necesarias por la aplicación.
Marcelo García: Implementación de Sistemas Empotrados de Control Distribuidos bajo el Estándar IEC-
61499
Máster en Ingeniería de Control, Automatización y Robótica 14
• Interfaz de Proceso: Su principal objetivo es ejecutar un mapeo de eventos y
datos entre las aplicaciones e interfaces de proceso, esto se logra mediante el uso
del Bloque de Función de Interfaz de Servicio (SIFB)
• Interfaz de Comunicación: Al igual que la interfaz anterior su función es
realizar el mapeo de eventos y datos entre las aplicaciones e interfaces de
comunicaciones, se lleva a cabo con la SIFBs
• Modelo de Dispositivo
Es una entidad física independiente, capaz de realizar una o más funciones específicas
en un contexto particular delimitado por sus interfaces (de proceso y de comunicación)
[13]. Se considera un contenedor de recursos, que proporciona un entorno de ejecución
para aplicaciones. Un dispositivo puede ser conectado a más de un segmento. Podemos
notar que posee dos tipos de interfaces:
• Interfaz de Proceso: permite la comunicación entre otros dispositivos y
aplicaciones
• Interfaz de Comunicación: Logra la comunicación entre los dispositivos y
aplicaciones del proceso.
Su modelo se representa en la Figura 4.
Fig. 4: Modelo de dispositivo
Marcelo García: Implementación de Sistemas Empotrados de Control Distribuidos bajo el Estándar IEC-
61499
Máster en Ingeniería de Control, Automatización y Robótica 15
• Modelo de Sistema
Consiste en una colección de dispositivos interconectados y comunicados entre sí, por
medio de una red de comunicaciones a través de segmentos y enlaces para formar un
conjunto de cooperación de aplicaciones [13]. Describe un segmento de red de un cierto
tipo, al cual varios dispositivos son conectados a través de enlaces. Se puede modelar
como se representa en la Figura 5.
Fig. 5: Modelo de sistema
• Modelo de Aplicación
Es una unidad funcional de software específica para la solución de un problema en
medición de procesos industriales o de control. Puede distribuirse entre varios recursos,
en el mismo o en diferentes dispositivos (subaplicación) y puede comunicarse con otras
aplicaciones. Usa las relaciones especificadas por la aplicación para determinar la
respuesta apropiada de eventos entre las interfaces de proceso y comunicación. Usando
una programación y ejecución de algoritmos internos permite la modificación de
variables, generación de eventos adicionales e interacciones con interfaces de proceso y
comunicación.
Cada aplicación está formada por una red de FBs, especificando el flujo de datos y
eventos entre las FBs, como se representa en la Figura 6.
Marcelo García: Implementación de Sistemas Empotrados de Control Distribuidos bajo el Estándar IEC-
61499
Máster en Ingeniería de Control, Automatización y Robótica 16
Fig. 6: Modelo de aplicación
• Modelo de Distribución
La fase final del proceso de desarrollo de la aplicación en IEC 61499-1 es la
distribución de la aplicación de control entre los dispositivos de control. En este paso
los FBs de la aplicación serán mapeados a los dispositivos de control donde serán
ejecutados.
Una aplicación puede ser distribuida colocando las instancias de los FBs que forman la
aplicación sobre los diferentes recursos en uno o más dispositivos [14]. Este modelo se
representa en la Figura 7.
Fig. 7: Modelo de distribución
Marcelo García: Implementación de Sistemas Empotrados de Control Distribuidos bajo el Estándar IEC-
61499
Máster en Ingeniería de Control, Automatización y Robótica 17
• Modelo de Gestión
Proporciona herramientas para la gestión de la relación de los recursos con los
dispositivos. El estándar propone dos esquemas [15]:
• Primer esquema, presenta la gestión de recursos compartidos que proporciona
facilidades para la gestión de otros recursos dentro de un dispositivo.
• Segundo esquema, presenta la gestión de servicios de distribución de recursos
dentro de un dispositivo.
La configuración de un IPMCS distribuido basado en IEC-61499 puede ser permitida
por el uso de funciones de gestión, las cuales pueden ser incluidas en cada dispositivo.
Para este propósito el estándar define un dispositivo de gestión y su interfaz, que es un
tipo de FB de gestión.
En la Figura 8, se muestra la representación del conjunto de modelos IEC-61499.
Fig. 8: Modelo de gestión
Marcelo García: Implementación de Sistemas Empotrados de Control Distribuidos bajo el Estándar IEC-
61499
Máster en Ingeniería de Control, Automatización y Robótica 18
2.2.3. Ambigüedades en la Semántica de IEC-61499
La norma IEC-61499 define la semántica para los FBs básicos y compuestos y sus redes
de comunicación. Estas definiciones han llamado la atención de muchos investigadores
y grupos de investigación a nivel mundial, cuya atención se centra ahora en la
ampliación del desarrollo y la promoción de la automatización inteligente distribuida,
en general, y en IEC-61499, en particular.
Incluso los primeros estudios, llevados a cabo durante el desarrollo de la norma y el
período de aprobación en el área industrial y académica (aproximadamente 2000-2003),
han señalado algunas debilidades semánticas. Siendo, algunas ambigüedades reportadas
las relacionadas con el tiempo de vida de los eventos variables en la ejecución del ECC
y las diferentes posibilidades de programación en las estructuras compuestas de los FB
[16]
Adicionalmente los siguientes puntos tienen ambigüedades y son temas abiertos de esta
norma: la efectividad del uso de requisitos, la fase del diseño de la arquitectura y la
semántica de ejecución.
• Efectividad del uso de requisitos. Los requisitos del estándar mencionan al FB
como la principal construcción que se puede realizar en esta norma, sin
embargo, los grupos de investigación académicos consideran que la Red de FBs
sea la primera especificación de la aplicación en el desarrollo de procesos.
• Fase del diseño de la arquitectura. La arquitectura de software debe ser
definida en las primeras fases de desarrollo basado en los requisitos para el
sistema.
• Semántica de ejecución. El estándar da una definición clara de la base de la
semántica de ejecución. Pero para los tipos de FBs son indefinidas. La semántica
de ejecución sigue en constantes modificaciones, lo que crea algunas
ambigüedades.
Estas ambigüedades tienen que ser abordadas, de tal forma se diseñan nuevas
alternativas de diseño, las cuales todavía están en proceso de ser aceptadas para
modificar el estándar.
Marcelo García: Implementación de Sistemas Empotrados de Control Distribuidos bajo el Estándar IEC-
61499
Máster en Ingeniería de Control, Automatización y Robótica 19
En trabajos posteriores ejemplo [17],[18] y [19], las ambigüedades de la semántica de la
norma IEC-61499 fueron clasificadas y analizadas en detalle, mostrando un posible
impacto en las diferentes interpretaciones en el correcto control de aplicaciones.
La implementación de dispositivos compatibles y sistemas bajo la norma IEC-61499
son logrados por compiladores que traducen el código fuente de FBs y aplicaciones
construidas por estos compiladores en código ejecutable y/o por entornos de ejecución
que interpretan el código fuente o el código ejecutable compilado. En el desarrollo de
estos compiladores, por lo expuesto anteriormente, pueden tomar diferentes decisiones
en cuestiones ambiguas, y, como resultado, la misma aplicación de control se ejecuta de
manera diferente en los dispositivos de control de varios vendedores.
Los dos mayores temas en la semántica de FBs han sido identificados e investigados por
los grupos académicos enfocados en esta norma. El primero es el comportamiento de
los FBs básicos y el segundo se refiere a la semántica de las redes de FBs, las cuales
forman las aplicaciones y el cuerpo de FBs compuestas y subaplicaciones. Una
aplicación construida por FBs ya representa un modelo de un sistema distribuido de
control. Sin embargo, la configuración del sistema es un paso más cerca de la realidad,
ya que incluye los detalles de los dispositivos y la comunicación entre ellos.
Obviamente, la semántica de los sistemas distribuidos es aún más complejo para
describir, ya que depende en gran medida de las propiedades de las redes de
comunicación. Los modelos semánticos distribuidos para IEC-61499 aún no se han
propuesto.
Por otro lado [19] argumenta que, “Aunque el IEC-61499 representa un paso importante
hacia una arquitectura de diseño unificada, proporciona una de las cinco vistas de
diseño requeridas para sistemas de control distribuidos..”. También afirma que las
opiniones de los demás diseñadores pueden afrontar los desafíos de construir grandes
sistemas distribuidos a nivel industrial.
Se han hecho varios estudios desde el año 2006. En [20] los autores señalan algunas
maneras de implementación:
• Conexiones entre FBs (Asociaciones de eventos y datos).
• Invocación de FB y disparo de eventos de entrada.
Marcelo García: Implementación de Sistemas Empotrados de Control Distribuidos bajo el Estándar IEC-
61499
Máster en Ingeniería de Control, Automatización y Robótica 20
• Cuántas transiciones pueden ser disparadas con un simple evento de entrada.
• Cuándo los eventos de salida son emitidos.
• Jerarquía de FBs compuestos.
• Tiempo de ejecución de algoritmos y planificación.
• Secuencia de comunicaciones locales.
• Disparador de eventos.
• Predictibilidad de tiempo de respuesta.
Otros investigadores encontraron en sus trabajos algunas limitaciones del estándar IEC-
61499:
• El comportamiento para un simple FB está definido por el ECC, pero el tiempo
de vida de un evento en un ECC no está claro.
• El comportamiento de un FB compuesto para una red no está direccionado, el
entorno de ejecución o runtime usa dos enfoques principales para programar
bloques en una red.
• La secuencia de eventos y el orden de propagación a través de una red.
Respetar las disposiciones de la norma es muy importante cuando se desarrolla una
aplicación comercial. En mi opinión, la eliminación de ambigüedades de la norma no
significa que no sea bueno. Cuando los desarrolladores intentan crear dispositivos y
herramientas que cumplen con la norma IEC 61499, deberán seguir la letra de la norma
(cuando sea posible) o su espíritu (cuando la norma no es insuficiente). Se debe admitir
que los desarrolladores académicos que siguen estrictamente la norma a menudo no han
sido publicados. Sin embargo, esto se puede explicar por la naturaleza de su trabajo de
investigación y la necesidad de ampliar sus horizontes y ver a los nuevos desafíos en la
automatización distribuida. Los implementadores e investigadores industriales tienen
que tener más cuidado en la interpretación de la norma para lograr una verdadera
portabilidad de sus productos y aplicaciones de control.
2.3. Entornos de Desarrollo y de Ejecución de la Norma IEC-61499
Como se ha mencionado anteriormente la parte 1 de la norma IEC-61499 define una
arquitectura de referencia aplicable al desarrollo, reutilización y despliegue de los FBs
en un sistema de control y automatización industrial empotrada (IPCMS). La parte 2 del
Marcelo García: Implementación de Sistemas Empotrados de Control Distribuidos bajo el Estándar IEC-
61499
Máster en Ingeniería de Control, Automatización y Robótica 21
mismo estándar define los requerimientos de las herramientas de software para apoyar
las tareas de ingeniería en el desarrollo de proyectos.
Zoitl en [21] reconoce que estos requisitos por si solos son insuficientes para garantizar
los elementos de software a través de las herramientas, configurabilidad por estas
herramientas de sistemas distribuidos y dispositivos y la interoperablidad de estos
dispositivos dentro de estos sistemas. La parte 4 del estándar IEC-61499 define los
requisitos para los “Perfiles de Conformidad” destinados a garantizar el cumplimiento
de estas cualidades por dispositivos distribuidos compatibles y herramientas de
software. Para que un sistema sea distribuido debe cumplir las siguientes características:
• Portabilidad : Soportar e interpretar correctamente configuraciones y
componentes software, creadas por otras herramientas software.
• Interoperabilidad : Los distintos dispositivos integrados pueden funcionar
conjuntamente para llevar a cabo las funciones propias de las aplicaciones
distribuidas.
• Configurabilidad : Cualquier dispositivo y sus componentes software pueden
ser configurados por otras herramientas de software de múltiples proveedores.
Por ejemplo, los Anexos A y B del IEC-61499 define a XML DTDs (Definición del
Tipo de Documento) para el intercambio de información entre las herramientas de
software, mientras que IEC-61499 requiere que los Perfiles de Conformidad
especifiquen el grado en que las herramientas de software compatibles son capaces de
emplear la sintaxis y la semántica de estos DTDs para lograr la portabilidad de los
elementos de software entre las herramientas [22]. Las relaciones entre las
características mencionadas anteriormente quedan demostradas en la Figura 9.
Marcelo García: Implementación de Sistemas Empotrados de Control Distribuidos bajo el Estándar IEC-
61499
Máster en Ingeniería de Control, Automatización y Robótica 22
Fig. 9: Portabilidad, Reconfigurabilidad e Interoperabilidad del IEC-61499
El entorno de desarrollo integrado, llamado también IDE (siglas en inglés: Integrated
Development Enviroment) es la herramienta de programación que ha sido empaquetado
como un programa de aplicación, es decir, consiste en un editor de código, un
compilador, un depurador y un constructor de interfaz gráfica (GUI) para el diseño de
sistemas de automatización bajo norma IEC-61499. Un entorno de ejecución (siglas en
inglés: RTE, Runtime Environment) es un estado de máquina virtual el cual proporciona
servicios software de procesos o programas mientras un ordenador está ejecutándose.
En la siguiente tabla se muestran los principales sistemas de desarrollo (herramienta
software) y sus entornos de ejecución bajo licencia de código abierto (open source) que
se utilizan actualmente:
ENTORNO DE DESARROLLO (IDE)
ENTORNO DE EJECUCIÓN (RTE)
4DIAC-IDE FORTE FBDK FBRT
ISaGRAF Workbench ISaGRAF Runtime nxtSTUDIO nxtRT61499F32
Tabla 1. Sistemas de Desarrollo y Ejecución de IEC-61499
A continuación se procede a describir los entornos de desarrollo y programación que
son productos comerciales compatibles o disponible como código abierto para IEC-
61499 en especial 4DIAC y FBDK ya que son los más utilizados a nivel académico.
Marcelo García: Implementación de Sistemas Empotrados de Control Distribuidos bajo el Estándar IEC-
61499
Máster en Ingeniería de Control, Automatización y Robótica 23
2.3.1 FBDK / FBRT
• Entorno de desarrollo: FBDK
Esta es la herramienta de software original de IEC-61499. Fue desarrollado en un inicio
como una simple aplicación JAVA [23] para dibujar FBs y redes de FBs, porque su
autor, un miembro del Grupo de Trabajo IEC (actualmente Grupo de Trabajo 15 del
IEC subcomité SC65B IEC SC65B/WG15) se cansó de dibujarlos con un software
básico y solo de presentación gráfica. Se desarrolló como una herramienta para probar
el modelo gráfico y el formato de intercambios de archivos XML definidos en el IEC-
61499-2, y al mismo tiempo se utilizó en el desarrollo de la primera demostración de
viabilidad del IEC- 61499 por el consorcio Holonic Manufacturing System (HMS). Fue
creado para guiar y coordinar los esfuerzos de todos los distribuidores e investigadores a
nivel mundial para demostrar la “Viabilidad de un Perfil de Conformidad”, el cual
posteriormente fue designado como el literal 4 de esta norma.
FBDK, Kit de Desarrollo de Bloques Funcionales (siglas en inglés de FBDK, Function
Block Development Kit) es de libre distribución y se ajusta al propósito de educación y
software libre [23]. Permite ingeniería centrada en la aplicación, tiene una librería de
componentes de software extensa y se puede descargar la aplicación de control a
diferentes dispositivos., por estas características es usada para proyectos de
investigación.
El editor es un Entorno de Desarrollo Integrado (IDE, Integrated Development
Environment) que soporta desarrollo gráfico de Bloques de función, sistemas y
traducción de clases java. Almacena los Bloques de función en el formato basado en
lenguaje de marcado extensible (siglas en inglés: XML, eXtensible Markup Language)
definido en el apartado 2 del estándar IEC 61499. Se pueden desarrollar y desplegar
aplicaciones de sistemas de control distribuido basadas en FBs.
Marcelo García: Implementación de Sistemas Empotrados de Control Distribuidos bajo el Estándar IEC-
61499
Máster en Ingeniería de Control, Automatización y Robótica 24
Fig. 10: Sistema de configuración en FBDK
• Entorno de ejecución: FBRT
Al igual que la herramienta de software FBDK, esta plataforma de ejecución fue
desarrollado en el lenguaje Java y se utiliza para las pruebas de viabilidad y la
demostración de la arquitectura IEC-61499, utilizando la tecnología de Java empotrado
de Imsys Technologies. Posteriormente [23], se utiliza en una serie de proyectos de
investigación con la plataforma de hardware ya obsoleto Netmaster23.
Una característica adicional es que en el FBRT los eventos de salida que disparan la
invocación de otros bloques, son implementados como una serie de llamadas a
funciones directas para el bloque destino dentro de una simple tarea. Este mecanismo
detiene la ejecución en la llamada al bloque a otros FBs a lo largo de la ruta de
propagación de eventos hasta que su ejecución haya sido completada.
2.3.2 4DIAC-IDE / FORTE
• Entorno de desarrollo: 4DIAC-IDE
4DIAC Estructura para la Automatización y Control Industrial Distribuida (siglas en
inglés de Framework for Distributed Industrial Automation and Control), es una
herramienta de ingeniería de código abierto basada en la plataforma de Eclipse, para
automatización distribuida, reconfigurable y software de control. 4DIAC fue creada en
el año 2000 por PROFACTOR GmbH & Viena University of Technology [24].
Marcelo García: Implementación de Sistemas Empotrados de Control Distribuidos bajo el Estándar IEC-
61499
Máster en Ingeniería de Control, Automatización y Robótica 25
Fig. 11: Sistema de configuración en 4DIAC-IDE
El editor es un entorno de desarrollo integrado 4DIAC-IDE. El objetivo de la iniciativa
de 4DIAC es proporcionar herramientas conforme al estándar que permiten establecer
un entorno de automatización y control, basado en los objetivos de portabilidad,
configurabilidad e interoperabilidad, mismos que son mencionados en el IEC 61499.
4DIAC persigue los siguientes objetivos [24]:
• Suministrar una base común para desarrollo, dispositivo industrial e
investigación de IEC-61499.
• Suministrar un paquete conteniendo un entorno runtime para diferentes
plataformas de control empotradas y el entorno de ingeniería.
• Suministrar ejemplos reales a nivel prototipo para incrementar la aceptación del
IEC-61499 en la industria.
• Proporcionar un incentivo para el uso de IEC-61499 con la industria.
Las características más relevantes de 4DIAC [24] son:
• 4DIAC-IDE es una herramienta IEC-61499 basada en Eclipse.
• Tiene tipos de datos elementales de acuerdo a IEC 61131-3.
• Tiene conexiones de eventos y datos.
• Configuración de comandos (crear, escribir, iniciar de acuerdo con IEC-61499).
• Tiene FBs de comunicación (Client/Server, Publish/Subscribe para Ethernet).
• Puede ejecutar bloques funcionales de tipo FB básicos, FB compuestos, FB
interfaces de servicio SIFBs y adaptadores.
Marcelo García: Implementación de Sistemas Empotrados de Control Distribuidos bajo el Estándar IEC-
61499
Máster en Ingeniería de Control, Automatización y Robótica 26
• Se ejecuta bajo plataforma Windows, Linux y Solaris.
Finalmente, como unas características especiales de este IDE es que en su reciente
versión soporta la depuración y prueba de aplicaciones de control distribuido en línea
además de forzar y establecer el valor de las variables de manera remota, lo cual le da
una ventaja sobre sus competidores.
• Entorno de Ejecución: FORTE
El entorno de ejecución de 4DIAC conforme a IEC-61499 es 4DIAC-RTE (FORTE).
FORTE es una pequeña implementación portable de un entorno runtime conforme a
IEC-61499 enfocado a pequeños dispositivos de control empotrados (16/32 Bit),
implementado en C++ y es portable para múltiples plataformas [24]. Los mecanismos
de ejecución en FORTE permiten la ejecución limitada en tiempo real de
configuraciones de control IEC-61499 desencadenadas por eventos externos, donde las
diferentes partes de la configuración pueden cumplir diferentes limitaciones en tiempo
real y la ejecución de los procesos de baja prioridad no perturban la ejecución de los
procesos de mayor prioridad
En el entorno runtime FORTE hace uso de un disparador de eventos para la
planificación de FBs, en este enfoque de colas, todos los eventos de entrada se los
entrega a los FBs destino en orden FIFO (primero entra-primero sale). El disparador de
eventos desacopla la ejecución de envío de eventos FB del bloque receptor, de ese modo
crea el periodo de bloqueo de un FB independiente de la topología de red. [24].
El entorno de ejecución sigue en continuo cambio, referente a la optimización de
ejecución e implementación de interfaz de comunicaciones. FORTE ha sido escrito para
funcionar independientemente de la plataforma a utilizarse, esto permite hacer más fácil
su uso en diversos tipos de hardware y plataformas de sistemas operativos. La versión
actual de FORTE es soportada por los siguientes sistemas: Windows(Win32), eCos,
POSIX, Lego Mindstorms NXT controller, etc.
2.3.3 Próximos Pasos en los entornos de desarrollo
Como hemos visto, un número creciente de proveedores están proporcionando
herramientas de software y plataformas de tiempo de ejecución para la arquitectura IEC-
Marcelo García: Implementación de Sistemas Empotrados de Control Distribuidos bajo el Estándar IEC-
61499
Máster en Ingeniería de Control, Automatización y Robótica 27
61499. Además, un gran número de vendedores a nivel global están comenzando a
ofrecer librerías específicas de dominio para su reutilización. Sin embargo, la falta de
“Perfiles de Conformidad” de consenso de varios proveedores y las correspondientes
series de pruebas y procedimientos de certificación imponen serias barreras a la entrada
y limita la flexibilidad de elección para los potenciales consumidores académicos e
industriales.
Según lo explica Zoitl en [25] el próximo paso para todos los entornos de desarrollo es
implementar una solución rápida a la generalización del perfil ampliamente usado
llamado “Cumplimiento de Perfil para Demostraciones de Viabilidad”, mediante la
eliminación de dependencias de la implementación, específicamente a las referencias
del lenguaje JAVA y particularmente a los protocolos de comunicación. Este último
podría ser fácilmente manejado haciendo la entrada ID de los FBs CLIENT, SERVER,
PUBLISH y SUBSCRIBE un tipo de dato que contenga un Identificador Universal de
Recurso (URI) de propósito general. Los detalles del protocolo de comunicación usado
podrían ser especificados de una manera dependiente del esquema del URI, por
ejemplo: “devicenet”, “canopen”, “fieldbus”,etc. Con esto se facilita la definición de
interfaces para un gran número de arquitecturas de red industriales, así como interfaces
de hardware, simplemente mediante la definición de la sintaxis y la semántica de los
esquemas de URI correspondientes.
Adicional a este existen un sinnúmero de problemas los cuales deben ser solucionados
por los entornos de desarrollo y por los grupos académicos de investigación para que el
estándar IEC-61499 pueda ser aplicado en toda su extensión.
Marcelo García: Implementación de Sistemas Empotrados de Control Distribuidos bajo el Estándar IEC-
61499
Máster en Ingeniería de Control, Automatización y Robótica 28
3. SOLUCIÓN PROPUESTA
3.1 RaspBerry PI
Raspberry Pi es un ordenador de placa reducida (siglas en inglés: Single Board
Computer o SBC), es decir es una computadora completa en un solo circuito. Es de bajo
costo y fue desarrollada en Reino Unido por la Fundación Raspberry Pi, con el objetivo
de estimular la enseñanza de ciencias de la computación en las escuelas. [26]
Su diseño se basa en un sistema modelo SOC (sigla en inglés: Syste On a Chip), es
decir, integran una gran parte de los módulos componentes de un ordenador en un chip
modelo Broadcom BCM2835, que contiene un procesador central ARM 1176JZF-s a
700 Mhz, un porcesador gráfico VideoCore IV y con 256MB o 512 MB de memoria
según la versión de la placa. El diseño no incluye un disco duro o una unidad de estado
sólido, ya que usa una tarjeta SD para el almacenamiento permanente; tampoco incluye
fuente de alimentación o carcasa
Fig. 12: Raspberry Pi modelo B
3.1.1. Hardware de Raspberry PI
Esta placa posee dos versiones dependiendo de su memoria. El sistema cuenta con 256
MB de memoria RAM en su modelo A, y con 512 MB de memoria RAM en su modelo
B. Las ventas iniciales fueron del modelo B. El modelo A solo tiene un puerto USB,
carece de controlador Ethernet y cuesta menos que el modelo B, el cual tiene dos
puertos USB y un controlador Ethernet 10/100
Marcelo García: Implementación de Sistemas Empotrados de Control Distribuidos bajo el Estándar IEC-
61499
Máster en Ingeniería de Control, Automatización y Robótica 29
A pesar que el Modelo A no tiene un puerto RJ45, se puede conectar a una red usando
un adaptador USB-Ethernet suministrado por el usuario. Por otro lado, a ambos
modelos se puede conectar un adaptador Wi-Fi por USB, para tener acceso a redes
inalámbricas o internet. Como es típico en los ordenadores modernos, se pueden usar
teclados y ratones con conexión USB compatible con Raspberry Pi. [26]
El Raspberry Pi no viene con reloj en tiempo real, por lo que el sistema operativo debe
usar un servidor de hora en red, o pedir al usuario la hora en el momento de arrancar el
ordenador. Sin embargo se podría añadir un reloj en tiempo real (como el DS1307) con
una batería mediante el uso de la interface I²C.
Las especificaciones técnicas para el modelo A y B, son las que se observan en la Tabla
2:
Características Modelo A Modelo B Precio 25 dólares 35 dólares SoC Broadcom BCM2835 Broadcom BCM2835 CPU ARM 1176JZFS a 700 MHz ARM 1176JZFS a 700 MHz GPU Videocore 4 Videocore 4 RAM 256 MB 512 MB Puertos USB 2.0 1 2 Salidas Video HDMI y RCA HDMI y RCA Resolución 1080p 1080p Salidas Audio HDMI y 3.5 mm HDMI y 3.5 mm Periféricos 8xGP 8 x GPIO, SPI, I2C, UART 8 x GPIO, SPI, I2C, UART Alimentación: 5V via microUSB 5V via microUSB Redes Ninguna Ethernet 10/100 Dimensiones: 85.60mm × 53.98mm 85.60mm × 53.98mm
Tabla 2. Resumen de características de Hardware de Rapberry PI
3.1.2. Software para Raspberry PI
El Raspberry Pi usa mayoritariamente sistemas operativos basados en el núcleo Linux.
Generalmente se usa como sistema operativo Raspbian, que es una distribución
derivada de Debian que está optimizada para el hardware de Raspberry Pi, se lanzó
durante julio de 2012 y es la distribución recomendada por la fundación para iniciarse
en su programación [26]
Pero existen otros sistemas operativos como Slackware ARM (también llamada
ARMedslack) versión 13.37 que arranca sin ninguna modificación. Los 256 o 512 MB
Marcelo García: Implementación de Sistemas Empotrados de Control Distribuidos bajo el Estándar IEC-
61499
Máster en Ingeniería de Control, Automatización y Robótica 30
de memoria RAM disponible en la Raspberry Pi, cubren los necesarios 64 MB de RAM
para arrancar esta distribución en sistemas ARM y i386 sin usar interfaz gráfica. Por
otro lado, se están creando distribuciones más específicas y ligeras como IPfire
(distribución para ser usada como firewall), o OpenELEC y Raspbmc (distribuciones
con el centro multimedia XBMC), RISC OS, etc.
Todas las versiones de sistemas operativos acceden a la GPU mediante una imagen del
firmware de código cerrado, llamado blob binario, que se carga dentro de la GPU al
arrancar desde la tarjeta SD. El blob binario está asociado a los drivers Linux que
también son de código cerrado. Las aplicaciones hacen llamadas a las librerías de
tiempo de ejecución que son de código abierto, y estas librerías hacen llamadas a unos
drivers de código abierto en el kernel de Linux. La API del driver del kernel es
específica para estas librerías [26].
Finalmente luego de varias versiones predecesoras la fundación RPI (Raspberry PI)
lanzó un prototipo de imagen de tarjeta SD que almacenaba un sistema operativo y que
podía ser cargado en una tarjeta SD. La imagen se basaba en Debian 6.0 (Squezze), con
el escritorio LXDE y el navegador Midori, más algunas herramientas de programación.
Funciona bajo QEMU permitiendo que el Raspberry Pi pudiera ser emulado en otros
sistemas.
En nuestro caso utilizamos el sistema operativo Raspbian, “wheezy” debido a nuestra
familiaridad con esa distribución y las optimizaciones hechas para el funcionamiento
específico en este dispositivo.
3.1.3. GPIO y Placa de expansión GERTBOARD
Raspberry PI posee un puerto de Entradas y Salidas de propósito general (GPIO) de 26
pines el cual es utilizado para su comunicación con el mundo exterior, teniendo en
cuenta que el nivel de voltaje con el cual trabaja esta tarjeta es 3.3 V. Todos los pines de
GPIO pueden ser configurados para proporcionar funciones tales como puerto SPI,
PWM, I2C, etc [27]. Exclusivamente los pines 14 y 15 pueden ser configurados como
puerto UART o para GPIO, en consecuencia se puede tener en total 17 pines ya sean de
entradas o salidas configurables.
Marcelo García: Implementación de Sistemas Empotrados de Control Distribuidos bajo el Estándar IEC-
61499
Máster en Ingeniería de Control, Automatización y Robótica 31
Cada pin de GPIO posee interrupciones por cambio a alto nivel, bajo nivel, caída o
subida de tensión, la comunicación con el GPIO no es directamente soportado por el
kernel de cualquiera de los sistemas operativos que existen para Raspberry PI, si no,
existen una seria de librerías de licencia abierta las cuales son utilizadas para dicha
comunicación.
Como se explicó anteriormente ya que Raspberry Pi no fue construida en un inicio para
interactuar con sistemas de control se ha diseñado una placa denominada Gertboard es
una interfaz diseñada por Gert van Loo, uno de los ingenieros de hardware involucrado
en el diseño original de la Raspberry Pi. Se conecta directamente en el cabezal GPIO de
la Raspberry Pi y provee un rango de amplio de posibilidades de interconexión con
dispositivos externos [28], como ser:
• Manejo de motores
• Detección de botones pulsados
• Iluminación de LEDs
• Manejo de relés
• Detección y salida de voltajes análogos
• Respuesta a eventos físicos externos
Fig. 13: GertBoard para Raspberry PI
Marcelo García: Implementación de Sistemas Empotrados de Control Distribuidos bajo el Estándar IEC-
61499
Máster en Ingeniería de Control, Automatización y Robótica 32
Las características principales la GertBoard son las siguientes:
• 12 x LEDs indicadores
• 12 x E/S con buffers de protección incluidos
• 3 x botones pulsadores momentáneos
• 6 drivers de colector abierto (50V, 0.5A)
• Controlador de motor bi-direccional 18V, 2A
• Incluye microcontrolador ATmega328 de 28 pines
• Conversor D/A de 2 canales, 8 bits
• Conversor D/A de 2 canales, 10 bits
3.2. Generación de bloques funcionales de interfaz de servicio (SIFB)
El Bloque Funcional de Interfaz de Servicio (siglas en inglés: SIFB de Service Interface
Function Block), es un bloque funcional que proporciona servicios a la aplicación,
permitiendo la interacción entre aplicación y recursos. Proporciona una interfaz entre el
software de control y el hardware con los sistemas de comunicaciones.
3.2.1. Elementos básicos de un SIFB
Los elementos básicos de un SIFB los resume el estándar IEC 61499-1 [4] que los
define en una plantilla general de un SIFB como se muestra en la Figura 14:
Fig. 14: Estructura general de un SIFB
Una de las funciones principales del SIFB es proporcionar servicios y el estándar IEC-
61499-1 define los siguientes conceptos:
Marcelo García: Implementación de Sistemas Empotrados de Control Distribuidos bajo el Estándar IEC-
61499
Máster en Ingeniería de Control, Automatización y Robótica 33
• Servicio: es la capacidad funcional de un recurso, la cual puede ser modelada
por una secuencia de primitivas.
• Primitiva: es una representación abstracta de una interacción entre una
aplicación y un recurso.
Para declarar los tipos de SIFBs, el estándar define el conjunto de entradas de eventos,
salidas de eventos, entradas de datos y salidas de datos, listados en la Tabla 3 y 4
respectivamente [4].
ENTRADA DE EVENTO ENTRADA DE DATOS INIT Esta entrada de evento debe ser asignada a una primitiva de petición la cuál solicita una inicialización del servicio proporcionado por la instancia del FB
QI: BOOL Representa un calificador en la primitiva de servicio asignada a la entrada del evento. Si esta entrada es VERDADERA sobre la ocurrencia de un evento INIT, el servicio de inicialización es solicitado; si es FALSA, el servicio de finalización es requerido
REQ Esta entrada de evento debe ser asignada a una primitiva de petición del servicio proporcionado por la instancia del FB
PARAMS: ANY La entrada contiene uno o más parámetros asociados con el servicio, típicamente como elementos de una instancia de un tipo de dato estructurado. Cuando esta entrada está presente, la especificación del tipo de FB debe definir el tipo de dato y valor inicial por defecto
RSP Esta entrada de evento debe ser asignada a una primitiva de respuesta del servicio proporcionado por la instancia del FB.
SD_1,…, SD_m : ANY Estas entradas contienen el dato asociado con las primitivas de petición y de respuesta. La especificación del tipo FB debe definir los tipos de datos y valores por defecto de estas estradas y debe definir sus asociaciones con entradas de eventos en un diagrama de secuencia de eventos.
Tabla 3. Eventos y Datos de entrada de un SIFB bajo norma IEC-61499
Marcelo García: Implementación de Sistemas Empotrados de Control Distribuidos bajo el Estándar IEC-
61499
Máster en Ingeniería de Control, Automatización y Robótica 34
SALIDA DE EVENTO SALIDA DE DATOS INITO Esta salida de evento debe ser asignada a una primitiva de confirmación que indica la finalización del procedimiento de un servicio de inicialización.
QO: BOOL Esta variable representa un calificador en la primitiva de servicio asignada a la salida de eventos. Por ejemplo, si el valor de esta salida es VERDADERO sobre la ocurrencia de un evento INITO indica la inicialización exitosa del servicio; si esta salida tiene un valor FALSO indica la inicialización NO exitosa.
CNF Esta salida de evento debe ser asignada a una primitiva de confirmación del servicio proporcionado por la instancia del FB.
STATUS: ANY Esta salida debe ser un tipo de dato apropiado para expresar el estado del servicio sobre la ocurrencia de una salida de evento.
IND Esta salida de evento debe ser asignada a una primitiva de indicación del servicio proporcionado por la instancia del FB.
RD_1,…, RD_n : ANY Estas salidas contienen los datos asociados con las primitivas indicación y confirmación. La especificación del tipo de FB debe definir los tipos de datos y valores iniciales de estas salidas y debe definir sus asociaciones con salida de eventos en un diagrama de secuencia de eventos.
Tabla 4. Eventos y Datos de salida de un SIFB bajo norma IEC-61499
3.2.2 Especificaciones del SIFB
Las interfaces externas de un SIFB tienen la misma apariencia que un FB. Sin embargo,
algunas entradas y salidas de un SIFB tienen semántica especializada y el
comportamiento de instancias de estos tipos de SIFBs está definido a través de una
notación gráfica especializada para secuencia de primitivas de servicio.
En función del tipo de SIFB, se ofrecen diferentes servicios. El estándar IEC 61499-1
define dos tipos de SIFBs que son representados en la Figura 15.
Marcelo García: Implementación de Sistemas Empotrados de Control Distribuidos bajo el Estándar IEC-
61499
Máster en Ingeniería de Control, Automatización y Robótica 35
Fig. 15: SIFB Requester y REsponder
1. Petición (REQUESTER). Representa una interacción para inicializar una
aplicación (ejemplo: envío de un mensaje). Este permanece pasivo hasta la
llegada de una entrada de evento. Por otro lado, su ejecución es similar a la
ejecución de un FB básico.
2. Respuesta (RESPONDER). Representa una interacción de inicializar un recurso.
Si un servicio en reposo lanza su ejecución, este tipo de SIFB proporciona una
salida de evento. También puede interrumpir la ejecución de cualquier otro FB.
La comunicación es muy importante en los sistemas de control distribuidos. En el
estándar IEC 61499-1 se implementa vía SIFBs de comunicaciones. Los dos
paradigmas de comunicación empleados son publicador/suscriptor
(PUBLISH/SUBSCRIBE) y cliente/servidor (CLIENT/SERVER).
La comunicación publicador/suscriptor transmite y recibe información en una única
dirección, (ver la Figura 16) es decir, la transferencia de datos es unidireccional y se
lleva a cabo por el uso del protocolo de datagrama de usuario (por ejemplo para UDP,
(User Datagram Protocol)
El método publicador/suscriptor envía los datos en el bus los cuales se “publican” una
vez, y todos los demás dispositivos que necesitan los datos escuchan o se “suscriben” a
la misma transmisión. Por lo tanto, un parámetro específico puede ser usado por tantos
dispositivos o funciones diferentes como el usuario requiera, sin incrementar el tráfico
en el bus o afectar gravemente al rendimiento de control.
Marcelo García: Implementación de Sistemas Empotrados de Control Distribuidos bajo el Estándar IEC-
61499
Máster en Ingeniería de Control, Automatización y Robótica 36
Este tipo de comunicaciones también son determinísticas. Esto significa que siempre
ocurren sobre un programa predeterminado, así que es seguro que la información se
transmitirá y recibirá precisamente cuando se necesita.
Fig. 16: Bloques de interfaz de comunicaciones Publish y Subscribe
La comunicación cliente/servidor transmite y recibe información en dos direcciones,
(ver Figura 17), es decir, la transferencia de datos es bidireccional y se lleva a cabo por
el uso del protocolo de control de transmisión (por ejemplo para TCP, Transmission
Control Protocol).
Fig. 17: Bloques de interfaz de comunicaciones Client y Server
Entre los trabajos de investigación relacionados con SIFBs destacan los siguientes:
Para [29] y [30] el par cliente/servidor describe mejor la operación de red Profibus,
donde la comunicación half-duplex (método o protocolo de envío de información
bidireccional pero no simultáneo) es usada para transferir los parámetros, la
configuración, el diagnóstico y los datos a través de la red.
Por otro lado, en [31] duplicar un FB de comunicaciones Publish y Subscribe garantiza
el flujo correcto de eventos y datos entre FBs de comunicaciones duplicados. El Publish
Marcelo García: Implementación de Sistemas Empotrados de Control Distribuidos bajo el Estándar IEC-
61499
Máster en Ingeniería de Control, Automatización y Robótica 37
envía eventos para notificar específicamente al Subscribe en los nodos duplicados. El
Subscribe notificado establece la conexión con Publish y le solicita los datos.
Como hemos señalado antes, es evidente que los SIFBs son importantes en el diseño de
un sistema de control distribuido, pero tal como lo menciona el estándar, las
comunicaciones son abiertas, es decir, los desarrolladores pueden utilizarlas como
mejor les convenga para resolver sus aplicaciones de control distribuidas.
Por último, se debe mencionar que el uso de los SIFBs es muy variado y no existen
metodologías de diseño y desarrollo para los mismos. Además, en los sistemas de
desarrollo actuales que permiten crear aplicaciones de control distribuidas y cumplen
con el estándar IEC-61499, no existen tipos de guías para la implementación de SIFBs y
hasta este momento los SIFBs se han introducido manualmente.
3.3. Metodología de Diseño de FBs
Con el objetivo de desarrollar FBs IEC61499 basados en C++ para el runtime FORTE
bajo el sistema operativo Debian que utiliza las Raspberry PI, se siguen los siguientes
pasos tal como se presenta en la Figura 18.
Fig. 18: Elementos de desarrollo de FBs
Marcelo García: Implementación de Sistemas Empotrados de Control Distribuidos bajo el Estándar IEC-
61499
Máster en Ingeniería de Control, Automatización y Robótica 38
1. Identificar el servicio.
2. Definir las entradas y salidas del FB. Definir las entradas de eventos, las salidas
de eventos, las entradas de datos y las salidas de datos, que son indispensables
para proporcionar los servicios.
3. Especificar las primitivas de servicio que llevará a cabo el FB.
4. Desarrollar los algoritmos que implementan el servicio en C++ y al mismo
tiempo incluir las funciones de acceso a hardware.
En el desarrollo de los tres primeros pasos de la metodología, se utilizó la herramienta
4DIAC-IDE basada en Eclipse y que emplea Java para su ejecución. Con estos tres
primeros pasos se ha generado una estructura vacía C++ de FB. Esta estructura incluye
la declaración y tipos de eventos y datos de entrada, eventos y datos de salida y se añade
el acceso al hardware. Una vez creada, se exporta como un fichero .cpp y como un
fichero .h con estructura FORTE [32].
Utilizando un editor de C++, que en nuestro caso es Eclipse CDT, se ha modificado el
archivo.cpp que 4DIAC-IDE nos entrega, definiéndose métodos IEC-61499 que enlazan
los algoritmos en el hardware para acceso de las entrada y salidas digitales y/o
analógicas de la Raspberry PI, también incluye las funciones para enlazar código C/C++
con código FORTE. La Figura 19, ilustra el escenario general para implementar FBs.
Fig. 19: Escenario general de desarrollo del software en 4DIAC
Marcelo García: Implementación de Sistemas Empotrados de Control Distribuidos bajo el Estándar IEC-
61499
Máster en Ingeniería de Control, Automatización y Robótica 39
3.4 FBs Desarrollados
Se han desarrollado 4 FBs utilizando la herramienta de diseño 4DIAC los cuales
permitirán interactuar a las aplicaciones desarrolladas en IEC-61499 con las entradas y
salidas del Raspberry PI implementando sistemas de control distribuidos.
El direccionamiento tanto de las entradas como de las salidas se realizan utilizando el
nombre de la variable almacenado en un archivo de configuración de formato .XML (
siglas en inglés: eXtensible Markup Language o Lenguaje de marcas extensible), en el
cual existe el listado del nombre de variable, el pin de la Raspberry PI referido a dicha
variable y el tipo de dicho pin, es decir entrada o salida y si es analógica o digital, con
esto se realizará un referenciado dinámico y de acuerdo a los procedimientos utilizados
actualmente por la mayoría de equipos de control.
Fig. 20: Archivo XML de configuración
Marcelo García: Implementación de Sistemas Empotrados de Control Distribuidos bajo el Estándar IEC-
61499
Máster en Ingeniería de Control, Automatización y Robótica 40
Adicional a los parámetros anteriores el archivo de configuración tendrá una breve
descripción asociada a cada variable, de esta manera cuaquier programador sabrá la
función en el proceso a controlarse de dicha variable.
El archivo de configuración es sumamente imprtante, ya que cada FB desarrolllado
como primer paso leerá este archivo para almacenar en una estructura las variables de
cada proceso. Si este archivo está mal configurado no se podría realizar la
automatización del proceso.
3.4.1 FB GERTBOARD_OUT
Este FB posee una entrada OUT la cual es de tipo ANY, ya que se podría enviar un
valor BOOL de salida digital o un valor REAL de salida analógica a la Raspberry PI.
Adicional tiene dos entradas de tipo STRING, la primera FILE en la cual se da la
dirección del archivo de configuración a ser utilizado y la segunda TAG con la cual se
pondrá el nombre de la variable que deseamos manipular finalmente QI es una línea de
control.
Este FB tiene dos eventos de entrada el primero INIT es el que se requiere ejecutar
inicialmente ya que está asociado a las variables FILE y TAG para determinar el pin de
salida a la cual queremos manipular en la placa y el evento REQ se ejecuta
periódicamente para asignar el estado lógico definido en OUT.
En el lado de salida, el evento INITO indica que la inicialización del FB está completa y
procede a mostrar el resultado de esta inicialización en QO y STATUS.
Fig. 21: FB GERTBOARD_OUT
Marcelo García: Implementación de Sistemas Empotrados de Control Distribuidos bajo el Estándar IEC-
61499
Máster en Ingeniería de Control, Automatización y Robótica 41
3.4.2 FB GERTBOARD_IN
Al igual que la anterior FB, posee dos entradas de tipo STRING, la primera FILE en la
cual se da la dirección del archivo de configuración a ser utilizado y la segunda TAG
con la cual se pondrá el nombre de la variable que deseamos manipular.
Este FB tiene dos eventos de entrada el primero INIT es el que se ejecuta inicialmente
ya que utiliza las variables FILE y TAG para determinar el pin de entrada y el evento
REQ se ejecuta periódicamente para leer el estado de la variable que queremos leer en
la Raspberry PI. De igual manera en el lado de salida, el evento INITO indica que la
inicialización del FB está completa y procede a mostrar el valor de la variable en la
salida IN que es de tipo ANY ya que podría indicar un valor digital o analógico según
sea el caso, el resultado de la inicialización se muestra las salidas QO y STATUS.
Fig. 22: FB GERTBOARD_IN
Marcelo García: Implementación de Sistemas Empotrados de Control Distribuidos bajo el Estándar IEC-
61499
Máster en Ingeniería de Control, Automatización y Robótica 42
4. CASO DE USO
El objetivo de la implementación de las FBs explicados en los apartados anteriores, es el
desarrollar una aplicación de control bajo IEC-61499, en consecuencia, una vez
definidos y compilados las librerías y programas en FORTE procedemos a su uso, al
utilizarlos para el control de dos procesos industriales. Para lo cual se utilizan dos
maquetas marca FESTO modelo MECLAB, la primera maqueta es la Estación de
Manipulación la cual recoge piezas del depósito y entrega a la cinta transportadora
utilizando un brazo manipulado accionado por dos cilindros de doble efecto. La segunda
maqueta utilizada es la cinta transportadora que posee un sensor inductivo, el cual
permite clasificar piezas metálicas o de plástico y esto permitirá al final de la cinta
activar un electroimán que da paso a uno de los dos compartimentos de
almacenamiento.
Como hemos explicado anteriormente se procederá a programar los FBs que serán
posteriormente descargados en nuestro sistema distribuido el cual está compuesto por
dos tarjetas Raspberry PI modelo B y un ordenador portátil el cual servirá como
estación de ingeniería y permitirá visualizar el proceso de control. El caso de estudio
queda explicado en la siguiente Figura 23
Fig. 23: Caso de Estudio
Marcelo García: Implementación de Sistemas Empotrados de Control Distribuidos bajo el Estándar IEC-
61499
Máster en Ingeniería de Control, Automatización y Robótica 43
4DIAC-IDE posee solo los FBs básicos para implementar un sistema de control bajo
norma IEC-61499, es por esto que para nuestra aplicación debemos desarrollar dos FBs
adicionales los cuales tendrán incluidos el algoritmo de control de cada maqueta a ser
utilizada. Estos FBs se crean utilizando 4DIAC-IDE y Eclipse CDT, el cual, permite
programar el algoritmo de control en c++, que es uno de los lenguajes aceptados por
esta norma, de esta manera se obtiene el comportamiento deseado de cada maqueta para
su funcionamiento en unión con los FBs desarrollados para la comunicación con las
entradas y salidas del Raspberry PI.
4.1 FB MAQUETA_CINTA
El primer FB desarrollado es MAQUETA_CINTA este posee el algoritmo de control de
la maqueta transportadora. Tiene dos entradas principales las cuales dan inicio al
proceso, la primera es AUTO/MANUAL de tipo BOOL, si está en 0 el proceso es
manual, caso contrario el proceso es automático, la segunda entrada es START/STOP
de igual manera que la anterior es de tipo BOOL y si su valor es 1 el proceso arranca o
si es 0 el proceso está parado, estas entradas son de suma importancia ya que si no
tienen un valor el proceso no arrancaría.
Si se ha decidido que el proceso sea MANUAL, se puede manipular el motor de la cinta
transportadora y el solenoide de clasificación con las entradas PB_CONVEYOR y
PB_SOLENOID respectivamente, las cuales son de tipo BOOL.
Fig. 24: FB MAQUETA_CINTA
Esta FB posee también entradas de los sensores y salidas a contactores que manipulan la
maqueta en su totalidad, es por esto que para el Sensor Inductivo de detección de
material de pieza está relacionado con la entrada IS, el Sensor detector de pieza esta
referenciado por la entrada BS, mientras que las salidas del Motor de la cinta puede ser
Marcelo García: Implementación de Sistemas Empotrados de Control Distribuidos bajo el Estándar IEC-
61499
Máster en Ingeniería de Control, Automatización y Robótica 44
manipulado por CONVEYOR y la salida del contacto de la solenoide estará
referenciado por SOLENOID, todas estas variables son de tipo BOOL.
Los eventos son los mínimos requeridos para un FB, el evento INIT permite la
inicialización del FB, y el evento REQ nos permitirá asignar un valor lógico a cada
entrada y salida según se cumplan las condiciones de control. En el lado de los Eventos
de Salida se tiene INITO que nos indica que el FB se ha inicializado y CNF que
confirma que el algoritmo interno de control se ha ejecutado.
4.2 FB MAQUETA_MANIPULADOR
Posee el algoritmo de control para la manipulación de entradas y salidas de todas las
variables que tiene esta maqueta. Este FB posee dos entradas principales para iniciar el
proceso las cuales son START/STOP y AUTO/MAN de tipo BOOL e indican los
estados de funcionamiento del mismo. El manipulador al estar formado por cilindros de
doble efecto tanto para el brazo vertical como para el horizontal, posee más actuadores
y sensores que indican la posición de los mismos. Por esta razón cuando el proceso está
en Manual se pueden manipular las siguientes entradas: Para la solenoide 1 del cilindro
horizontal le corresponde PB_C1M1, la solenoide 2 del cilindro horizontal se manipula
con la entrada PB_C2M1, para la solenoide 1 del cilindro vertical se tiene la entrada
PB_C1M2, la solenoide 2 del mismo cilindro se manipulará con PB_C2M2 y
finalmente la garra que captura las piezas se puede manipular con la entrada PB_C3M1.
Todas estas entradas son de tipo BOOL.
Adicional posee 4 entradas para indicar el estado de los sensores que nos permiten
identificar la posición de los cilindros horizontal y vertical. Para el cilindro horizontal se
tiene las entradas C1S1 que nos indica que el cilindro está recogido y C1S2 que indica
que está extendido. De la misma manera se tiene las entradas C2S1 y C2S2 para
detectar si el cilindro vertical está extendido o recogido respectivamente. De igual
manera son de tipo BOOL
Las salidas de este FB corresponde a las solenoides de activación de los cilindros, para
el cilindro horizontal se tiene las salidas C1M1 y C1M2 que permiten activar a la
válvula de control. Con el cilindro vertical se tiene las salidas C2M1 y C2M2 mientras
que la salida C3M1 activa y desactiva la garra que permite recoger las piezas, son de
Marcelo García: Implementación de Sistemas Empotrados de Control Distribuidos bajo el Estándar IEC-
61499
Máster en Ingeniería de Control, Automatización y Robótica 45
tipo BOOL.
Los eventos cumplen la misma función que en el FB anterior, todo lo explicado
anteriormente podemos verlo graficado en la Figura 25.
Fig. 25: FB MAQUETA_MANIPULADOR
4.3 Diseño de la Aplicación de Control
La aplicación de control se desarrolla en el software 4DIAC-IDE, posee tres tipos de
dispositivos los cuales se detalla a continuación:
El primer dispositivo será la estación de ingeniería y HMI la cual está representada en
color amarillo en nuestra aplicación, este dispositivo permitirá la manipulación de las
entradas y salidas de las maquetas en la opción MANUAL, indicándonos
adicionalmente el estado de los sensores del proceso y dará la señales de inicio o parada
en automático o manual.
El segundo dispositivo será la Tarjeta Raspberry PI que controla la Maqueta de la Cinta
Transportadora la cual se encuentra en color azul, aquí podemos observar como
utilizamos los FBs desarrollados anteriormente para el control de las entradas y salidas,
así como para el algoritmo de control de la maqueta.
Finalmente se tiene la tarjeta Raspberry PI para el control de la maqueta de Brazo
Manipulador en color verde, como para la anterior maqueta se observa que se usan los
FBs desarrollados en los pasos anteriores y con esto podemos tener un Sistema de
Control Distribuido embebido de bajo costo, como se puede apreciar en la Figura 26
Marcelo García: Implementación de Sistemas Empotrados de Control Distribuidos bajo el Estándar IEC-
61499
Máster en Ingeniería de Control, Automatización y Robótica 46
Fig. 26: Aplicación de Control Distribuido en 4DIAC-IDE
Marcelo García: Implementación de Sistemas Empotrados de Control Distribuidos bajo el Estándar IEC-
61499
Máster en Ingeniería de Control, Automatización y Robótica 47
4.4 Diseño de la Configuración del Sistema
El sistema de comunicación se configura con tres dispositivos cada uno con un único
recurso y comunicados a través de una red Ethernet. El primer dispositivo es un
RTM_FRAME con un único recurso PANEL_RESOURCE denominado HMI. En este
caso es obligatorio que el dispositivo sea tipo FRAME y no tipo DEV ya que la
aplicación así lo requiere debido a que implica una visualización en pantalla. En cuanto
a la configuración del dispositivo hay que indicarle los parámetros referentes a la
pantalla de visualización que son el BOUNDS y el GRID. La IP y el puerto del manager
en MGR_ID que para este dispositivo es 172.16.1.180:61499
Los siguientes dispositivos son los que se mapearán sobre las tarjetas Raspberry PI tanto
de la Cinta Transportadora como del Brazo Manipulador, son de tipo RTM_DEV y con
un único recurso EMB_RES denominados RPI_CINTA y RPI_MANIPULADOR
respectivamente y en los cuales sólo hay que indicarle la IP y el puerto del manager en
MGR_ID siendo para el primer dispositivo la IP 172.16.1.18761505 y para el segundo
dispositivo 172.16.1.188:61510
Fig. 27: Configuración del Sistema
4.4.1 Configuración del recurso HMI
Todos los FBs de color amarillo se mapearán sobre el recurso HMI, el cual, nos
permitirá obtener la interfaz gráfica con el cual se podrá comprobar el buen
funcionamiento de la aplicación. Este recurso se descargará sobre el runtime FBRT de
4DIAC-IDE el cual corre en la estación de ingeniería. Se puede ver que se utilizan
varios FBs de tipo SUBSCRIBE y PUBLISH los que nos permitirán enviar las señales
de cada botón del HMI para su dispositivo Raspberry PI adecuado, las IPs utilizadas son
Marcelo García: Implementación de Sistemas Empotrados de Control Distribuidos bajo el Estándar IEC-
61499
Máster en Ingeniería de Control, Automatización y Robótica 48
Fig. 28: Configuración del Recurso HMI
Marcelo García: Implementación de Sistemas Empotrados de Control Distribuidos bajo el Estándar IEC-
61499
Máster en Ingeniería de Control, Automatización y Robótica 49
de tipo multicast, se envían los datos en grupos usando la misma dirección IP pero por
diferentes puertos, lo que permite el envío de una manera eficiente de los datos en la red
de comunicación. Como último paso se conecta la señal COLD y WARM a cada
entrada INIT de los FBs utilizados, de esta manera se inicializará automáticamente al
descargar el recurso al runtime.
Este recurso al ser descargado al runtime FBRT que dispone 4DIAC nos proporciona
una interfaz gráfica muy sencilla la cual se presenta en la siguiente Figura.
Fig. 29: Pantalla del Recurso HMI
4.4.2 Configuración del recurso RPI_CINTA
Los FBs de color azul se mapean sobre el Recurso RPI_CINTA, podemos observar que
posee los FBs desarrollados anteriormente para control de las entradas y salidas de la
Raspberry PI y para control de dicha maqueta. Este recurso se descargará sobre el
runtime FORTE a través de 4DIAC-IDE una vez que haya sido lanzado por el
controlador embebido. El runtime FORTE se inicializa automáticamente al encender el
Raperry PI sin necesidad de ejecutar algún paso adicional.
Como en los casos anteriores se tienes FBs de SUBSCRIBER y PUBLISHER que
utilizan IPs multicast para la transmisión de datos que también serán enviados en
grupos y usando la misma IP pero con diferentes rangos de puertos, la IP multicast
utilizada para este dispositivo es 225.0.0.1. Se debe notar que antes de los FBs
GERTOBOARD_IN y GERTBOARD_OUT deben estar FBs que permiten la
conversión de BOOL a BOOL esto se debe a que los FBs desarrollados pueden recibir
datos tipo BOOL o REAL si se usa para manipular las entradas digitales o analógicas
respectivamente. Como se puede observar en la Figura 30
Marcelo García: Implementación de Sistemas Empotrados de Control Distribuidos bajo el Estándar IEC-
61499
Máster en Ingeniería de Control, Automatización y Robótica 50
Fig. 30: Configuración de Recurso RPI_CINTA
Finalmente la señal WARM y COLD del recurso se conectarán a cada INIT de los FBs
desarrollados de esta manera se inicializará la ejecución de los mismos, lo cual
permitirá la lectura del archivo de configuración en los FBs que manipulan las entradas
y salidas o prepara el algoritmo de control en el FB destinado para este objetivo. Se
añade un FB E_CYCLE el cual da el tiempo cíclico de ejecución, en nuestro caso de 1
ms, permitiendo que se actualicen las entradas o salidas de los FBs desarrollados según
las condiciones del proceso, la señal EO de este FB se conectará a cada evento REQ de
los FBs.
4.4.3 Configuración del recurso RPI_MANIPULADOR
Todos los FBs de color verde se mapearán sobre este recurso el cual permite el control
de la maqueta del Brazo Manipulador. Como en el caso anterior posee FBs
SUBSCRIBER Y PUBLISHER para la comunicación de los datos en grupos usando la
misma dirección multicast IP pero con diferentes puertos, en este caso la IP será
225.0.0.2. Se configura de igual manera que el recurso anterior porque su
funcionamiento en rasgos generales es el mismo. Esto lo observamos en la Figura 31.
Marcelo García: Implementación de Sistemas Empotrados de Control Distribuidos bajo el Estándar IEC-
61499
Máster en Ingeniería de Control, Automatización y Robótica 51
Fig. 31: Configuración de Recurso RPI_MANIPULADOR
4.5. Diseño etapa de Acondicionamiento de señal para Raspberry PI
De acuerdo a lo descrito anteriormente la Raspberry PI posee pines de GPIO que
funcionan solamente con voltaje que no supere los 3.3V, es por esta razón que se
necesita diseñar una tarjeta de acondicionamiento de la señal la cual realizará la
conversión fiable a un voltaje de 24V, el cual es usado a nivel industrial en dispositivos
de control y sensores.
Para aislar eléctricamente los pines de la Raspberry PI cuando se utilice como entrada
Marcelo García: Implementación de Sistemas Empotrados de Control Distribuidos bajo el Estándar IEC-
61499
Máster en Ingeniería de Control, Automatización y Robótica 52
de voltaje, se usa el circuito optoacoplador CNY74-4 que consiste en un fototransistor
ópticamente acoplado a un diodo emisor de infrarrojos y cuya forma es un paquete
rectangular de doble línea con 16 pines, el cual posee las siguientes características:
• Cuatro canales de aislamiento
• Baja capacitancia alrededor de 0.3 pF
• Voltaje máximo de aislamiento 5 kV
• Voltaje máximo de funcionamiento 70 V
• Corriente máxima 60 mA
• Disipación de potencia 100 mW
Cuando se recibe la señal de 24V de un sensor industrial en una de las entradas de los
diodos emisores, esta permite la conducción del fototransistor el cual tiene conectado su
emisor a una fuente de 3.3 V y este es el voltaje que recibirá cualquier pin GPIO de la
Raspberry Pi, protegiendo de cualquier falla de conexión o subida de tensión en el
proceso. Lo explicado queda detallado en el diagrama siguiente.
Fig. 32: Esquema de conexión entre circuito CNY74-4 y entradas de Raspberry PI
Adicionalmente, si se configura los pines de la Raspberry Pi como salidas, estas solo
proporcionarán 3.3 V y una intensidad de 16 mA, la que es insuficiente para poder
controlar los relés de los dispositivos de control a nivel industrial que funcionan con 24
V. Por lo tanto se usará un circuito integrado L293B, que incorpora dos drivers
Marcelo García: Implementación de Sistemas Empotrados de Control Distribuidos bajo el Estándar IEC-
61499
Máster en Ingeniería de Control, Automatización y Robótica 53
denominados “puentes H” los cuales están formados por 4 compuertas de “3 estados” y
posee las siguientes características:
• Cuatro canales de salida (habilitados de dos en dos).
• Corriente de salida de hasta 1A por canal.
• Señales de control compatibles TTL (max. 7v).
• Posibilidad de controlar hasta cuatro motores sin inversión de giro o dos motores
con control de giro.
• Posibilidad de alimentación externa de motores de hasta 36 V.
• El modelo L293D incluye diodos de protección internos.
Para iniciar su funcionamiento este circuito posee dos pines de habilitación de las 4
compuertas de “3 estados”, son los pines 1 y 15, los cuales deben estar a 5V. Cuando la
entrada de cualquiera de sus compuertas tiene un estado lógico alto de 3.3 V, el cual es
proporcionado por un pin de salida de la Raspberry PI, el L293B al tener habilitadas
todos los drivers proporcionan una salida amplificada hasta un voltaje máximo de 24 V
el que esta referenciado en el pin 14 del circuito, de esta manera podemos manejar
solenoides de activación de los cilindros de las maquetas o el motor de la cinta
transportadora. Esto queda demostrado en el siguiente esquema.
Fig. 33: Esquema de conexión entre circuito L293B y salidas de Raspberry PI
Marcelo García: Implementación de Sistemas Empotrados de Control Distribuidos bajo el Estándar IEC-
61499
Máster en Ingeniería de Control, Automatización y Robótica 54
5. CONCLUSIONES Y LÍNEAS FUTURAS
El presente proyecto se ha centrado en el estándar IEC-61499, cuyo objetivo principal
es ofrecer un entorno adecuado para el desarrollo de aplicaciones distribuidas. Para lo
cual, se ha conseguido la integración de una plataforma IEC-61499 FORTE en un
sistema embebido de bajo costo como es el Raspberry PI.
A la hora de elegir el controlador embebido, se ha tenido en cuenta el bajo costo de esta
placa, el sistema operativo embebido que posee, en este caso Debian, que presta varias
herramientas de compilación y edición para FORTE como gcc, g++, etc, y su amplio
uso en el ámbito académico actual.
Las posibles futuras líneas de investigación pueden aportar más ideas y desarrollos
dirigidos a afrontar nuevos cambios en las aplicaciones de control distribuidas. Entre las
posibles líneas de investigación se resaltan las siguientes: implementación de la
solución en una planta real, creación de nuevos FBs que permitan automatizar otros
procesos industriales e integración de nuevas herramientas y funcionalidades
compatibles con el estándar IEC-61499 para conseguir adaptarse a las nuevas
tendencias tecnológicas.
En conclusión, este trabajo se considera un paso más en el objetivo de continuar
avanzando en el despliegue de este emergente estándar. Del mismo modo, los resultados
obtenidos demuestran que es viable continuar investigando sobre este tema, buscando
nuevos objetivos para poder explotar consecuentemente todos los potenciales que el
estándar IEC-61499 brinda.
Marcelo García: Implementación de Sistemas Empotrados de Control Distribuidos bajo el Estándar IEC-
61499
Máster en Ingeniería de Control, Automatización y Robótica 55
6. BIBIOGRAFÍA
[1] ARTIST2, “Roadmap on Real-Time Techniques in Control System Implementation –
Control for Embedded Systems Cluster”, EU/IST FP6 Artist2 NoE,
www.artistembedded.org, 2006.
[2] Vyatkin Valery, “IEC 61499 as Enabler of Distributed and Intelligent Automation:
State-of-the-Art Review”, IEEE transactions on industrial informatics, VOL. 7, 2008
[3] T. Tommila, et al., “Next generation of industrial automation – Concepts and
architecture of a component-based control system”, VTT Research Notes 2303,
2005.
[4] International Electrotechnical Commission Std. “IEC 61499: Function blocks, Part
1-4.” IEC 61 499, 2005. [Online]. Available: www.iec.ch
[5] J.H.Christensen, “Design patterns for systems engineering in IEC 61499” , Otto-
von-Guericke-Universität Magdeburg, Germany, 22-23 March 2000, 63-71
[6] R. W. Lewis, “Modeling control systems using IEC 61499”. lEE Publishing, 2001,
no. ISBN: 0 85296 796 9.
[7] Vyatkin V. and Hanisch H.–M., “Verification of distributed control systems in
intelligent manufacturing”, Journal of Intelligent Manufacturing 1/2003, pp. 123 –
136
[8] Schimmel and A. Zoitl, "Distributed online change for IEC 61499," in Emerging
Technologies Factory Automation (ETFA), 2011 IEEE 16th Conference on, Sept. 20
II.
[9] Strasser, T., Sünder, C., Zoitl, A., Rooker, M., Brunnenkreef, J. 2007. “Enhanced
IEC 61499 Device Management Execution and Usage for Downtimeless
Reconfiguration”. 5th IEEE International Conference on Industrial Informatics,
(INDIN’07), Vienna, Austria, pp. 1163–1168. ISSN: 1935-4576. ISBN: 978-1-4244-
0851-1.
[10]Zoitl, C. Sunder, and 1. Terzic, "Dynamic Reconfiguration of Distributed Control
Applications with Reconfiguration Services based on IEC 61499," in Distributed
Intelligent Systems: Collective Intelligence and Its Applications, 2006. DIS 2006.
IEEE Workshop on, June 2006,pp. 109-114.
[11]Vyatkin, V., Chouinard, J. 2008. “On Comparisons of the ISaGRAF
Implementation of IEC 61499 with FBDK and other Implementations”. 6th IEEE
Marcelo García: Implementación de Sistemas Empotrados de Control Distribuidos bajo el Estándar IEC-
61499
Máster en Ingeniería de Control, Automatización y Robótica 56
International Conference on Industrial Informatics, (INDIN’08), Daejeon, Korea,
pp. 289-294. IBSN: 978- 1-4244-2170-1.
[12]Dai, W., Vyatkin, V. 2010. “Redesign Distributed IEC 61131-3 PLC System in IEC
61499 Function Blocks”. 15th IEEE International Conference on Emerging
Technologies and Factory Automation, (ETFA’10), Bilbao, Spain, pp. 8. ISBN: 978-
1- 4244-6849-2.
[13]Zoitl and V. V yatkin, "IEC 61499 Architecture for Distributed Automation: the
"Glass Half Full" View," IEEE Industrial Electronics Magazine, vol. 3, no. 4, pp. 7-
23, 2009.
[14]L. H. Yoong, P. S. Roop, V. Vyatkin, and Z. Salcic. (2009, Sept. 2). ‘‘A
synchronous approach for IEC 61499 function block implementation,’’ IEEE Trans.
Comput. [Online]. Available: http://doi.ieeecomputer
[15]Kaghazchi, H., Joyce, R., Heffernan, D. 2007. “A Function Block Diagnostic
Framework for a Multi-vendor PROFIBUS environment”. Journal: Assembly
Automation. Vol. 27, No. 3, pp.240-246. ISSN: 0144-5154.
[16]J. Christensen, “Basic Concepts of IEC 61499”. URL:
http://www.holobloc.com/papers/1499_conc. zip, [Acceso el 17-07-2013].
[17] Thramboulidis, K. 2009. “IEC 61499 Function Block Model: Facts and Fallacies,
IEEE Industrial Electronics”, Magazine. Vol. 3, No. 4, pp. 7-23. ISBN: 1932-4529.
[18]Thramboulidis, K. 2006. “A Model Based Approach to Address Inefficiencies of the
IEC 61499 Function Block Model”. 19th International Conference on Software and
Systems Engineering (ICSSEA’06), Paris, France, pp. 9.
[19]Lewis, R. 2001. “Modelling control systems using IEC 61499.” The Institution of
Electrical Engineers, London, United Kingdom. London, United Kingdom. Serie 59.
ISBN: 0 85296 796 9.
[20] Dubinin, V., Vyatkin, V. 2006.” Towards a Formal Semantic Model of IEC-61499
Function Blocks.” 4th IEEE International Conference on Industrial
Informatics,(INDIN’06), Singapore, pp. 6. ISSN: 4244-9701.
[21] A. Zoitl: “RealTime Execution for IEC 61499” ; ISA, Durham, North Carolina,
2008, ISBN: 9781934394274.
[23] Holobloc, Inc., 2008. “Tutorials - Basic Concepts of IEC 61499 tutorial FBDK
Function Block Development Kit,” Disponible online: http://www.holobloc.com/
[Acceso 11-07-2013]
Marcelo García: Implementación de Sistemas Empotrados de Control Distribuidos bajo el Estándar IEC-
61499
Máster en Ingeniería de Control, Automatización y Robótica 57
[24] 4DIAC Consortium. 2000. “4DIAC – Framework for Distributed Industrial
Automation and Control, Open Source for Distributed Industrial Automation”.
Disponible en: http://www.fordiac.org [Acceso el 03-08-2013].
[25] Zoitl, A., Vyatkin, V. 2009. “IEC 61499 Architecture for Distributed Automation:
The “Glass Half Full” View”. IEEE Industrial Electronics, Magazine. Vol. 3, No. 4,
pp. 7-23. ISBN: 1932-4529.
[26]Celan-Jones Rory, “Raspberry PI”, Available: http://es.wikipedia.org/wiki/
Raspberry_Pi. [Acceso el 05-08-2013].
[27]Upton Eben, “Raspberry Pi User guide”, Available: http://www.myraspberry-
pi.org/wp-content/uploads/2013/02/ Raspberry.Pi_.User_.Guide_.pdf [Acceso el 05-
08-2013].
[28]Gert Van Loo and Myra VanInewen. “Gert Board User Manual revision 2.0”.
2012,pp 2-4.
[29]Vyatkin, V., Chouinard, J. 2008. “On Comparisons of the ISaGRAF
Implementation of IEC 61499 with FBDK and other Implementations”. 6th IEEE
International Conference on Industrial Informatics, (INDIN’08), Daejeon, Korea,
pp.289-294. IBSN: 978- 1-4244-2170-1.
[30]Vyatkin, V. 2007. “IEC 61499 Function Blocks for Embedded and Distributed
Control System Design”, Ed. ISA O3NEIDA, United Stated of America. ISBN 978-
0-9792343-0-9.
[31]Santos, A., de Sousa, M. 2010.” Replication in Distributed Systems using IEC-
61499 Standard”. 15th IEEE International Conference on Emerging Technologies
and Factory Automation, (ETFA’10), Bilbao, Spain, pp. 8. ISBN: 978-1-4244-6849-
2.
[32]Morán, G. “Generación de aplicaciones de control distribuidas basada en
componentes funcionales”. Tesis doctoral. Departamento de Ingeniería de Sistemas
y Automática. (UPV-EHU) Bilbao