norma iec-61499 para el control distribuido

Actas de las XXXV Jornadas de Automática, 3-5 de septiembre de 2014, ValenciaISBN-13: 978-84-697-0589-6 © 2014 Comité Español de Automática de la IFAC (CEA-IFAC)

NORMA IEC-61499 PARA EL CONTROL DISTRIBUIDO.APLICACIÓN AL CNC.

Esteban Querol, Julio Ariel Romero, Antonio M. Estruch, Fernando RomeroDep. Enginyeria de Sistemes Industrials i DissenyUniversitat Jaume I, Campus de Riu Sec, Castelló

[email protected], [email protected], [email protected], [email protected]

Resumen

En este artículo se exponen algunos conceptos ypropuestas para el desarrollo de un prototipo quepermita la investigación en el campo de los sis-temas de fabricación flexibles aplicando la normaIEC 61499 para el desarrollo de sistemas de con-trol distribuidos. Las ideas y conceptos descritostienen en cuenta las características de dicha nor-ma, así como las herramientas y tecnología queactualmente la soportan.

Palabras clave: CNCs adaptativos e inteligen-tes, control distribuido, IEC 61499

1. INTRODUCCIÓN

Durante los últimos años el concepto de Bloque deFunción (FB) ha estado cada vez más presente enla programación de sistemas de automatización ycontrol industrial. A esto ha contribuido en granmedida el uso cada vez más extendido del estándarIEC 61131-3, que tiene a los FBs como uno de susconceptos de programación básicos, [2].

Desde el punto de vista de la programación, un FBes una unidad de software en la que se encapsulandatos y código y que cuenta con entradas y sali-das. A partir de un FB se pueden crear instancias,cada una de las cuales tendrá un comportamientodeterminado, el cual dependerá de los datos inter-nos almacenados en las instancia del FB y de susentradas.

Las características antes comentadas de los FBhan hecho que estos sean vistos como una herra-mienta efectiva para la automatización de siste-mas de fabricación flexibles y reconfigurables, [7].En este tipo de aplicaciones una instancia de FBpuede encapsular parte de los datos de un procesoque se ejecutará en una máquina de mecanizadoCNC, por ejemplo la operación de desbaste de unaranura, el acabado de una cajera o el taladrado deun agujero, generando diferentes salidas para lasmismas entradas en función del estado de las va-riables internas que dependerán de las variables dela máquina o de los propios procesos de mecani-zado (fuerzas, deflexiones, etc.).

Además del estándar IEC 61131-3, existe actual-mente otra norma en el ámbito de la automatiza-ción industrial que considera a los FBs como piezafundamental para la creación de aplicaciones. Setrata de la norma IEC 61499 para el desarrollo desistemas de control distribuidos, [3]. Ello ha moti-vado que la aplicación de esta norma al control desistemas de fabricación flexible esté siendo el focode atención de numerosas investigaciones.

Este artículo es el resultado de los primeros pa-sos para el desarrollo de un prototipo que permitala investigación en el campo de los sistema de fa-bricación flexibles aplicando la norma IEC 61499.El prototipo se desarrolla en el marco de un pro-yecto de investigación Desarrollo de sistemas ho-lónicos para el control de procesos de fabricacióncomplejos, en el cual se pretende definir y desarro-llar un sistema avanzado de control de procesosde fabricación que incorpore las últimas propues-tas tecnológicas y estándares de comunicación eintegración (protocolos y estándares de comuni-cación y los modelos de información) que se handesarrollado en los últimos años.

Una parte importante del artículo está dedicada ala norma IEC 61499, donde se describen sus carac-terísticas fundamentales desde un punto de vistaconceptual y se presenta las distintas herramientasy tecnologías que permiten el desarrollo de aplica-ciones basados en dicha norma. Finalmente descri-ben las características e ideas fundamentales quese están teniendo en cuenta para el desarrollo delprototipo.

2. EL ESTÁNDAR IEC 61499

2.1. DEFINICIÓN

