Universidad de Los Andes
Tesis de Maestrıa
Implementacion de un sistema decontrol distribuido siguiendo el estandar
IEC 61499
Autor:
Sergio Bacca
Asesor:
Dr. Fredy Segura
Trabajo de tesis presentado para obtener
el tıtulo de Magıster en ingenierıa electronica y de computadores
en el
Centro de Microelectronica de la Universidad de los Andes
Departamento de ingenierıa electrica y electronica
Enero 2015
ii
Declaracion de propiedad
Yo, Sergio Bacca, declaro que esta tesis titulada, ’Implementacion de un sistema de
control distribuido siguiendo el estandar IEC 61499’ y el trabajo presentado en esta son
mıos. Ademas confirmo que:
� En caso de haber consultado el trabajo de otras personas, este sera referenciado
adecuadamente.
� Se hara una mencion agradeciendo a todas las personas que colaboraron en este
proyecto.
� En caso que parte del trabajo haya sido desarrollada en conjunto con otras per-
sonas, se mencionara cual fue el aporte de esas personas.
� Las imagenes presentadas pertenecientes a otros trabajos, libros, revistas y artıculos
seran referenciadas adecuadamente; todas las imagenes fueron tomadas con fines
netamente academicos y se utilizan unicamente para ilustrar conceptos.
� Pese a que se esta utilizando la tecnologıa EtherCAT, ninguna de las implementa-
ciones realizadas se encuentra certificada por EtherCAT Technology Group (ETG)
ni por ninguno de sus integrantes.
� Aunque se ha hecho un esfuerzo por verificar la veracidad y la calidad de la infor-
macion presentada, el autor no se hace responsable por ningun incidente que se
produzca por el mal uso de dicha informacion o por imprecisiones en el contenido.
Firma:
Fecha:
i
“Si conoces a los demas y te conoces a ti mismo, ni en cien batallas correras peligro; si
no conoces a los demas, pero te conoces a ti mismo, perderas una batalla y ganaras otra;
si no conoces a los demas ni te conoces a ti mismo, correras peligro en cada batalla”
Sun Tzu
UNIVERSIDAD DE LOS ANDES
Resumen
Facultad de ingenierıa
Departamento de ingenierıa electrica y electronica
Magıster en ingenierıa electronica y de computadores
Implementacion de un sistema de control distribuido siguiendo el estandar
IEC 61499
por Sergio Bacca
Durante anos, los lenguajes de control descritos en el estandar IEC 61131-3 han domi-
nado la programacion de los controladores de logica programable (PLC) y de los sistemas
de control en general; incluyendo los sistemas de control distribuido (DCS). Estos lengua-
jes, denominados lenguajes clasicos en este documento,se caracterizan por su simplicidad
y por el amplio conocimiento que los ingenieros y los tecnicos de control han desarro-
llado de los mismos. El nivel de conocimiento ha llegado al punto que varios autores
han metodologıas estructuradas de diseno basadas en la logica inherente a los lenguajes
clasicos. Por ejemplo en [1] se presenta una metodologıa denominada logica en cascada
(Cascading Logic) la cual utiliza diagramas de escalera (LD) para desarrollar programas
que controlan maquinas.
Aunque los lenguajes clasicos son simples y bastante utilizados, presentan varias las
cuales en su mayorıa han surgido por la imposibilidad de explotar varios avances tec-
nologicos y por los nuevos retos de produccion de las empresas [2]. La principal lim-
itacion, en el contexto de produccion, es la dificultad para reconfigurar los sistemas y
cambiar las lıneas de produccion con el objetivo de fabricar nuevos productos reuti-
lizando equipos. Esta limitacion en parte es causada por la forma como se estructura el
codigo ya que estos, en el enfoque clasico, se ejecutan secuencialmente. Esto significa que
el programa solo debe ejecutarse en un orden especıfico lo cual hace el codigo inservible
si este se ejecuta en un orden distinto. La imposibilidad de reutilizar los algoritmos
ya programados limita la reconfiguracion de nuevas tareas de control ya que cualquier
modificacion puede ser costosa y demorada.
Desde el punto de vista tecnologico, en la actualidad los sistemas de control siguen un
enfoque de control distribuido. Es decir, se utilizan redes de comunicacion para conectar
varios dispositivos a un sistema de control; los dispositivos se convierten en nodos del
sistema. Los lenguajes clasicos no contemplan la reparticion de las tareas logicas en los
nodos de una red al nivel de dispositivos; en la seccion 1.4 se muestran los niveles de un
sistema de control. Con los lenguajes clasicos, lo mas cercano al enfoque de reparticion
de tareas en los nodos de la red es lo establecido en el estandar IEC 61804. El estandar
define bloques de funcion estandar para describir dispositivos e implementar lazos de
control. La tecnologıa Foundation Fieldbus (FF) implementa de manera exitosa los
bloques del estandar en los dispositivos de campo, permitiendo configurar lazos cerrados
de control de forma distribuida [3]. Sin embargo, ninguna parte del programa principal
es ejecutada en los nodos de la red; ninguna seccion de la secuencia logica se implementa
en los dispositivos. En resumen, se esta desaprovechando la oportunidad de repartir las
tareas del codigo en varios procesadores repartidos a lo largo de una red. Esto permitirıa
ejecutar algoritmos complejos de forma paralela y descentralizada.
Varias de estas limitaciones han sido resueltas utilizando otro tipo de lenguajes para la
implementacion de los algoritmos de control. Por ejemplo, algunos lenguajes de progra-
macion como C, C++, Java, Python . . . proporcionan librerıas y acceso a herramientas
que facilitan la comunicacion entre procesos que se encuentran en la misma maquina
o en una maquina remota; los sockets son un ejemplo de estas herramientas [4]. Sin
embargo, estos lenguajes han tenido un uso limitado en los PLC ya que este tipo de
lenguajes de alto nivel no estan enfocados a los sistemas de control y su ejecucion puede
ser impredescible. Adicionalmente, los lenguajes del estandar IEC 61131-3 son bastante
simples y permiten programar tareas de control con mayor facilidad dada la simplicidad
de su sintaxis. Para entender y utilizar los lenguajes clasicos no se requiere tener un
amplio conocimiento de programacion, ni tampoco es necesario conocer los paradigmas
inherentes a los lenguajes como C++.
Debido a las limitaciones de los lenguajes clasicos, a mediados de los 90 el comite 6
de la IEC empezo a trabajar en un nuevo estandar el cual debıa presentar un enfoque
para cumplir con 3 requerimientos principales: permitir la reconfiguracion de los nuevos
sistemas de control con mayor facilidad que los lenguajes ya existentes; aprovechar las
capacidades de procesamiento paralelo de los sistemas de control distribuido; y mantener
la simplicidad de los lenguajes clasicos. El resultado de mas de 10 anos de trabajo fue
el estandar IEC 61499 que propone un lenguaje basado en bloques funcionales para
cumplir con los 3 requerimientos mencionados. A diferencia del lenguaje clasico de
bloques funcionales, los nuevos bloques se manejan por eventos. Ademas mantiene el
uso de entradas y salidas las cuales, junto a los eventos, sirven para comunicar los bloques
entre sı. Adicionalmente, con el objetivo de mantener la simplicidad en el lenguaje, la
descripcion de cada bloque se puede hacer utilizando los lenguajes clasicos como se vera
en la seccion 1.2.
En este documento se presenta una implementacion de un sistema de control distribuido
que utiliza y sigue el enfoque del nuevo estandar.El sistema se implementa desde la
capa Hardware, incluye un stack de comunicaciones e incluye aplicaciones de alto nivel
que implementan la logica del estandar de forma distribuida. El objetivo principal es
presentar las ventajas del nuevo enfoque con respecto al enfoque clasico. Ademas de
mostrar los distintos componentes que una implementacion de este estilo podrıa tener.
La informacion presentada en este documento esta organizada en capıtulos de la siguiente
forma:
• Capıtulo 1: Introduccion, presenta una explicacion de algunos temas que sirven
para entender el contenido de los demas capıtulos. Adicionalmente se definen los
objetivos de este trabajo.
• Capıtulo 2: Capa fısica, presenta el desarrollo de una plataforma Hardware
capaz de soportar la implementacion del sistema de control distribuido.
• Capıtulo 3: Stack de comunicaciones, se muestran detalles de la capa de
enlace de datos y de la capa de aplicacion que se utilizan en la plataforma sobre
la cual se implementa el sistema de control distirbuido. Ademas se hace una
descripcion detallada sobre la forma como la plataforma seleccionada se integra
con el enfoque del estandar.
• Capıtulo 4: Uso de FBDK (Function Block Development Kit), Se mues-
tran detalles de la implementacion utilizando el estandar IEC 61499.
• Capıtulo 5: Resultados y conclusiones, por ultimo, se analizan en detalle los
resultados obtenidos en el capıtulo anterior y se presentan algunas propuestas de
trabajo futuro.
Agradecimientos
En primer lugar quiero agradecer al profesor Fredy Segura por haberme asesorado y
guiado durante el desarrollo de este trabajo y por su espıritu innovador que demuestra
al apoyar trabajos en temas novedosos y actuales. Tambien quiero agradecer a mi equipo
de trabajo ROBOCOL por todo lo que me han ensenado y por darme la oportunidad
de seguir aprendiendo todos los dıas.
vii
Contenidos
Declaracion de propiedad i
Resumen iii
Agradecimientos vii
Contenidos viii
Lista de Figuras xi
Lista de Tablas xiv
Abreviaciones xv
1 Introduccion 1
1.1 Panorama actual de los sistemas de control . . . . . . . . . . . . . . . . . 1
1.2 El estandar IEC 61499 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.2.1 Bloques de funcion . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.2.2 Herramienta de desarrollo . . . . . . . . . . . . . . . . . . . . . . . 8
1.3 Requerimientos de los programas de control . . . . . . . . . . . . . . . . . 9
1.4 Buses de campo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
1.4.1 Dispositivos inteligentes . . . . . . . . . . . . . . . . . . . . . . . . 15
1.4.2 Los buses de campo y el modelo OSI . . . . . . . . . . . . . . . . . 15
1.5 Tecnologıas de buses de campo . . . . . . . . . . . . . . . . . . . . . . . . 16
1.5.1 Niveles de los buses de campo . . . . . . . . . . . . . . . . . . . . . 18
1.5.2 Foundation Fieldbus . . . . . . . . . . . . . . . . . . . . . . . . . . 19
1.5.2.1 Configuracion de red . . . . . . . . . . . . . . . . . . . . . 21
1.5.2.2 Configuracion de dispositivos . . . . . . . . . . . . . . . . 22
1.5.3 Profibus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
1.5.4 Devicenet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
1.5.5 Resumen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
1.6 Ethercat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
1.6.1 Ventajas y desventajas . . . . . . . . . . . . . . . . . . . . . . . . . 28
1.7 Wireless HART . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
1.7.1 Tecnologıas inalambricas . . . . . . . . . . . . . . . . . . . . . . . . 29
viii
Contenidos ix
1.8 Arquitectura del sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
1.9 Definicion del proyecto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
1.9.1 Obejtivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
1.9.2 Alcance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
1.9.3 Trabajo futuro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
2 Capa fısica 32
2.1 Requerimientos de EtherCAT . . . . . . . . . . . . . . . . . . . . . . . . . 32
2.1.0.1 Bloques de una implementacion . . . . . . . . . . . . . . 33
2.2 Seleccion de alternativas . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
2.2.1 ESC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
2.2.2 ESC en FPGA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
2.2.3 Procesadores con funcionalidades de red . . . . . . . . . . . . . . . 35
2.2.4 Tarjetas comerciales . . . . . . . . . . . . . . . . . . . . . . . . . . 36
2.3 Diagrama de bloques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
2.3.1 Alimentacion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
2.3.2 Interfaz fısica de ethernet . . . . . . . . . . . . . . . . . . . . . . . 41
2.3.3 Secuencia de inicio . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
2.3.4 Memorıas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
2.3.5 Otros perifericos . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
2.4 Consideraciones de ruteo . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
2.4.1 Crosstalk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
2.5 Fabricacion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
3 Stack de comunicaciones 49
3.1 Implementacion de nodos Ethercat . . . . . . . . . . . . . . . . . . . . . . 49
3.2 Implementacion de un Stack . . . . . . . . . . . . . . . . . . . . . . . . . . 51
3.2.1 Seleccion de la plataforma Software . . . . . . . . . . . . . . . . . 51
3.2.2 Capa de enlace de datos . . . . . . . . . . . . . . . . . . . . . . . . 53
3.2.2.1 Estructura del paquete . . . . . . . . . . . . . . . . . . . 54
3.2.2.2 Metodos de acceso a los esclavos utilizando datagramas . 58
3.2.2.3 Servicios de la capa de enlace de datos . . . . . . . . . . 60
3.2.2.4 Reloj distribuido . . . . . . . . . . . . . . . . . . . . . . . 60
3.2.2.5 Estructura de la capa de enlace de datos . . . . . . . . . 60
3.2.2.6 Implementacion de la capa de enlace de datos . . . . . . 61
3.2.2.7 EtherCAT sobre UDP/IP . . . . . . . . . . . . . . . . . . 63
3.2.3 Capa de aplicacion . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
3.2.3.1 Maquina de estados de EtherCAT (ESM) . . . . . . . . . 64
3.2.3.2 Implementacion de la capa de aplicacion . . . . . . . . . 65
3.3 Descripcion de dispositivos EtherCAT . . . . . . . . . . . . . . . . . . . . 67
3.4 Resumen del stack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
4 Uso de FBDK (Function Block Development Kit) 69
4.1 Aspectos basicos de la herramienta FBDK . . . . . . . . . . . . . . . . . . 69
4.2 Manejo basico de ST (Structered Text) . . . . . . . . . . . . . . . . . . . . 70
4.3 Integracion de FBDK con la red EtherCAT . . . . . . . . . . . . . . . . . 70
4.3.1 Traduccion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
Contenidos x
5 Resultados y conclusiones 73
5.1 Pruebas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
5.2 Resumen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
5.3 Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
5.4 Trabajo futuro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
Lista de Figuras
1.1 Fragmento de un programa escrito en IL. Tomado de [5] con fines academicos 1
1.2 Fragmento de un programa escrito en ST. Tomado de [5] con fines academicos 2
1.3 Fragmento de un programa descrito utilizando bloques funcionales logicos.Tomado de [5] con fines academicos . . . . . . . . . . . . . . . . . . . . . . 2
1.4 Fragmento de un programa descrito utilizando diagramas de escalera.Tomado de [5] con fines academicos . . . . . . . . . . . . . . . . . . . . . . 2
1.5 Fragmento de un programa descrito utilizando SFC. Imagen de uso libredescargada de Wikimedia . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.6 Cambios en las condiciones de produccion de las empresas manufactur-eras. Adaptado de [6] con fines academicos . . . . . . . . . . . . . . . . . 4
1.7 Factores de manufactura y produccion que mas afectan los indicadoresfinancieros de una companıa. Tomado de [6] con fines academicos . . . . . 5
1.8 Comportamiento esperado de la tasa de fallas del software a lo largo desu ciclo de vida. Tomada de [7] con fines academicos . . . . . . . . . . . . 6
1.9 Representacion de un bloque de funcion segun el estandar IEC 61499.Captura de pantalla tomada con fines academicos del programa FBDKde Holobloc, Inc . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.10 Representacion interna de un bloque de funcion utilizando una maquinade estados. Captura de pantalla tomada con fines academicos del pro-grama FBDK de Holobloc, Inc . . . . . . . . . . . . . . . . . . . . . . . . 8
1.11 Interfaz de usuario basada en los lineamientos del consorcio ASM. Tomadade [8] con fines academicos . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
1.12 Organizacion por niveles de los equipos de un sistema de control segun elestandar ANSI/ISA-88.00.01-2010. Adaptada de [9] con fines academicos . 11
1.13 Nomenclatura utilizada para los componentes de un lazo de control. Basadaen [10] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
1.14 Implementacion de un sistema sin buses de campo (izquierda) y con busesde campo (derecha) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
1.15 Niveles de un sistema de control distribuido (DCS) de una solucion ofre-cida por la empresa moxa. Tomada de [11] con fines academicos . . . . . . 19
1.16 MAU de FF. Tomada de [12] con fines academicos . . . . . . . . . . . . . 20
1.17 Bloques de funcion para configurar y utilizar un dispositivo FF de medicion.Tomada de [3] con fines academicos . . . . . . . . . . . . . . . . . . . . . . 22
1.18 Lazo de control cerrado implementado en los dispositivos de campo deFF. Tomada de [13] con fines academicos . . . . . . . . . . . . . . . . . . 23
1.19 Frame de un paquete estandar de CAN. Tomada de [14] con fines academicos 25
1.20 Frame de un paquete estandar de EthernetII. Tomada de wikimedia confines academicos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
xi
Lista de Figuras xii
1.21 Topologıa de lınea de una implementacion con EtherCAT. Tomada de [15]con fines academicos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
2.1 Transmision de una senal utilizando pulsos cuadrados. Tomado de [16]con fines academicos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
2.2 Transmision de una senal utilizando senales de Voltaje diferencial. Tomadode [16] con fines academicos . . . . . . . . . . . . . . . . . . . . . . . . . . 33
2.3 Interfaz de Ethernet que utiliza como PHY (Capa fısica) el circuito inte-grado TLK110 de Texas Instruments. Tomado de [17] con fines academicos 33
2.4 Diagrama de bloques de la tarjeta de desarrollo FB1111-0140 desarrolladapor la companıa Beckhoff. Tomado de [18] con fines academicos . . . . . . 35
2.5 Diagrama de bloques del circuito integrado ET1100 desarrollado por lacompanıa Beckhoff. Tomado de [19] con fines academicos . . . . . . . . . 35
2.6 Diagrama de bloques de la tarjeta de desarrollo FB1130 desarrollada porla companıa Beckhoff. Tomado de [20] con fines academicos . . . . . . . . 36
2.7 Tarjeta ICE V2 que soporta una topologıa de lınea de EtherCAT. Tomadodel sitio web de Texas Instruments con fines academicos . . . . . . . . . . 37
2.8 Diagrama de bloques de una tarjeta que funciona como nodo EtherCAT . 38
2.9 Diagrama de bloques del circuito integrado TPS65910A3. Tomado de [21]con fines academicos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
2.10 Alimentacion utilizando el circuito integrado TPS65910A3 . . . . . . . . . 40
2.11 Seleccion de pines del procesador AM3357 que se van a utilizar comointerfaz MII0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
2.12 Seleccion de pines del procesador AM3357 que se van a utilizar comointerfaz MII1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
2.13 Generacion de senales de reloj para los PHY Ethernet . . . . . . . . . . . 42
2.14 Conector ARJE-0032 que integra un conector RJ45 y un conector USBhembra tipo A. Tomado del catalogo de la empresa Abracon con finesacademicos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
2.15 Esquematico de un MAU Ethernet . . . . . . . . . . . . . . . . . . . . . . 43
2.16 Seleccion de pines del procesador AM3357 que se van a utilizar comointerfaz MDI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
2.17 Conexion de una memoria RAM al procesador; los perifericos en el proce-sador utilizan los nombres mostrados en la figura . . . . . . . . . . . . . . 44
2.18 Transformada de Fourier de una senal de 1MHz con tiempo de subida de20ns. Tomada de [22] con fines academicos . . . . . . . . . . . . . . . . . 45
2.19 Transformada de Fourier de una senal de 1MHz con tiempo de subida de1ns. Tomada de [22] con fines academico . . . . . . . . . . . . . . . . . . . 45
3.1 Diagrama de bloques de la tarjeta Intel Galileo. Tomada de [23] con finesacademicos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
3.2 Topologıa de lınea de una implementacion con EtherCAT. Tomada de [15]con fines academicos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
3.3 Topologıas utilizadas por EtherCAT. Tomada de [15] con fines academicos 53
3.4 Estructura de un paquete de EtherCAT. Tomada de [24] con fines academicos 54
3.5 Estructura de un datagrama de EtherCAT. Tomada de [25] con finesacademicos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
3.6 Organizacion de memoria y de un datagrama cuando se utiliza direc-cionamiento logico. Tomada de [25] con fines academicos . . . . . . . . . . 59
Lista de Figuras xiii
3.7 Modelo de funcionamiento de la capa de enlace de datos. Tomada de [25]con fines academicos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
3.8 Implementacion de la capa de enlace de datos. Tomada de [26] con finesacademicos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
3.9 Modelo de la capa de aplicacion integrado con el modelo de la capa deenlace de datos. Tomada de [27] con fines academicos . . . . . . . . . . . 64
3.10 Maquina de estados de la red EtherCAT. Tomada de [25] con fines academicos 65
3.11 Estructura funcional de un nodo maestro. Tomada de [27] con finesacademicos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
3.12 Estructura funcional de un nodo esclavo simple. Tomada de [27] con finesacademicos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
3.13 Estructura funcional de un nodo esclavo completo. Tomada de [27] confines academicos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
4.1 Ejemplo de ST, se puede observar que la sintaxis es sencilla y en ciertomod se parece a mucho a la sintaxis de Matlab. Tomada de [28] con finesacademicos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
4.2 Bloque de ejemplo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
4.3 Descripcion de un algoritmo en XML . . . . . . . . . . . . . . . . . . . . . 71
5.1 Ejemplo utilizado para probar el sistema. Tomado de [2] . . . . . . . . . . 73
5.2 Interfaz del ejemplo. Tomado de [2] . . . . . . . . . . . . . . . . . . . . . . 74
5.3 Interfaz del ejemplo. Tomado de [2] . . . . . . . . . . . . . . . . . . . . . . 74
Lista de Tablas
1.1 Descripcion de las capas que conforman el modelo OSI . . . . . . . . . . . 16
1.2 Velocidad permitida de transmision asociada a la longitud del bus ProfibusDP. Adaptada de [29] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
1.3 Carga util para el ejemplo de una red de control . . . . . . . . . . . . . . 27
1.4 Descripcion de las capas a implementar durante este trabajo . . . . . . . . 30
2.1 Distribucion de Voltajes de alimentacion generados por el circuito inte-grado TPS65910A3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
3.1 Comparacion de plataformas para implementar el stack de EtherCAT . . 52
3.2 Tipos de paquetes utilizados por EtherCAT a nivel de la capa de enlacede datos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
3.3 Descripcion de las maquinas de estado que implementan la capa de enlacede datos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
3.4 Descripcion de los estados de ESM . . . . . . . . . . . . . . . . . . . . . . 65
xiv
Abreviaciones
ADC Analog Digital Converter
ASM Abnormal Situation Management
BSP Board Support Package
CAN Controller Area Network
CI Circuito Integrado
CRC Ciclyc Redundancy Check
DCS Distribuited Control System
ECC EtherCAT Controller Chart
EFI Extensible Firmware Interface
ENI EtherCAT Network Information
ESC EtherCAT Slave Controller
ESI EtherCAT Slave Information
ETG EtherCAT Technology Group
FBD Functional Block Diagram
FBDK Function Block Development Kit
FF Foundation Fieldbus
GCC GNU Compiler Collection
GPIO General Purpose Input Output
HMI Human Machine Interface
IEC International Electrotechnical Commission
ISA Instrumentation System Automation society
IL Instructions List
LAN Local Area Network
LAS Linking Active Scheduler
LD Ladder Diagram
xv
Abreviaciones xvi
LVDS Low Voltage Differential Signaling
MAU Medium Access Unit
MTBF Mean Time Between Failures
ODVA Open Devicenet Vendor Association
OSI Open System Interconnection
PLC Programmable Logic Controller
PWM Pulse Width Modulation
RTC Real Time Counter
SIS Safety Instrumented System
SFC Sequential Function Chart
SO Sistema Operativo
SOC System On Chip
ST Structured Text
TI Texas Instruments
XML Extensible Markup Language
Dedicado a mi papa y a mi mama por todo su apoyo durante todosestos anos
xvii
Capıtulo 1
Introduccion
1.1 Panorama actual de los sistemas de control
Durante las ultimas decadas y, en la actualidad, en la programacion de sistemas de
control han predominado los lenguajes clasicos de control. Estos lenguajes son:
• Lista de instrucciones (Instructions List(IL)): Lenguaje caracterizado por
el uso de instrucciones que se ejecutan en el orden que aparecen en una lista.
Tiene una sintaxis similar a la de los lenguajes ensambladores (assembler). En la
Figura 1.1 se presenta un ejemplo de IL.
Figura 1.1: Fragmento de un programa escrito en IL. Tomado de [5] con finesacademicos
• Texto estructurado (Structured Text(ST)): A diferencia de IL permite tra-
bajar a un nivel mas alto, ya que permite crear lazos y utilizar funciones. Se
puede pensar en la siguiente analogıa: IL es a ST lo que assembler es para C. En
la Figura 1.2 se puede observar un fragmento de ST en el cual se debe resaltar que
las variables tienen tipos como bool.
• Functional Block Diagrams(FBD): Es un lenguaje grafico que utiliza bloques
con una logica interna que ejecuta ciertas funciones a partir de unas entradas
para obtener unas salidas. Las entradas y las salidas se pueden conectar a otros
1
Capıtulo 1. Introduccion 2
Figura 1.2: Fragmento de un programa escrito en ST. Tomado de [5] con finesacademicos
bloques o a algunos perifericos, ademas algunos bloques pueden representar dis-
positivos tales como transmisores, analizadores, poscionadores de valvulas. . . En
la Figura 1.3 se muestra un fragmento de una descripcion utilizando bloques fun-
cionales.
Figura 1.3: Fragmento de un programa descrito utilizando bloques funcionales logicos.Tomado de [5] con fines academicos
• Diagramas de escalera (Ladder Diagrams(LD)): Es un lenguaje basado en
la antigua logica de reles que poseıan los primeros circuitos de automatizacion. El
lenguaje, como se muestra en la Figura 1.4, esta basado en contactores y embobi-
nados.
Figura 1.4: Fragmento de un programa descrito utilizando diagramas de escalera.Tomado de [5] con fines academicos
• Cuadros de Funcion Secuenciales (Sequential Function Charters(SFC)):
Es un lenguaje basado en la filosofıa de las redes de Petri y de la logica secuencial
en cascada [30]. En la Figura Figura 1.5 se muestra una descripcion hecha en SFC.
Desde antes de la aparicion del estandar IEC61131-3 en el ano de 1998, los lenguajes del
clasicos han sido la base en la programacion de PLCs de la gran mayorıa de empresas de
Capıtulo 1. Introduccion 3
Figura 1.5: Fragmento de un programa descrito utilizando SFC. Imagen de uso libredescargada de Wikimedia
automatizacion [30]; el estandar IEC61131 tiene 5 partes que tratan otros temas asocia-
dos con los PLC, no solo los lenguajes utilziados para programarlos. Su simplicidad y la
amplia gama de opciones y enfoques de programacion ha facilitado la implementacion de
sistemas de automatizacion por parte de los ingenieros y del personal tecnico en general.
A diferencia de otros lenguajes como C, Java y C++, para utilizar los lenguajes del
estandar no se requiere conocer la sintaxis, el manejo de la memoria, ni la forma como
funcionan los compiladores y/o los interpretadores. Por su simplicidad, suelen ser bas-
tante eficientes computacionalmente haciendo que su uso sea adecuado para programar
sistemas instrumentados seguros (SIS); ver estandar IEC61511 e IEC61508.
Pese al gran desarrollo de los lenguajes clasicos, su potencial y utilidad parecen haber
llegado a su lımite [2]. La principal razon son los cambios productivos que han experi-
mentado las companıas en los ultimos anos. Como se observa en la Figura 1.6 el cambio
mas grande que han enfrentado las companıas es el incremento de nuevos productos. La
encuesta la realizo LNS research y consistıa en que los delegados de varias companıas
escogieran de una lista cuales habıan sido los cambios en la produccion que enfrentaron
sus companıas entre el 2012 y el 2013 [6].
Esto representa un panorama completamente diferente al panorama bajo el cual se
concibieron los lenguajes clasicos de control. En ese momento, despues de la segunda
guerra mundial, el enfoque era producir en masa un producto con una vida util larga
y producir ese producto durante mucho tiempo; en ese entonces se empezaba a utilizar
la logica de reles. Hoy dıa el enfoque es producir una gran variedad de productos con
un vida util mas reducida en comparacion con la de los productos antiguos. Ademas,
esos productos se van a manufacturar durante un periodo de tiempo menor. Es decir,
Capıtulo 1. Introduccion 4
0 10 20 30 40 50 60 70 80
Adquirir una nueva empresa o una facilidad
Crear o trasladar una facilidad
Involucrarse en un nuevo negocio subcontratando
Aumentar la cantidad de trabajo por out-sourcing
Reducir el tiempo de lanzamiento de nuevos productos
Incrementar la demanda de clientes
Introducir mas productos complejos
Incrementar la volatilidad de demanda de clientes
Incrementar la oferta de productos SKUS o variantes
35
39
41
42
45
54
64
66
71
Porcentaje
Figura 1.6: Cambios en las condiciones de produccion de las empresas manufactur-eras. Adaptado de [6] con fines academicos
las mejoras, las actualizaciones o incluso el reemplazo de un producto novedoso puede
ser lanzado en meses [2]. En resumen, hoy dıa se lanzan productos nuevos al mercado
en menos tiempo y las lıneas de produccion deben ser capaces de cambiar para permitir
manufacturar productos nuevos.
Sumado a esto, el 30% de los ejecutivos creen que el manejo de inventarios es uno de
los factores que mas afecta los indicadores financieros. En la Figura 1.7 se muestran las
metricas de produccion que los ejecutivos consideran que mas afectan los indicadores
financieros; la encuesta la realizo MES en conjunto con LNS research [6].
Se puede observar que el manejo de inventarios es uno de los factores que mas afectan los
indicadores financieros. Esto se debe a que siempre hay un costo asociado al transporte,
al almacenamiento de equipos y componentes, y en ocasiones a un sistema de gestion de
activos.
Teniendo en cuenta la importancia del manejo de inventarios, ha surgido una nueva
de idea de produccion en la cual se busca reemplazar el almacenamiento de una gran
cantidad de items por lıneas de produccion versatiles capaces de suplir la demanda de
cierto producto en poco tiempo [2]. Por ejemplo, un fabricante de motores tiene un
catalogo de 300 productos y usualmente cuenta con 10000 unidades de cada uno de sus
productos almacenados en inventario. Las cantidades de inventario se mantienen con el
objetivo de suplir la demanda de cada producto ya que para producir cada uno de estos
Capıtulo 1. Introduccion 5
0 5 10 15 20 25 30 35 40
Innovar
Cumplimiento
Mantenimiento
No sabe
Inventario
Responsabilidad
Calidad
Eficiencia
6
6
8
18
21
26
31
33
Porcentaje
Figura 1.7: Factores de manufactura y produccion que mas afectan los indicadoresfinancieros de una companıa. Tomado de [6] con fines academicos
se utiliza un procedimiento de fabricacion distinto; no necesariamente el procedimiento
es completamente distinto.
Lo anterior representa un costo de almacenamiento y de catalogacion mediante un sis-
tema de gestion de activos CMMS que afecta las utilidades de la companıa. Como
alternativa, ese mismo fabricante puede tener una lınea de produccion versatil que le
permita producir cualquier producto que se requiera con un pequeno tiempo de retraso.
Esa lınea podrıa estarıa constituida por celdas de produccion faciles de adaptar al pro-
ducto que se necesita fabricar para suplir un pedido. De esta forma, no serıa necesario
mantener un inventario tan grande y solo se producirıa sobre pedido sin sacrificar la
variedad de productos del catalogo.
El nuevo enfoque productivo y las preocupaciones de manejo de inventarios hace que sea
necesario tener sistemas reconfigurables y confiables en poco tiempo. Para lograr esto,
es necesario poder reutilizar las maquinas de produccion con facilidad y ademas poder
adaptarlas con facilidad a las nuevas cadenas productivas. La respuesta a esto es lo que
se conoce como celdas de produccion. Sin embargo, los mecanismos no son los unicos
que deben poder cambiar con facilidad, tambien el software debe poder cambairse y
reutilizarse con facilidad. Reciclar el Software no solo facilita la adaptacion de las celdas
de produccion para manufacturar nuevos productos, sino que tambien permite utilizar
Software que ya ha sido probado y depurado antes. Esto tiene un impacto importante
Capıtulo 1. Introduccion 6
en la confiabilidad si se considera que entre mas viejo es el Software, mas confiable es.
En la Figura 1.8 se muestra una representacion de la tasa de fallas del Software tomada
de [7].
Figura 1.8: Comportamiento esperado de la tasa de fallas del software a lo largo desu ciclo de vida. Tomada de [7] con fines academicos
El estandar IEC61499 es la respuesta a los nuevos desafıos de produccion. No solo porque
plantea un lenguaje que permite reutilizar bloques de Software sino porque tambien esta
pensado para aprovechar los avances tecnologicos de la ultima decada. El estandar, como
se vera en la siguiente seccion, aborda temas como control distribuido, procesamiento
en paralelo y bloques de propiedad intelectual (bloques IP).
1.2 El estandar IEC 61499
El lenguaje que define el estandar, esta basado en bloques de funcion que pueden operar
de manera independiente. Es decir, los bloques no se programan pensado en una eje-
cucion secuencial de sus algoritmos. De esta forma, es posible reutilizar los bloques los
cuales pueden describir desde movimientos simples compuestos por unos pocos hasta
secuencias de operacion compuestas por varios elementos finales de control; motores,
valvulas, actuadores, servomecanismos... Los bloques de funcion, como se muestra en
la Figura 1.9, se diferencian de los bloques de funcion clasicos en la forma como se rep-
resentan y en que no solo tienen varibales de entrada y salida sino que tambien tienen
eventos de entrada y salida [2].
Como ya se menciono, los bloques son paquetes de Software independientes que pueden
reconectarse entre sı para cumplir con los requerimientos de un sistema de control. Es
precisamente esa facilidad de reconfiguracion, sumado a la independencia de los bloques,
la que permite reutilizar paquetes y reprogramar con facilidad un sistema de control;
en la seccion anterior se explico porque puede ser necesario reprogramar un sistema de
Capıtulo 1. Introduccion 7
Figura 1.9: Representacion de un bloque de funcion segun el estandar IEC 61499.Captura de pantalla tomada con fines academicos del programa FBDK de Holobloc,
Inc
control. Adicionalmente, la independencia de los bloques permite distribuir el programa
principal a lo largo de los procesadores disponibles en los dispositivos de campo de los
sistemas de control distribuido. De esta forma se aprovecha el poder de procesamiento
paralelo de un DCS y los avances en las redes de comunicaciones.
1.2.1 Bloques de funcion
En la cabeza del bloque se pueden observar los eventos que entran y que salen del bloque,
mientras que en el cuerpo del bloque se encuentran las entradas y salidas del mismo.
Es importante mencionar que graficamente se deben relacionar las salidas de un bloque
con los eventos de salida como se muestra en la Figura 1.9; cuadrados sobre las senales
y los eventos que se unen con lıneas verticales. Con esta asociacion se indica que salidas
del bloque han sido actualizadas cuando el evento se activa y tambien
Internamente el bloque contiene una maquina de estados con algoritmos especıficos para
cada uno de los estados. La logica que define la transicion entre estados utiliza los
eventos, el valor de las variables externas e internas del bloque, y el estado actual para
determinar el paso de un estado a otro. Los algoritmos que contiene cada uno de los
estados se puede describir utilizando los lenguajes clasicos de control (lenguajes del
estandar IEC 61131-3) o utilizando lenguajes secuenciales como C. De esta forma el
estandar mantiene la simplicidad de los lenguajes clasicos y ademas abre la posibilidad
para utilizar otro tipo de lenguajes que el estandar IEC 61131-3 no contempla. En la
Figura 1.10 se presenta una representacion interna de un bloque con una maquina de
estados.
Los bloques de funcion no solo se utilizan para describir dispositivos, mecanismos y
secuencias de trabajo. Tambien sirven para describir elementos propios de la interfaz
de usuario (HMI por sus siglas en ingles). De esta forma el programador puede con-
templar la forma como el operador va a manejar el sistema cuando este se encuentra
Capıtulo 1. Introduccion 8
Figura 1.10: Representacion interna de un bloque de funcion utilizando una maquinade estados. Captura de pantalla tomada con fines academicos del programa FBDK de
Holobloc, Inc
operando normalmente, cuando se presentan modos de falla y cuando se realizan labores
de mantenimiento.
Para cerrar esta seccion, es necesario definir evento en el contexto del estandar IEC
61499. Este concepto es clave ya que el manejo de eventos es uno de los factores clave
que define el nuevo estandar en comparacion con el enfoque clasico. Lo anterior no
significa que los eventos no se utilicen en los lenguajes clasicos, pero si es necesario decir
que en el estandar IEC 614999 los eventos son esenciales para la comunicacion entre
bloques. Un evento, en el lenguaje del estandar, representa un cambio de estado de una
variable booleana. Es decir, el paso de una variable de 0 a 1 logico o un paso de 1 a 0
logico.
La principal diferencia entre los eventos de los lenguajes clasicos y los eventos del lenguaje
del nuevo estandar es el nivel del Software en el cual se manejan. El estandar IEC
61499 plantea el uso obligatorio de eventos al nivel de bloque el cual esta por encima
de la maquina de estados interna del bloque la cual, a su vez, esta por encima de la
programacion de los algoritmos del bloque.
1.2.2 Herramienta de desarrollo
Para el desarrollo de algoritmos siguiendo el nuevo estandar, se va a utilizar el programa
Function Block Development Kit (FBDK). Este programa fue desarrollado por Rockwell
Capıtulo 1. Introduccion 9
Automation y por Holobloc, y es gratuito si utiliza con fines academicos e investigativos.
El programa contiene un entorno de trabajo como el mostrado en la Figura y un .
Adicionalmente, se puede integrar con el IDE Eclipse para realizar tareas de depuracion
de codigo. Sumado a lo anterior, a continuacion se presentan algunas razones por las
que se escogio esta herramienta:
• Lleva mas de 5 anos de desarrollo y sus desarrolladores han resuelto una gran
cantidad importante de bugs; se tuvo en cuenta el comportamiento de la tasa de
fallas del Software mostrada en la Figura 1.8.
• Por estar escrito en Java puede portarse y ejecutarse en distintos sistemas opera-
tivos; el autor lo ha probado en Ubuntu 14.04 y en Windows 7.
• Exporta las descripciones en un formato XML el cual sera traducido utilizando un
Script de bash, que utiliza gawk y sed [31], para generar funciones en lenguajes
como C o Assembler que puedan ser interpretadas por los dispositivos del sistema
de control.
1.3 Requerimientos de los programas de control
Antes de explicar en detalle la composicion y el uso de los bloques de funcion, es impor-
tante mencionar que cualquier programa que se utilice en control debe cumplir con lo
siguientes requerimientos:
• Los equipos deben tener una operacion simple y segura: Ante todo los
equipos deben ser seguros y estar pensados para que sus modos fallas sean detecta-
dos a tiempo. Esto con el fin de evitar perjudicar la salud y la vida de las personas
o el medio ambiente; la empresa Rockwell Automation publico una cartilla que re-
sume varios de los factores que se deben considerar a la hora de disenar maquinas
seguras[32]. Adicionalmente, en los estandares IEC 61511 e IEC 61508 se trata
el tema de los SIS que son equipos encargados de garantizar que los sistemas de
forma segura.
Con respecto a la simpleza de la operacion, es necesario contar con interfaces de
operacion (HMI) efectivas. El consorcio ASM publico una guıa para desarrollar in-
terfaces de operador efectivas [33]. En la Figura 1.11 se muestra un ejemplo de una
interfaz de operador sencilla y efectiva que sirve para controlar un turbocompresor;
la interfaz cumple con los lineamientos establecidos en [33].
Capıtulo 1. Introduccion 10
Figura 1.11: Interfaz de usuario basada en los lineamientos del consorcio ASM.Tomada de [8] con fines academicos
• Tener claridad acerca de lo que se va a controlar y garantizar la del
sistema: Siempre, antes de desarrollar una estrategia de control y, evidentemente,
antes de programarla, se debe tener claridad sobre lo que se va a programar. Es
necesario conocer el sistema y asegurar un buen funcionamiento de sus equipos y
componentes. De hecho, una buena practica de control es asegurar que el sistema
funciona bien de forma manual antes de tratar de desarrollar un programa de
control automatico. Citando a Lieberman[34]:
“If it does work on manual, we can automate it”
• Minimizar los tiempos de comisionamiento: El comisionamiento hace a
la puesta en marcha de un sistema. Las tecnicas de comisionamiento no solo se
aplican cuando finaliza la construccion de una locacion, de un area o de una celula
de proceso. Tambien se aplica cuando por algun motivo se detuvo una parte de
la locacion, el cual puede ser una facilidad de produccion o una planta; se esta
utilizando la nomenclatura del estandar ISA 88 el cual presenta una jerarquıa
como la de la Figura 1.12 para agrupar los equipos de un sistema de control
y produccion. Es importante tener claro que ningun sistema puede operar de
forma continua indefinidamente ya que las partes mecanicas se desgastan, sufren
Capıtulo 1. Introduccion 11
de fatiga, se desalinean... Es por eso que en las plantas de proceso (locaciones en
la Figura 1.12) se programan paradas a distintos niveles para realizar labores de
mantenimiento. Ademas, de las paradas programadas, muchas veces es necesario
detener areas, celulas de produccion, unidades o modulos de equipos por fallos.
Figura 1.12: Organizacion por niveles de los equipos de un sistema de control segunel estandar ANSI/ISA-88.00.01-2010. Adaptada de [9] con fines academicos
Para minimizar los tiempos de comisionamiento, los sistemas de control deben
permitir la operacion manual de los elementos finales de control ademas de obtener
mediciones de forma individual a partir de los elementos secundarios de control;
se sigue la nomenclatura presentada en [10], en la Figura 1.13. De esta forma,
es posible poner a funcionar los equipos siguiendo una secuencia basada en el
comportamiento de los procesos.
• Reducir los tiempos de parada: Existen varios factores que componen el
tiempo de parada de una locacion o de alguna de sus estructuras subyacentes.
Por ejemplo, la confiabilidad del sistema vista cuantitativamente como el tiempo
promedio entre fallas (MTBF) es clave ya que entre menos fallas se produzcan
habra menos paradas no programadas. Adicionalmente, las interfaces de usuario y
los programas deben estar pensados para permitir hacer pruebas con el fin de en-
contrar las causas de las fallas cuando estas se presentan. Todo esto generalmente
Capıtulo 1. Introduccion 12
Figura 1.13: Nomenclatura utilizada para los componentes de un lazo de control.Basada en [10]
va acompanado de procedimientos y documentos de lecciones aprendidas que fa-
cilitan el diagnostico de los sistemas a distintos niveles. En resumen, el Software
debe ser confiable y tambien debe permitir realizar diagnosticos con facilidad.
• Desarrollar programas faciles de cambiar: Como se pudo ver en la seccion
1.2, actualmente hay una necesidad de reconfiguracion rapida de los sistemas de
control. Adicionalmente, el Software debe poderse mejorar a medida que se de-
tectan bugs, esto con el fin de disminuir la tasa de fallas como se muestra en la
Figura 1.8.
• Desarrollar soluciones realizables y estandarizadas: En cualquier proyecto
que implique trabajo en equipo para desarrollar Software es necesario que el codigo
o que los diagramas sean claros y faciles de leer y entender. Esto con el fin de mejo-
rar la comunicacion entre los programadores reduciendo los costos y el tiempo de
desarrollo. Para alcanzar este objetivo es necesario pensar en soluciones descritas
siguiendo algun estandar que establezca unas reglas para facilitar el entendimiento;
puede ser un estandar coorporativo.
Otro beneficio asociado al desarrollo estandarizado de Software es que se facilita
la labor de cualquier ingeniero o tecnico de control, de los operadores y de las
personas encargadas del mantenimiento; todas estas personas por los roles que
desempenan pueden requerir una interaccion con el Software.
Capıtulo 1. Introduccion 13
Los requerimientos anteriores fueron establecidos en [1] y representan necesidades co-
munes de cualquier maquina, proceso o sistema en general que se vaya a controlar. Mas
adelante se incluiran estos requerimientos en la definicion del proyecto y se explicara
como se van a cumplir.
1.4 Buses de campo
El inicio de la tercera revolucion industrial, que segun [35] empezo en el 2006, tiene como
uno de sus cimientos los sistemas de comunicaciones. Una de las posibles razones de
esto es que hoy dıa los sistemas de comunicaciones, en especial las redes, han alcanzado
un nivel de ubicuidad. Hoy dıa en una gran cantidad de dispositivos hay tarjetas y
adaptadores los cuales permiten la conexion de los mismos a distintos tipos de redes.
Los equipos utilizados en los sistemas de control no se quedan atras a la hora de seguir
esta tendencia. En la actualidad la gran mayorıa de equipos de medicion y control se
conectan entre sı formando redes de equipos. A las tecnologıas de red que se utilizan para
conectar dispositivos en un sistema de control y automatizacion (ver Figura 1.12 para
entender como estan estructurados) se les llama buses de campo.Antes de continuar, es
necesario contar brevemente la historia de como los dispositivos de control llegaron a
ese enfoque de conectividad.
En la decada de los 70, aparecieron las primeras implementaciones de sistemas de con-
trol que utilizaban redes de comunicaciones los cuales no fueron muy populares en un
principio. Sin embargo, en la decada de los 80 las implementaciones que utilizaban redes
de comunicaciones ganaron aceptacion y se utilizaban principalmente para comunicar
los PLC, los computadores del cuarto de control y las interfaces de usuario (HMI) re-
motas. Esto permitio descentralizar los equipos de control que antes se ubicaban en su
totalidad dentro de los cuartos de control. Ahora, esos dispositivos podıan distribuirse
en toda el sitio (ver Figura 1.12) y comunicarse utilizando una red; a estos sistemas se
les denomina sistemas de control distribuido (DCS). Pese a la aceptacion de las redes
locales en los sistemas de control durante esta decada, aun los instrumentos de medicion
y control se conectaban directamente a los PLC [3]. Tecnologıas de conexion punto a
punto analogas como 4-20 mA eran muy populares. Por ultimo, en la decada de los
90, se empezaron a utilizar de forma masiva los buses de campo que contemplan el uso
de redes a nivel de dispositivos, no solo a nivel de PLCs, computadores e interfaces de
usuario (nivel de host, ver seccion 1.5) [3].
Los buses de campo surgen como una respuesta a los siguientes requerimientos[3]:
Capıtulo 1. Introduccion 14
• Los dispositivos, antes de la aparicion de los buses de campo, no eran capaces
de transmitir una cantidad de informacion significativa. Por ejemplo, la salida de
los instrumentos de medicion, por lo general, era una senal analoga de corriente
o de Voltaje que entraba directamente a un PLC o a una tarjeta de medicion.
Con la integracion de los dispositivos de medicion y de control en una red de
comunicaciones, hoy en dıa es posible obtener informacion de diagnostico de los
equipos. Ademas es posible configurarlos remotamente por medio utilizando el
canal de comunicacion establecido por el bus de campo.
• El cableado y la complejidad dificultaban la implementacion y el mantenimiento
de sistemas complejos de control. Las plantas de proceso modernas pueden tener
cientos o miles de dispositivos conectados haciendo que el cableado se vuelve com-
plejo e indescifrable. Por esta razon surgieron estructuras basadas en buses de
campo (fieldbus) ya que reducen el cableado y optimizan los recursos de la red.
En la Figura 1.14 se muestra un gabinete de control que implementa una solucion
utilizando buses de campo y un gabinete que implementa la misma solucion sin
utilizar buses de campo.
Figura 1.14: Implementacion de un sistema sin buses de campo (izquierda) y conbuses de campo (derecha)
Se puede observar con claridad que el sistema que utiliza buses de campo posee
un cableado mucho mas sencillo y estructurado. Esto reduce los costos de imple-
mentacion, el tiempo de implementacion, el tiempo de mantenimiento y la posi-
bilidad de fallas humanas o fallas sistematicas.
• La transmision de mediciones analogas no es confiable ya que las senales pueden
presentar algun tipo de interferencia. Las senales digitales tienen un nivel mayor
de inmunidad al ruido. En el estandar IEEE 512 se clasifican las senales segun su
nivel de susceptibilidad al ruido [36].
• Los dispositivos se comunican utilizando estandares de comunicacion o tecnologıas
de buses de campo abiertas; una tecnologıa abierta es aquella que puede ser uti-
lizada por cualquier fabricante, esto no significa que los archivos de desarrollo de la
Capıtulo 1. Introduccion 15
misma sean gratuitos. De esta forma, en un sistema de control se pueden utilizar
equipos de cualquier fabricante que cumpla con los estandares.El estandar IEC
61518 define las condiciones para que una tecnologıa sea considerada un bus de
campo.
1.4.1 Dispositivos inteligentes
La capacidad de comunicacion de los dispositivos concuerda y facilita la implementacion
de dispositivos inteligentes. Cuando se habla de instrumentos inteligentes se hace a
cualquier equipo de medicion o de control que cumple con las siguientes condiciones[10]:
• Posee elementos primarios y elementos de medicion (ver Figura 1.13) que incluyen
los ultimos avances tecnologicos.
• Permite mostrar e integrar varias mediciones.
• Permite compensar efectos no deseados producidos por la aplicacion y con la .
• Envıan diagnosticos y alertas relacionados con su funcionamiento.
• Se pueden configurar y calibrar remotamente.
• Permiten al usuario seleccionar que informacion desea ver.
Es necesario mencionar que no solo los dispositivos que utilizan buses de campo se
clasifican como dispositivos inteligentes. Como alternativa a los buses de campo se
encuentran protocolos como Hart que tambien permiten realizar una comunicacion con
los equipos de un sistema de control.
1.4.2 Los buses de campo y el modelo OSI
En el ano de 1980 la IEC en conjunto con la ISO, emitio el estandar ISO/IEC 7498-
1 el cual define el modelo OSI (Open System Interconnection). El objetivo de este
modelo constituido por 7 capas es establecer una estructura que puede ser utilizada por
cualquier red de comunicaciones. El ejemplo mas famoso son las redes de computadores
que implementan las 7 capas y que poseen protocolos para la comunicacion entre capas.
En la Tabla 1.1 se presenta una descripcion general de cada una de las capas.
Los buses de campo solo implementan 3 capas del modelo a nivel de campo (ver seccion
1.5). Las capas 3, 4, 5 y 6 se omiten porque no se requieren muchos de sus servicios,
como la comunicacion entre redes utilizando direcciones, y porque los pocos servicios
Capıtulo 1. Introduccion 16
Numero Nombre de la capa Descripcion
1 Capa fısica Hace referencia al Hardware.
2 Capa de enlace de datos En esta capa se establece laconexion entre dispositivos.
3 Capa de red En esta capa se establecen las reglasy los medios para comunicar variasredes entre sı.
4 Capa de transporte En esta capa se establecen reglas yprotocolos para el transporte de in-formacion. Aquı se divide la infor-macion en paquetes, si se requiere, yse puede o no establecer conexionesque utilizan mensajes de Acknowl-edges para lograr una comunicaionconfiable.
5 Capa de sesion En esta capa se establecen las re-glas y los medios para repartir lainformacion que llega o que sale devarias aplicaciones que comparten elmismo stack de comunicacion.
6 Capa de presentacion En esta capa se prepara la infor-macion que se va a pasar a las apli-caciones. Por ejemplo, a este nivelse puede encriptar o desencripatarinformacion.
7 Capa de aplicacion Es la capa que sirve de interfaz entrela red y las aplicaciones.
Tabla 1.1: Descripcion de las capas que conforman el modelo OSI
que se necesitan pueden ser prestados en otras capas. En ocasiones implementan una
capa adicional que esta por encima de la capa de aplicacion conocida como la capa de
usuario. Esta capa presta servicios que mejoran la interaccion de los usuarios con las
redes de dispositivos.
Como se vera en la siguiente seccion, a nivel de host es comun encontrar implementa-
ciones de las 7 capas en los buses de campo.
1.5 Tecnologıas de buses de campo
Actualmente, en el mercado, es posible encontrar dispositivos de medicion, control y
movimiento que utilizan distintas tecnologıas de buses de campo. La principal inquietud
de cualquier persona que empieza una carrera en el mundo del control distribuido es:
¿cual tecnologıa puede ser la mas adecuada? La respuesta a esta pregunta, segun [3],
Capıtulo 1. Introduccion 17
es que hay tecnologıas disenadas para aplicaciones especıficas. Segun su aplicacion, es
posible agrupar las distintas tecnologıas en 3 grupos:
1. Buses para la automatizacion de fabricas con pocos dispositivos.
2. Buses para la automatizacion de fabricas con una gran cantidad de dispositivos.
3. Buses para la automatizacion de procesos. Entendiendo que un proceso es cualquier
conjunto de actividades quımicas, fısicas o biologicas que se desarrollan para trans-
formar, transportar, almacenar o preparar materia o energıa.
Las tecnologıas de buses para la automatizacion de fabricas generalmente se utilizan para
transmitir entradas y salidas digitales, principalmente. Los programas generalmente
utilizan logica discreta y se desarrollan en lenguajes como Ladder Diagram (LD). Las
salidas digitales sirven para controlar lıneas de produccion que, por ejemplo, contienen
servomecanismos, actuadores, motores, sensores de posicion, sensores de . . . Si las lıneas
de produccion son pequenas, poseen pocos dispositivos y solo es necesario transmitir
unos cuantos bits de informacion entre dispositivos, se utilizan buses de campo de la
categorıa 1. Dentro de esta categorıa se encuentran, por ejemplo, tecnologıas como AS-I
(Actuator Sensor Interface). En resumen, existen buses de campo para sistemas que
tienen una carga muy baja de informacion.
En fabricas que poseen cientos o miles de dispositivos se utilizan tecnologıas de comuni-
cacion que permitıan transmitir grandes cantidades de informacion en poco tiempo de
manera confiable; generalmente se requieren velocidades del orden de los Megabits por
segundo. En este tipo de fabrica, las labores de produccion generalmente se desarrollan
de forma secuencial y coordinada que si se desincronizan pueden causar fallos en la pro-
duccion o, en ocasiones, afectar la seguridad y el medio ambiente. Es por eso que estos
sistemas se consideran sistemas de tiempo real fuertes (hard real-time [37]). Algunos
ejemplos de tecnologıas utilizadas en este tipo de fabricas son:
• DeviceNet.
• ControlNet.
• Profibus DP y FMS.
• EtherCAT.
Por ultimo, las plantas de proceso tienen requerimientos distintos a las fabricas. En las
plantas de proceso generalmente se transmiten los valores de las variables de proceso y
Capıtulo 1. Introduccion 18
valores escalados para manejar dispositivos de control; en la Figura 1.13 se muestra un
lazo de control que adquiere una medicion y determina una accion. Es decir, las plantas
de proceso se caracterizan por utilizar en su mayorıa algoritmos de control continuo,
como el PID, que utilizan mediciones y dispositivos de actuacion analogos. Esto no
significa que en las plantas de proceso no haya dispositivos que utilicen logica discreta,
aunque no son tan utilizados como los dispositivos de medicion analoga. Adicionalmente,
en algunas plantas, como las facilidades de produccion de hidrocarburos, los buses de
campo utilizados deben operar en areas clasificadas. Es decir, deben cumplir ciertas
restricciones y tener la etiqueta Ex que garantiza, entre otras cosas, que una falla electrica
del equipo no producira un incendio [38].
Para el control de procesos se utilizan 3 tecnologıas principalmente:
• Hart.
• Foundation Fieldbus.
• Profibus PA.
Pese a que hay distintas tecnologıas de buses de campo disenadas para necesidades
especıficas, es posible encontrar locaciones donde se utilizan varias tecnologıas con
propositos distintos mezcladas. A veces se utilizan tecnologıas que fueron disenadas
y optimizadas para cierto proposito en aplicaciones donde depronto no son la solucion
mas optima. Por ejemplo, en una fabrica puede haber transmisores que envıan medi-
ciones analogas utilizando Devicenet.
1.5.1 Niveles de los buses de campo
Antes de explicar en detalle algunas tecnologıas de buses de campo, es necesario men-
cionar que las redes de los controles distribuidos DCS generalmente tienen 2 niveles.
Un nivel en el cual se conectan varios dispositivos a un PLC, una RTU, un linking de-
vice (puente de comunicacion entre 2 redes) o simplemente un nodo que funciona como
maestro. A este nivel las redes cumplen la funcion de integrar y coordinar inteligentes.
Tambien, muchos buses de campo proporcionan alimentacion a los utilizando el bus de
campo. Por ejemplo, Foundation Fieldbus utiliza el mismo par de cables de comuni-
cacion para alimentar los dispositivos.
El segundo nivel, es el nivel de Host al cual se conectan los nodos maestros, algunos
servidores (Ej,un servidor OPC), computadores donde se tiene la interfaz de operacion,
HMIs remotos, impresoras. . . En ocasiones se utilizan routers para conectar las redes
Capıtulo 1. Introduccion 19
Host a sistemas empresariales de gestion de activos y de produccion (MEM), por ejemplo.
En la Figura 1.15 se muestran los 2 niveles de un DCS. El nivel de campo corresponde
al bus de campo (Fieldbus, lıneas negras).
Figura 1.15: Niveles de un sistema de control distribuido (DCS) de una solucionofrecida por la empresa moxa. Tomada de [11] con fines academicos
Se puede observar como hay dispositivos especiales que sirven para conectar los 2 niveles.
A estos dispositivos se les conoce como dispositivos de conexion (linking devices, en
ingles). Adicionalmente, se puede ver con claridad que la red de area local (LAN) en el
nivel de Host tiene redundancia; hay un cableado doble. Esta practica suele mejorar la
confiabilidad del sistema siempre y cuando se haga un mantenimiento adecuado. En [3]
se muestran las distintas formas de redundancia en una red Ethernet.
A continuacion se muestran algunos detalles de algunas tecnologıas de buses de campo.
Esta informacion servira como referencia para seleccionar la tecnologıa adecuada para
este trabajo.
1.5.2 Foundation Fieldbus
Es una tecnologıa que a nivel de campo generalmente utiliza 2 cables y esta basada en
transreceptores que utilizan codificacion Manchester; a esta tecnologıa se le denomina
Fieldbus H1. Cuando se implementa utilizando 2 conductores, la comunicacion y la
alimentacion de los dispositivos que estan conectados al bus se transmiten por el mismo
par de conductores. Esto hace que sea necesario utilizar fuentes de suministro de po-
tencia con un filtro el cual evita conflictos entre la alimentacion y la comunicacion. Es
Capıtulo 1. Introduccion 20
comun utilizar circuitos gyratores para implementar ese filtro [39]. En la Figura 1.16
se muestra una implementacion de un MAU (Medium Acces Unit)de FF basada en el
circuito integrado (CI) Amis 492x0 de on-semiconductors. Esta implementacion permite
alimentar el nodo FF H1 y tambien permite la comunicacion por el bus.
Figura 1.16: MAU de FF. Tomada de [12] con fines academicos
Con esta implementacion, FF H1 logra una velocidad maxima de transmision a nivel de
campo de 31.25 kbps. Si se compara esta velocidad con la de otros buses de campo, se
puede concluir que este bus de campo tiene una velocidad mucho menor que Profibus
DP, por ejemplo. Sin embargo, esta tecnologıa tiene 3 ventajas principales:
• Reduce al mınimo el cableado ya que aprovecha los cables de alimentacion para
transmitir datos.
• Puede utilizarse en areas clasificadas; siempre se debe verificar que el equipo
cumpla con la reglamentacion correspondiente a cada area.
• Permite implementar algoritmos de control de forma distribuida por medio de
bloques de funcion estandar.
Capıtulo 1. Introduccion 21
Comparando FF con otas tecnologıas de buses de campo para control de procesos, los
dispositivos que utilizan FF, a diferencia de Hart y Profibus PA, pueden configurarse e
integrarse mediante el uso de bloques de funcion. Esto permite desarrollar con facilidad
una estrategia de control distribuido ya que algunos lazos de control se procesan y
ejecutan en los dispositivos de campo. Ademas, a diferencia de los dispositivos Hart,
no utiliza ningun tipo de senal analoga como las senales de 4-20mA; todo se comunica
digitalmente. Esto mejora la inmunidad del bus frente a las distintas fuentes de ruido y
permite reducir el error de cuantizacion tıpico de las senales 4-20mA; error asociado a
las conversiones analogo-digital y digital-analogo.
Es importante tener presente que Foundation Fieldbus H1, al igual que Profibus PA, es
una tecnologıa basada en el estandar IEC 61158-2. Ademas, a nivel de la capa fısica
ambos utilizan la misma tecnologıa; el MAU es el mismo de la Figura 1.16. Sin embargo,
en capas superiores utilizan distintos protocolos.
Como ya se menciono, en un DCS hay un nivel de campo y un nivel de Host. En el nivel
de campo se encuentran varios lazos de Fieldbus H1 que se conectan mediante puertas
(gateways) al nivel de Host. En el nivel de Host se utiliza Ethernet (Fieldbus HSE) en
las capas inferiores de la red segun el modelo OSI. El Ethernet que se utiliza en el nivel
de Host generalmente tiene redundancia [3].
Para cerrar esta seccion, a continuacion se presentan algunos aspectos relacionados con
la configuracion de una bus FF. La informacion se va a tratar desde 3 enfoques: Config-
uracion de red, configuracion de dispositivos y configuracion de la estrategia de control.
Cuando se habla de configuracion se debe tener presente que esta se puede hacer cuando
la red se ha puesto en marcha o antes de la red se comisione. Generalmente la configu-
racion de dispositivos se hace cuando la red no esta funcionando. Sin embargo, cuando
la red esta funcionando generalmente se hacen pequenos ajustes.
1.5.2.1 Configuracion de red
Existen 3 tipos de nodos en una red Fieldbus H1: nodos basicos, nodos de conexion
maestros y puentes. Algunos dispositivos pueden cumplir mas de una funcion por lo que
es importante configurarlo desde el BOS. Los nodos de conexion maestros se caracterizan
porque sirven para escoger el nodo LAS (Linking Active Scheduler). Cuando una red
inicia, se escoge un nodo LAS que se encargara de:
• Detectar nuevos dispositivos y asignarles direcciones.
• Sincronizar los tiempos de transmision.
Capıtulo 1. Introduccion 22
• Controlar la transferencia de datos.
En una red tıpica, el LAS primario es el dispositivo que sirve como interfaz entre los
2 niveles: dispositivo de conexion o acoplador, segun sea el caso. Sin embargo, si este
dispositivo falla, la red puede seguir operando ya que automaticamente otro nodo de
conexion maestro asume el papel de LAS.
El puente necesariamente debe ser el dispositivo de conexion ya que un puente debe
poder conectarse con otra red Fieldbus H1. Una vez definidos los roles, la red tiene la
capacidad de resolver los demas parametros de comunicacion como las direcciones.
1.5.2.2 Configuracion de dispositivos
Los dispositivos Fieldbus son descritos por bloques de funcion similares a los bloques
de funcion de una estrategia de control. Estos bloques contienen informacion rela-
cionada con el uso de los dispositivos descritos. Los bloques de funcion a su vez poseen
parametros los cuales tienen valores y estados. Un bloque se puede definir como una
entidad contenedora de informacion relevante de un dispositivo o de una estrategia de
control; esta definicion aplica para el estandar IEC 61131.
Cualquier dispositivo descrito por bloques funcionales debe tener un bloque de recurso
(Resource). Adicionalmente si se trata de un dispositivo de medicion o de un elemento
final de control (ver), debe tener un bloque transductor (Transducer). Por tratarse
de bloques de configuracion, estos bloques no se comunican con otros bloques o se
interconectan en la implementacion de una estrategia de control. A la hora de nombrar
los bloques, se recomienda utilizar el mismo TAG del dispositivo con una terminacion
que indique el tipo de bloque. En la Figura 1.17 se muestran los bloques que describen
un dispositivo.
Figura 1.17: Bloques de funcion para configurar y utilizar un dispositivo FF demedicion. Tomada de [3] con fines academicos
Como ya se menciono, los bloques de funcion se caracterizan por tener parametros. Los
parametros pueden ser estaticos, dinamicos o no volatiles. Un parametro estatico es
Capıtulo 1. Introduccion 23
aquel que no puede ser cambiado por el usuario; por ejemplo, el numero de revisiones
y ajustes que se le han hecho a un transmisor. Los parametros dinamicos son aquellos
que cambian constantemente; por ejemplo el valor de una medicion. Por ultimo, los
parametros no volatiles son aquellos que se graban en una memoria no volatil. De
esta forma, cuando hay una perdida de alimentacion del equipo, estos parametros no se
borran; por ejemplo, la configuracion de un rango de medicion.
A nivel de campo, se pueden anadir bloques de funcion que implementan algoritmos
de control en lazo cerrado, como PID, los cuales se ejecutan a nivel de campo; en la
Figura 1.18 se presenta un bloque de funcion de PID.
Figura 1.18: Lazo de control cerrado implementado en los dispositivos de campo deFF. Tomada de [13] con fines academicos
En resumen, los dispositivos de campo son vistos como bloques de funcion a la hora de
programar una estrategia de control. Configurando esos bloques, se configuran dichos
dispositivos.
1.5.3 Profibus
Es la tecnologıa de bus de campo mas utilizado. En su utlima version permite velocidades
de transmision de hasta 12 Mbps. Profibus (PROcess FIeld BUS) ha sido desarrollado
por varias empresas alemanas, principalmente, desde 1996 [29]. Esta reglamentado por
el estandar europeo EN50170. En Profibus se utilizan dos tipos de dispositivos: maestros
y esclavos. Los maestros son los encargados de controlar y manejar la red. Los esclavos
generalmente son sensores, valvulas y actuadores.
Existen 3 tipos de Profibus:
• DP (Perifericos distribuidos): Se caracteriza por permitir varios maestros. Cada
esclavo solo responde a un maestro. Sin embargo, cuando ese esclavo responde,
Capıtulo 1. Introduccion 24
otro maestro u otro esclavo puede leer la respuesta de ese esclavo. A nivel de la
capa fısica utiliza RS485 el cual permite implementar el bus a nivel de campo.
• FMS (Fieldbus Message specification): Es un tipo de comunicacion punto a punto,
como la que hace el estandar EIA232 (Puerto serial RS232). Se utiliza con frecuen-
cia para realizar comunicaciones entre maestros. Comunmente, se utiliza junto a
DP (Profibus DP/FMS).
• PA (Process Automation): Utiliza el mismo principio de operacion que DP. Sin
embargo, PA utiliza niveles de Voltaje y corriente distintos a los utilizados por
DP; tiene una capa fısica diferente, igual a la de FF H1. Mediante Profibus PA, se
comunican y alimentan sensores y actuadores siguiendo el estandar IEC 1158-2.
Una implementacion real de Profibus conecta varios segmentos de Profibus PA o de
Profibus DP a nivel de campo, los cuales se conectan mediante dispositivos de conexion
al nivel de Host. En el nivel de Host se utiliza Ethernet (profiNET) en las capas inferiores
de la red segun el modelo OSI. Es comun, tanto en Profibus como en FF, encontrar im-
plementaciones utilizando Modbus/TCP a nivel de Host. En estos casos, Modbus/TCP
reemplaza a profiNet y FF HSE.
La velocidad maxima de transmision de Profibus DP no es la misma para todos los
segmentos de la red, sino que esta varıa con la longitud del cable. En la tabla 1.2 se
presentan los valores mas utilizados de transmision para distintas longitudes.
Longitud (m) Velocidad permitida (kbps)
1200 9.6
1200 19.2
1200 93.75
600 187.5
200 500
200 1500
100 12000
Tabla 1.2: Velocidad permitida de transmision asociada a la longitud del bus ProfibusDP. Adaptada de [29]
Al igual que Fieldbus, Profibus DP, permite implementar lazos de control en los de
campo. Sin embargo, Profibus PA no permite realizar implementaciones de lazos de
control en campo.
Capıtulo 1. Introduccion 25
1.5.4 Devicenet
Devicenet es una tecnologıa libre ya que no pertenece a ningun fabricante en particular.
Sin embargo, existe una organizacion sin animo de de lucro que se encarga de emitir las
reglas que debe seguir cualquier dispositivo que utiliza Devicenet. Esa organizacion es la
ODVA (Open Devicenet Vendor Assosiation, inc) y esta conformada por representantes
de distintas companıas que utilizan Devicenet.
Al igual que los buses de campo que se han presentado, Devicenet solo implementa
las capas 1, 2 y 7 de la arquitectura OSI. En la capa 1, capa fısica, Devicenet utiliza
un bus con Controladores de red de area (CAN). Los buses CAN crean un canal de
comunicacion utilizando dos cables: uno azul (CANL) y uno blanco (CANH); colores
estandar definidos por la ODVA. El primero maneja Voltajes entre 2.5V y 1.5V. El
segundo maneja Voltajes entre 2.5V y 4V. Cuando alguno de los 2 cables tiene un
Voltaje de 2.5V, se dice que ese cable es recesivo. Cuando CANL esta en 1.5V, se dice
que ese conductor es dominante. Cuando CANH esta en 4 V se dice que ese conductor
es dominante. Si no hay un maestro en la red, los dos conductores deben ser recesivos;
el Voltaje en los dos conductores, medido desde V-, debe ser cercano a 2.5V. Si se asigna
un maestro y la red esta escaneando los nodos, CANH toma un valor cercano a los
3V y CANL un valor de 2.4V, aproximadamente. En la operacion regular de una red,
cuando los 2 conductores estan en estado recesivo, se esta transmitiendo un 1 logico. En
contraste, si los dos conductores estan en estado dominante, se esta transmitiendo un 0
logico [29].
A nivel de la capa de enlace de datos, se utilizan paquetes estandar, paquetes extendi-
dos y paquetes especiales de los buses CAN. Es importante resaltar que cada paquete
estandar de CAN solo puede transportar 8 bits y que la velocidad maxima de trans-
mision depende de la distancia que tenga el bus CAN. Para distancias menores a 10 m
la velocidad maxima de transmision es de 1 Mbps. En la Figura Figura 1.19 se muestra
el marco de un paquete estandar de un bus CAN.
Figura 1.19: Frame de un paquete estandar de CAN. Tomada de [14] con finesacademicos
Capıtulo 1. Introduccion 26
Se debe resaltar que el paquete CAN estandar tiene una longitud de 108 bits de los cuales
64 bits son informacion (payload) y 44 bits son el encabezado (header); es decir, en un
paquete estandar aproximadamente el 60% es informacion de la capa de aplicacion. Se
puede observar que el encabezado contiene informacion importante para garantizar una
buena comunicacion entre dispositivos. Por ejemplo, contiene la longitud del paquete,
la direccion de origen (¿quien envio el mensaje?), la direccion de destino, algunos bytes
para aplicar el algoritmo de deteccion de errores CRC (Chequeo de redundancia cılclica)
y un bit de acknowledge para indicar que el paquete llego bien al nodo destino.
A nivel de la capa de aplicacion, se definen diccionarios basados en la aplicacion y
protocolos de configuracion de la red. Para obtener detalles de esta implementacion es
necesario tener acceso a los documentos de la ODVA, los cuales no son gratuitos, o se
debe adquirir un stack de Devicenet. Por razones presupuestales, para el desarrollo de
este trabajo no se adquirieron dichos documentos ni el stack.
1.5.5 Resumen
En esta seccion se clasificaron las tecnologıas de buses de campo y se describieron algunas
de las tecnologıas mas utilizadas; hay otras tecnologıas que no se describieron. Esta
informacion sirve de base para poder evaluar las ventajas y desventajas de las distintas
tecnologıas de buses de campo. En este trabajo no se va a utilizar ninguna de estas
tecnologıas ya que para poder desarrollarlas es necesario adquirir estandares y notas de
aplicacion que estan fuera del presupuesto del proyecto. Adicionalmente, como se vera
en la siguiente seccion, existen otras tecnologıas que pueden ser mas favorables para
aprovechar el enfoque del estandar IEC 61499.
1.6 Ethercat
Es un bus de campo que utiliza Ethernet (IEEE802.3) a nivel de campo para la im-
plementacion de las 2 primeras capas del modelo OSI; a nivel de la capa 2 tiene otros
servicios. Historicamente, las tecnologıas de Ethernet siempre habıan tenido la desven-
taja de desaprovechar su capacidad de informacion ya que por defecto, Ethernet tiene
un encabezado de 14 bytes (Capas 1 y 2 con soporte de VLAN), 4 bytes de chequeo de
redundancia cıclica (CRC) y un espacio entre mensajes de 8 bytes. Esto sin contar los
encabezados de las otras capas de un stack convencional de una red de computadores.
Adicionalmente, el tamano mınimo de la carga util es 46 bytes. En resumen, una trans-
mision de un paquete de Ethernet que transmite solo un byte de informacion tiene una
carga util de 1.38% ya que tiene 26 bytes asociados al protocolo y 45 bytes que deben
Capıtulo 1. Introduccion 27
llenarse para completar la carga util mınima. En la Figura 1.20 se muestra un marco de
Ethernet a nivel de la capa de enlace de datos.
Figura 1.20: Frame de un paquete estandar de EthernetII. Tomada de wikimedia confines academicos
Para entender mejor el problema se presenta el siguiente ejemplo:
En un sistema de control secuencial, se tienen 20 tarjetas cada una con 16 salidas digi-
tales, 20 tarjetas cada una con 16 entradas digitales y 10 tarjetas de control de servome-
canismos las cuales se configuran con 10 bytes cada una y, ademas, envıan un diagnostico
de 15 bytes cada una. Tambien se considera que en un ciclo de operacion del programa
de logica secuencial que controla el sistema cada tarjeta de entrada envıa un mensaje,
cada tarjeta de salida recibe un mensaje y cada tarjeta de control envıa y recibe un
mensaje. Si se implementa una solucion donde cada uno de los dispositivos se conecta
a una LAN que es manejada por un nodo maestro, los mensajes enviados en cada ciclo
se presentan en la tabla 1.3.
Tarjetas Paquetes Carga util
Salidas digitales 20 2.78%
Entradas digitales 20 2.78%
Servomecanismos 10 20.83%
Total 50 6.39%
Tabla 1.3: Carga util para el ejemplo de una red de control
Se puede concluir del ejemplo anterior que la utilizacion del paquete de Ethernet en una
red de control que utiliza la filosofıa de las LAN de oficina es menor al 10%. Ademas, en
el ejemplo anterior no se contemplo el uso de las capas de red y transporte, por ejemplo,
las cuales anaden mas bytes de encabezado. Tampoco se consideraron paquetes de
sincronizacion los cuales podrıan reducir aun mas la carga util.
Ethercat se puede clasificar como un bus de campo del tipo 2 (ver seccion 1.5) ya que
esta disenado para enviar grandes cantidades de informacion a una velocidad de 100
Mbps. Como tal, el Ethernet no esta estandarizado para ser utilizado en exteriores a
menos que se utilice fibra optica o cable coaxial. Esto aumenta los costos e imposibilita
utilizar tecnologıas de alimentacion por Ethernet. Por esta razon EtherCAT puede no
ser la mejor solucion para el control de procesos.
Capıtulo 1. Introduccion 28
1.6.1 Ventajas y desventajas
La baja utilizacion de los canales de Ethernet ha sido una de las razones por las cuales
las redes que utilizan Ethernet no tuvieron mucha acogida a nivel de dispositivos; a nivel
de host Ethernet es la tecnologıa dominante. Adicionalmente la adquisicion de equipos
tales como switches y enrutadores hace que las implementaciones de redes basadas en
Ethernet sean muy costosas a nivel de campo.
EtherCAT plantea soluciones a estos problemas. En primer lugar, debido a que en un
mismo paquete de EtherCAT se envıa informacion relevante para todos los nodos de la
red, se puede aprovechar casi en su totalidad la capacidad del paquete para transmitir
informacion. Esto reduce el porcentaje de bytes que son utilizados como encabezado,
aumentado la carga util de la trasnmision. En el capıtulo 3 se vera mas acerca de la
forma como EtherCAT aprovecha el marco de Ethernet.
Ademas de mejorar la carga util, los equipos que utilizan EtherCAT suelen tener 2
interfaces de red; 2 puertos Ethernet independientes. Esto facilita la implementacion de
topologıas en lınea como la que se muestra en la Figura 1.21. De esta forma, se forman
cadenas de dispositivos sin necesidad de utilizar switches o hubs para interconectar
dispositivos. Claramente esto reduce el costo de las implementaciones de EtherCAT
a nivel de campo. Es importante mencionar que la topologıa de lınea no es la unica
topologıa permitida para implementar una red EtherCAT, tambien es posible utilizar
topologıas de arbol o de estrella.
Figura 1.21: Topologıa de lınea de una implementacion con EtherCAT. Tomada de[15] con fines academicos
La principal ventaja de Ethercat es que su velocidad permite sincronizar procesos que
se ejecutan en distintos CPUs. Se debe tener presente que el estandar IEC61499 esta
pensado para aprovechar las capacidades de procesamiento en paralelo. En la siguiente
seccion se muestra en detalle las razones por las que se escogio EtherCAT.
Capıtulo 1. Introduccion 29
1.7 Wireless HART
1.7.1 Tecnologıas inalambricas
Pese a que hoy en dıa los buses de campo son ampliamente utilizados en los sis-
temas de control, es necesario mencionar que han aparecido tecnologıas de comunicacion
inalambrica que pueden reemplazarlos en algunas aplicaciones. Por ejemplo, Wireless
Hart es una alternativa interesante que sigue el estandar ISA 100 el cual define algunos
requerimientos bascios para utilizar redes inalambricas a nivel de dispositivos. Para
llegar a reemplazar a los buses de campo, las tecnologıas inalambricas deben enfrentar
desafıos como:
• Lidiar con el ya saturado espectro electromagnectico.
• Implementar protocolos de comunicacion encriptados para evitar ataques informaticos.
• Proporcionar medios de alimentacion alternativos para los equipos que antes se
alimentaban utilizando el bus de campo.
1.8 Arquitectura del sistema
Para la implementacion se escogio EtherCAT considerando los siguientes aspectos:
• Es el bus de campo que posee mayor velocidad de transmision de datos; en im-
plementaciones con fibra optica alcanza velocidades de 1 Gbps. Esto favorece la
implementacion de soluciones que utilizan procesamiento paralelo y de sistemas de
tiempo real hard.
• A nivel de la capa fısica se pueden utilizar tarjetas de red convencionales.
• Se puede acceder a los estandares de forma gratuita si se tiene una membresıa que
tambien es gratuita.
• Ethercat proporciona mecanismos para que la integracion a nivel de campo sea
directa; no se requieren dispositivos especiales a nivel de la capa fısica ya que
funcionan bien dispositivos con 2 tarjetas de red de Ethernet 100baseTX.
Segun lo anterior, la arquitectura del sistema que se va a utilizar se puede observar en
la tabla 1.4. En los capıtulos siguientes, se veran detalles de cada una de las capas que
se presentan en la tabla.
Capıtulo 1. Introduccion 30
Capa Nombre de la capa Descripcion
8 Capa de usuario Se utiliza la herramienta de FBDK para crearlos bloques de funcion manejados por eventos.Luego se utiliza un traductor de XML para con-figurar la red EtherCAT. Adicionalmente, sedebe generar una aplicacion que facilite la con-figuracion de nodos maestros y esclavos. Porultimo, se debe pensar en una estrategia quepermita utilizar alguno de los lenguajes clasicosde control. De esta forma, se podran realizarimplementaciones que permitan mostrar los delnuevo enfoque en comparacion con el enfoqueclasico.
7 Capa de aplicacion Para la implementacion de esta capa se utilizanlos estandares proporcionados por ETG (Ether-CAT Technology Group) y el ejemplo de unstack que proporciona la companıa Beckhoff. Eneste punto se deben establecer mensajes que per-mita la configuracion de los nodos y la comuni-cacion de eventos y variables necesarios para laintegracion de bloques del estandar IEC61499
2 Capa de enlace de datos Siguiendo los estandares proporcionados porETG (EtherCAT Technology Group) y el ejem-plo de un stack que proporciona la companıaBeckhoff, se va a implementar esta capa enun sistema operativo (SO). Para esta imple-mentacion tambien hay 2 alternativas que de-penden de la plataforma sobre la cual se im-plementa la capa fısica. Por un lado, se puedeutilizar un sistema operativo propio de un fabri-cante como el SYS/BIOS de Texas Instruments.Por otro lado se puede utilizar un SO completa-mente libre como Linux. En los capıtulos 2 y 3se vera en detalle cual alternativa se seleccionoy porque.
1 Capa fısica Se requiere de tarjetas de red que utilicen , paraesto se tienen 2 alternativas: hacer tarjetas per-sonalizadas y utilizar tarjetas . En los capıtulos2 y 3.
Tabla 1.4: Descripcion de las capas a implementar durante este trabajo
1.9 Definicion del proyecto
Teniendo en cuenta la informacion presentada en el resumen y en este capıtulo se
definieron los objetivos y el alcance del proyecto. Es claro que el objetivo general es re-
alizar una implementacion de un sistema de control distribuido utilizando 2 tecnologıas
Capıtulo 1. Introduccion 31
de punta: el lenguaje del estandar IEC61499 y el bus de campo EtherCAT. A partir de
esta implementacion se podran analizar los beneficios y las ventajas de estas tecnologıas.
1.9.1 Obejtivos
• Implementar o seleccionar una plataforma Hardware adecuada para utilizar Ether-
CAT.
• Documentar los principales requerimientos de una implementacion de EtherCAT
y describir el Hardware requerido.
• Implementar un stack de EtherCAT sobre una plataforma Software que facilite el
uso de drivers de tarjetas de red.
• Integrar el enfoque de telegramas de EtherCAT con el enfoque de bloques fun-
cionales manejados por eventos del estandar IEC61499.
• Realizar implementaciones en el area de la robotica utilizando el estandar IEC61499
y EtherCAT.
1.9.2 Alcance
Se implementara una plataforma de control multiproposito que contempla las 3 capas
ya mencionadas del modelo OSI para buses de campo. La plataforma tendra como base
el uso de EtherCAT en las capas 1,2 y 7 del modelo OSI y, a nivel de la capa de usuario,
se integrara con el enfoque del estandar IEC61499.
1.9.3 Trabajo futuro
• Implementar el diseno Hardware que se presenta en el capıtulo 2.
• Integrar la plataforma Ethercat con una plataforma de otra tecnologıa como Wire-
less Hart.
• Certificar la implementacion Hardware y del stack ante ETG.
• Tomar medidas de confiabilidad de la implementacion.
Capıtulo 2
Capa fısica
2.1 Requerimientos de EtherCAT
Los requerimientos de la capa fısica de EtherCAT, aparecen en el estandar ETG.1000.2
[40]. Sin entrar en muchos detalles, a nivel de la capa fısica EtherCAT se basa en el
estandar IEEE 802.3 que es el estandar de Ethernet. Generalmente, se utiliza Ethernet
100base-TX o 100base-FX, aunque EtherCAT tambien plantea el uso de LVDS (Low-
Voltage Differential Signaling) para instalaciones dentro del mismo gabinete. LVDS,
como su nombre lo indica, es una transmision diferencial por un par de conductores
con niveles de Voltaje menores a los del Ethernet convencional; en la Figura 2.1 se
presenta una transmision convencional y en la Figura 2.2 una transmision utilizando
Voltajes diferenciales. Otro punto importante de EtherCAT es que limita la distancia
maxima de transmision del Ethernet 100base-TX a 20 m y no a 100 m como ocurre con
el Ethernet de oficina.
Figura 2.1: Transmision de una senal utilizando pulsos cuadrados. Tomado de [16]con fines academicos
El estandar ETG.1000.2 da a entender que las interfaces fısicas de Ethernet 100base-
TX y 100base-FX sugerida en el estandar IEEE802.3 cumplen con los requerimientos.
Si se escogiera una tecnologıa de LVDS en lugar del Ethernet convencional, habrıa que
cumplir con ciertos requerimientos de impedancia caracterıstica en el par de conductores,
32
Capıtulo 2. Capa fısica 33
Figura 2.2: Transmision de una senal utilizando senales de Voltaje diferencial.Tomado de [16] con fines academicos
ademas tocarıa anadir terminadores. En resumen, serıa necesario adaptarse al estandar
ANSI TIA/EIA-644-A. El estandar ETG.1000.2 esta mas orientado a como implementar
EtherCAT sobre una interfaz LVDS.
Es necesario mencionar que la capa fısica puede variar dependiendo de los requerimientos
de la instalacion. Por ejemplo, si se va a implementar EtherCAT en un area clasificada
donde la atmosfera contiene un gas explosivo, la implementacion debe cumplir con el
estandar IEC 60079. Tambien, si se va a implementar EtherCAT en un SIS (Sistema
Instrumentado Seguro) es necesario cumplir con el estandar IEC 61511 y con el estandar
IEC 61508.
2.1.0.1 Bloques de una implementacion
Como ya se menciono, una interfaz convencional de una tarjeta de Ethernet 100base-
TX puede cumplir con los requerimientos de EtherCAT siempre y cuando no haya re-
querimientos especiales como la operacion en areas clasificadas. Una interfaz Ethernet
convencional consta de los bloques mostrados en la Figura 2.3.
Figura 2.3: Interfaz de Ethernet que utiliza como PHY (Capa fısica) el circuitointegrado TLK110 de Texas Instruments. Tomado de [17] con fines academicos
Para utilizar una implementacion en lınea como la mostrada en la Figura 1.21 con
redundancia, el maestro y los esclavos deben tener 2 interfaces fısicas de red. Si no se
Capıtulo 2. Capa fısica 34
cuenta con 2 interfaces de red, es posible implementar redes con topologıas de estrella y
de arbol.
2.2 Seleccion de alternativas
Para la implementacion de EtherCAT en este trabajo se evaluaron 4 alternativas prin-
cipales:
• Los ESC (EtherCAT Slave Controller).
• La implementacion de ESC en FPGA.
• Procesadores con funcionalidades de red.
• Tarjetas que ya tengan interfaces de red.
Todas las alternativas utilizan los bloques de la Figura 2.3. Para justificar cual alter-
nativa se selecciono y porque, a continuacion se presentan detalles de cada alternativa
junto a sus ventajas y desventajas.
2.2.1 ESC
Los ESC son una implementacion economica si solo se requiere que el dispositivo de
campo para leer entradas y salidas analogas. Estan basados en un CI capaz de crear
mensajes de EtherCAT a partir de entradas y salidas digitales o de datos que ingresan por
medio de interfaces seriales como SPI o I2C. Adicionalmente, el dispositivo se configura
utilizando dichas interfaces seriales o archivos de configuracion que se envıan a traves
del bus de campo. El hecho que toda la informacion tenga que pasar por un canal de
comunicacion SPI o I2C, puede anadir un cuello de botella en la comunicacion.
En la Figura 2.4 se muestra una implementacion de un ESC utilizando el circuito inte-
grado ET1100. Se puede observar que en este tipo de implementaciones toda la infor-
macion debe pasar por el ESC que en este caso es implementado por el ET1100; en la
Figura 2.5 se muestra el diagrama de bloques del circuito integrado.
2.2.2 ESC en FPGA
Como alternativa a los circuitos integrados dedicados, algunos fabricantes de FPGAs
ofrecen bloques IP (Intelectual Property) los cuales cumplen la misma funcion del ESC.
Capıtulo 2. Capa fısica 35
Figura 2.4: Diagrama de bloques de la tarjeta de desarrollo FB1111-0140 desarrolladapor la companıa Beckhoff. Tomado de [18] con fines academicos
Figura 2.5: Diagrama de bloques del circuito integrado ET1100 desarrollado por lacompanıa Beckhoff. Tomado de [19] con fines academicos
Xilinx es uno de esos fabricantes, en la Figura 2.6 se muestra una implementacion de un
ESC utilizando una FPGA Spartan 3.
Es importante mencionar que el bloque IP no es gratuito. Para utilizarlo, es necesario
adquirirlo; existen distintos tipos de licencias para su uso. Altera tambien ofrece bloques
IP, que al igual que el bloque ofrecido por Xilinx, describe todos los bloques de la
Figura 2.5.
2.2.3 Procesadores con funcionalidades de red
Cualquier procesador que tenga 2 interfaces de MII o RMI podrıa utilizarse para Ether-
CAT capaces de implementar una topologıa en lınea (ver Figura 1.21). Tambien se
pueden utilizar procesadores con una interfaz MII para implementar topologıas de arbol
Capıtulo 2. Capa fısica 36
Figura 2.6: Diagrama de bloques de la tarjeta de desarrollo FB1130 desarrollada porla companıa Beckhoff. Tomado de [20] con fines academicos
o de estrella. Cuando se implementa un nodo utilizando solo el procesador, es necesario
programar todo el stack de EtherCAT que incluye los servicios de la capa de enlace
de datos y de la capa de aplicacion. Algunos fabricantes como Texas Instruments o
Freescale ofrecen stacks de EtherCAT, sin embargo estos stacks tienen funcionalidad
limitada; en el stack de Texas Instruments no es posible modificar el diccionario si no
se tiene una membresıa de EtherCAT.
2.2.4 Tarjetas comerciales
En el mercado existen una gran cantidad de tarjetas de desarrollo con interfaces de red.
Por ejemplo, las tarjetas Galileo de Intel, las Beagle Board, las tarjetas de Olimex y
tarjetas de fabricantes de procesadores. En principio cualquier tarjeta con una interfaz
de Ethernet podrıa utilizarse como nodo de EtherCAT siempre y cuando soporte la
implementacion de un stack. En la Figura 2.7 se muestra la tarjeta ICE V2 de Texas
Instruments la cual puede utilizarse en una implementacion de lınea de EtherCAT.
Finalmente, se selecciono la alternativa del procesador y de las tarjetas comerciales
debido a que se busca que los esclavos sean capaces de procesar parte del codigo asociado
a los bloques de funcion. Si se utiliza un ESC puede haber cuellos de botella en la
comunicacion que retrasen el envıo de la informacion. Esto es crucial para aprovechar
el enfoque de procesamiento paralelo en tiempo real del estandar IEC 61499.
2.3 Diagrama de bloques
La recomendacion de Texas Instruments para desarrollar con procesadores es construir
primero un diagrama de bloques. Es importante tener en cuenta que cuando se trabaja
Capıtulo 2. Capa fısica 37
Figura 2.7: Tarjeta ICE V2 que soporta una topologıa de lınea de EtherCAT. Tomadodel sitio web de Texas Instruments con fines academicos
con procesadores es necesario integrar algunos componentes que generalmente vienen
integrados en algunos microcontroladores. A continuacion se presentan algunas iniciales:
• Es necesario integrar como mınimo una memoria RAM ya que la memoria RAM in-
terna de los procesadores tiene una capacidad muy limitada; en el caso del AM3357
tiene una capacidad de 64KB.
• Se enecesitan dos interfaces de red que soporten Ethernet 100base-TX.
• Debido a que el codgio que va a ejecutar la tarjeta va a manejar varios proce-
sos de forma simultanea, es necesario que la tarjeta pueda utilizar algun sistema
operativo.
• Es necesario tener una memoria externa no volatil para guardar los archivos de
arranque de un sistema operativo, el sistema operativo como tal y algunos archivos.
• Los puertos de Ethernet deberıan estar conectados a las unidades de tiempo real del
procesador: PRU (Process Real-time Unit). Esto permitirıa utilizar eficientemente
el sistema ya que los nucleos del PRU se encargarıan de procesar y retransmitir el
paquete de EtherCAT y el nucleo principal se encargarıa de manejar los procesos
asociados al nodo.
Teniendo en cuenta las consideraciones anteriores, en la Figura 2.8 se muestra un dia-
grama de bloques de la implementacion sugerida para un nodo de EtherCAT basado en
el procesador AM3357.
Capıtulo 2. Capa fısica 38
Figura 2.8: Diagrama de bloques de una tarjeta que funciona como nodo EtherCAT
El diagrama tiene como componente principal un microprocesador AM3357 de texas .
Este procesador tiene las siguientes caracterısticas que mejoran el rendimiento de un
stack EtherCAT y que facilitan sum implementacion en comparacion con otros porce-
sadores disponibles comercialmente:
• Posee 2 interfaces MII que permiten la comunicacion con 2 PHY de Ethernet
independientes.
• Posee 2 nucleos PRU (Process Real-time Unit) con acceso a las 2 interfaces MII.
Esto permite que uno de los PRU se encargue de extraer el telegrama al nodo,
de anadir un nuevo telegrama para transmitir informacion y ademas retransmite
el mensaje al siguiente nodo en la cadena. Al encargarse el PRU de estas labores,
el procesador principal puede hacer otras tareas.
• Ya ha sido utilizado para implementaciones de EtherCAT como la de la tarjeta de
desarrollo ICE V2.
• Es posible portar un sistema Linux a partir de implementaciones existentes. Para
esto se debe generar un SPL, una version del U-boot personalizada para la tarjeta
y un Kernel personalizado.
Capıtulo 2. Capa fısica 39
2.3.1 Alimentacion
Para la alimentacion de los procesadores Sitara, familia del procesador AM3357,se utiliza
el circuito integrado TPS65910A3 que es el recomendado por Texas Instruments. El CI
escogido posee alimentacion separada para cada uno de los modulos del procesador los
cuales son generados utilizando 8 reguladores lineales (LDO) y 4 convertidores DC/DC;
en la Figura 2.10 se muestran los bloques que componen el circuito integrado.
Figura 2.9: Diagrama de bloques del circuito integrado TPS65910A3. Tomado de[21] con fines academicos
Todos los modulos tienen un Voltaje de entrada de 5V (Vbat) a partir del cual se generan
Voltajes de 3.3V para alimentar el procesador. En la tabla 2.1 se presentan los Voltajes
generados y los modulos que alimenta cada uno de esos Voltajes. La distribucion de
Voltajes esta basada en el diseno de referencia que se presenta en [41].
Capıtulo 2. Capa fısica 40
Voltaje de alimentacion (m) Modulo alimentado
VAUX1 VDDA1P8V USB, CDCE913
VAUX2 I2C, VDDSHV1, VDDSHV3,VDDSHV5, VDDSHV6, SYS-BOOT
VAUX33 VDDA3P3V USB, regulador VTT
VDD1 SMPS VDD MPU
VDD2 SMPS VDD CORE
VDDS DDR VDDS DDR, SDRAM, referenciadel regulador VTT
VMMC VDDSHV2, VDDSHV4, microSD
VDAC VDDS
VDIG2 VDDS PLL MPU,VDDS SRAM CORE BG,VDDS PLL CORE LCD,VDDS OSC
VPLL VDDA ADC
VRTC VDDS RTC
Tabla 2.1: Distribucion de Voltajes de alimentacion generados por el circuito inte-grado TPS65910A3
Teniendo en cuenta la distribucion de la tabla 2.1, en la Figura ?? se muestra el es-
quematico asociado al circuito integrado TPS65910A3 que se utiliza para generar los
Voltajes. Adicionalmente, el diseno cuenta con un regulador para alimentar los PHY
Ethernet (ver Figura 2.13), un regulador de proposito general y un regulador para el
RTC (Real-Time Counter).
Figura 2.10: Alimentacion utilizando el circuito integrado TPS65910A3
Capıtulo 2. Capa fısica 41
2.3.2 Interfaz fısica de ethernet
Como ya se menciono se requieren 2 interfaces de Ethernet para implementar una
topologıa de lınea. Sin embargo, tanto la interfaz MII0 PRUSS1 como la interfaz
MII1 PRUSS1 pueden utilizar varios pines para cumplir con su funcion; ambas interfaces
estan multiplexadas con otras funciones. Para garantizar que no haya conflictos entre
los pines de las 2 interfaces MII y los pines de los demas perifericos, se utilizo la her-
ramienta Software de TI pinmux. Utilizando esta herramienta se resolvieron todos los
conflictos y se obtuvo una distribucion de pines que cumple con el diagrama de bloques
de la Figura 2.8. En la Figura 2.11 se muestra la distribucion de pines para la interfaz
MII0 y en la Figura 2.12 los pines para la interfaz MII1.
Figura 2.11: Seleccion de pines del procesador AM3357 que se van a utilizar comointerfaz MII0
Figura 2.12: Seleccion de pines del procesador AM3357 que se van a utilizar comointerfaz MII1
Ahora se deben conectar los pines de las interfaces MII a 2 PHY. Para el diseno de esta
tarjeta se selecciono el circuito integrado TLK110 de TI. Con el objetivo de mantener
sincronizados los 2 PHY, se esta utilizando la misma fuente de generacion de reloj. como
se muestra en la Figura 2.13, se esta utilizando el circuito integrado CDCE913.
Capıtulo 2. Capa fısica 42
Figura 2.13: Generacion de senales de reloj para los PHY Ethernet
En cuanto la conexion de los PHY, se esta utilizando un conector ARJE-0032 que ya
trae transformadores de aislamiento para las senales de Ethernet y que ademas integra
un puerto USB. En la Figura 2.14 se muestra un conector de estos.
Figura 2.14: Conector ARJE-0032 que integra un conector RJ45 y un conector USBhembra tipo A. Tomado del catalogo de la empresa Abracon con fines academicos
El diseno del MAU (Medium Acces Unit) que contiene los bloques de la Figura 2.3, se
hizo con base en la hoja de datos del circuito integrado TLK110 [17]. Se puede observar
que el MAU posee. En la Figura 2.15 se muestra el MAU, considerando que el reloj es
generado por el circuito de la Figura 2.13.
Para cerrar esta seccion es importante mencionar algunos consideraciones de diseno:
• Para que el CI TLK110 inicie en modo MAU, es necesario que el pin RX DV se
encuentre conectado por medio de un pull-up a VCC.
• Se puede observar que, como parte de la interfaz MII, el MAU tiene un MDI que
es un bus de comunicacion utilizado para configurar y manejar el PHY desde el
procesador. En la Figura 2.16 se pueden ver los pines del procesador asociados al
MDI.
• Los dos MAU que utiliza la tarjeta, comparten la interfaz MDI.
Capıtulo 2. Capa fısica 43
Figura 2.15: Esquematico de un MAU Ethernet
• Las salidas de reloj de los PHY (CLKOUT) ingresan al procesador. Estas senales
seran utiles a la hora de sincronizar los PHY con el procesador. Sin embargo, esto
puede ser una tarea opcional.
Figura 2.16: Seleccion de pines del procesador AM3357 que se van a utilizar comointerfaz MDI
2.3.3 Secuencia de inicio
El procesador tiene un bootloader cargado en una memoria ROM el cual inicializa varios.
Ese bootloader se configura utilizando los pines SYSBOOT del procesador. Es una buena
practica utilizar buffers para que el procesador pueda utilizar estos pines despues de que
haya arrancado para otras funciones.El dispositivo puede bootear desde una memoria
Flash, desde una memoria SD o desde un puerto de comunicacion serial.
2.3.4 Memorıas
El procesador tiene hasta 1GB de direcciones para asignar en memoria. Es indispensable
adicionar una memoria RAM externa que utilice una interfaz DDR2 o DDR3; se sugiere
utilizar una memoria DDR3. En la Figura 2.17 se muestra la conexion de una memoria
SDRAM.
Capıtulo 2. Capa fısica 44
Figura 2.17: Conexion de una memoria RAM al procesador; los perifericos en elprocesador utilizan los nombres mostrados en la figura
Adicionalmente, se puede incluir una memoria SPI Flash que solo requiere de una in-
terfaz SPI para funcionar correctamente y una memoria microSD. El adaptador de la
memoria puede conectarse directamente al SOC (System On Chip) AM3357. La memo-
ria microSD puede utilizarse para cargar el SPL (Secondary Program Loader) el cual
puede cargar un U-boot que puede ser el encargado de lanzar el Kernel de Linux, por
ejemplo.
2.3.5 Otros perifericos
Aparte de los dispositivos ya mencionados, se pueden anadir otros perifericos dependi-
endo de lo que se necesite. Se recomienda utilizar la herramienta pinmux para asignar
otros perifericos.
Capıtulo 2. Capa fısica 45
2.4 Consideraciones de ruteo
Una vez disenado el esquematico, siguiendo todas las recomendaciones de las hojas de
datos y cumpliendo con el diagrama de bloques de la Figura 2.8, es necesario tener en
cuenta algunas consideraciones a la hora de realizar las conexiones:
• Hay senales digitales de alta frecuencia (MHz) que tienen tiempos de subida y de
bajada los cuales producen armonicos de alta frecuencia. Estos armonicos hacen
que algunas pistas se comporten como lıneas de transmision. En la Figura 2.18 se
muestran los armonicos para una senal de 1MHz que tiene un tiempo de subida de
20ns y en la Figura 2.19 se muestran los armonicos para una senal de 1MHz con
un tiempo de subida de 1ns.
Figura 2.18: Transformada de Fourier de una senal de 1MHz con tiempo de subidade 20ns. Tomada de [22] con fines academicos
Figura 2.19: Transformada de Fourier de una senal de 1MHz con tiempo de subidade 1ns. Tomada de [22] con fines academico
Capıtulo 2. Capa fısica 46
Se puede observar como aumenta el numero de armonicos de alta frecuencia y su
magnitud cuando disminuye el tiempo de subida. Una regla empırica, presentada
en [42], establece que si el tiempo de propagacion de la senal en la pista es al menos
10 veces menor al tiempo de subida de la senal, la pista se considera una lınea de
transmision.
Cuando las pistas se comportan como lıneas de transmision es necesario considerar
el acople de impedancias y el acople electromagnetico entre pistas (crosstalk).
• Hay senales digitales de alta frecuencia que pueden funcionar como antenas afectando
incumpliendo con algunas restricciones de compatibilidad electromagnetica. Una
buena practica puede ser ubicar las pistas que transportan estas senales entre
planos de referencia.
• Los encapsulados, los orificios pasantes y los conectores pueden anadir resistencias,
capacitancias e inductancias parasitas.
• Existen notas de aplicacion publicadas por los fabricantes de CI con consejos
practicos de diseno y con ruteos (layouts) de referencia.
• El calentamiento de los componentes disminuye su vida util y cambia sus condi-
ciones de operacion. En [42] se presentan mas detalles.
Algunas de las recomendaciones anteriores hacen que sea necesario anadir algunos com-
ponentes al esquematico; por ejemplo terminadores para el acople de impedancias. Con
el objetivo de reducir el tamano de la tarjeta, de reducir los acoples elctromagneticos y
de adaptar el diseno a las restricciones de diseno del lugar donde se fabrican las PCB,
se diseno un PCB de 6 capas.
Se recomienda utilizar un PCB de 6 capas de las cuales 2 representan planos de ali-
mentacion, uno Voltaje de alimentacion y el otro tierra, que sirven como referencia para
las lıneas de transmision de los tipos microstrip y stripline.
2.4.1 Crosstalk
El crosstalk hace referencia al acople entre distintas lıneas de transmision el cual es
causado por la interaccion de los campos electricos (acople capacitivo) y magneticos
(acople inductivo). Cualquier modelo circuital que involucreel efecto de Crosstalk esta
basado en la capacitancia y en la inductancia de acople de las lıneas de transmision.
A partir de estos valores de acople, se puede generar un circuito equivalente el cual,
mediante el uso de simulaciones, puede utilizarse para predecir el comportamiento de
las senales []. Es importante tener en cuenta que esas interacciones dependen de la
Capıtulo 2. Capa fısica 47
geometrıa de las lıneas, de los armonicos de frecuencia de las senales y de la cercanıa
que haya entre las lıneas.
Para calcular el efecto de Crosstalk en el circuito se va a seguir el siguiente procedimiento:
1. Clasificar las senales en: senales analogas de baja susceptibilidad, senales analogas
de alta susceptibilidad, senales digitales de baja frecuencia, senales digitales de alta
frecuencia y buses de alimentacion. Para cada una de estas senales se tienen en
cuenta distintos aspectos en el ruteo; esto tambien incluye otros efectos distintos
al crosstalk.
2. Examinar las distintas posibilidades de ruteo de las senales digitales de alta fre-
cuencia. Se tratara de ubicar las lıneas de alta frecuencia entre planos para reducir
la radiacion electromagnetica.
3. Calcular las impedancias mutuas utilizando el Software de simulacion libre Open-
EMS que se ejecuta sobre Octave o sobre Matlab.
4. Construir un modelo de circuito considerando la impedancia mutua a distintas
fecuencias y probar el comportamiento del circuito con senales similares a las que
va a manejar el circuito. Es importante tener la impedancia a distintas frecuencias
ya que las senales cuadradas poseen armonicos en distintas frecuencias.
5. Analizar los resultados y modificar el diseno si es necesario.
El procedimiento anterior esta basado en [43]. La ventaja de desarrollar el paso 3
utilizando metodos numericos para resolver el problema directamente con las ecuaciones
de Maxwell es que se tienen en cuenta las interacciones de todas las pistas del sistema;
no solo de las pistas que se encuentran cercanas.
2.5 Fabricacion
Para fabricar un PCB de 6 capas se deben fabricar varios PCBs individuales y unirlos con
una prensa de PCBs. La principal restriccion para fabricar un diseno de estos utilizando
los recursos de la universidad, es la perforacion y el metalizado de through holes para
las senales del procesador. Por recomendacion de Texas Instruments el diametro de de
los PADs utilizados para fijar el encapsulado BGA del procesador debe ser de 0.4 mm.
La perforacion mas pequena que se realiza con las brocas del laboratorio de circuitos
impresos es de 0.3 mm lo cual dejarıa un anillo de solo 0.05 mm de cobre en el PAD
para fijar la bola de soldadura. Se adquirieron brocas de 0.2mm, pero no se hicieron
Capıtulo 2. Capa fısica 48
pruebas de metalizado con agujeros de este diametro; en este momento se garantiza que
los through holes de 0.3 mm quedan bien metalizados.
Capıtulo 3
Stack de comunicaciones
3.1 Implementacion de nodos Ethercat
En el capıtulo anterior se mostraron detalles sobre como implementar un nodo EtherCAT
a nivel de la capa fısica; se utilizo como referencia el diseno de la tarjeta ICE V2 de
Texas Instruments. Por cuestiones de tiempo y de presupuesto, la implementacion de
una plataforma Hardware para EtherCAT se dejo fuera del alcance de este trabajo; esta
implementacion hace parte del trabajo futuro. Como alternativa, los nodos EtherCAT se
van a implementar en una plataforma Intel Galileo. Se destacan los siguientes aspectos
de esta plataforma:
• Tiene un SOC (System On Chip) que contiene un procesador de 400 MHz con
arquitectura x86.
• Tiene una memoria SPI-flash de 8MB de que puede grabarse utilizando EFI (Ex-
tensible Firmware Interface).
• Posee una interfaz de Ethernet, esencial para la conexion de EtherCAT.
• Tiene un socket para memoria micro SD.
• Posee un puerto PCI express que sirve para conectar modulos como adaptadores
de Wi-Fi.
• Intel proporciona las plantillas de desarrollo para Yocto las cuales incluyen un BSP
(Board Support Package). Las plantillas facilitan la labor de reconstruccion del
Kernel de Linux.
• Posee 2 puertos micro-USB, uno Host y el otro cliente lo cual permite manejar
dispositivos o manejar la tarjeta como dispositivo, respectivamente.
49
Capıtulo 3. Stack de comunicaciones 50
• Tiene una interfaz serial que permite depurar y acceder a la terminal de Linux y a
la consola de EFI. Desde la consola de EFI se puede grabar la memoria Flash de
la tarjeta y lanzar el Software Grub que puede pasar el control de la tarjeta a un
sistema operativo como Linux.
• La alimentacion es de 5V y se hace utilizando un Jack.
En la figura Figura 3.1 se muestra el diagrama de bloques de una tarjeta Galileo.
Figura 3.1: Diagrama de bloques de la tarjeta Intel Galileo. Tomada de [23] con finesacademicos
Como las tarjetas Galileo solo poseen una interfaz de Ethernet, es imposible imple-
mentar una topologıa de lınea como la mostrada en la Figura 3.2. Por esta razon, la
implementacion de EtherCAT tendra una topologıa de estrella. Adicionalmente, las tar-
jetas Galileo poseen un puerto PCI express que permitira integrar adaptadores de Wi-Fi
a la red. De esta forma, sera posible evaluar el desempeno del sistema cuando se integra
EtherCAT con otros protocolos como TCP y UDP. Es decir, se van a plantear escenar-
ios en los cuales llegan paquetes desde la interfaz de Wi-Fi que deben ser transmitidos
utilizando EtherCAT por la interfaz de Ethernet.
Por ultimo, es posible aprovechar otros perifericos de las tarjetas Galileo como el I2C,
ADC (Analog-Digital Converter), PWM (Pulse Width Modulation) y GPIO (General
Purpose Input Output) para integrar tarjetas de aplicacion. De esta forma, se podran
controlar motores, actuadores y adquirir datos utilizando el bus de campo. En la seccion
Capıtulo 3. Stack de comunicaciones 51
Figura 3.2: Topologıa de lınea de una implementacion con EtherCAT. Tomada de[15] con fines academicos
4 se presentan algunos de los modulos Hardware que se podrıan manejan utilizar en
conjunto con las tarjetas Galileo.
3.2 Implementacion de un Stack
Para implementar un stack de EtherCAT, que es el Software asociado a las capas 2 y 7
del modelo OSI, es neceario tener en cuenta que una capa del modelo OSI tiene servicios
y protocolos. En general los servicios son la respuesta a la pregunta: ¿que hace la capa?
Mientras que los protocolos son la respuesta a ¿como la capa cumple su funcion?. Por
ejemplo, a nivel de la capa fısica, los servicios pueden ser modelos orientados a describir
lo que se puede hacer y lo que ofrece una tarjeta de red que es manejada por un driver.
Mientras que los protocolos son las interacciones electromagneticas que se utilizan para
enviar, recibir y procesar senales. En resumen, los protocolos son lo que le interesa al
desarrollador o al programador de un stack mientras que los servicios son lo que mas le
interesa al usuario de un stack.
En el capıtulo anterior, y en las 2 secciones anteriores, se trato en detalle el tema de
la capa fısica, en esta seccion se vera la implementacion de las capas 2 y 7. Primero se
veran los servicios de la capa de enlace de datos, luego los protocolos y la forma como
se implementan. Luego se veran los servicios y los protocolos de la capa de apliacion,
junto a su implementacion. Por ultimo, se presentara la forma estandar de describir un
dispositivo esclavo por medio de un archivo XML.
3.2.1 Seleccion de la plataforma Software
Antes de observar las implementaciones, es importante mencionar algunos aspectos ac-
erca de la plataforma sobre la cual se va a implementar el stack. La plataforma Software
debe cumplir con los siguientes requerimientos:
• Debe tener los drivers de los adaptadores de red que se utilizan a nivel de la capa
fısica. No es el objetivo de este trabajo desarrollar drivers para tarjetas de red.
Capıtulo 3. Stack de comunicaciones 52
• Debe permitir ejecutar varios procesos con el fin de adquirir los paquetes, procesar
la informacion y retransmitir los paquetes cumpliendo restricciones de tiempo real.
• Debe tener drivers para utilizar PWM, GPIO, ADC, I2C . . . los cuales serviran
para integrar tarjetas Hardware de control e instrumentacion. En el Capıtulo ??
se muestran algunos de estos modulos.
Segun lo anterior, se requiere utilizar un sistema operativo que posea los drivers requeri-
dos y que permita la ejecucion de varios procesos simultaneamente. Hay que recordar,
como se menciono brevemente en el capıtulo 1, que se evaluaron 2 alternativas para
implementar el stack. La primera es programar un stack sobre un sistema operativo
como el SYS/BIOS que pertenece a Texas Instruments. La segunda es implementar el
stack sobre un sistema operativo libre como Linux. En la tabla 3.1 se presenta una
comparacion de las 2 alternativas.
Caracterıstica Linux SYS/BIOS
Desempeno Por defecto, Linux no es un SO de tiemporeal, aunque se puede aplicar un parchey recompilar el Kernel para convertirlo enun SO de tiempo real.
Es un SO de tiempo real.
Licencia Es completamente libre y existe una co-munidad de desarrolladores que cada dıamejoran el Kernel.
Es un SO perteneciente aTexas Instruments y no escompletamente libre.
Trabajo previo Existen implementaciones de stacksEtherCAT tanto para los nodos es-clavos como para los nodos maestros.Sin embargo, estas implementacionesestan desactualizadas. Se destaca laimplementacion presentada en [44]
Existe un stack actualizadopara los nodos esclavos. Sinembargo, no hay stacks librespara los nodos maestros.
Portabilidad El Kernel posee los drivers de una buenacantidad de interfaces de red de distin-tos fabricantes como Intel y tambien so-porta una cantidad significativa de ar-quitecturas de procesadores. Adicional-mente, Linux trata de seguir el estandarPOSIX lo cual facilitarıa la integracion delstack con otros sistemas Unix
Solo tiene drivers para lasinterfaces MII de los proce-sadores de Texas Instrumentslas cuales pueden comunicarsecon algunos PHY de Ethernet.No sigue el estandar POSIX
Tabla 3.1: Comparacion de plataformas para implementar el stack de EtherCAT
Segun lo presentado en la tabla 3.1 se selecciono Linux principalmente porque una im-
plementacion en este SO puede portarse a una gran cantidad de dispositivos que lo
utilizan; incluyendo una plataforma como la presentada en el Capıtulo 2. Adicional-
mente, no hay que adquirir licencias ni permisos especiales para tener acceso al codigo
fuente del Kernel.
Capıtulo 3. Stack de comunicaciones 53
3.2.2 Capa de enlace de datos
El desarrollo de la capa de enlace de datos esta basdo en los estandares ETG.1001.3[45]
y ETG.1001.4[26]. En el capıtulo 1 se menciono que EtherCat solo implementa 3 capas
del modelo OSI. Sin embargo, a nivel de la capa de enlace de datos se implementan
algunos servicios que normalmente se implementarıan a nivel de la capa de red y de
la capa de transporte; como ya se menciono, los servicios representan al stack desde el
punto de vista del usuario o de la capa superior.
EtherCAT utiliza una filosofıa maestro-esclavo para la transmision de informacion en
la red. El maestro crea un mensaje que es enviado a un esclavo el cual lee y escribe
informacion del mensaje original, segun lo haya determinado el maestro, y luego puede
retransmitirlo a otros esclavos si se utiliza una topologıa de lınea o de arbol. Si hay mas
ramas en el arbol o mas nodos en la lınea (tambien llamada segmento), el mensaje es
retransmitido por esos esclavos a los siguientes esclavos; estos esclavos tambien leen y
escriben informacion en el mensaje que les llego. El procedimiento se repite hasta llegar
a un final de segmento o de arbol en el cual no hay un nodo al cual retransmitirle la
informacion. Cuando el mensaje esta en un fin de segmento, todos los nodos ya han
leıdo y modificado el mensaje original el cual se devuelve hacia el maestro por el mismo
camino que llego.
Si hay varios esclavos esclavos conectados a un maestro por medio de un hub o de un
switch, topologıa estrella, el maestro utiliza las direcciones MAC de los esclavos para
enviarles informacion. En algunos casos se pueden utilizar direcciones IP, como se vera
mas adelante. En la Figura 3.3 se muestran varias topologıas de EtherCAT.
Figura 3.3: Topologıas utilizadas por EtherCAT. Tomada de [15] con fines academicos
Capıtulo 3. Stack de comunicaciones 54
3.2.2.1 Estructura del paquete
Antes de ver los servicios de la capa de enlace de datos, es importante mostrar la
composicion del paquete de EtherCAT a nivel de esta capa. En la Figura 3.4 se muestra
el marco (frame, en Ingles) de un paquete EtherCAT.
Figura 3.4: Estructura de un paquete de EtherCAT. Tomada de [24] con finesacademicos
Dependiendo del tipo de paquete que se este utilizando, la informacion puede organizarse
dentro del paquete utilizando bloques llamados DLPDU (Data Link Protocol Data Unit);
tambien llamados datagramas. Cada datagrama contiene ordenes para pedir informacion
a cada nodo. Sin embargo, como se vera mas adelante, no es necesario utilizar varios
datagramas para acceder a todos los esclavos. Como se vera mas adelante, con los
metodos de direccionamiento logico se puede acceder a varios esclavos utilizando un solo
datagrama.
En la estructura de la Figura 3.4 se puede observar que hay un encabezado de EtherCAT
el cual contiene:
• 11 bits que indican la longitud de todos los datagramas del mensaje.
• 1 bit reservado que debe tener siempre un valor de 0.
• 4 bits que indican el tipo de los mensajes de EtherCAT. En operacion normal,
estos 4 bits representan un 1; es decir, en binario tiene un valor de 0001. Otros
tipos de mensajes incluen mensajes de red y correos que utilizan el servicio de
buzon (mailbox) de la capa; estos mensajes no dividen el paquete de Ethernet en
datagramas. Los mensajes de red configuran las variables de la red de EtheCAT.
Mientras que los correos son utilizados para establecer comunicacion entre esclavos
y entre dispositivos fuera del segmento. Cuando se describa la capa de aplicacion
Capıtulo 3. Stack de comunicaciones 55
se van a describir varios de estos servicios en detalle. En la tabla 3.2 se presentan
los tipos de paquetes que utiliza EtherCAT.
ID Protocolo Descripcion
0x01 Datagramas En este protocolo el paquetese divide en secciones lla-madas datagramas. Cadadatagrama contiene instruc-ciones que sirven para leer y/oescribir la memoria de los no-dos esclavos
0x04 Mailbox Es un protocolo utilizado paracomunicar nodos esclavos en-tre sı y para implementar ser-vicios de la capa de apli-cacion orientados a transmi-tir archivos, transmitir men-sajes convencionales de unared Ethernet y enviar reportesde errores. En cada paquetesolo es posible transportar uncorreo por lo que la utilizaciondel paquete puede disminuir.Por esta razon, los Mailboxgeneralmente se utilizan en laconfiguracion de la red y enaplicaciones de comunicacionasıncrona.
0x05 Paquetes de red Son paquetes utilizadospara la configuracion de lasllamadas variables de red.Estas variables se utilizanpara diagnosticar y evaluarel rendimiento de la redEtherCAT. Un paquete dered puede contener variasvariables de red.
Tabla 3.2: Tipos de paquetes utilizados por EtherCAT a nivel de la capa de enlacede datos
Cuando se utilizan datagramas, ademas del encabezado de EtherCAT, el paquete con-
tiene:
• Un encabezado estandar de Ethernet que contiene la informacion de la Figura 1.20.
Las direcciones MAC de fuente y destino, por ejemplo, hacen parte de este en-
cabezado, junto a un identificador del tipo de Ethernet que se esta utilizando.
Capıtulo 3. Stack de comunicaciones 56
• Datagramas que contienen instrucciones de la capa de enlace de datos y la infor-
macion necesaria para ejecutar esas instrucciones.
• Encabezados de datagrama (1 por cada datagrama) el cual contiene, entre otras
cosas, la direccion del dispositivo esclavo que utiliza esa informacion y una direccion
fısica. El uso de una direccion o de la otra depende del modo de direccionamiento
que se utilice. Los segmentos (lıneas de EtherCAT, Figura 3.2) pueden utilizar
alguna de estas direcciones o las 2 dependiendo del modo de direccionaamiento
que se este utilizando para acceder a la informacion de los nodos esclavos.
• Un FCS (Frame Check Sequency) que sirve para verificar que no haya errores en
el paquete. El FCS hace parte del encabezado estandar de Ethernet y contiene
el calculo del CRC (Chequeo de Redundancia Cıclica). Cada vez que un paquete
llega a un esclavo, este verifica si hay errores y calcula un nuevo FCS antes de
retransmitirlo siempre y cuando el mensaje haya modificado el mensaje que llego.
En caso de detectar un error, el esclavo no lo corrige pero si informa al maestro
que ocurrio un error.
El encabezado del datagrama no solo contiene las direcciones de los nodos esclavos a los
cuales se dirige cada instruccion sino que tambien contiene la instruccion a ejecutar y los
parametros de la instruccion; hay una instruccion por cada datagrama. En la Figura 3.5
se muestra la composicion del encabezado de un datagrama.
Figura 3.5: Estructura de un datagrama de EtherCAT. Tomada de [25] con finesacademicos
Cada DLPDU o datagrama contiene:
• Un codigo para cada orden (CMD); mas adelante se muestran las instrucciones.
• La longitud de los datos del datagrama en numero de bytes (len); los datos se
agrupan en bytes.
Capıtulo 3. Stack de comunicaciones 57
• Un ındice (IDX) que sirve como identificador de la orden por parte del maestro.
Es decir, el maestro utiliza un identificador para las ordenes que da con el objetivo
de monitorearlas.
• Un campo de 32 bits para direcciones que tiene una direccion de incremento y una
direccion de posicion; el uso varıa dependiendo del tipo de direccionamiento como
se vera mas adelante.
• Las R y la C son campos reservados cuyo uso varıa dependiendo de la instruccion.
• La M es el parametro NEXT que sirve para indicar el final del datagrama. Es
decir, cuando esta en 0 indica que en el paquete no hay mas datagramas despues
del datagrama que se esta leyendo y cuando esta 1 indica que hay mas datagramas
en el paquete.
• Un espacio llamado IRQ que esta reservado y que es utilizado por algunas instruc-
ciones para enmascarar eventos.
• Los datos del datagrama que deben seguir unas normas de codificacion definidas
en el estandar ETG.1001.4. Las normas definen los tipos de datos numericos y los
tipos de caracteres, ası como la forma en que estos deben organizarse dentro del
datagrama.
• Un WKC (Working Counter, 1 por cada datagrama) que se aumenta cada vez
que un nodo accede a la informacion del DLPDU ya sea para leerla o modificarla;
cuando se lee se incrementa suma 1 y cuando se escribe se suma 2 al contador.
El maestro tiene presente cuanto deberıa cambiar cada WKC, por lo que puede
detectar errores si los valores de los WKC que retornan de los esclavos no coinciden
con los registros del maestro.
El acceso a los nodos utilizando datagramas es el metodo mas eficiente en terminos de
utilizacion del ancho de banda ya que permite concatenar varias ordenes en un solo
paquete; cuando se utiliza direccionamiento logico se puede acceder a todos los nodos
con un solo datagrama. Los paquetes que transmiten correos (Mailbox) generalmente
utilizan un solo paquete por cada correo. Esto hace que su uso sea ineficiente a la hora
de transmitir datos de proceso (datos asociados a la operacion normal del sistema de
control). Sin embargo, al utilizar un paquete de Ethernet completo, los correos pueden
transmitir una gran cantidad de informacion. Esto hace que se utilicen para transmitir
archivos, paquetes TCP/IP y UDP/IP que pueden venir de redes de computadores
convencionales; por ejemplo las redes a nivel Host en un sistema de control distribuido.
En resumen, hay 3 tipos de paquetes de EtherCAT (Ver Tabla 3.2) y uno de esos tipos,
los datagramas, tienen 3 formas de direccionamiento que se veran a continuacion.
Capıtulo 3. Stack de comunicaciones 58
3.2.2.2 Metodos de acceso a los esclavos utilizando datagramas
Segun el estandar ETG.1001.3, existen 4 formas de acceder a los nodos esclavos cuando se
utilizan datagramas las cuales se denominan tipos de direccionamientos. A continuacion
se presenta en detalle cada tipo de direccionamiento:
• Direccionamiento por segmentos: Hace referencia a la forma como un mae-
stro accede a los esclavos en una topologıa tipo estrella. Este tipo de direc-
cionamiento generalmente utiliza las direcciones MAC de los dispositivos esclavos
que se conectan al mismo dominio de transmision que el maestro. Es decir, el
maestro accede a los dispositivos utilizando los servicios convencionales de un red
de Ethernet de oficina. En algunas ocasiones, como cuando se integra el nivel
de host con el nivel de dispositivos, (ver Figura 1.15), se utilizan direcciones IP
para comunicar varios dispositivos. En este escenario se anade un encabezado de
UDP y un encabezado de IP, los cuales disminuyen la carga util del paquete. Adi-
cionalmente, cuando los paquetes deben pasar por routers compartidos por otros
dispositivos ajenos a la red EtherCAT, el desempeno de la tecnologıa se disminuye.
• Direccionamiento por posicion: En el espacio de la direccion de incremento se
coloca un numero negativo representado en base 2 el cual se aumenta en 1 cuando
pasa por cada uno de los esclavos. El esclavo que lee un 0 en esta direccion es el que
debe ejecutar la orden. Este tipo de direccionamiento es util en la inicializacion de
la red EtherCAT ya que permite escanear los nodos y conocer su ubicacion fısica.
Los servicios de incializacion hacen parte de la capa de aplicacion y se veran mas
adelante.
Por ejemplo, si se quiere acceder al tercer nodo de un segmento, el maestro escribe
un -2 en la direccion de incremento; en el campo de la direccion de posicion el
maestro coloca la posicion en la memoria del esclavo que se va a acceder. De
esta forma, cuando el paquete sale del primer nodo del segmento la direccion de
incremento toma un valor de -1 y cuando sale del segundo nodo tiene un valor de
0. Como el tercer nodo del segmento lee un cero en la direccion de incremento,
este ejecuta la instruccion.
• Direccionamiento por nodo: En este tipo de direccionamiento, cada datagrama
tiene una direccion de destino fija ubicada en el campo de la direccion de posicion.
De esta forma, cuando cada esclavo tiene su direccion asignada, verifica en el
paquete de EtherCAT si algun datagrama contiene su direccion. Cuando se utiliza
este tipo de direccionamiento, el campo de la direccion de incremento se utiliza para
indicar la posicion de la memoria del esclavo que se va a escribir o a leer. Este tipo
de direccionamiento se utiliza bastante para comunicar datos de proceso que son lo
Capıtulo 3. Stack de comunicaciones 59
datos de operacion del sistema de control, leer banderas en los nodos que pueden
indicar la presencia de un correo y cambiar algunas opciones de configuracion
accediendo a registros en los esclavos.
• Direccionamiento logico: El direccionamiento logico se basa en un modelo que
contempla un mapa de memoria global para todos los dispositivos. Todos los
dispositivos de la red, o del segmento, tienen una seccion de memoria delimitada
por un rango de direcciones. Cuando el maestro envıa un datagrama, indica el
rango de direciones que quiere leer o escribir y cada esclavo verifica si las direcciones
solicitadas hacen parte de su segmento. En caso que haga parte de su segmento,
el esclavo ejecuta la orden de lectura y/o de escritura contenida en el datagrama.
En la Figura 3.6 se muestra un ejemplo de acceso a varios esclavos utilizando este
tipo de direccionamiento.
Figura 3.6: Organizacion de memoria y de un datagrama cuando se utiliza direc-cionamiento logico. Tomada de [25] con fines academicos
El direccionamiento logico es muy util cuando hay muchos dispositivos esclavos
con datos de procesos con longitud reducida. Cuando se utiliza este tipo de direc-
cionamiento, el campo de la direccion de posicion se utiliza para indicar la posicion
de la memoria del esclavo que se va a escribir o a leer. En redes donde los datagra-
mas contienen muy pocos bytes de informacion, el direccionamiento logico permite
acceder a varios nodos con poca informacion utilizando un solo datagrama. De
esta forma solo se utiliza un encabezado de datagrama para obtener la informacion
de varios dispositivos. Esto mejora la utilizacion del paquete.
Capıtulo 3. Stack de comunicaciones 60
Como se pudo ver, cada tipo de direccionamiento tiene sus usos y sus ventajas las cuales
son aprovechadas por los servicios de la capa de aplicacion.
3.2.2.3 Servicios de la capa de enlace de datos
El estandar ETG.1001.3 se centra en esos servicios de la capa de enlace de datos. Los
servicios definidos por el estandar se dividen en 4 grupos:
• Servicios de lectura.
• Servicios de escritura.
• Servicios de lectura y escritura.
• Servicios de red.
• Mailboxes
Cada servicio de lectura y/o de escritura tiene un CMD asociado que se registra en el
encabezado (ver Figura 3.5). Adicionalmente, hay un servicio de lectura, uno de escritura
y uno de lectura/escritura para cada metodo de direccionamiento. Adicionalmente, hay
servicios de transmision que sirven para acceder a la misma seccion de memoria de varios
nodos.
3.2.2.4 Reloj distribuido
Una de las caracterısticas de EtherCAT es la implementacion de un reloj distribuido que
permite sincronizar todos los nodos de la red. El reloj tiene una resolucion de menos de
1 microsegundo por lo que es ideal para sincronizar procesos con restricciones de tiempo
exigente como las de los sitemas de tiempo real fuertes [37]. En caso que las restricciones
de tiempo no sean muy demandantes, se pueden utilizar algunos servicios de lectura y
escritura para sincronizar los procesos.
La sincronizacion se realiza en cada nodo utilizando que toma como parametros los
retardos y las compensaciones temporales calculadas por el nodo maestro.
3.2.2.5 Estructura de la capa de enlace de datos
El estandar ETG.1001.3 define un modelo que resume el funcionamiento de la capa de
enlace de datos; ver Figura 3.7. Este modelo no debe interpretarse como una guıa de
Capıtulo 3. Stack de comunicaciones 61
implementacion de un stack ya que una descripcion . En la Figura 3.8 se presenta la
estructura de un stack basada en maquinas de estado.
Figura 3.7: Modelo de funcionamiento de la capa de enlace de datos. Tomada de [25]con fines academicos
El modelo tiene como componente principal un espacio de memoria (DPRAM) que
consta de 3 secciones:
• Registros de configuracion y de estado.
• Mailbox
• Datos de proceso (PDI)
Las distintas secciones de memoria se acceden utilizando las instrucciones ya vistas.
Funcionalmente, hay 2 mecanismos de accedo a la memoria FMMMU y SYNCM. Los
SYNCM son mecanismos compuestos por 3 buffers mientras que los FMMU se componen
de un buffer.
3.2.2.6 Implementacion de la capa de enlace de datos
El estandar ETG.1001.4 define una estructura para la capa de enlace de datos basada en
6 maquinas de estados que interaccionan entre sı siguiendo el esquema de la Figura 3.8;
en la tabla 3.3 se describe la funcion de cada maquina de estados. Las maquinas de
estado no son un modelo como la estructura de la Figura 3.7, por el contrario definen
condiciones y especificaciones propias de la implementacion.
Capıtulo 3. Stack de comunicaciones 62
Figura 3.8: Implementacion de la capa de enlace de datos. Tomada de [26] con finesacademicos
Maquina de es-tados
Descripcion
PSM Implementa los servicios de Ethernet anivel de la capa de enlace de datos. Estoincluye el procesamiento de direccionesMAC, por ejemplo.
DHSM Se encarga de identificar y direccionar cor-rectamente el tipo de paquete que se estautilizando (ver Tabla 3.2). Si se estanutilizando datagramas, parte el paquete ypasa cada fraccion a la maquina de esta-dos que corresponda.
SYSM Proporciona servicios de acceso a lamemoria utilizando mecanismos conocidoscomo SYNCM
SIISM Es una interfaz local para acceder a losregistros de configuracion del dispositivo.Dependiendo de la implementacion Hard-ware del nodo, puede acceder a una memo-ria EEPROM externa; ver Figura 3.7.
DCSM Se encarga de manejar el reloj distribuido,en caso que se este utilizando este servi-cio. El manejo incluye la compensacionde tiempo por retardos en la transmisionde paquetes.
RMSM Se encarga de manejar el envıo y el proce-samiento de los correos.
Tabla 3.3: Descripcion de las maquinas de estado que implementan la capa de enlacede datos
Capıtulo 3. Stack de comunicaciones 63
No es el objetivo de este documento describir en detalle la estructura interna de cada
maquina de estados. Se recomienda revizar la seccion de Anexos del estandar ETG.1001.4
para una descripcion detallada de las maquinas de estado la cual incluye transiciones de
estados basada en eventos y condiciones.
Para este trabajo se va a utilizar el stack proporcionado por la empresa Beckhoff para
los integrantes de EtherCAT Technology Group (ETG). El stack contiene codigo en C
que implementa las maquinas de estado y la capa de aplicacion. En Linux la maquina
de estado se debe implementar junto a un raw Socket . El raw Socket es un servicio
del sistema operativo que permite transmitir mensajes sin los encabezados de Ethernet
propios de la capa de red y de transporte.
3.2.2.7 EtherCAT sobre UDP/IP
Para cerrar esta seccion, es importante mencionar que es posible enviar datagramas
de EtherCAT utilizando un paquete con encabezado de UDP/IP. Este tipo de imple-
mentaciones e muy utilizada a nivel de Host en un sistema de control distribuido. De
esta forma, se puede integrar con facilidad una red EtherCAT compuesta por varios
segmentos con una red empresarial.
3.2.3 Capa de aplicacion
La capa de aplicacion proporciona una interfaz para las aplicaciones que quieren ac-
ceder a los servicios que presta EtherCAT. Su desarrollo esta basdo en los estandares
ETG.1001.5[27] y ETG.1001.6[46] que definen los servicios y los protocolos de la capa,
respectivamente. Igual que en cualquier implementar que sigue el modelo OSI, las capas
superiores utilizan los servicios proporcionados por las capas inferiores.
La capa de aplicacion presta 5 servicios principales a las aplicaciones que la utilizan:
• Ethernet over EtherCAT (EoE): Es un servicio que utiliza correos para trans-
mitir mensajes tradicionales de Ethernet, TCP/IP y UDP/IP, en una red Ether-
CAT.
• CAN over EtherCAT (CoE): Este servicio se utiliza para transmitir mensajes
que se encuentran en un marco de CAN utilizando correos.
• File over EtherCAT (FoE): Es un servicio utilizado para transmitir archivos.
Capıtulo 3. Stack de comunicaciones 64
• Service Description Object (SDO): Son objetos, definidos en una clase, que
sirven para describir servicios utilizados por las aplicaciones que hacen uso de la
capa de aplicacion. Se utilizan principalmente para leer los datos de procesos.
• Process Description Object (PDO): Son objetos, definidos en una clase, que
sirven para describir servicios utilizados por la red para acceder a los datos de
proceso. Los PDO son la interfaz entre la capa de aplicacion y la capa de enlace
de datos.
La mayorıa de los servicios mencionados utilizan correos, en especial los servicios que se
integran con otros protocolos: EoE, CoE y FoE. En la Figura 3.9 se muestra el modelo
de la capa de aplicacion integrado con el modelo de la capa de enlace de datos.
Figura 3.9: Modelo de la capa de aplicacion integrado con el modelo de la capa deenlace de datos. Tomada de [27] con fines academicos
No es necesario implementar el servicio de correo a nivel de la capa de enlace de datos
si no se van a utilizar los servicios de la capa de aplicacion que hacen uso de estos.
3.2.3.1 Maquina de estados de EtherCAT (ESM)
La maquina de estados de EtherCAT define los posibles estados de la red. Estos estados
generalmente representan una secuencia de inicio. En la Figura 3.10 se muestra la
secuencia de la maquina de estados y en la Tabla 3.4 se describe cada uno de los estados.
Cuando los nodos se encuentran trabajando en el estado de operacion, la mayorıa de
tareas de la red estan relacionadas con los datos procesos: Actualizacion, lectura y
escritura.
Capıtulo 3. Stack de comunicaciones 65
Figura 3.10: Maquina de estados de la red EtherCAT. Tomada de [25] con finesacademicos
Estado Descripcion
Init No se prestan servicios a nivel de la capade aplicacion y el maestro tiene acceso alos registros de configuracion de los es-clavos.
Pre-operational Esta activo el servicio de correo y no haytransmision cıclica de datos de proceso.
Safe-operational Esta activo el servicio de correo a nivel dela capa de aplicacion y hay transmision dedatos de proceso, aunque solo se procesanentradas de proceso no salidas.
Operational Todos los servicios estan activos y seprocesan tanto entradas como salidas deproceso.
Tabla 3.4: Descripcion de los estados de ESM
3.2.3.2 Implementacion de la capa de aplicacion
Al igual que la capa de enlace de datos, la capa de aplicacion tiene en cuenta que hay
un maestro y hay un esclavo. El maestro tiene la estructura de la Figura 3.11 que se
caracteriza porque para cada esclavo hay un manejador el cual contiene, entre otras
cosas, los parametros de configuracion del nodo y el estado en que se encuentra; ver
Figura 3.10.
Por otra parte los esclavos pueden tener la estructura de la Figura 3.12 o de la Figura 3.13.
La estructura de la Figura 3.12 corresponde a un esclavo simple que puede accederse
Capıtulo 3. Stack de comunicaciones 66
Figura 3.11: Estructura funcional de un nodo maestro. Tomada de [27] con finesacademicos
directamente desde la aplicacion. Mientras que la Figura 3.13 muestra un esclavo com-
pleto.
Figura 3.12: Estructura funcional de un nodo esclavo simple. Tomada de [27] confines academicos
A diferencia de la capa de enlace de datos, la capa fısica se implementa utilizando clases
que permiten crear objetos de acceso a la memoria llamados ASE (Application Service
Entity). En resumen, el acceso a la informacion de la memoria del stack se realiza
declarando objetos y utilizando los metodos de acceso propios de cada clase.
Capıtulo 3. Stack de comunicaciones 67
Figura 3.13: Estructura funcional de un nodo esclavo completo. Tomada de [27] confines academicos
3.3 Descripcion de dispositivos EtherCAT
Una de las ventajas de EtherCAT es que permite la integracion con protocolos de red que
implementan la capa de red y la capa de transporte. La descripcion de los dispositivos
esclavos se hace en un archivo .XML (Extensible Markup Language) . Este archivo
contiene toda la informacion referente a los registros de configuracion en la memoria
como se vio en la capa de enlace de datos.
Estos archivos generalmente son proporcionados por los fabricantes de dispositivos Ether-
CAT y se denominan ESI (EtherCAT Slave Information). Utilizando estos archivos el
maestro genera un archivo llamado ENI (EtherCAT Network Information) el cual se
utiliza cuando se inicializa la red siguiendo la maquina de estados de la Figura 3.10.
En resumen, los archivos ESI son archivos que proporcionan a los nodos maestros la
descripcion de los nodos esclavos de la red.
3.4 Resumen del stack
El stack implementa dos capas de la arquitectura definida para este trabajo. Con el stack
solo resta implementar una aplicacion que permita programar utilizando el estandar IEC
61499. En el siguiente capıtulo se hablara de la capa de usuario de la implementacion en
la cual se encuentran las aplicaciones que hacen uso de la capa de aplicacion del stack
de EtherCAT.
Capıtulo 3. Stack de comunicaciones 68
El acuerdo de licencia entre la empresa Beckhoff y los usuarios del stack que proporcionan
a los integrantes de ETG prohıbe su reproduccion. Por esta razon, no se presentan
detalles del codigo contenido en este.
Capıtulo 4
Uso de FBDK (Function Block
Development Kit)
4.1 Aspectos basicos de la herramienta FBDK
Como se menciono en la introduccion, se va a utilizar la herramienta FBDK de Holobloc
Inc como ambiente de desarrollo para el lenguaje del estandar IEC 61499. La her-
ramienta proporciona un ambiente de desarrollo grafico que permite crear bloques a
partir de plantillas, exportar la descripicion del bloque en formatos como XML y eje-
cutar redes de bloques para verificar su funcionamiento; la ejecucion se realiza en un
entorno de simulacion por defecto en FBDK.
La herramienta permite:
• Crear bloques simples con la estructura vista en la introduccion.
• Crear bloques complejos los cuales integran varios bloques simples.
• Crear bloques que modelan dispositivos.
• Crear bloques que definen objetos propios de una interfaz de usuario.
• Interconectar bloques y ejecutar simulaciones.
En [2] se presentan detalles de uso de la herramienta aunque se recomienda revisar
detalladamente el tutorial de Holobloc ya que se han cambiado algunos aspectos de
manejo de la herramienta.
69
Capıtulo 5. Uso de FBDK 70
4.2 Manejo basico de ST (Structered Text)
Como se menciono en el Capıtulo 1, ST es un lenguaje que trata de integrar algunos
aspectos de lenguajes como C. ST permite utilizar variables, operadores, expresiones y
controles de flujo (lazos, por ejemplo). Sus componentes, propios de un lenguaje de mas
alto nivel, hacen que su traduccion a un lenguaje como C sea sencilla. Para mas detalles
sobre el uso de ST se recomienda revisar [47] que es una guıa resumida de la sintaxis del
lenguaje.
El enfoque y la sencillez del lenguaje facilitan la traduccion a otros lenguajes como C.
En la Figura 4.1 se muestra un programa simple escrito en ST el cual puede ser leıdo
con facilidad si se ha trabajado con otro lenguaje de alto nivel.
Figura 4.1: Ejemplo de ST, se puede observar que la sintaxis es sencilla y en ciertomod se parece a mucho a la sintaxis de Matlab. Tomada de [28] con fines academicos
4.3 Integracion de FBDK con la red EtherCAT
Una de las labores mas importantes es la integracion del ambiente de desarrollo FBDK
con el stack de EtherCAT que se presento en el capıtulo 3. Para esto se va a aprovechar
el hecho que la herramienta FBDK exporta el contenido de los bloques de funcion en
un archivo XML. Es importante resaltar que el lenguaje XML sirve para organizar el
contenido en un formato que puede leerse con facilidad. Por ejemplo, en la Figura 4.2
se muestra un bloque funcion y en la Figura 4.3 se muestra la descripcion de uno de los
algoritmos de ese bloque en XML.
El traductor busca las secciones de codigo de los algoritmos y de las maquinas de estado
y utilizando las etiquetas de XML y luego las traduce.
Capıtulo 5. Uso de FBDK 71
Figura 4.2: Bloque de ejemplo
Figura 4.3: Descripcion de un algoritmo en XML
Para integrar el stack de EtherCAT con la herramienta se utilizaron los programas gawk
y sed que vienen instalados con la consola bash de Linux; hay otros sistemas operativos
que pueden utilizar esta consola. Estos 2 programas se utilizan para procesar texto
con base en condiciones y patrones. De esta forma, la integracion se hace siguiendo los
siguientes pasos:
1. Se describen los bloques de funcion y sus interacciones utilizando la herramienta
FBDK.
2. Se generan los archivos XML que describen los bloques de funcion.
3. Se define donde van a ser ejecutados los bloques de funcion; en que nodos se van
a ejecutar.
4. Se utiliza un script que se ejecuta en bash el cual traduce la informacion del
archivo XML en porciones de codigo que pueden ejecutarse en los nodos de la
red. La traduccion de los algoritmos se hace a un lenguaje como C el cual puede
ser compilado utilizando herramientas como GCC (GNU Compiler Collection) y
ejecutado en los nodos que utilizan el kernel de Linux.
Capıtulo 5. Uso de FBDK 72
5. Se inicia la red de EtherCAT la cual sigue el proceso de la maquina de estados de
EtherCAT (ESM) que se muestra en la Figura 3.10.
6. El codigo de los bloques se transmite a los nodos utilizando el servicio FoE (Files
over EtherCAT).
7. Los eventos y los datos entre bloques, en operacion normal, son transportados
como datos de proceso. No se utilizan servicios como CoE (CAN over Ethernet)
para esto.
4.3.1 Traduccion
Cada algoritmo va a ser representado como una funcion que recibe las variables y los
eventos a utilizar como parametros. Adicionalmente la maquina de estados que repre-
senta el ECC tambien se describe en C como otra funcion; la descripcion de la maquina
de estados, como es comun, se realiza utilizando la funcion switch y la etiqueta case.
Para facilitar la traduccion, los algoritmos se describen utilizando el lenguaje ST (Struc-
tured Text). Como ya se vio, este lenguaje contempla la declaracion de variables y el uso
de funciones lo cual hace que la traduccion a un lenguaje como C sea mas sencilla. La
herramienta FBDK permite describir los algorimtos utilizando cualquier lenguaje clasico
de control, pero no se va a desarrollar para un script para traducir los otros lenguajes.
En resumen, para integrar la herramienta FBDK con la red de EtherCAT se deben
desarrollar programas para:
• Convertir los algoritmos de los bloques de funcion en funciones de C.
• Convertir el ECC (Execution Control Chart) en una funcion de C.
• Definir el diccionario de la red EtherCAT el cual permitira pasar la informacion
de configuracion (codigo a ejecutar, por ejemplo), las variables y los eventos.
• En caso tal que se ejecuten varios bloques de funcion en un nodo, crear un proceso
por cada uno de estos en el sistema operativo y utilizar herramientas de comuni-
cacion de procesos para sincronizarlos.
• Desarrollar un menu o una interfaz grafica que facilite la labor de configuracion
de la red por parte de los usuarios de la implementacion.
Capıtulo 5
Resultados y conclusiones
5.1 Pruebas
El sistema se probo distribuyendo el diagrama de bloques presentado en la Figura 5.1
Figura 5.1: Ejemplo utilizado para probar el sistema. Tomado de [2]
El ejemplo representa un sistema simple que tiene como objetivo hacer parpadear 4
LED (Light Emitting Diode) de distintas formas dependiendo del modo de operacion
seleccionado. En la parte baja se puede observar que tambien hay un archivo XML
asociado al diagrama de red. En la implementacion, este archivo no se utiliza ya que los
datos de proceso (variables entre bloques y eventos) se definen en un archivo distinto
el cual indica que nodo va a ejecutar cada bloque. El formato de ese archivo tiene la
estructura mostrada en la Figura 5.2
73
Capıtulo 6. Resultados y conclusiones 74
Figura 5.2: Interfaz del ejemplo. Tomado de [2]
La red de bloques de la Figura 5.1 posee 1 bloque de interfaz que se va a ejecutar en el
nodo maestro (Computador personal): START. Adicionalmente, los bloques RUNSTOP,
RS GATE, DT y PERIODIC tambien se ejcutan en el nodo maestro. Estos bloques estan
asociados a acciones que el usuario ejecuta desde la interfaz; varias de las variables de
entrada de estos bloques son proporcionadas por el usuario que utiliza una interfaz como
la de la Figura 5.3.
Figura 5.3: Interfaz del ejemplo. Tomado de [2]
Los bloques FLASHIT, MODE y LEDS se ejecutan en una tarjeta Galileo que funciona
como dispositivo esclavo. Los LEDS son GPIOs de la tarjeta manejados por las librerıas
de GPIO que se encuentran en el compilador cruzado que proporciona Intel. El resul-
tado de la prueba fue que la integracion de herramientas y el traductor funcionaron
correctamente.
En [2] se describe el ejemplo en detalle.
Capıtulo 6. Resultados y conclusiones 75
5.2 Resumen
A lo largo de este documento se describieron todos los componentes de una imple-
mentacion que sigue el estandar IEC 61499. Adicionalmente, se describieron las her-
ramientas utilizadas para la implementacion. De esta forma, las herramientas utilizadas
en la implementacion fueron:
• Tarjeta Galileo para la capa fısica: Pese a que se trato de disenar una
plataforma Hardware personalizada para esta implementacion, se utilizaron tarje-
tas Galileo como plataforma Hardware. Las restricciones de fabricacion del lab-
oratorio de circuitos impresos no son las adecuadas para la fabricacion de dicha
plataforma.
• Sistema operativo Linux como plataforma Software: Intel proporciona una
imagen de Linux para las tarjetas Galileo la cual se utilizo para implementar el
stack. Se escogıo esta plataforma porque hay plantillas de Yocto que facilitan la
labor de personalizar el Kernel para mejorar su desempeno en terminos de tiempo
real.
• Stack de Beckhoff para las capas de enlace de datos y la capa de apli-
cacion: Se utilizo el stack que proporciona Beckhoff. En caso que se quiera
comercializar la implementacion, es necesario construir un stack propio ya que el
stack es proporcionado para usos academicos.
• Programas gawk y sed para traducir los bloques: Son programas estandar
de la consola de Windows para procesar texto.
• Herramienta FBDK para construir los bloques: Es una herramienta que
permite describir bloques que cumplen con el etandar IEC 61499. La descripcion
se exporta en un formato XML
5.3 Conclusiones
La principal conclusion de este trabajo es que las tecnologıas de buses de campo como
EtherCAT se integran de forma sencilla con el lenguaje del estandar. La combinacion de
estas dos tecnologıas modernas de control, EtherCAT y el estandar IEC61499, permiten
aprovechar al maximo las posibilidades de procesamiento paralelo de un sistema de
control distribuido. A continuacion se presentan mas conclusiones del trabajo:
Capıtulo 6. Resultados y conclusiones 76
• La tecnologıa EtherCAT puede implementarse en una gran variedad de tarjetas y
sistemas existentes ya que a nivel de la capa fısica solo requiere de una tarjeta de
red para Ethernet convencional.
• La principal ventaja de utilizar EtherCAT son los servicios y la logica detras de
su funcionamiento. EtherCAT proporciona una interfaz de comunicacion y de
coordinacion entre los programas ejecutados por los nodos que se adapta a la
perfeccion al uso de algoritmos.
• Los entregables de este trabajo no deben utilizarse en una implementacion de un
sistema de control industrial; es decir, su aplicacion debe ser academica. Como
se menciono en la introduccion un sistema de control debe cumplir con otros
estandares que dependen de la aplicacion.
• La libertad que existe para desarrollar sobre alguna tecnologıa de bus de campo
se encuentra limitada por factores como el pago por estandares o membresıas;
esto influyo bastante a la hora de escoger EtherCAT como tecnologıa. Es decir,
las implementaciones de stacks de buses de campo estan lejos de ser consideradas
Software libre segun los termino de GNU. Esto puede ser una limitante a la hora
de trabajar con estas; de hecho gran parte del tiempo de desarrollo de este trabajo
se gasto obtebiendo la membresıa a ETG para poder acceder a los estandares.
• Utilizar un enfoque de programacion por bloques permite redisribuir la ejecucion de
tareas de forma flexible. Parte de la labor del programador es distribuir la ejecucion
del programa para aprovechar de la mejor manera la capacidad de procesamiento
de los nodos.
5.4 Trabajo futuro
En esta seccion se proponen algunas tareas a desarrollar para mejorar el entregable de
este trabajo. Estas mejoras quedaron fuera del alcance de este trabajo por falta de
recursos o porque su desarrollo requerıa de una cantidad de tiempo por fuera de los
lımites de tiempo establecidos para una tesis de maestrıa. A continuacion se mencionan
dichas tareas:
• Implementar una plataforma Hardware que permita utilizar la topologıa de lınea
de EtherCAT.
• Mejorar el rendimiento del Kernel para que cumpla con restricciones de tiempo
real.
Bibliografıa 77
• Programar un stack propio de EtherCAT siguiendo los estandares mencionados en
el capıtulo 3.
• Programar traductores para otros lenguajes de control como IL.
• Certificar una posible implementacion Hardware y una implementacion del stack
ante ETG.
• Realizar pruebas de confiabilidad y verificacion estadıstica sobre una implementacion
mejorada para determinar su cumplimiento con estandares de seguridad funcional
como el estandar IEC61508.
Bibliografıa
[1] G. Kirckof. Cascading logic: A machine control methodology for programmable logic
controllers. The Instrumentation, Systems, and Automation Society(ISA), 2003.
[2] V. Vyatkin. IEC 61499 Function blocks for embedded and distribuited control
systems design. The Instrumentation, Systems, and Automation Society(ISA) y
O3neida, 2012.
[3] J. Berge. Fieldbuses for process control: Engineering, Operation, and Maintenance.
The Instrumentation, Systems, and Automation Society(ISA) y O3neida, 2004.
[4] M. Kerrisk. The Linux Programming Interface: A Linux and UNIX System Pro-
gramming Handbook. No Starch Press, Inc, 2010.
[5] R. Dahl-Skog. Introduccion a la Programacion de controladores logicos ( P L C ).
[6] Manufacturing metrics that really matter, 2014.
[7] W. L. Mostia. Troubleshooting: A Technician’s Guide (2nd edition), NC: Research
Triangle Park. The Instrumentation, Systems, and Automation Society(ISA), 2005.
[8] ASM Consortium. Asm consortium guidelines: Effec-
tive operator display design. Disponible en: https :
//www.asmconsortium.net/Documents/ASMHandoutDisplay.pdf .
[9] Ansi/isa-88.00.01, batch control part 1: Models and terminology. Technical report,
The Instrumentation, Systems, and Automation Society(ISA), 2010.
[10] G. K. McMillan. Essential of Modern Measurement and Final Elements in the
Process Industry: A guide to design, configuration, installation, and maintenance.
The Instrumentation, Systems, and Automation Society(ISA), 2010.
[11] Optimized manufacturing with networked dcs system at naphtha cracking plant.
Technical report, Moxa, 2008.
[12] Amis-49200 fieldbus mau reference design. Technical report, AMI Semiconductor a
ON-semiconductor corp., 1997.
78
Bibliografıa 79
[13] Implementing fieldbus in deltav system: Answers to your questions about imple-
menting fieldbus in deltav systems. Technical report, Emerson Process Manage-
ment: DeltaV, 2013.
[14] K. Pazul. AN713: Controller Area Network (CAN) Basics. Microchip, 1999.
[15] Ethercat: Technical introduction and overview. Technical report, Ethercat Technol-
ogy group, 2013. Disponible en: http : //www.ethercat.org/en/technology.html.
[16] D. R. Starr. Understanding Ethernet Layer-1. Cisco learning network. Disponible
en: https : //learningnetwork.cisco.com/docs/DOC − 22113.
[17] A. Yarmakov. TLK1XX Design and Layout Guide. 2013. Disponible en: http :
//www.ti.com/lit/an/slva531a/slva531a.pdf .
[18] Hardware Data Sheet: FB1111-0140 FB1111-0141 FB1111-0142. 2011.
[19] Hardware Data Sheet: ET1100. 2014.
[20] Hardware Data Sheet: FB1130. 2009.
[21] TPS65910x Integrated Power-Management Unit Top Specification. 2014.
[22] J. Ganssle. Fourier and us. Portal embedded.com, 2013.
[23] Galileo datasheet. Technical report, Intel, 2014.
[24] ETG.2200: EtherCAT Slave Implementation Guide. 2014.
[25] EtherCAT Communication: Communication Principles. EtherCAT Technology
Group (ETG), 2012.
[26] ETG.1001.4: EtherCAT Data Link Layer Protocols. 2014.
[27] ETG.1001.5: Application Layer service definition. 2013.
[28] IEC 61131. 2012.
[29] S. Mackay E. Wrigth D. Reynders J. Park. Practical industrial data networks:
Design, installation and troubleshooting. Newnes, 2004.
[30] M. Tiegelkamp K. John. IEC 61131-3: Programming Industrial Automation Sys-
tems. Springer, 2010.
[31] C. Bresnahan R. Blum. Linux Command Line and Shell Scripting Bible (Segunda
edicion). Wiley, 2011.
[32] Allen-Bradley Guard Master. Safety book 4: Sistemas de seguridad para maquinaria
industrial. Rockwell Automation.
Bibliografıa 80
[33] P. Bullemer D. V. Reising C. Burns J. Hajdukiewicz J. Andrzejewski. Effective
operator display design 2008. ASM Joint R&D Consortium, 2008.
[34] N. P. Lieberman. Troubleshooting Process Plant Control. Wiley, 2011.
[35] J. Rifkin. La tercera revolucion industrial. Paidos, 2011.
[36] Ieee std 512-1982: Ieee guide for the installation of electrical equipment to mini-
mize electrical noise inputs to controllers from external sources. Technical report,
Institute of Electrical and Electronics Engineers (IEEE), 1990.
[37] P.A. Laplante. Practical industrial data networks: Design, installation and trou-
bleshooting (4th edition). Wiley-IEEE Press, 2011.
[38] Iec 60079 series explosive atmosphere standards. Technical report, International
Electrotechnical Commission (IEC), 2011.
[39] Foundation fieldbus power supply: A look at powering fieldbus. Technical report,
Analog Services, Inc, 2000.
[40] Etg.1000.2s(r)v1.0.3: Physical layer service and protocol specification. Technical
report, Ethercat Technology group, 2013.
[41] TMDXICE3359: Schematic. 2013.
[42] P. Wilson. The Circuit Designer’s Companion (Third edition). Newness, 2012.
[43] J. C. Rautio. Rigorous Evaluation of Worst Case Total Crosstalk in the Time
Domain Using Frequency Domain Scattering Parameters. Sonnet Software, Inc.,
2001.
[44] Simple Open EtherCAT Master. 2004.
[45] ETG.1001.3: EtherCAT Data Link Layer Services. 2014.
[46] ETG.1001.6: Application Layer protocol specification. 2013.
[47] Logix5000 Controllers Structured Text. 2012.
Top Related