Implementación de un sistema de control distribuido ...

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

http://www.uniandes.edu.co

http://cmua.uniandes.edu.co

http://iee.uniandes.edu.co

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

http://www.uniandes.edu.co

https://ingenieria.uniandes.edu.co/

http://iee.uniandes.edu.co

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


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,


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


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


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


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


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


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


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


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


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.


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


• 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


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


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


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


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


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


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.


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.


• 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


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,


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.


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


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


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.


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.


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.


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


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


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.


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


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


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.


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.


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


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


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.


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.


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.


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.


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


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


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


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


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.


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


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


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


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.


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


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


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


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.


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


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.


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


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.


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


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


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.


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.


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.


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.


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.


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:


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

Implementación de un sistema de control distribuido ...

Documents

Transcript of Implementación de un sistema de control distribuido ...