El estándar IEC 61499 es una arquitectura de re-ferencia diseñada para facilitar el desarrollo deaplicaciones de control con lógica descentralizada[3, 5]. Para ello, propone una arquitectura basadaen bloques funcionales (FB) que se definen comola unidad estructural básica de los modelos. Cadabloque se caracteriza por sus entradas, salidas yfunciones internas, así al igual que ocurre con losdiagramas de bloques clásicos, a partir de las en-

DavidA

Resaltar

DavidA

Resaltar

DavidA

Resaltar

DavidA

Resaltar

DavidA

Resaltar


tradas y la definición del bloque (comportamientointerno) tendremos unas salidas. A través de la in-terconexión de bloques simples podemos conseguirmodelar aplicaciones y modelos complejos. El es-tándar busca aprovecha los amplios conocimientosde los ingenieros en el desarrollo de los diagramasde bloques mediante esta forma de modelado.

Otra de las nociones básicas de este estándar, jun-to con la definición de bloque funcional, es la formade ejecución de los FB. Los bloques funcionales nose ejecutan hasta que reciben una señal de entra-da, así estos permanecen en un estado de reposohasta que es necesaria su ejecución, a diferencia delos componentes de la IEC 61131, donde las subru-tinas son verificadas periódicamente. Esta formade ejecución tiene por objetivo la portabilidad yreutilización de los FB. Gracias a que cada FB tie-ne su propio contexto y es ejecutado sólo ante unademanda, podemos considerar que este se compor-ta como una unidad totalmente independiente delresto.

2.2. OBJETIVOS

El estándar busca conseguir un alto grado de con-trol distribuido siendo este su principal objetivo.A diferencia de los otros estándares de control,más antiguos y no adecuados a los nuevos com-ponentes (sistemas embebidos, PC industriales yredes más avanzadas) pueden ser utilizados paradescentralizar la lógica de control y poder implan-tar controles holónicos o multiagente, que haganlos sistemas más flexibles. Además, la creciente im-portancia del software en el control hace que la re-utilización de código sea vista como una cuestiónfundamental. Es decir, poder diseñar un mismosoftware para dos máquinas que tienen que hacerlo mismo pero son de fabricantes diferentes.

Por estas razones, la arquitectura del IEC 61499está fundamentada en la busca de tres aspectosclave, [1]:

Portabilidad: La herramientas de softwarepueden aceptar e interpretar correctamentelos componentes de software y las configura-ciones del sistema creadas por diferentes he-rramientas de desarrollo.

Configurabilidad: Cualquier dispositivo y susoftware puede ser configurado por las herra-mientas de desarrollo de diferentes vendedo-res.

Interoperabilidad: Los dispositivos embebidospueden trabajar juntos para realizar las fun-ciones necesarias de las aplicaciones distribui-das.

2.3. ESTRUCTURA DEL ESTÁNDAR

En cuanto a la estructuración del estándar, estese encuentra distribuido en 4 partes, siendo cadauna independiente de las otras y con objetivos di-ferentes. A continuación resumimos estas 4 partesy sus objetivos.

Parte 1: Define la arquitectura de referencia pa-ra el desarrollo, reutilización e implementa-ción de los bloques funcionales. Se definen,entre otros, los conceptos de bloque funcio-nal básico, bloque funcional compuesto, apli-cación, interfaz, dato, señal evento. . .

Parte 2: En esta parte se definen los requisitosque deben cumplir las herramientas de desa-rrollo para poder desarrollar las arquitecturaspropuestas en la parte 1. No obstante, los re-quisitos definidos no permiten por ellos mis-mo garantizar la interoperabilidad, portabili-dad y la configurabilidad. Entre otras cosas,se definen los esquemas XML para el inter-cambio de ficheros entre las distintas herra-mientas.

Parte 3: Información didáctica que tiene por ob-jeto mostrar las funcionalidades y ejemplosde aplicación de la IEC 61499 en un amplioconjunto de dominios.

