Máster en Ingeniería de Control, Automatización y …repositorio.educacionsuperior.gob.ec/bitstream/28000/1535/1/T... · Marcelo García: Implementación de Sistemas Empotrados

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


61499


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.


61499


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


61499


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.


61499


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.


61499


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


61499


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


61499


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.


61499


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:


61499


• 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


61499


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.


61499


• 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


61499


• 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.


61499


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


61499


• 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


61499


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.


61499


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.


61499


• 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


61499


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.


61499


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.


61499


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.


61499


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].


61499


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.


61499


• 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-


61499


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.


61499


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


61499


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


61499


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.


61499


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


61499


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:


61499


• 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


61499


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.


61499


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.


61499


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


61499


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


61499


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


61499


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


61499


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


61499


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


61499


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


61499


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


61499


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


61499


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


61499


Fig. 26: Aplicación de Control Distribuido en 4DIAC-IDE


61499


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


61499


Fig. 28: Configuración del Recurso HMI


61499


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


61499


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.


61499


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


61499


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


61499


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


61499


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.


61499


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


61499


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]


61499


[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

Documents

Máster en Ingeniería de Control, Automatización y …repositorio.educacionsuperior.gob.ec/bitstream/28000/1535/1/T... · Marcelo García: Implementación de Sistemas Empotrados