Parte 4: El objetivo de esta parte es definir unosperfiles de compilación de forma que se pue-dan cumplir los objetivos de la norma IEC61499 en los dispositivos compatibles y las he-rramientas de desarrollo.

2.4. DUALIDADMODELO-IMPLEMENTACIÓN

Desde cierto punto de vista se puede ver la IEC61499 como una forma de modelar aplicaciones decontrol a través del concepto de bloque funcional,ya que entre otras cosas nos permite la encapsula-ción de componentes (otros FB) y la visualizaciónde las interconexiones entre componentes. De es-te modo podemos ver el sistema desde diferentesniveles de abstracción según el nivel de detalle ne-cesario. Pero al mismo tiempo esta arquitecturatambién es una implementación del propio control,el modelo diseñado será implementado y ejecutadodirectamente. Esta dualidad puede resultar confu-sa a la hora de abordar este estándar, además ladependencia de ciertas partes del modelo, como losbloques funcionales de interfaz de servicio (SIFB)que dependen de la plataforma de ejecución pue-den suponer una desventaja, ya que el modelo delsistema debería ser independiente de la platafor-ma.

DavidA

Resaltar

DavidA

Resaltar

DavidA

Resaltar

DavidA

Resaltar


3. MODELOS DE LA NORMAIEC 61499

En esta sección desarrollaremos algunos de losconcepto clave para entender la arquitectura delestándar IEC 61499. Estos conceptos se encuen-tran definidos en la parte 1 del estándar y consti-tuyen el esqueleto de la misma.

3.1. MODELO DE SISTEMA

El sistema es el elemento de mayor nivel que con-templa esta arquitectura, engloba todos los dispo-sitivos capaces de comunicarse y el conjunto deaplicaciones, así como las relaciones entre estosdos grupos. Desde el punto de vista del sistema,las aplicaciones son unitarias pero estas se puedenencontrar distribuidas entre los diferentes disposi-tivos del sistema, Figura 1, usando los mecanismosque el propio estándar define.

Figura 1: Modelo de sistema en la norma IEC61499, [3].

3.2. MODELO DE DISPOSITIVO

El modelo de dispositivo que podemos ver en laFigura 2, representa la entidad física que va a eje-cutar nuestra red de bloques funcionales. Lo po-dríamos asimilar a un sistema embebido o a unPC. El dispositivo es capaz de comunicarse conotros dispositivos o con sus periféricos a travésde interfaces de comunicación. Al mismo tiempoes igualmente capaz de comunicar con la red debloques funcionales a través de un interfaz de pro-ceso.

3.3. MODELO DE RECURSO

Un recurso se puede definir como una parte deldispositivo designada a ejecutar un conjunto debloques funcionales determinado, pertenecientes ono a la misma aplicación. El concepto de recur-so podría ser visto como el conjunto de “recursosdel dispositivo” dedicados exclusivamente al con-junto de bloques funcionales asignados a ese re-curso. Cada recurso tiene la característica de ser

Figura 2: Modelo de dispositivo en la norma IEC61499, [3].

independiente de los demás, esto implica que, unparte de los bloques funcionales que se están eje-cutando en un determinado dispositivo se puedenparar, ejecutar o redefinir sin que esto afecte a losotros bloques definidos en el resto de recursos deldispositivo.

3.4. MODELO DE APLICACIÓN

Una aplicación es un conjunto de bloques funcio-nales interconectados entre si y unidos por un flu-jos de señales y datos. Las aplicaciones como he-mos visto se pueden distribuir entre diferentes re-cursos, del mismo dispositivo o de dispositivos di-ferentes, Figura 3.

Figura 3: Modelo de aplicación en la norma IEC61499, [3].

DavidA

Resaltar


3.5. MODELO DE BLOQUEFUNCIONAL

3.5.1. Interfaz, señales y datos

Como habíamos introducido previamente cadabloque funcional representa una unidad compu-tacional independiente, cada bloque tiene su pro-pio contexto de ejecución (variables) y sus algo-ritmos. Gráficamente, cada uno de estos bloquesfuncionales, independientemente de su tipo, se re-presenta mediante un interfaz.

Figura 4: Ejemplo de interfaz de bloque funcional.

En la Figura 4, podemos ver dicho interfaz. En élse distinguen varias partes. En la parte superior sedefinen las señales de entrada, a la izquierda lasde entrada y a la derecha las de salida.

En la parte central, se observa el tipo de bloquefuncional, no hay que confundir el tipo con el nom-bre del bloque. El nombre del bloque lo podemosver en la parte superior y fuera del mismo, en elejemplo sería “instancia de Suma”, este nombrenos permite identificar cada bloque concreto den-tro de un esquema.

En la parte inferior podemos observar el flujo dedatos, en la izquierda se representan los datos deentrada y en la derecha los de salida. Cada datotiene un tipo y, al igual que ocurría con las seña-les, éste suele venir indicada al lado de la entra-da/salida correspondiente. Finalmente, el últimoelemento que representamos gráficamente es el co-nector WITH que está formado por dos pequeñoscuadrados y una línea que une algunas señales conuno o más datos. El WITH puede definirse comouna asociación entre señales y datos, de forma quecuando se reciba o envíe una señal se actualizaránlos registros de los campos datos asociados.

3.5.2. Bloque funcional básico

Una vez hemos definido el interfaz general de unbloque funcional, vamos a pasar ahora a explicarlas características propias de un bloque funcionalbásico, que representa la unidad funcional de másbajo nivel a partir de la cual se construyen el resto.Concretamente nos centraremos en el análisis desu comportamiento interno.

En la Figura 5, podemos observar dicho FB. Apar-

Figura 5: Interfaz de un bloque funcional básicoen la norma IEC 61499, [3].

te de las partes del interfaz que ya hemos comen-tado, el BFB se caracteriza por dos elementos quesólo posee él: el control de ejecución (ECC, exe-cution control chart) y los algoritmos del propiobloque.

El ECC, representa el comportamiento interno delbloque, es decir, define como debe actuar el bloqueante un estímulo determinado (señal). La defini-ción de la ECC es muy similar a la de una máqui-na de estados. Cada BFB contiene exactamente 1ECC, no es posible definir más de uno por bloque.

Figura 6: Execution control chart (ECC) del blo-que Suma.

En la Figura 6 podemos observar un ejemplo deECC, se trata del control de ejecución del bloquefuncional “Suma” que hemos presentado anterior-mente. Los rectángulos del ECC representan losestados en los que se puede encontrar el bloque,siendo el rectángulo con doble borde el estado dereposo por defecto. Si estando en un estado se re-cibe la señal de disparo correspondiente, el estadodel bloque evoluciona al siguiente. Aunque no hayninguna limitación formal, se recomienda limitar

DavidA

Resaltar


el número de estados a un máximo de 4-5 para lasaplicaciones más complejas.

Cada estado tiene asociado uno o más algoritmosque se ejecutarán cuando se entre en el estado. Enel ejemplo anterior, el algoritmo “SumaSimple” seencuentra asociado con el estado “Calculo” de for-ma que tras recibir la señal “Sumar” el estado delbloque pasa a “Calculo” y se ejecuta el algoritmo“SumaSimple”. Cuando el algoritmo se acabe deejecutar, se generaran las señales de salida perti-nentes. Estas se encuentran definidas en el ECCjunto al algoritmo que las dispara.

En cuanto a la creación de los algoritmos hay quedestacar que, el IEC 61499 no define el lengua-je en el que se tiene que programar y, por tanto,se puede ejecutar cualquier lenguaje que la imple-mentación sea capaz de interpretar.

Además de los algoritmos y los ECC, un bloquebásico posee otra característica propia, su contex-to, que se puede definir como el conjunto de varia-bles globales para todo el bloque. Las variables de-finidas en el contexto del bloque pueden ser usadaspor todos los algoritmos del bloque pero en nin-gún caso serán accesibles para un elemento fuerade éste.

Finalmente, hay que resaltar que aunque el ECCse suele crear de forma gráfica, éste al igual quenos ocurría con el interfaz, también lo podemosdefinir textualmente.

Además de los BFB existe dos tipos más de FB:

Bloque funcional compuesto: Los bloquesfuncionales compuestos, CFB, por sus siglasen inglés son bloques funcionales compuestosde bloques funcionales básicos. Así, dentro decada bloque compuesto podemos encapsularuna cantidad ilimitada de bloques simples. Elinterfaz de cada bloque es idéntico al de unbloque simple, e igual al que hemos descritopreviamente.

Bloque funcional de interfaz de servicio:Los bloques de interfaz de servicio, SIFB,son los encargados de gestionar las comuni-caciones entre los bloques funcionales y elmundo exterior. Se encargan de proveer losservicios que los bloques necesitan a estosefectos, entre los servicios más comunessuelen estar la gestión (escritura y lectura)de entradas/salidas y la comunicación entreaplicaciones y recursos diferentes.

3.6. MODELO DE SUBAPLICACIÓN

El modelo de subaplicación puede verse como unmodelo de bloque funcional compuesto distribui-

ble. En efecto, las subaplicaciones son una red debloques básicos, compuestos u otras subaplicacio-nes. Estas pueden distribuirse entre diferentes re-cursos, a diferencia de los bloques compuestos olos simples.

Sin embargo, una subaplicación nunca puede es-tar contenida dentro de un bloque compuesto, sólopueden pertenecer a aplicaciones o a otras subapli-caciones. La asociación de señales es muy similara la de los bloques compuestos pero con menosrestricciones, se permite por ejemplo conectar unaentrada directamente a una salida sin pasar porningún bloque intermedio.

4. HERRAMIENTAS DEDESARROLLO DE LOSMODELOS

Como hemos introducido en la primera sección delpresente documento, en la parte 2 de la normase especifican las características que deben cum-plir de las herramientas de desarrollo para lograrla interoperabilidad, uno de los principales obje-tivos de esta norma. A continuación presentamosbrevemente las 4 herramientas de desarrollo másimportantes y su grado de interoperabilidad.

4.1. FUNCTIONAL BLOCKDEVELOPMENT KIT (FBDK)

Este es el primer entorno de desarrollo que se creó,por uno de los miembro creadores del IEC 61499.Su principal objetivo era permitir la visualizaciónde los FB, aunque con los años ha ido evolucionan-do y ahora permite además de representar, testearlos bloques e intercambiarlos en forma de XML co-mo se define en la parte 2 de la norma.

En cuanto a la herramienta, se encuentra desa-rrollada en java, posee un interfaz simple y pocoamigable para el usuario. La aplicación aún tienesoporte y se distribuye de forma gratuita por laempresa Holoblocs. Inc. Los distribuidores sacanactualizaciones continuas para reflejar los constan-tes cambios y mejoras en la norma. Es capaz deexportar e importar desde 4DIAC y nxtStudio. Enla Figura 7 se muestra una imagen del entorno dedesarrollo de FBDK.

4.2. 4DIAC-IDE

4Diac es un entorno de desarrollo opersource ex-tensible a través de plugins, basado el reconoci-do entorno de desarrollo Eclipse. La aplicación esmuy robusta y muy intuitiva, tiene soporte oficialy saca dos actualizaciones del entorno por año.Permite la creación de bloques básicos, sistemas


Figura 7: Entorno de desarrollo de FBDK.

aplicaciones y el resto de modelos. Además, permi-te distribuir muy fácilmente las aplicaciones entrediferentes recursos de forma gráfica. En las últimasversiones ha añadidos las funcionalidad de test ydebug por medio de un display online que permi-te fijar y leer los valores de las variables de formaremota. Se ha demostrado su portabilidad con nx-tStudio y con FBDK. En la Figura 8 se muestrauna imagen del entorno de desarrollo de 4Diac.

Figura 8: Entorno de desarrollo de 4DIAC-IDE.

4.3. NxtOne

Esta es una aplicación comercial desarrollada porla compañía nxtControl, que ofrece soporte para lanorma IEC 61499, se ha utilizado en una multitudde dispositivos y máquinas de diferentes vendedo-res. Al igual que 4DIAC, es compatible con el restode herramientas de desarrollo a excepción de ISa-GRAF, además incluye funciones de debugging yde test. Posee un HMI para visualizar la ejecucióna diferencia de 4DIAC. Por otra parte tambiénincluye una funcionalidad CAT (Compound Au-tomation Types) que nos aporta un conjunto deelementos de control prediseñados.

4.4. ISaGRAF

Al igual que nxtOne es una herramienta comercialdesarrollada por la compañía ICE Triplex que per-

tenece a Rockwell automation. Esta herramientasoporta la IEC 61499 conjuntamente con la IEC61131. Al igual que 4DIAC y nxtOne, tiene fun-cionalidades de debug y test y soporte oficial. Seha utilizado en el desarrollo de muchas aplicacio-nes en componentes de diferentes vendedores. Unode los grandes inconvenientes de esta herramientaes su incompatibilidad con el resto de plataformasde desarrollo.

5. PLATAFORMAS DEEJECUCIÓN

Como hemos definido previamente el IEC 61499propone una arquitectura de referencia, un mode-lo pero no es una implementación. Una vez desa-rrollado el modelo de control distribuido necesi-tamos una plataforma de ejecución que se encar-gue ejecutar nuestro modelo. Esta plataforma deejecución se encargará de interpretar y gestionarnuestro modelo, así definirá las reglas de ejecuciónde cada bloque y sus prioridades, es el encargadode suministrar el organizador de tareas o “taskscheduling” que se ha introducido en la primerasección.

La plataforma de ejecución se encargara de ges-tionar el Hardware del dispositivo sobre el quese ejecuta nuestro modelo, entre otras cosas de-berá gestionar la memoria, las comunicaciones ylas entradas/salidas del dispositivo. A estos efec-tos podemos asimilar la plataforma de ejecucióna un sistema operativo que se encarga de ejecutarnuestro programa.

Para poder ejecutar nuestro modelo, la plataformadeberá conocer todos los tipos de bloque funcio-nal utilizados en él. Es decir, si hacemos nuestrospropios tipos de bloques funcionales primero de-beremos compilar una nueva versión de la plata-forma de ejecución, a partir de los ficheros fuentedonde habremos añadido nuestros tipos. Despuéspodremos ejecutar la plataforma y enviar nuestromodelo, para finalmente poderlo ejecutar.

5.1. FUNTIONAL BLOCK RUNTIME(FBRT)

Este runtime fue el primero que se desarrolló jun-to a FBDK para poder testear y hacer las prime-ras demostraciones usando la norma IEC 61499.Esta desarrollado en java y tiene dos versiones di-ferentes. La primera se desarrolló en java embe-bido para poder ser utilizada en los dispositivosembebidos, no obstante cuando aparecieron otrosruntime se dejó de desarrollar, entre toras cosas,por la dificultad de lograr un sistema tiempo realen java.

DavidA

Resaltar

DavidA

Resaltar


La otra versión no-embebida estaba desarrolladaen java estándar y se puede ejecutar en cualquierdispositivo con JVM. Esta última versión siguesiendo evolucionada y presenta la ventaja respectoa otras de que tiene un HMI que permite visualizarlos resultados. Es por esto que se sigue utilizandoFBRT, especialmente para simular y depurar apli-caciones.

Además de FBDK, FBRT también puede ser con-figurado y utilizado por 4DIAC-IDE y nxtOne.

5.2. FORTE

Es una pequeña plataforma de ejecución imple-mentada en C++ y de código abierto, desarrolla-da por el mismo equipo que 4DIAC. Esta espe-cialmente desarrollada para ejecutarse en peque-ños sistemas embebidos y sistemas de tiempo real,ya que tiene los mecanismos necesarios para poderasegurar la ejecución en tiempo real y la gestión deprioridades. Otro de los puntos fuertes de FORTEes que ha sido diseñada para ser independiente dela plataforma sobre la que se ejecute, para poderser ejecutada en diferentes hardwares y sistemasoperativos. En la actualidad FORTE se ha lleva-do a diferentes sistemas operativos como POSIX,windows32, threadX y eCos.

FORTE se puede configurar con 4DIAC pero tam-bién es compatible con otros entornos como FBDKo nxtOne.

5.3. ISaGRAF RUNTIME

A diferencia de las otras plataformas de ejecuciónque presentamos en este documento, este runtimeno se ha desarrollado con el perfil de compilaciónpropuesto por Holobloc, que es el que se ha adop-tado como estándar, sino que usa su propio perfilde compilación. En consecuencia, ISaGRAF Run-time sólo se puede utilizar desde ISaGRAF y noexiste interoperabilidad con las otras plataformasde ejecución.

Por otra parte, este runtime tiene ciertas caracte-rísticas de ejecución que no cumple estrictamentecon el IEC 61499, entre otras cosas no utiliza elmodelo de ejecución basado en eventos. Es decir,en lugar de ejecutar un bloque solamente cuandollega la señal de entrada, ISaGRAF runtime uti-liza un modelo más cercano a las subrutinas de611131, y hace una verificación continua del estadode la entrada. Esta diferencia de comportamientopuede suponer una diferencia de ejecución respec-to a las otras plataformas aunque, según los inves-tigadores [6] las diferencias deberían ser mínimasen la mayoría de los casos.

5.4. nxtRT61499F

Esta plataforma de ejecución se basa en FORTE,ha sido modificada para incluir algunas funciona-lidades adicionales y hacerla más eficiente. Perte-nece a nxtControl y puede ser configurada tantodesde nxtOne como desde 4DIAC y FBDK. Se haimplantado en dispositivos de diferentes vendedo-res entre los que destacan SIEMENS o BOSCH[4].

6. DESARROLLO DELPROTOTIPO

Para que el desarrollo de un sistema de control deuna célula de mecanizado basado en FBs sea po-sible, es importante considerar la evolución de losCNCs en los últimos años. Una evolución que havenido marcada por los avances en las arquitectu-ras de los sistemas de control numérico distribui-dos y los CNC abiertos, una orientación que tienepor objetivo crear una plataforma de integraciónen la que los componentes de software puedan serfácilmente integradas con el núcleo de la funciona-lidades de un CNC.

Para nuestro prototipo se ha seleccionado un con-trol abierto de nueva generación, en concreto elFAGOR 8070 OL, un sistema abierto basado enPC que corre bajo el Sistema operativo WindowsXP embebido, puede controlar hasta cuatro cabe-zales y cuatro almacenes y posee grandes posibi-lidades de conectividad a través de la Ethernet yde los bus de campo Sercos, CANOpen y Mecha-trolink.

En este prototipo las órdenes de ejecución de lasoperaciones de mecanizado son enviadas al CNCdesde una red de FBs implementada en el runtimede Forte siguiendo la norma IEC 61499. Estos FBsse comunican con los distintos servidores del CNCutilizando la tecnología COM para enviar coman-dos, acceder a variables y recibir notificaciones.Por lo tanto, ha sido necesario desarrollar una ca-pa de encapsulamiento de comunicaciones COMcon los principales servidores del CNC. Sobre es-ta capa se han implementado FBs específicos delCNC formando parte del firmware. Su desarrolloha sido complejo y ha requerido partir del códigofuente C++ de Forte para desarrollar estos nue-vos FBs específicos sobre la capa de comunicaciónCOM que invoca a los servidores del CNC. La Fi-gura 9 muestra la integración entre el runtime deForte y el CNC 8070.

Otro aspecto importante es el tratamiento deeventos que ocurren en el CNC y que deben sertratados correctamente por la red de FBs. Porejemplo, el envío de órdenes de mecanizado al PLC


Figura 9: Integración entre el runtime de Forte yel CNC 8070.

sólo es posible cuando el PLC levanta la señalCYStart. Esta situación provoca una notificaciónque da luz verde al envío por parte de un FB deun bloque de órdenes en el lenguaje ISO al CNC.La ejecución de las operaciones de mecanizado noes inmediata y la finalización de la ejecución delas mismas sólo se detecta por un cambio en lasvariables de estado del CNC. Estos cambios en lasvariables de estado generan a su vez eventos quedeben ser tratados por los FBs para continuar conla ejecución de las siguientes operaciones. La Fi-gura 10 muestra de forma simplificada la ejecuciónde la operación de fresado de una cajera (pocket)utilizando FBs.

Figura 10: Ejecución de la operación de fresado deuna cajera.

7. CONCLUSIONES

El estándar IEC 61499 aporta a los desarrollado-res de software de control una arquitectura de refe-rencia para poder diseñar más fácilmente las apli-caciones de control distribuido, gracias a esta ar-quitectura es posible llegar a implantar controlesholónicos o multi-agente que hasta ahora perma-necían en un plano teórico. Las posibilidades yventajas de adoptar este tipo de arquitectura sonmúltiples y variadas, ente otras, podríamos desta-car la capacidad de pasar del diseño a la imple-mentación de forma directa, a través del toolchainapropiado, o la capacidad de usar dispositivos em-bebidos y PCs para el control.

Actualmente existe numerosas herramientas y tec-nología que permiten la aplicación de la normaIEC 61499 al caso de los CNC distribuidos. En esesentido, la existencia de los CNC abiertos permi-ten de forma efectiva la integración de aplicaciones

desarrolladas bajo el paradigma IEC 61499 con lasfuncionalidades básicas de un control CNC, posi-bilitando el desarrollo de CNCs adaptables e inte-ligentes. Unos CNCs que además, al programarsemediante FBs pueden integrarse en un sistema decontrol distribuido basado basados en esta mismatecnología. Una opción que puede mejorar la flexi-bilidad, por ejemplo a nivel de rutas y secuencias,de los que los actuales Sistemas de FabricaciónFlexible.

Agradecimientos

Este trabajo ha sido financiado por el proyectoP1.1B2012-60 Plan de Promoción de la Investiga-ción de la Universitat Jaume I del año 2012.

Referencias

[1] Julien Chouinard and Robert Brennan. Soft-ware for Next Generation Automation andControl. In 2006 IEEE International Con-ference on Industrial Informatics, pages 886–891. IEEE, August 2006.

[2] John Karl-Heinz and Michael Tiegelkamp.IEC 61131-3: Programming Industrial Au-tomation Systems - Concepts and Program-ming Languages, Requirements for Program-ming System, Aids to Decision-Making Tools.2001.

[3] Robert W. Lewis. Modelling Control SystemsUsing IEC 61499. Applying function blocks todistributed systems. The Institution of Engi-neering and Technology, 2001.

[4] Valeriy Vyatkin. IEC 61499 as Enabler of Dis-tributed and Intelligent Automation: State-of-the-Art Review. IEEE Transactions on In-dustrial Informatics, 7(4):768–781, November2011.

[5] Valeriy Vyatkin. Software Engineering in In-dustrial Automation: State of the Art Review.IEEE Transactions on Industrial Informatics,(c):1–1, 2013.

[6] Valeriy Vyatkin and Julien Chouinard. Oncomparisons of the ISaGRAF implementationof IEC 61499 with FBDK and other implemen-tations. In 2008 6th IEEE International Con-ference on Industrial Informatics, pages 289–294. IEEE, July 2008.

[7] Hongqiang Wang, Xun Xu, and J. Des Ted-ford. An adaptable cnc system based on step-nc and function blocks. International Jour-nal of Production Research, 45(17):3809–3829,2007.

DavidA

Resaltar

norma iec-61499 para el control distribuido

Documents