Ronald Uriel Grosso Barrera - repositorio.unal.edu.co

Implementación de la comunicación por estándar OPC entre los equipos Allen Bradley

ubicados en el Laboratorio de Automatización Industrial y los equipos ABB ubicados en el

Laboratorio de Sistemas Inteligentes Robotizados

pertenecientes a redes LAN diferentes.

Ronald Uriel Grosso Barrera

Universidad Nacional de Colombia

Facultad Ingeniería, Departamento Ingeniería Eléctrica y Electrónica

Bogotá, Colombia

2020


ubicados en el Laboratorio de Automatización Industrial y los equipos ABB ubicados en el

Laboratorio de Sistemas Inteligentes Robotizados

pertenecientes a redes LAN diferentes.

Ronald Uriel Grosso Barrera

Trabajo de grado presentado como requisito parcial para optar al título de:

Magister en Automatización Industrial

Director:

Ing. Eduardo Barrera Gualdron

Universidad Nacional de Colombia

Facultad Ingeniería, Departamento Ingeniería Eléctrica y Electrónica

Bogotá, Colombia

2020

Dedicatoria

A mi familia por haberme ofrecido su apoyo

incondicional para alcanzar este nuevo logro

en mi vida.

Agradecimientos

A mi familia, por su apoyo, sus invaluables consejos y su acompañamiento a través de mi

proceso de formación académica.

A mi director de proyecto Ing. Eduardo Barrera Gualdron, por su orientación, sus

conocimientos y aportes para el desarrollo de este proyecto.

A la Universidad Nacional de Colombia, por brindarme los espacios y recursos para poder

alcanzar un nuevo logro en mi formación académica.

Resumen IX

Resumen

Este documento describe las características principales de un sistema de comunicaciones

implementado con el fin de permitir el intercambio de información entre los equipos de la

marca Allen Bradley, ubicados en el Laboratorio de Automatización de Máquinas

(LabAuto), y los robots de la marca ABB, ubicados en el laboratorio de Sistemas

Inteligentes Robotizados (LabSIR) de la Universidad Nacional de Colombia sede Bogotá,

utilizando las especificaciones del estándar OPC definidas por la OPC Foundation. Para

esta implementación, se realizó la adecuación y configuración de la red Ethernet existente

entre los dos laboratorios, garantizando un medio físico de transmisión de datos entre los

equipos ubicados en los mismos. Por otra parte, se desarrolló un sistema SCADA en la

plataforma Ignition 8, el cual puede ser ejecutado en un computador con sistema operativo

Windows conectado a la red de la universidad, y se puede acceder a su interfaz gráfica

desde el mismo computador o desde un dispositivo móvil con sistema operativo Android

conectado a la misma red. Además, se desarrolló la programación de una rutina Pick and

Place doble con comandos de activación externos basados en interrupciones, en uno de

los robots IRB 140 de ABB del laboratorio LabSIR. El sistema SCADA funciona como el

eje central de las comunicaciones por estándar OPC, entre los equipos de ambos

laboratorios, permitiendo que los usuarios del sistema puedan ingresar acciones de control

y recibir información sobre el estado del robot, desde las interfaces graficas del sistema, o

desde una HMI desarrollada en un Panel View Plus 1000, que se encuentra conectado a

un PAC Compac LOGIX 5370 - L30ELRM en el laboratorio LabAuto. Por último, se

desarrolló una aplicación alojada en la plataforma IBM Watson IoT, que permite a los

usuarios acceder a una interfaz gráfica con todas las funcionalidades de control y

supervisión del sistema, desde cualquier dispositivo que permita ejecutar un navegador

web y cuente con una conexión a Internet, independientemente de su ubicación.

Palabras clave: comunicaciones industriales, especificaciones OPC, sistema

SCADA, robótica Industrial, Industria 4.0, Internet de las cosas.

X Abstract

Abstract

This document describes the main characteristics of a communications system

implemented in order to allow the exchange of information between Allen Bradley brand

equipment, located in the Machine Automation Laboratory (LabAuto), and ABB brand

equipment, located in the Laboratory of Robotized Intelligent Systems (LabSIR) of the

National University of Colombia in Bogotá, using the specifications of the OPC standard

defined by the OPC Foundation. For this implementation, the adaptation and configuration

of the existing Ethernet network between the two laboratories was carried out, guaranteeing

a physical means of data transmission between the equipment located in them. On the

other hand, a SCADA system was developed on the Ignition 8 platform, which can be

executed on a computer with Windows operating system connected to the university

network, and its graphical interface can be accessed from the same computer or from a

device mobile with Android operating system connected to the same network. In addition,

the programming of a double Pick and Place routine with interrupt-based external activation

commands was developed in one of ABB IRB 140 robots from the LabSIR laboratory. The

SCADA system functions as the central axis of communications by OPC standard, between

the equipment of both laboratories, allowing the users of the system to enter control actions

and receive information on the status of the robot, from the graphical interfaces of the

system, or from an HMI developed on a Panel View Plus 1000, which is connected to a

PAC Compac LOGIX 5370 - L30ELRM in the LabAuto laboratory. Finally, an application

hosted on the IBM Watson IoT platform was developed, which allows users to access a

graphical interface with all the system's control and supervision functionalities, from any

device that allows running a web browser and has a connection to the Internet, regardless

of your location.

Keywords: industrial communications, OPC specifications, SCADA system,

Industrial robotics, Industry 4.0, Internet of things.

Lista de figuras XI

Contenido

Pág.

Resumen ........................................................................................................................ IX

Lista de figuras ............................................................................................................ XVI

Lista de tablas ............................................................................................................. XIX

Lista de Símbolos y abreviaturas ................................................................................ XX

Introducción .................................................................................................................. 23

1. Marco de referencia ............................................................................................... 28

1.1 Automatización de procesos industriales .................................................... 28

Nivel 1. ......................................................................................................... 29

Nivel 2. ......................................................................................................... 29

Nivel 3. ......................................................................................................... 29

Nivel 4. ......................................................................................................... 30

Nivel 5. ......................................................................................................... 30

La nube. ....................................................................................................... 30

1.2 Comunicaciones industriales ........................................................................ 31

1.2.1 Redes de comunicaciones industriales .............................................. 32

1.2.2.1 Modelo OSI ...................................................................................... 32

Nivel 1 - capa física. ......................................................................... 33

Nivel 2 - capa de enlace de datos. ................................................. 33

Nivel 3 - capa de red. ...................................................................... 34

Nivel 4 - Capa de transporte. ......................................................... 34

Nivel 5 - capa de sesión. ................................................................ 34

Nivel 6 - capa de presentación. ...................................................... 34

XII Implementación de la comunicación por estándar OPC entre los equipos Allen Bradley

ubicados en el Laboratorio de Automatización Industrial y los robots ABB ubicados en el LabSIR.

Nivel 7 - capa de aplicación............................................................. 34

1.2.2.2 Modelo TCP/IP ................................................................................. 34

Nivel 1 - capa física. ......................................................................... 35

Nivel 2 - capa de acceso a la red. ................................................... 35

Nivel 3 - capa de Internet. ................................................................ 35

Nivel 4 - capa de transporte. ........................................................... 36

Nivel 5 - capa de aplicación............................................................. 36

1.2.2.3 Redes de área local (LAN) ............................................................... 37

1.2.2.3.1 Topologías ............................................................................... 37

Bus. ......................................................................................... 38

Árbol. ...................................................................................... 38

Anillo. ..................................................................................... 39

Estrella. .................................................................................. 39

1.2.2.3.2 Medios de transmisión guiados UTP y STP........................... 40

Cable de par trenzado ........................................................... 41

1.2.2.3.3 El estándar IEEE 802.3 y Ethernet .......................................... 42

1.2.2.3.4 Dispositivos para la implementación de redes Ethernet ...... 44

Repetidores ........................................................................... 44

Hubs ....................................................................................... 45

Routers .................................................................................. 45

Puertas de enlace de transporte y de aplicación (Gateway)

..................................................................................................... 45

1.2.2.3.5 Direccionamiento IP ................................................................ 45

1.2.2.3.6 Cliente/servidor IP (sockets) ................................................... 47

1.3 Sistemas SCADA ............................................................................................ 47

1.3.1 Objetivos de un sistema SCADA ............................................................. 48

1.3.2 Arquitectura de un sistema SCADA ........................................................ 48

1.3.3 Hardware de un sistema SCADA ............................................................. 49

Interfaz Hombre Maquina (HMI). ........................................................... 49

Unidad central (MTU, Master Terminal Unit). ....................................... 49

Unidad remota (RTU, Master Terminal Unit). ....................................... 50

Sistemas remotos. ................................................................................. 50

Sistema de comunicación. .................................................................... 50

1.3.4 Comunicación entre aplicaciones por OPC ............................................. 50

XIII

1.3.4.1 Definición de OPC ........................................................................... 51

1.3.4.2 Tecnología OPC .............................................................................. 51

1.3.4.3 Arquitectura cliente/servidor OPC ................................................. 52

Servidor OPC. ................................................................................... 52

Cliente OPC. ..................................................................................... 52

1.3.4.4 Especificaciones OPC Classic y OPC UA ..................................... 53

OPC DA (Data Access) ..................................................................... 53

OPC HDA (Historical Data Access). ................................................ 53

OPC AE (Alarms and Events). ......................................................... 54

1.4 Internet de las cosas y MQTT ........................................................................ 54

1.4.1 MQTT (Meessage Queue Telemetry Transport) ....................................... 56

Modelo Publicación/Suscripción en MQTT ......................................... 56

Arquitectura del protocolo MQTT ........................................................ 57

Calidad del servicio (QoS) .................................................................... 58

Tópicos .................................................................................................. 59

1.5 Contextualización del proyecto ..................................................................... 60

2. Programación de los robots industriales ............................................................. 63

2.1 El robot IRB 140 y el controlador IRC 5 de ABB .......................................... 63

2.1.2 Espacio de trabajo del robot IRB 140 .................................................. 64

2.1.3 Comunicaciones del controlador IRC 5 .............................................. 64

2.1.4 El FlexPendant ...................................................................................... 65

2.1.5 RobotStudio .......................................................................................... 66

2.1.6 Lenguaje y entorno RAPID ................................................................... 66

2.1.6.1 Estructura de los programas RAPID ..................................................... 66

2.2 Instrucciones de movimiento ........................................................................ 67

2.3 Programación de las rutinas de movimiento ............................................... 68

2.3.1 Rutina principal (main) ......................................................................... 70

2.3.2 Rutina Tomar Objeto ............................................................................ 71

2.3.3 Rutina Dejar Izquierda .......................................................................... 72

2.3.4 Rutina Dejar Derecha ........................................................................... 73

2.3.5 Interrupciones externas Detener, Pausar y Reset .............................. 74

XI

V



3. Sistema SCADA e implementación de las comunicaciones por estándar OPC 75

3.1 Softwares de desarrollo utilizados ................................................................ 75

3.1.1 Software SCADA Ignition 8 .................................................................. 75

3.1.2 Softwares de Rockwell Automation .................................................... 76

Studio 5000 Logix Designer. ................................................................. 76

Factory Talk View Studio Machine Edition. ......................................... 76

SoftLogix 5800. ...................................................................................... 77

3.1.3 IRC5 OPC Server .................................................................................. 77

3.2 Arquitectura de red implementada ................................................................ 78

3.3 Arquitectura de comunicaciones implementada .......................................... 79

Servidores OPC ........................................................................................... 79

Cliente OPC. ................................................................................................ 79

3.3.1 Flujo de datos del sistema implementado .......................................... 80

3.3.1.1 Flujo de datos para usuarios del sistema SCADA ........................ 80

3.3.1.2 Flujo de datos para usuarios del HMI............................................. 82

3.4 Interfaces graficas del sistema ...................................................................... 85

3.4.1 Interfaz gráfica para PC y dispositivos Android ................................ 85

Interfaz gráfica general .......................................................................... 85

Interfaces gráficas independientes virtual y real ................................ 86

Visualización de históricos del sistema ............................................... 88

Gestión de alarmas del sistema............................................................ 89

3.4.2 Interfaz gráfica HMI .............................................................................. 89

4. Integración con plataforma IoT ............................................................................. 92

4.1 Herramientas de software utilizadas ............................................................. 92

4.1.1 IBM Watson IoT Plataform ................................................................... 92

4.1.1.1 Internet of Things Plataform ......................................................... 93

4.1.2 EMQX Broker ........................................................................................ 93

4.1.3 Módulos MQTT Engine y MQTT Distributor ........................................ 94

4.1.4 Node.js .................................................................................................. 95

XV

4.2 Arquitectura de comunicaciones implementada ......................................... 96

4.2.1 Flujo de datos para usuarios web ....................................................... 96

1. Comunicación entre la plataforma IoT de IBM y el Broker MQTT EMQX ..................................................................................................................... 97

2. Comunicación entre el Broker MQTT EMQX y los módulos MQTT .... 99

3. Comunicación entre el servidor OPC IRC5 y el controlador IRC5 ....100

4. Comunicación entre el controlador IRC5 y el servidor OPC IRC5 ....100

5. Comunicación entre los módulos MQTT y el Broker EMQX..............100

6. Comunicación entre el Broker EMQX y la plataforma IoT de IBM ....100

4.3 Interfaz gráfica IoT ........................................................................................101

HMI general ................................................................................................101

HMI VIRTUAL ROBOT y HMI REAL ROBOT .............................................102

5. Conclusiones y recomendaciones ...................................................................... 105

5.1 Conclusiones .................................................................................................105

5.2 Recomendaciones .........................................................................................107

Bibliografía .................................................................................................................. 109

Lista de figuras XVI

Lista de figuras

Pág.

Figura 1-1: Pirámide de la automatización (modelo CIM). .............................................. 29

Figura 1-2: Modelo de referencia OSI. ........................................................................... 33

Figura 1-3: Modelo TCP/IP comparado con el modelo OSI. ........................................... 35

Figura 1-4: Modelo TCP/IP con algunos de sus protocolos más comunes. .................... 37

Figura 1-5: Topología de comunicación en bus. ............................................................. 38

Figura 1-6: Topología de comunicación en árbol. ........................................................... 38

Figura 1-7: Topología de comunicación en anillo. .......................................................... 39

Figura 1-8: Topología de comunicación en estrella. ....................................................... 39

Figura 1-9: Cable UTP cat 5 con cuatro pares trenzados. .............................................. 41

Figura 1-10: Formatos de trama. (a) Ethernet (DIX) (b) IEEE 802.3. ............................ 42

Figura 1-11: (a) Capas TCP/IP de los dispositivos. (b) Tramas y encabezados. ............ 44

Figura 1-12: Direcciones IP. (a) Notación binaria. (b) Notación punto. ........................... 46

Figura 1-13: Clases de direcciones IP. ........................................................................... 46

Figura 1-14: División de la dirección IP en parte de subred y parte de dispositivo. ........ 46

Figura 1-15: Arquitectura básica de un sistema para supervisión y mando. ................... 49

Figura 1-16: Arquitectura cliente/servidor OPC. ............................................................. 52

Figura 1-17: Modelo de referencia IoT según UIT. ......................................................... 55

Figura 1-18: Ejemplo del modelo Pub/Sub MQTT para sensores Iot. ............................. 57

Figura 1-19: Publicación de mensaje con nivel de servicio QoS 0. ................................. 58



XVII

Figura 1-22: Ejemplo de un topico MQTT de 3 niveles. .................................................. 59

Figura 1-23: Laboratorio LabSIR, Universidad Nacional de Colombia. ........................... 60

Figura 1-24: Estación de trabajo y HMI Allen Bradley. LabAuto UNAL. .......................... 61

Figura 2-1: (a) Robot IRB 140 [35] (b) Controlador IRC 5. ........................................... 63

Figura 2-2: Posiciones extremas Robot IRB 140. ........................................................... 64

Figura 2-3: Partes del FlexPendant. ............................................................................... 65

Figura 2-4: Estructura de la memoria de programas en RAPID. ..................................... 67

Figura 2-5: Orden de ejecución de la secuencia Pick & Place doble programada. ......... 68

Figura 2-6: Diagrama de flujo de la rutina main. ............................................................. 70

Figura 2-7: Diagrama de flujo de la rutina TomarObjeto. ................................................ 71

Figura 2-8: Diagrama de flujo de la rutina DejarIzquierda ............................................... 72

Figura 2-9: Diagrama de flujo de la rutina DejarDerecha ................................................ 73

Figura 2-10: Diagramas de flujo de las rutinas TRAP ..................................................... 74

Figura 3-1: Arquitectura de red entre los laboratorios LabAuto y LabSIR. ...................... 78

Figura 3-2: Arquitectura de comunicaciones del sistema implementado. ........................ 79

Figura 3-3: Flujo de datos entre el sistema SCADA implementado y los robots ABB...... 80

Figura 3-4: Flujo de datos entre la HMI implementada y los robots ABB ........................ 82

Figura 3-5: Interfaz gráfica general del sistema SCADA. ................................................ 85

Figura 3-6: Interfaz gráfica para robot virtual. ................................................................. 87

Figura 3-7: Visualización de históricos sobre el uso del robot. ........................................ 88

Figura 3-8: Pantalla de alarmas del sistema SCADA. ..................................................... 89

Figura 3-9: Pantalla de inicio, HMI LabAuto. ................................................................... 90

Figura 3-10: Pantalla general, HMI LabAuto. .................................................................. 90

Figura 3-11: Pantalla para el robot virtual, HMI LabAuto. ............................................... 91

Figura 4-1: Arquitectura de comunicaciones IBM Watson IoT Plataform. ....................... 93

Figura 4-2: Arquitectura de comunicaciones IoT implementada. .................................... 96

Figura 4-3: Flujo de datos para usuarios de interfaz gráfica web. ................................... 97

Figura 4-4: Mensaje CONNECT requerido por EMQX Broker. ....................................... 98

Figura 4-5: Mensaje CONNACK para confirmación de conexión con el Broker MQTT. .. 98

X

VII

I



Figura 4-6: Formato de publicación de la interfaz web. .................................................. 98

Figura 4-7: Formato de mensaje requerido para publicación en MQTT Engine. ............. 99

Figura 4-8: Interfaz gráfica desarrollada en plataforma IoT de IBM. ............................. 101

Figura 4-9: Bloque HMI General. Interfaz gráfica web. ................................................. 101

Figura 4-10: Bloques de visualización de históricos. Interfaz gráfica web. ................... 103

Lista de figuras XIX

Lista de tablas

Pág.

Tabla 1-1: Algunos números de puerto de uso común. ................................................... 47

Tabla 2-1: Limites de movimiento de ejes robot IRB 140. ............................................... 64

Tabla 2-2: Elementos del FlexPendant. .......................................................................... 65

Tabla 2-3: Instrucciones de posicionamiento en lenguaje RAPID. .................................. 67

Tabla 2-4: Argumentos de una instrucción de posicionamiento RAPID. .......................... 68

Tabla 2-5: Variables utilizadas en la programación de la secuencia Pick & Place doble. 69

Tabla 2-6: Instrucciones de movimiento para la rutina TomarObjeto. .............................. 71

Tabla 2-7: Instrucciones de movimiento para la rutina DejarIzquierda. ........................... 72

Tabla 2-8: Instrucciones de movimiento para la rutina DejarDerecha. ............................ 73

Tabla 3-1: Direcciones IP de los equipos mostrados en la Figura 3-1. ............................ 78

Tabla 3-2: Elementos de mando y monitorización interfaz gráfica general. ..................... 86

Tabla 3-3: Elementos de mando y monitorización interfaz gráfica del robot virtual. ........ 87

Tabla 4-1: Elementos de mando y monitorización de la interfaz gráfica web. ............... 102

Tabla 4-2: Elementos de visualización de históricos para la interfaz gráfica web. ......... 103

Lista de figuras XX

Lista de Símbolos y abreviaturas

Abreviaturas Abreviatura Término

LabAuto Laboratorio de Automatización de Maquinas

LabSIR Laboratorio de Sistemas Inteligentes Robotizados

HMI Interfaz Hombre Maquina

PAC Programmable Automation Controller

OPC Ole for Proces Control

CIM Computer Integrated Manufacturing

MQTT Message Queue Telemetry Transport

SCADA Supervisión Control y Adquisición de Datos

TCP/IP Transport Control Protocol/Internet Protocol

OSI Open System Interconnection

LAN Local Area Networks

I/O Entradas/Salidas

Pub/Sub Publicador/Suscriptor

RAPID Robotics Application Programming Interactive Dialogue

TCP Tool Center Point

IoT Internet of Things

IIoT Industrial IoT

MAC Media Access Control

COM Component Object Model

XXI

DCOM Distributed COM

PC Personal Computer

LLC Logical Link Control

OPC DA OPC Data Acces

OPC UA OPC Unified Architecture

Introducción

Los dispositivos desarrollados para aplicaciones en el entorno industrial, han evolucionado

a medida que las necesidades de los procesos productivos cambian. Como resultado, en

la actualidad se puede encontrar una diversa gama de tecnologías enfocadas a la

automatización de procesos industriales, desarrolladas por diferentes fabricantes. Esta

diversidad permite a integradores cubrir las necesidades tecnológicas en los procesos

productivos, y al mismo tiempo minimizar costos de implementación, gracias a la amplia

oferta comercial disponible [1].

Aun cuando la variedad de tecnologías y dispositivos disponibles a nivel comercial ofrecen

ventajas en la implementación de sistemas industriales automatizados, también pueden

generar dificultades para interconectar dichos dispositivos de tal forma que funcionen como

un conjunto, y permitan interrelacionar las plantas industriales en todos sus niveles. De

forma genérica, el conjunto de métodos, sistemas, medios físicos y herramientas que

permiten el intercambio de información entre los dispositivos que conforman una planta

industrial, se conocen como Comunicaciones Industriales, y son el pilar fundamental para

lograr una cohesión en el funcionamiento de los procesos modernos [1].

El progreso histórico de la automatización se ha caracterizado por ser un proceso más

evolutivo que revolucionario. Los nuevos desarrollos suelen estar basados en la evolución

de tecnologías anteriores, que han permitido obtener resultados satisfactorios en su

implementación [2]. Por supuesto, las Comunicaciones Industriales también han ido

evolucionando, para adaptarse a las demandas tecnológicas de los nuevos desarrollos. En

este sentido se pueden distinguir dos componentes fundamentales en los que se han

enfocado los desarrollos que se usan actualmente; las redes de comunicaciones

industriales y los buses de campo.

24 Implementación de la comunicación por estándar OPC entre los equipos Allen Bradley


En cuanto a las redes de comunicación industrial, las redes LAN (Local Área Network)

industriales, usualmente tienen el más alto nivel de jerarquía en el modelo CIM descrito en

el capítulo 1 de este documento [3]. Los estándares más ampliamente utilizados son:

MAP (Manufacturing Automation Protocol): fue diseñado específicamente para ser

usado en el ámbito industrial y permite un medio de transmisión determinista.

Inicialmente fue promovido por General Motors y posteriormente el IEEE lo

normalizo. No fue diseñado para funcionar a nivel de bus de campo, sin embargo,

permite establecer pasarelas para conectarse a dichos buses por medio de

terminales.

Ethernet Industrial: Ethernet fue desarrollado por Xerox Corporation y fue registrado

en conjunto con Digital Equipment Corporation e Intel Corporation. Es un estándar

de red que ha evolucionado muy rápidamente y fue la base para el estándar IEEE

802.3. Aunque Ethernet fue desarrollado sobre una topología bus serie con

mecanismo CSMA/CD para el MAC (Media Access Control), en la actualidad dicho

mecanismo ha sido prácticamente desplazado por técnicas de conmutación

(Ethernet Conmutada), lo que ha permitido a este estándar de red incorporarse de

forma masiva en el entorno industrial, como un medio de transmisión confiable,

veloz y prácticamente determinista [3].

Por otra parte, el objetivo de los buses de campo es permitir la integración los dispositivos

de campo, con los equipos industriales de control. Existe una variada oferta comercial de

buses de campo como; AS-I, DeviceNet, Modbus, Profibus, Fundation Fieldbus, entre

otros, cada uno con diferentes prestaciones y velocidad de comunicación [3]. Sin embargo,

es importante resaltar la gran acogida que Ethernet IP ha tenido en el sector industrial,

incluso posicionándose por delante de los Buses de Campo tradicionales en cuanto a la

cantidad de nuevos dispositivos de campo instalados [4]. Esto de acuerdo al estudio que

cada año HMS Industrial Networks realiza teniendo como objetivo definir el

comportamiento comercial de las plantas que usan sistemas de comunicación. Según

dicho estudio, Industrial Ethernet cubrió el 64% de los nuevos nodos instalados a nivel

industrial en 2020, en comparación con el 59% que revelo el estudio para 2019 y el 52%

que se tenía en 2018. Por otra parte, los buses de campo abarcaron un 30% en 2020 (35%

Capítulo 1 25

en 2019). EtherNet / IP se convirtió en la red con el mayor número de instalaciones con un

17%, aunque PROFINET se acerca con un 15% [4].

Otra característica fundamental de las tecnologías desarrolladas en torno a la

automatización industrial, es la capacidad de realizar adquisición, monitorización y control

de datos relevantes en los procesos industriales. En un proceso automatizado pueden

existir múltiples elementos de control y monitorización, y cada fabricante crea un driver que

permite establecer comunicación entre su producto y otro equipo específico, generalmente

haciendo el manejo de datos en forma inaccesible para el usuario. La interfaz desarrollada

por el fabricante hace la conversión de los datos del dispositivo en datos que el sistema de

monitorización y control pueda usar [5].

Uno de los problemas más difíciles de solucionar en el entorno industrial es la integración

entre aplicaciones. Varios sistemas de control y monitorización, cada uno con métodos de

comunicación definidos en forma distinta, deben funcionar en armonía para garantizar un

acceso rápido y seguro a la información [5]. Entre los desarrollos abocados a solucionar

esta problemática se encuentran; Activex que no es más que una librería de enlaces

dinámicos (DLL), DDE (Dynamic Data Exchange) creada para aplicaciones basadas en

Windows y OPC (OLE for Proces Control) que, gracias a su versatilidad se tomó como

base para los desarrollos realizados en el proyecto descrito en este documento.

Por último, es importante resaltar la relevancia que ha venido tomando en la

automatización industrial la denominada industria 4.0, y en especial uno de sus pilares; IoT

(Internet of Things). De acuerdo con un estudio realizado por la firma tecnológica CISCO,

para el año 2010 se dio el punto de inflexión en el que se tenían más “cosas” que personas

conectadas a internet [6], [7]. A finales de 2019, la firma de análisis IDC reveló que, de

acuerdo con análisis realizados sobre las tendencias del mercado de tecnologías aplicadas

a la industria, se estima que habrá 41,600 millones de dispositivos IoT conectados

(Incluyendo máquinas, sensores y cámaras) o “cosas”, generando 79.4 Zettabytes (ZB) de

datos en 2025. Las previsiones de IDC en gastos totales mundiales en IoT, es que se

alcanzaran los $745 mil millones de dólares en 2019, superando la barrera de $1 trillón de

dólares en 2022. Mientras que los países que verán el crecimiento más rápido (en términos

de su Tasa Anual Compuesta de Crecimiento / CAGR) del gasto en IoT para 2022 se



encuentran en América Latina: México con 28.3%, Colombia con 24.9% y Chile con un

23.3% [8].

Es de vital importancia para los profesionales en Automatización Industrial, contar con las

competencias necesarias para implementar desarrollos que permitan satisfacer las

necesidades tecnológicas de los procesos industriales en constante evolución. El objetivo

del proyecto descrito en este documento, es implementar un sistema de comunicaciones

industriales, que permita la interacción entre los dispositivos de supervisión y control de la

marca Allen Bradley, y los robots industriales IRB 140 de la marca ABB, disponibles en los

laboratorios LabAuto y LabSIR de la Universidad Nacional de Colombia con sede en

Bogotá, incluyendo tecnologías IIoT para la integración del sistema con una interfaz de

control y supervisión alojada en cloud.

El Laboratorio de Sistemas Inteligentes Robotizados (LabSIR) de la Universidad Nacional

de Colombia sede Bogotá, cuenta con 2 robots IRB 140 de ABB. Actualmente el control y

la programación de los robots es realizado de forma local desde controladores IRC5 ABB,

ya sea por medio del Flex Pendant (Control manual) o por medio de software externo

(Robot Studio). Por otra parte, el laboratorio de Automatización de Maquinas de la

universidad (LabAuto) cuenta con 5 PAC’s modulares Compac LOGIX 5370 L3 – 1769 –

L30ELRM de la marca Allen Bradley. También se cuenta con 2 pantallas HMI View Plus

1000 de Allen Bradley. Cada uno de los equipos descritos, fue utilizado para cumplir con

los objetivos propuestos en este proyecto. A continuación, se hace una descripción general

de la metodología desarrollada:

En primer lugar, se realizó la adecuación y configuración de la red Ethernet, para lograr la

integración de los equipos ubicados en LabSIR y LabAuto. Posteriormente, se hizo una

solicitud formal a la universidad pidiendo la asignación de direcciones IP para los robots

IRB 140 ABB y una vez fueron asignadas, se configuraron dichas direcciones en los robots

vía Flex Pendant. Los detalles de la arquitectura de red implementada se muestran en

secciones posteriores de este documento.

Una vez configurada la red de comunicaciones entre los dos laboratorios, se procedió a

desarrollar la programación de los robots. Dicha programación se realizó y probó

inicialmente en el software Robot Studio de ABB, y posteriormente se implementó en uno

Capítulo 1 27

de los robots IRB 140 de ABB disponibles en LabSIR. En forma resumida, la rutina de

movimiento programada consistió en una secuencia Pick & Place doble, con opciones de

selección para el numero de secuencias a ejecutar y opciones de interacción por comandos

externos basados en interrupciones.

Con el objetivo de lograr establecer comunicación entre los robots ABB y los equipos Allen

Bradley ubicados en LabSIR y LabAuto respectivamente, se creó un servidor OPC DA y

un servidor OPC UA haciendo uso del software Ignition de Inductive Automation en su

versión 8.0.16. Ignition cuenta con los drivers necesarios para hacer la conexión de los

equipos Allen Bradley en versiones Compac LOGIX y Control LOGIX con el servidor OPC

UA creado, sin embargo, para el caso de los robots IRB 140 ABB fue necesario crear un

servidor OPC adicional con ayuda del software ABB IRC 5 OPC.

Por otra parte, se desarrolló la programación para un PAC Compac LOGIX 5370 L3 – 1769

– L30ELRM de la marca Allen Bradley ubicado en LabAuto por medio del software STUDIO

5000 de Rockwel Automation, que permite el envío de comandos hacia el servidor OPC

UA de Ignition. Adicionalmente se desarrolló la programación de una interfaz gráfica

(mímico) en un Panel View Plus 1000 de Allen Bradley ubicado en LabAuto, por medio del

software Factory Talk View Studio de Rockwell Automation, para la interacción de los

usuarios con un robot IRB 140 ABB ubicado en LabSIR, o con un robot IRB 140 ABB virtual

(simulado en el software Robot Studio) funcionando en un PC conectado a la red de la

universidad.

De igual forma, se desarrolló una interfaz gráfica por medio del Designer de Ignition, que

permite la interacción de los usuarios con los robots (real y virtual). Dicha interfaz puede

ser accedida desde un PC con sistema operativo Windows, o desde un Smartphone con

sistema operativo Android, siempre y cuando se encuentren conectados a la red de la

universidad (ya sea por cableado o por Wireless).

Por último, con el fin de integrar la aplicación desarrollada con las tendencias de la industria

4.0, se realizó la creación de un servidor MQTT por medio del software Ignition.

Posteriormente, haciendo uso de los servicios de IBM Cloud, se desarrolló una aplicación

IoT que permite al usuario acceder desde Internet (en cualquier ubicación) a una interfaz

gráfica para la interacción con los robots (real y virtual).



1. Marco de referencia

En este capítulo se presentará un resumen de los principales conceptos alrededor de la

automatización de procesos y las comunicaciones industriales, haciendo énfasis en las

tecnologías que fueron utilizadas en la implementación de este proyecto. Por otra parte, al

final de este capítulo se hace una descripción detallada de las condiciones locativas y

tecnológicas existentes en los laboratorios de Automatización y Robótica de la Universidad

Nacional de Colombia con sede en Bogotá, con el fin de ofrecer una visión general del

contexto en el que se desarrolló este proyecto.

1.1 Automatización de procesos industriales

En un contexto general, la automatización hace referencia a los medios por los cuales un

proceso o procedimiento se puede desarrollar de forma independiente a la intervención

humana [9], [10]. En el entorno industrial la automatización involucra a máquinas,

herramientas, dispositivos y sistemas desarrollados e implementados por humanos para

realizar actividades inherentes a los procesos, de forma eficiente y sin necesidad de

intervención humana [9].

Generalmente la automatización industrial es asociada únicamente con los dispositivos de

campo y de monitorización existentes en las fábricas, sin embargo, a medida que las

tecnologías han evolucionado, la automatización ha permitido la integración e interrelación

de los distintos niveles presentes en los procesos productivos [10]. La llamada “pirámide

de la automatización” o modelo CIM (Computer-Integrated Manufacturing), es un modelo

definido por NBS (National Bureau of Standars) que tiene como objetivo la conversión de

decisiones de nivel empresarial en operaciones de control a bajo nivel [12]. En la Figura

1-1 se muestra un esquema propuesto por [11], que se basa en el modelo de NBS. A

continuación, se hace una descripción general de cada uno de los niveles del modelo.

Capítulo 1 29

Figura 1-1: Pirámide de la automatización (modelo CIM) [11].

Nivel 1: hace referencia a todos los sensores, actuadores y elementos de hardware

ubicados en campo (Field Devices). En este nivel se hace la adquisición de datos por

medio de sensores que miden las variables del proceso y se envían hacia el nivel 2,

además, se reciben las señales de control enviadas desde el nivel 2 y se ejecutan las

acciones de control por medio de los actuadores.

Nivel 2: en este nivel se ubican los dispositivos de control como PLCs, sistemas de

control numérico, tarjetas de control, ordenadores para control industrial, entre otros.

En el nivel 2 se reciben los datos de proceso medidos en el nivel 1 y se envían señales

de control hacia dicho nivel. Por otra parte, se reciben consignas y configuraciones por

parte del nivel 3 y se envían datos del proceso hacia el mismo.

Nivel 3: es el nivel de supervisión y adquisición de datos. De este nivel hacen parte los

sistemas SCADA (Supervisión Control y Adquisición de Datos) y las HMI (Interfaces

Hombre Maquina). En este nivel se realizan múltiples tareas como adquisición y

tratamiento de datos, monitorización y sincronización de células, gestión de alarmas,

entre otras. El nivel 3 emite consignas y ordenes de ejecución al nivel 2 y recibe

información de estado del mismo. Por otra parte, este nivel recibe programas de

producción, calidad, etc. por parte del nivel 4 y envía información de estado del

proceso, ordenes de trabajo, etc. al mismo.



Nivel 4: es el nivel MES (Manufacturing Execution System). En este nivel se realizan

tareas como la programación de la producción, gestión de materiales y compras,

control de inventarios, gestión de recursos de fabricación, entre otras. Este nivel envía

ordenes de producción hacia el nivel 3 y recibe realimentación del estado de las

mismas por parte de dicho nivel, además, recibe desde el nivel 5 información sobre

pedidos, ingeniería de producto y de proceso, etc. y envía hacia el nivel 5 información

del estado de producción, costos de producción y de operación, cumplimiento de

metas, etc.

Nivel 5: es el nivel ERP (Enterprise Resource Planning). En este nivel se realizan

tareas como la gestión comercial, planificación financiera y administrativa, gestión de

tecnología, ingeniería de producto y de proceso, y demás actividades corporativas. El

nivel 5 envía información referente a pedidos, metas de producción, ingeniería, etc. y

recibe por parte del nivel 4 información sobre cumplimiento de metas de producción,

costos de operación, cambios de ingeniería, etc.

La nube: el modelo de pirámide de la automatización definido por NBS (National

Bureau of Standars) contempla los cinco niveles descritos anteriormente. Sin embargo,

es importante resaltar que en la actualidad las tendencias de la denominada industria

4.0, están dirigiendo los procesos productivos hacia una transformación digital, en la

que los datos de los cinco niveles del modelo piramidal pueden ser alojados y

analizados desde servidores o aplicaciones web, con el fin de generar información que

permita utilizar los recursos empresariales de forma más eficiente. Además,

permitiendo realizar tareas de control y supervisión desde la web [11].

El enfoque integrador del modelo piramidal CIM, requiere la interacción de los dispositivos

y recursos pertenecientes a cada nivel y entre los distintos niveles del proceso productivo,

por lo tanto, es de vital importancia generar un medio de comunicación efectiva que permita

realizar el intercambio de información, cumpliendo las restricciones requeridas en cada

nivel para los tiempos de respuesta [12]. Es en este punto donde las comunicaciones

industriales desempeñan un papel fundamental.

Capítulo 1 31

1.2 Comunicaciones industriales

Las comunicaciones industriales pueden definirse como el conjunto de métodos, sistemas,

medios físicos y herramientas que permiten establecer el flujo de información entre los

subsistemas, tanto del mismo nivel, como de niveles distintos en el modelo piramidal CIM

[1], [13].

Tal como lo menciona [11], la red de comunicación para el intercambio de información

entre los equipos pertenecientes a los niveles 1 y 2 del modelo CIM, debe garantizar

tiempos de respuesta en el orden de microsegundos o milisegundos. Por otra parte, [5]

explica la importancia de hacer la selección de la tecnología para implementar dicha red

de comunicación, teniendo en cuenta los siguientes aspectos:

Costos de instalación bajos, acordes a las necesidades tecnológicas del proceso.

Flexibilidad para el tendido del cableado (cualquier topología).

Comunicaciones robustas (inmune a interferencias).

Protocolo de comunicación que garantice respuestas en tiempo real (rápido y

determinístico).

Tecnología acorde a la cantidad y complejidad de la información transmitida entre

dispositivos.

Protección IP elevada (IP65 como mínimo).

Resistencia a amplios márgenes de temperatura (-25°C a +85°C).

Proceso de instalación simple, evitando la necesidad de procedimientos laboriosos y

de costo elevado.

Interfaces adaptados a cada necesidad.

Por otra parte, el intercambio de información entre los niveles 2,3,4, y 5 del modelo CIM

requiere tiempos de respuesta del orden de milisegundos (incluso segundos, dependiendo

de la aplicación) [11]. En dichos niveles, son las denominadas redes de comunicaciones

industriales las que usualmente se usan como mecanismo para el intercambio de

información.



1.2.1 Redes de comunicaciones industriales

Son dos los objetivos principales que las comunicaciones industriales deben cumplir [16]:

El primero es el intercambio de información entre los dispositivos de control y los

dispositivos conectados a la maquina o proceso (dispositivos de campo), con el fin de

integrar las señales de proceso provistas por los dispositivos de campo, con la

ejecución en tiempo real de los algoritmos programados en las estaciones de control.

El segundo es el intercambio de datos pedidos o enviados a la estación de control

desde las estaciones de nivel superior en el proceso (nivel de supervisión, nivel de

operación y planificación de la producción y nivel de gestión empresarial). El objetivo

es permitir la parametrización, configuración y programación de todas las estaciones

pertenecientes a la red de comunicación, así como el telemando o mando remoto

desde otras redes o centros de operación.

La variada oferta comercial de tecnologías ofrecidas por distintos fabricantes, ha

ocasionado que el desarrollo de software de comunicaciones de propósito específico tenga

un costo demasiado elevado para ser aceptable. Por esta razón, los fabricantes se han

visto obligados a adoptar e implementar convenciones comunes o estándares, para lograr

ocupar una sección del mercado [17]. En este sentido existen dos arquitecturas que se han

convertido en la base de los desarrollos en torno a las comunicaciones industriales; el

modelo de referencia OSI (Open System Interconnection) y el grupo de protocolos TCP/IP

(Transport Control Protocol/Internet Protocol), siendo este último el estándar de facto.

1.2.2.1 Modelo OSI

El modelo OSI (Open Systems Interconnection), es un modelo basado en la propuesta

desarrollada por la Organización Internacional de Normas (ISO) con el fin de avanzar hacia

la estandarización internacional de los protocolos que se ocupan de la conexión de

sistemas abiertos; es decir, sistemas que permiten establecer mecanismos de

comunicación con otros sistemas [18].

El modelo OSI mostrado en la Figura 1-2, está definido por siete capas. A continuación, se

hace una descripción breve de cada una de ellas.

Capítulo 1 33

Figura 1-2: Modelo de referencia OSI [17].

Nivel 1 - capa física: hace referencia a las especificaciones mecánicas, eléctricas, de

procedimiento y funcionales del medio físico de transmisión de datos y de las interfaces

con las que se logra la conexión física de los dispositivos a dicho medio de transmisión

(tarjetas de red) [17].

Nivel 2 - capa de enlace de datos: define el agrupamiento o empaquetamiento de

los datos con una longitud adecuada y agrega los mecanismos requeridos para

controlar la transmisión de información [17], [18].

La capa de enlace de datos a su vez puede dividirse en dos subcapas funcionales [5]:

- LLC (Logical Link Control): hace referencia al control sobre la línea para la

transmisión de datos. Define toda la información necesaria para establecer un

enlace entre dos estaciones.

- MAC (Media Access Control): hace referencia al método específico para

conectarse a la línea de transmisión. El método MAC puede definirse a través de

dos sistemas de acceso al medio; CSMA (Carrier Sense Multiple Access) en el que

cualquier estación puede emitir si el bus no está ocupado y Token Passing que

consiste en definir un permiso de emisión que se va pasando entre estaciones.

Estación 1Capa

7 Aplicación

Interfaz

6 Presentación

Sesión5

Transporte4

Red3

Enlace de datos2

Física1

Estación 2

Aplicación

Presentación

Sesión

Transporte

Red

Enlace de datos

Física

Nombre de la unidad

APDU

PPDU

SPDU

TPDU

Paquete

Trama

Bit

intercambiada

Enrutador

Protocolo de transporte

Protocolo de sesión

Protocolo de presentación

Protocolo de aplicación



Nivel 3 - capa de red: esta capa se encarga del direccionamiento de los paquetes de

datos haciendo uso de técnicas de encaminamiento (routing) y mediante el control del

flujo de datos [17].

Nivel 4 - Capa de transporte: recibe datos de la capa de sesión, de ser necesario

separarlos en unidades de menor tamaño de tal forma que sean manejables para el

sistema de transmisión, para luego enviarlos a la capa de red [18].

Nivel 5 - capa de sesión: se encarga de establecer y administrar la transmisión de

datos entre usuarios de máquinas distintas en la red [5]. Las funciones que cumple esta

capa son; Control de dialogo, manejo de tokens y sincronización.

Nivel 6 - capa de presentación: hace énfasis en la sintaxis de los paquetes

transmitidos. Permite realizar la conversión de datos a una representación común, que

sea reconocible por todas las maquinas conectadas a la red [5], [17].

Nivel 7 - capa de aplicación: administra y proporciona los mecanismos para que el

usuario acceda a las funciones de comunicación [5]. Algunos de los protocolos

pertenecientes a esta capa son [17], [18]:

- Protocolo de transferencia de hipertexto o HTTP (Hypertext Transfer Protocol).

- Protocolo de transferencia de ficheros o FTP (File Transfer Protocol).

- Protocolo MAP (Manufacturing Automation Protocol).

- Protocolo simple de transferencia de correo electrónico o SMTP (Simple Mail

Transfer Protocol).

1.2.2.2 Modelo TCP/IP

En un comienzo el modelo TCP/IP fue utilizado por el DoD (Departamento de Defensa de

Estados Unidos) como base para el desarrollo de una red de investigación conocida como

APRANET. Más adelante esta red fue liberada con el fin de permitir a distintas redes

alrededor del mundo conectarse entre sí, sentando las bases de lo que hoy se conoce

como Internet [18]. El modelo TCP/IP mostrado en la Figura 1-3, es el estándar de facto y

en la actualidad está mucho más difundido que el modelo OSI [3]. Está estructurado por

las 5 capas descritas a continuación.

Capítulo 1 35

Figura 1-3: Modelo TCP/IP comparado con el modelo OSI [17].

Nivel 1 - capa física: especifica la interfaz física entre las máquinas y el medio de

transmisión [17].

Nivel 2 - capa de acceso a la red: se ocupa del agrupamiento y empaquetamiento de

los datos (equivalente a la capa de enlace del modelo OSI), así como del intercambio

de información entre la maquina (terminal, estación de trabajo, etc.) y la red en la que

se encuentra conectada [17].

Nivel 3 - capa de Internet: la capa de Internet acepta y transfiere paquetes dentro de

la red o entre redes [17]. Este nivel maneja tres protocolos fundamentales [19].

- Protocolo IP: se encarga de asignar las direcciones IP, establecer y administrarlas

comunicaciones host a host, definir datagramas (agrupamiento de paquetes) y

realiza fragmentación de paquetes de longitud extensa (la reconstrucción de

paquetes está a cargo del receptor).

- Protocolo ARP: presta servicios al protocolo IP ayudando a enviar los datagramas

a un receptor específico. Esto lo hace por medio de la asignación de direcciones

Ethernet (de 48 bits) a las direcciones IP que ya están definidas (de 32 bits).

- Protocolo ICMP: hace la detección y registro de errores que se presentan en la

red. Estos errores están relacionados con; paquetes soltados (paquetes demasiado

rápidos para poder procesarlos), fallos de conectividad y re direccionamiento.



Nivel 4 - capa de transporte: esta capa establece comunicación de extremo a

extremo. Asegura que los paquetes lleguen al receptor en el orden correcto y sin

errores, haciendo confirmaciones de la llegada y retransmitiendo los paquetes que no

lleguen [19]. Esta capa maneja dos protocolos fundamentales [18], [19].

- Protocolo TCP (Transmission Control Protocol): es un protocolo orientado a la

conexión. Permite la comunicación entre aplicaciones como si estuvieran

conectadas por un medio físico. El protocolo TCP divide los bytes entrantes en

segmentos y los pasa a la capa de Internet. En el receptor, el protocolo TCP une

nuevamente los segmentos recibidos para definir el flujo de salida.

- Protocolo UDP (User Datagram Protocol): al contrario del protocolo TCP, el

protocolo UDP no está orientado a la conexión, lo que lo convierte en un protocolo

no confiable usado por aplicaciones que no desean la definición de secuencia de

TCP, ya que pueden proveerla por sí mismas. UDP es muy utilizado en las

consultas de una sola ocasión del tipo cliente-servidor, así como en aplicaciones

que priorizan una transmisión oportuna sobre una transmisión precisa (por ejemplo,

voz o video).

Nivel 5 - capa de aplicación: el modelo TCP/IP no incluye los niveles de sesión o de

presentación. En este modelo las aplicaciones se encargan de todas las funciones de

sesión o presentación necesarias. Mientras que el envío y recepción de información se

realiza por medio de la capa de transporte, en la capa de aplicación se incluyen los

servicios de Internet y las aplicaciones disponibles para el usuario [18], [19]. Entre los

protocolos definidos para esta capa se encuentran: FTP (File Transfer Protocol), DNS

(Domain Name System), HTTP (Hypertext Transfer Protocol), RDISC (Router

Discovery Server), RIP (Routing Information Protocol), SMTP (Simple Mail Transfer

Protocol) y RTP (Real Time Transport Protocol). En la Figura 1-4 se muestra la

interacción entre algunos de los protocolos más usados del modelo TCP/IP.

Capítulo 1 37

Figura 1-4: Modelo TCP/IP con algunos de sus protocolos más comunes [17].

Ahora que se han presentado los modelos de referencia en los que se basan las

tecnologías utilizadas para el desarrollo de este proyecto, se considera pertinente hacer

una descripción de las características que definen la implementación de estos estándares

en el ámbito industrial.

1.2.2.3 Redes de área local (LAN)

Una red LAN (Local Area Networks), es una red de uso privado que funciona en una

ubicación que abarca pocos kilómetros de longitud, por ejemplo, un edificio, una residencia

o una fábrica [18]. En el ámbito industrial son muy utilizadas para conectar distintas

estaciones de trabajo, PCs, controladores, entre otros dispositivos localizados en un mismo

edificio. Las características fundamentales que definen una red LAN son; la topología, el

medio de transmisión, la disposición y las técnicas de acceso al medio. En esta sección se

hace una descripción breve de dichas características.

1.2.2.3.1 Topologías

En términos de una red de comunicación industrial, la topología hace referencia a la

disposición física con la que se conectan los diferentes dispositivos pertenecientes a la

red, alrededor del medio de transmisión [20]. Las configuraciones básicas usadas a nivel

industrial son:

Física + acceso a

la red

Internet

Transporte

Aplicación



Bus: cada uno de los dispositivos de la red o nodos están conectados directamente,

por medio de una interfaz física, al medio de transmisión con una distribución lineal o

bus (Figura 1-5). Los límites del bus están definidos por terminadores ubicados en sus

extremos, que tienen como objetivo suprimir las señales que se transmiten por el bus,

una vez lleguen al terminador. El intercambio de información entre cada nodo de la red

y la toma de conexión (interfaz física) es full-duplex (comunicación bidireccional y

simultanea), esto permite que la transmisión y recepción de datos se pueda hacer de

forma simultánea a través del bus. Cada vez que alguno de los nodos en la red

transmite un mensaje, este se propaga en el bus y los demás nodos lo reciben.

Figura 1-5: Topología de comunicación en bus [17].

Árbol: Es una variación de la topología en bus, con una distribución en ramales sin

formar lazos cerrados (Figura 1-6). De la misma forma que para la topología en bus,

los mensajes transmitidos por un nodo se propagan por cada ramal y llegan a los

demás nodos conectados en la red.

Figura 1-6: Topología de comunicación en árbol [17].

Capítulo 1 39

Anillo: una red en anillo está conformada por un grupo de repetidores conectados por

medio de enlaces punto a punto unidireccionales, con una distribución en bucle cerrado

(Figura 1-7). El objetivo de los repetidores es recibir datos del nodo para luego

retransmitirlos bit a bit. Cada vez que un nodo transmite un mensaje por medio del

repetidor, es dividido en tramas, que viajan por el anillo en un solo sentido, ya sea

horario o anti horario.

Figura 1-7: Topología de comunicación en anillo [17].

La topología en anillo es, potencialmente, la distribución de red que ofrece un mejor

rendimiento en comparación con las demás topologías [17].

Estrella: todos los nodos pertenecientes a la red están conectados a un conmutador,

repetidor o concentrador central común (Figura 1-8), que en general permite establecer

enlaces bidireccionales.

Figura 1-8: Topología de comunicación en estrella [17].

Se tienen dos opciones de funcionamiento para el nodo central [17]:



- Modo difusión. De esta forma, el nodo central actúa como concentrador, es decir;

recibe las tramas enviadas por cada nodo y las reenvía a los demás nodos

conectados en la red.

- Modo conmutador. En este modo, el nodo central almacena la trama enviada por

un nodo de red para luego reenviarla únicamente al nodo de destino.

Otra opción para la distribución de nodos es la topología en red, en la que cada nodo de

la red se comunica con los demás nodos a través de múltiples caminos, sin embargo, no

es muy usada a nivel industrial debido a su complejidad y altos costos de implementación

[5]. Además, es importante resaltar que las configuraciones pueden ser mixtas, dando lugar

topologías como anillo-estrella [17].

1.2.2.3.2 Medios de transmisión guiados UTP y STP

Un aspecto muy importante en el diseño de una red LAN es el medio físico utilizado para

realizar la transmisión de información en la red (capa física). La elección del medio físico

utilizado para la implementación de una red de comunicaciones industriales, está ligada a

la topología implementada y a otros factores como [18]:

- Ancho de banda. Hace referencia al espectro de frecuencias que soporta el medio.

Un ancho de banda amplio, permite mayores velocidades de transmisión.

- Compatibilidad de dispositivos. Es importante contar con una variada oferta

comercial de dispositivos compatibles con las interfaces físicas del medio de

transmisión seleccionado.

- Seguridad. Se refiere al grado de dificultad que tiene el medio para que la

información transmitida sea interceptada.

- Fiabilidad.

- Costos.

Para la implementación del proyecto descrito en este documento, se seleccionó como

medio de transmisión el cable de par trenzado. A continuación, se muestran algunas de

las principales características de dicho medio.

Capítulo 1 41

Cable de par trenzado

Es uno de los medios de transmisión más antiguos, sin embargo, también es de los más

usados [18]. Un par trenzado está formado por dos cables de cobre aislados, comúnmente

con un diámetro de 1 mm, trenzados en forma helicoidal (Figura 1-9). Normalmente la

transmisión de señales se hace como la diferencia de voltaje entre los dos conductores del

par. Los dos conductores del par están en paralelo, formando una antena simple, y cuando

se trenzan los conductores las ondas de distintos trenzados terminan cancelándose,

disminuyendo la efectividad de irradiación del conductor. Esto permite disminuir la

susceptibilidad de la transmisión al ruido externo, pues el ruido tiende a afectar a los dos

conductores en la misma proporción, por lo tanto, el diferencial de voltaje no se modifica.

Figura 1-9: Cable UTP cat 5 con cuatro pares trenzados [18].

Una de las ventajas del cable de par trenzados es que permite la transmisión de

señales analógicas y digitales. gracias a su buen desempeño y bajo costo, los pares

trenzados son el medio físico de transmisión más usado en distancias relativamente

cortas y debido a las mejoras en sus prestaciones disponibles con las distintas

categorías, es probable que su uso se siga extendiendo por varios años más [18]. El

arreglo de conductores mostrado en la Figura 1-9, conformado por cuatro pares

trenzados puede ser de dos tipos; UTP Y STP.

En el cable apantallado o STP (Shielded Twister Pair), cada par del cable posee un

blindaje o apantallamiento que tiene como objetivo minimizar las interferencias

electromagnéticas. Esta tecnología fue desarrollada por IBM a comienzos de la década

de los 80, aunque su uso no es extendido debido a su gran volumen y alto costo.

El cable sin apantallar o UTP (Unshielded Twister Pair) es muy utilizado en la

implementación de redes LAN, gracias a su bajo costo y facilidad de instalación y uso.

Los conductores UTP se clasifican en las siguientes categorías:



- Categoría 1: es usado únicamente para telefonía. No es apropiado para su uso en

transmisión de datos.

- Categoría 2: son usados cuando se tienen requerimientos bajos de velocidad para

la transmisión de datos (máximo 4 Mbps).

- Categoría 3: en un comienzo se usaban en redes Ethernet a 10 Mbps, para

segmentos menores a 100 m y una distancia máxima de 500 m para la red

completa. Pero su uso es más extendido en redes con paso de testigo a 4 Mbps y

16 Mbps.

- Categoría 4: permite velocidades de transmisión de hasta 20 Mbps.

- Categoría 5 y 5e: es la categoría más usada gracias a las altas velocidades de

transmisión (100 y 150 Mbps). En la actualidad está disponible la categoría 5e que

permite velocidades de transmisión de hasta 1 Gbps [17].

- Categorías 6 y 6a: permiten manejar anchos de banda de 250 y 600 MHz,

respectivamente. Su costo es un poco más elevado debido a que el calibre de los

pares es mayor, sin embargo, suele ser usado en redes que requieren prestaciones

de alta velocidad (hasta 10 Gbps) [18].

1.2.2.3.3 El estándar IEEE 802.3 y Ethernet

Es común que los nombres IEEE 802.3 y Ethernet sean usados sin hacer ninguna

distinción entre ellos. Esto es debido a que ambas especificaciones son idénticas, excepto

por diferencias sutiles en el formato de la trama definido en el protocolo de subcapa MAC

(Figura 1-10). A continuación, se describe el formato de la trama definida por el estándar

IEEE 802.3 y se explican dichas diferencias.

Figura 1-10: Formatos de trama. (a) Ethernet (DIX) (b) IEEE 802.3 [18].

Capítulo 1 43

- Preámbulo: tiene una longitud de 8 bytes, todos los bytes contienen el conjunto de

bits 10101010 (excepto por el último byte, cuyos últimos 2 bits son 11). El 802.3

llama a este último byte SOF (start of frame).

- Dirección de destino: también llamada dirección MAC de destino, consta de 6 bytes.

Es la identificación del receptor.

- Dirección de origen: también se conoce como dirección MAC de origen, está

formada por 6 bytes. Permite identificar la estación que envió la trama.

- Longitud/Tipo: este campo representa la diferencia que existe entre el estándar

IEEE 802.3 y la especificación Ethernet primitiva. Según el estándar IEEE 802.3

este campo especifica la longitud de la trama de datos. Para el caso de Ethernet,

este campo especifica el tipo de datos que contiene la trama, para así determinar

el proceso que se le debe aplicar. Por fortuna, el IEEE decidió en 1997 que la trama

Ethernet primitiva también quedaba permitida (es decir ignorando el LLC), por lo

que hablar de IEEE 802.3 y Ethernet sin distinción no se considera una mala

práctica [18]. Así pues, en este documento se habla de Ethernet e IEEE 802.3

indistintamente.

- Datos: se tiene una longitud máxima de datos de hasta 1500 bytes por trama y una

longitud mínima de 64 bytes.

- Relleno: bytes agregados para garantizar que la trama tenga una longitud suficiente

para que la técnica de detección de colisiones funcione adecuadamente.

- Suma de verificación o FCS (Frame Check Sequence): es un algoritmo CRC

(Comprobación de Redundancia Cíclica) de 32 bits. Permite determinar si la trama

enviada por el transmisor llego correctamente al receptor.

Otra característica muy importante especificada por el estándar IEEE 802.3 es el protocolo

de acceso múltiple con detección de portadora y detección de y detección de colisiones

CSMA/CD. Dicho protocolo consta de dos procesos. En primer lugar, se tiene el acceso

múltiple con detección de portadora CSMA, que consiste en hacer que la estación

transmisora primero escuche el canal para detectar si en ese momento hay otra estación

transmitiendo y, si es así, espera un tiempo aleatorio para repetir el intento de transmisión,

que solo podrá realizarse si el canal está inactivo. Por supuesto, si dos estaciones

transmisoras detectan a la vez que el canal está inactivo, comenzaran ambas con el

proceso de transmisión y se generara una colisión. Es en este caso en el que entra en



acción el segundo proceso del protocolo CSMA/CD llamado detección de colisiones (CD);

dicho proceso consiste en hacer que la estación transmisora escuche el canal durante la

transmisión, y se asegure de que lo que está escuchando sea igual a lo que está

transmitiendo, de lo contrario está ocurriendo una colisión, en cuyo caso deberá interrumpir

la transmisión y esperar un tiempo aleatorio para intentarlo de nuevo [18].

Por otra parte, uno de los aspectos que hace a Ethernet la red con más auge a nivel

industrial, es la constante evolución que el estándar IEEE 802.3 ha tenido para adaptarse

a los inevitables avances tecnológicos en aplicaciones y dispositivos para comunicaciones

industriales [4], [17]. En la actualidad dicho estándar incluye velocidades de transmisión

muy altas que llegan hasta los 10 Gbps.

1.2.2.3.4 Dispositivos para la implementación de redes Ethernet

Con el objetivo de facilitar la descripción de los dispositivos utilizados en la implementación

de redes Ethernet, es conveniente asociar cada equipo con la capa del modelo TCP/IP en

la que opera. En la Figura 1-11, se muestra dicha relación.

CAPA FÍSICA

CAPA DE ACCESO

A LA RED

CAPA DE INTERNET

CAPA DE TRANSPORTE

CAPA DE APLICACIÓNPuerta de enlace de

aplicación

Puerta de enlace de

transporte

Enrutador

Puente, switch

Repetidor, hub

Encabezado

de trama

Encabezado

de paquete

Encabezado

TCP

Datos de

usuarioCRC

Paquete (suministrado por la capa de Internet)

Trama (suministrada por la capa de acceso a la red)

(a) (b)

Figura 1-11: (a) Capas TCP/IP de los dispositivos. (b) Tramas y encabezados [18].

Repetidores

Son dispositivos analógicos que tienen como función interconectar dos segmentos de

red y regenerar las señales que se transmiten, permitiendo aumentar el alcance de la

red. Estos dispositivos trabajan en la capa física, por lo tanto, permiten hacer la

conexión de medios físicos de transmisión distintos (UTP, Fibra, Etc), ya que para

lograrlo solo es necesario alterar el formato físico de la señal y no los paquetes o

encabezados de las tramas [5], [17].

Capítulo 1 45

Hubs

Un hub tiene varios puertos de entrada que permiten conectar segmentos de red

eléctricamente. Las tramas que llegan a cualquiera de los puertos de entrada son

enviadas a todos los segmentos de red conectados a los demás puertos (broadcast)

[18].

Routers

Los routers operan en la capa de Internet del modelo TCP/IP. En el momento en que

una trama llega a un enrutador, tanto el encabezado como el terminador son retirados,

dejando únicamente la carga útil de la trama (denominado paquete en la Figura 1-11)

para ser procesada por el software de enrutamiento. El software de enrutamiento elige

una línea de salida (en el caso de un paquete IP el encabezado del paquete es de 32

bits si es IPv4, si es IPv6 es de 128 bits) [18]. En general, la asignación de direcciones

IP se hace de forma estática en cada estación conectada a la red. Sin embargo, los

routers ADSL modernos suelen permitir la activación de servidores DHCP (Dynamic

Host Configuration Protocol), que facilitan la asignación de direcciones IP de forma

dinámica para dichas estaciones (siempre y cuando las estaciones puedan ser

configuradas como clientes DHCP; es decir que admitan configuración TCP/IP

dinámica) [22].

Puertas de enlace de transporte y de aplicación (Gateway)

Un Gateway, pasarela o puerta de enlace, se encarga de hacer la traducción entre

familias de protocolos diferentes, permitiendo establecer comunicación de extremo a

extremo entre redes de distinta naturaleza [17]. De forma general, las puertas de enlace

se pueden describir como un proceso de reenvió y modificación de formato que opera

en una capa alta [18].

1.2.2.3.5 Direccionamiento IP

Una dirección IP es un número binario de 32 bits o 4 bytes, que generalmente es

representada en notación “punto”, en la que cada byte se convierte en su decimal

equivalente y se separa por puntos (Figura 1-12).



Figura 1-12: Direcciones IP. (a) Notación binaria. (b) Notación punto. [17].

Una dirección IP se divide en dos partes; la dirección de red y la dirección local, que

identifican la red y el nodo especifico al que está conectado el dispositivo [17]. El número

de bits destinado a la dirección de red y a la dirección local, determina el tipo de dirección

IP. En la Figura 1-13 se muestran los tipos de IP más usados.

Figura 1-13: Clases de direcciones IP [17].

Además de los formatos IP mostrados en la Figura 1-13, existen los formatos D y E que

comienzan con un número entre 224-239 y 240-255 respectivamente. Las direcciones

clase D son usadas en multidifusión (multicast; transmitir mensajes a varios dispositivos

en la red simultáneamente), en tanto que las direcciones clase E están reservadas para

uso experimental.

En el entorno industrial es muy común tener que dividir el espacio de direcciones en

subredes [17]. Con este fin, la parte local de la dirección se divide como en la Figura 1-14.

Figura 1-14: División de la dirección IP en parte de subred y parte de dispositivo [17].

Para que un dispositivo este completamente con figurado dentro de una red IP, debe contar

como mínimo con; dirección IP, Mascara de red y subred (consiste en un numero de 32

bits con tantos bits puestos a 1 desde el inicio del número, como bits tiene la dirección IP

en la parte de red), dirección IP de por lo menos un enrutador (enrutador por defecto en el

Capítulo 1 47

caso de que solo haya uno), dirección IP de por lo menos un servidor DNS (para poder

usar aplicaciones invocándolas con nombres en lugar de direcciones IP).

1.2.2.3.6 Cliente/servidor IP (sockets)

Generalmente las aplicaciones IP (servicios IP) están formadas por; un servidor de la

aplicación (proceso del sistema operativo que acepta peticiones de conexión) y los clientes

que se conectan al servidor. En el arranque, cada servidor crea una estructura abstracta

conocida como socket, en la memoria del dispositivo. Los sockets son espacios de

memoria que contienen entre otra información; la dirección IP, el protocolo de transporte

(TCP o UDP) y el puerto de comunicación asociado, lo que permite la definición de una

dirección de Internet, compuesta por la dirección IP y el puerto de comunicación TCP. En

general, el número de puerto puede ser configurado, sin embargo, a los números de puerto

hasta el 1023 se les llama “bien conocidos” [17]. En la Tabla 1-1, se muestran algunos de

estos números de puerto.

Tabla 1-1: Algunos números de puerto de uso común [17].

1.3 Sistemas SCADA

Ahora que se ha hecho una revisión detallada de las redes de comunicaciones industriales

Ethernet, destinadas a garantizar el intercambio de información entre los niveles 2,3,4 y 5

del modelo CIM (Figura 1-1), se considera pertinente mostrar algunas de las características

básicas de los sistemas SCADA (Supervisory Control And Data Acquisition).



Un sistema SCADA puede ser definido como cualquier software que facilite el acceso a los

datos remotos de un proceso y que, haciendo uso de las herramientas de comunicación

requeridas para cada caso, permita controlar dicho proceso [5]. Por lo tanto, no se trata de

un sistema de control, sino de una herramienta de software que permite establecer una

interfaz, tanto entre los equipos ubicados en el nivel 3 del modelo CIM, como entre dichos

equipos y los pertenecientes a los niveles 2 y 4.

1.3.1 Objetivos de un sistema SCADA

Entre los objetivos que busca cumplir un sistema SCADA se pueden destacar:

- Economía: disminuir la cantidad de dispositivos de visualización local, así como los

operarios requeridos para el monitoreo y mantenimiento de dichos dispositivos.

- Accesibilidad: acceso simple a cada etapa del proceso, permitiendo establecer

consignas, poner en marcha o detener equipos, establecer configuraciones, etc.

- Mantenimiento: utilizar los datos adquiridos para presentarlos en una forma

inteligible para usuarios no especializados, indicándoles información relativa a

fechas de mantenimiento y alarmas ante fallas en las maquinas.

- Ergonomía: asegurar que la relación entre el usuario y el proceso sea amigable,

intentando presentar toda la información necesaria sin fatigar al usuario.

- Gestión: usar herramientas estadísticas, graficas, tabulaciones, etc., que faciliten a

los operadores del sistema y a los departamentos de niveles superiores, tomar

decisiones en la búsqueda de optimizar y mejorar el rendimiento del proceso.

- Flexibilidad: las modificaciones del sistema de visualización no deben implicar

cambios físicos en los sistemas de control, además, el SCADA debe ser escalable.

- Conectividad: idealmente, se buscan sistemas de visualización abiertos, es decir;

que permitan la integración con aplicaciones estándar (incluso de otros

fabricantes). Además, el SCADA debe contar con procesos sencillos de instalación

en los sistemas operativos más comunes (Windows, Mac, Linux, etc.).

1.3.2 Arquitectura de un sistema SCADA

Usualmente, los sistemas SCADA están basados en la arquitectura mostrada en la Figura

1-15. El usuario tiene acceso al sistema de control y adquisición del proceso desde una

Capítulo 1 49

aplicación de supervisión, que generalmente es ejecutada desde un ordenador y que le

ofrece al usuario herramientas de control y visualización (sistema servidor). Como ya se

ha mencionado, las comunicaciones entre los sistemas de control y supervisión, suelen

implementarse por medio de redes corporativas (Ethernet) [5]. Por otra parte, las

comunicaciones entre el sistema de control de proceso y los elementos de campo

(sensores y actuadores) se realiza mediante los denominados Buses de Campo.

Figura 1-15: Arquitectura básica de un sistema para supervisión y mando [5].

La información que se genera mediante la ejecución de las tareas de supervisión y control

se almacena con el fin de ser utilizada a posteriori. En la actualidad, la tendencia es integrar

las comunicaciones entre cada nivel de los procesos en una base común como Ethernet

Industrial y de esta forma integrar los datos de maquina directamente con la red

empresarial, permitiendo generar estrategias globales de empresa [5], [4].

1.3.3 Hardware de un sistema SCADA

Conceptualmente, un sistema SCADA está conformado por captadores de datos y

utilizadores de datos [5]. Estos sistemas se pueden dividir en los siguientes elementos:

Interfaz Hombre Maquina (HMI): está conformada por los sinópticos de control y los

sistemas de representación gráfica. Su función es representar de forma simplificada e

inteligible el sistema que se está controlando [5].

Unidad central (MTU, Master Terminal Unit): permite centralizar el mando del

sistema. Es el ordenador central encargado de intercambiar información en tiempo real

entre centros de control y subestaciones del proceso. En general, se trata de un PC

que soporta el HMI y cumple funciones de; recopilación de datos y transmisión de

consignas a las RTU, interfaz de operadores con el proceso, administración de las

comunicaciones, y otras funciones especializadas para cada proceso [5], [23].



Unidad remota (RTU, Master Terminal Unit): la función de una RTU es procesar las

comunicaciones bidireccionales entre los equipos de control y la MTU (recolectar datos,

llevar comandos de control y gestionar la seguridad de la información). En la actualidad,

los PLC (Programmable Logic Controller) incorporan prestaciones para el

procesamiento de comunicaciones en forma de módulos de expansión, por lo que las

funciones de una RTU quedan incluidas dentro de un PLC moderno [5].

Sistemas remotos: es muy común que las estaciones remotas sean más complejas

que un PLC con prestaciones para el procesamiento de comunicaciones, incluso

pueden incluir sistemas complejos de visualización y control. Por lo tanto, las unidades

remotas pueden definirse de forma más general como; el conjunto de elementos de

control y/o supervisión de un sistema, distantes del MTU y conectados a éste, por

medio de un canal de comunicación bidireccional [5], [23].

Sistema de comunicación: la interacción entre servidores y clientes es de tipo

productor-consumidor. Los servidores solicitan información cíclicamente a los

dispositivos de control (polling), recopilando información del proceso. El servidor

central puede gestionar varios protocolos simultáneamente, (dependiendo de la

capacidad física de las tarjetas de comunicación de la MTU). De esta forma, y haciendo

uso de los medios de transmisión y topologías que más convengan en cada caso

(siendo las redes Ethernet Industrial las más usadas en la actualidad [4]), la

comunicación bidireccional entre la MTU y las RTU puede ser implementada [5].

1.3.4 Comunicación entre aplicaciones por OPC

Con frecuencia, la integración entre sistemas es uno de los aspectos más difíciles de lograr

en los procesos industriales. En un sistema de automatización puede haber una variedad

de dispositivos de control y monitorización, con protocolos de comunicación y sistemas

operativos específicos. Cada fabricante crea un driver que permite establecer

comunicación entre su producto y otro equipo específico, haciendo el manejo de datos en

forma inaccesible para el usuario [5]. Existen inconvenientes de compatibilidad implícitos

en este método, por lo que surgen las preguntas; ¿Qué sucede cuando en una planta

existen equipos de diferentes fabricantes y es necesario integrarlos a un sistema nuevo, o

existente?, ¿es obligatorio que una empresa adquiera únicamente equipos de un solo

fabricante para no tener problemas de compatibilidad?

Capítulo 1 51

OPC (OLE for Process Control) fue creado con el objetivo de establecer un estándar para

el intercambio de datos entre aplicaciones, sin importar la tecnología con la que se realice.

Independientemente del tipo de dispositivo, el formato de presentación y acceso a los datos

no cambia, por lo tanto, el intercambio de datos podrá realizarse con cualquier equipo que

cumpla con el estándar OPC [5].

1.3.4.1 Definición de OPC

OPC (OLE for Process Control) es un estándar que define especificaciones diseñadas para

el intercambio de información entre dispositivos, controladores y/o aplicaciones de distintos

fabricantes, determinando una interfaz estándar para la transmisión y recepción de datos

sin hacer distinciones en cuanto al tipo de dispositivo, tipo de tecnología, protocolo, medio,

etc. [5], [24], [25]. El primer desarrollo fue implementado por la OPC Task Force, con apoyo

de algunas de las empresas más importantes del sector: Fisher-Rosemount, Intellution,

Intuitive Technology, Opto22, Rockwell y Siemens AG. En el año de 1996 fue introducida

la versión inicial llamada OPC Specification Version 1.0, que se basó en COM (Component

Object Model), y OLE (Object Linking and Embedding). En la actualidad, las

especificaciones de OPC son mantenidas y actualizadas por OPC Foundation; que agrupa

a algunas de las compañías de software y hardware más importantes, así como a usuarios

finales en todo el mundo.

1.3.4.2 Tecnología OPC

OPC está basado en la tecnología para inserción de datos de Microsoft OLE/DCOM. OLE

(Object Link Embedded) posibilita acceder a los datos de dispositivos dentro de una red

LAN o WAN. Por otra parte, las tecnologías COM (Component Object Model) y su

ampliación DCOM (Distributed COM) permiten habilitar la creación de objetos de

comunicación entre procesos, facilitando a los clientes OPC (locales o remotos

respectivamente) acceder al servidor OPC. Estos objetos se pueden utilizar en entornos

diferentes para los que fueron creados, incluso afuera de los límites físicos de los

dispositivos. La conversión de tipos entre diferentes interfaces de un objeto se logra a

través del método QueryInterface.

Es importante resaltar que, aunque inicialmente OPC estaba restringido al sistema

operativo Windows, OPC Foundation ha desarrollado las especificaciones OPC UA con



arquitecturas de plataforma abierta con tecnología de funcionalidad múltiple, escalable,

extensible y enfocada a las mejoras necesarias con el paso del tiempo [24], [26].

1.3.4.3 Arquitectura cliente/servidor OPC

El intercambio de información entre dispositivos y/o aplicaciones por estándar OPC, se

basa en una arquitectura cliente servidor (Figura 1-16). En esta sección se definen los dos

elementos fundamentales de dicha arquitectura.

Figura 1-16: Arquitectura cliente/servidor OPC [5].

Servidor OPC: es una herramienta de software que cuenta con al menos una de las

especificaciones definidas por la OPC Foundation, y que permite establecer una

interfaz de comunicación estándar entre las fuentes de datos utilizando sus protocolos

nativos (PLCs, módulos I/O, controladores, reguladores, etc.) y las aplicaciones que

contienen Clientes OPC (SCADAs, HMIs, generadores de informes, graficadores, etc.)

[5], [24], [25].

Cliente OPC: es un módulo de software que cuenta con al menos una de las

especificaciones definidas por la OPC Foundation, y que permite a la aplicación desde

donde se está ejecutando (SCADA, HMI, graficadores, historiadores, etc.), establecer

comunicación bidireccional con servidores OPC compatibles (un Cliente OPC puede

comunicarse con varios servidores OPC de forma simultanea). Conceptualmente, los

Clientes OPC hacen las veces de usuario final de los datos, iniciando y controlando la

comunicación bidireccional con Servidores OPC, de acuerdo a las peticiones

realizadas desde la aplicación en la que se encuentran embebidos [25].

Es común llamar Cliente OPC a la aplicación que contiene a un cliente OPC (SCADA, HMI,

graficadores, historiadores, etc.), sin embargo, esto es un error, ya que el cliente OPC es

Capítulo 1 53

solo un módulo de dicha aplicación. Por otra parte, es importante tener en cuenta que las

comunicaciones Cliente OPC / Servidor OPC son bidireccionales, por lo que los Clientes

OPC pueden realizar acciones de lectura/escritura en los dispositivos por medio de los

servidores OPC. De esta forma, en una arquitectura Cliente OPC / Servidor OPC, el

Servidor OPC hace las veces de esclavo, mientras que el Cliente OPC es el maestro.

1.3.4.4 Especificaciones OPC Classic y OPC UA

OPC es un estándar de comunicaciones libre y abierto a programadores que deseen

desarrollar aplicaciones de este tipo. La OPC Foundation ha definido especificaciones

denominadas OPC Classic, que han tenido un gran éxito en el entorno industrial [26].

Dentro de las especificaciones de OPC Classic sobresalen:

OPC DA (Data Access): define la forma en que se hace el intercambio de datos

(valores, formatos, información de tiempo y calidades) [26]. Su versión más reciente es

la OPC DA 3.0. Esta especificación incorpora:

- Definición de la arquitectura OPC client/server, así como del formato y la estructura

de los datos.

- Definición de un espacio de direcciones, leer, escribir y suscribirse a notificaciones

de actualización de datos.

- Definiciones específicas de interfaces, métodos, parámetros y comportamientos

requeridos.

- Descripciones específicas de tipos y formatos de los datos.

La especificación OPC DA está basada en las tecnologías COM (para clientes OPC

locales) y DCOM (para clientes OPC remotos) de Microsoft, por lo tanto, no puede ser

utilizada en sistemas operativos como MAC, Linux, entre otros. Esta ha sido la razón

principal por la cual OPC Foundation introdujo la especificación OPC UA.

OPC HDA (Historical Data Access): especifica los métodos de consulta y análisis

definidos para datos históricos con marca de tiempo. Así mismo, define la forma en la

que un servidor OPC almacena información en una base de datos y cómo los clientes

OPC pueden acceder a dicha información [26].



OPC AE (Alarms and Events): define el método por el cual se realiza el intercambio

de datos tipo evento y alarma. Por medio de esta especificación un servidor OPC puede

monitorear estados de proceso y notificar a los Clientes OPC cuando se presenten

condiciones de alarma en el mismo [5], [26].

Por otra parte, OPC UA (Unified Architecture) lanzada en 2008 por la OPC Foundation, es

una arquitectura orientada a servicios que no depende de la plataforma en la que se

implemente, incluyendo cada una de las funcionalidades definidas en las especificaciones

de OPC Classic en forma integrada y extensible [26]. OPC UA se diseñó con el objetivo de

mejorar las especificaciones de OPC Classic, y eliminar sus limitantes de uso en sistemas

operativos distintos de Windows. OPC UA es funcionalmente equivalente a OPC Classic,

pero incorpora nuevas prestaciones. Dentro de las características de OPC UA sobresalen:

- Equivalencia funcional: todas las características asociadas a las tecnologías

COM y DCOM de OPC Classic quedan incluidas en OPC UA. Así mismo, todas las

funcionalidades de las especificaciones OPC Classic quedan incluidas.

- Independencia de plataforma: OPC UA puede ser implementado en diversas

plataformas de hardware (PC tradicional, servidores en la nube, PLCs,

microcontroladores, etc.) y en los principales sistemas operativos (Windows, Mac

OSX, Android, Linux, etc.).

- Seguridad: OPC UA es completamente compatible con Firewall, así mismo,

incluye características de cifrado, firma de mensajes, autenticación y auditoria.

- Extensibilidad: OPC UA permite adicionar nuevas tecnologías y metodologías,

como protocolos de transporte, algoritmos de seguridad, estándares de codificación

o servicios de aplicación, sin afectar la compatibilidad con los productos existentes.

1.4 Internet de las cosas y MQTT

Conceptualmente, Internet de las cosas se define como el conjunto de herramientas y

tecnologías que permiten que el mundo virtual de información se integre con el mundo real

de las cosas [27]. De acuerdo con [28] el término “cosas”, puede ser definido de forma

distinta dependiendo del contexto en el que se esté utilizando:

Capítulo 1 55

- Industria: en este contexto, el término “cosas” se utiliza para referirse al producto,

los dispositivos, las maquinas, medios de transporte, etc. Es decir; hace referencia

a cada fuente de información participante en el ciclo de vida de los productos.

- Entorno: aquí las “cosas”, se refieren a todos los dispositivos y/o fuentes de

información que hacen parte de las actividades abocadas a la protección,

seguimiento y desarrollo de los recursos naturales (reciclaje, agricultura, etc.).

- Sociedad: en este contexto las “cosas” se usa para referirse a los dispositivos y

aplicaciones desarrolladas con el objetivo de facilitar la vida diaria de las personas

(domótica, salud, seguridad, etc.).

En la actualidad hay numerosos modelos IoT de referencia, que tienen como objetivo

facilitar el trabajo de desarrolladores y proveedores de servicios. Uno de los modelos más

utilizados, es el definido por la Unión Internacional de Telecomunicaciones (UIT) mostrado

en la Figura 1-17, que consta de cuatro capas horizontales y dos capacidades verticales

que abarcan la mayoría de protocolos IoT más comunes [29]. Cada capa se describe a

continuación.

Figura 1-17: Modelo de referencia IoT según UIT [30].

Capa de dispositivo: incluye los dispositivos físicos que tienen embebida la

aplicación, se gestiona su identificación, sus características de hardware y el recurso

energético requerido.

Capa de red: contiene las tecnologías de comunicación, los algoritmos de inserción,

enrutamiento y diseminación.



Capa de apoyo a servicios y aplicaciones: incluye las capacidades genéricas y

específicas utilizadas por las aplicaciones y servicios IoT.

Capa de aplicación: esta capa contiene todas las aplicaciones IoT. En esta capa se

encuentran los componentes de visualización de datos.

Capacidades de gestión: capacidades genéricas (gestión de dispositivos, gestión de

la topología de red local y gestión del tráfico y la congestión) y capacidades especificas

(requisitos específicos de las aplicaciones).

Capacidades de seguridad: en la capa de aplicación, se refieren a la autorización,

autentificación, confidencialidad de datos de aplicación, protección y antivirus. En la

capa de red, se refieren a la autorización, autentificación, confidencialidad de datos de

señalización y datos de uso, y protección de las señales. Y en la capa de dispositivo,

se refieren a la autorización, autentificación, control de acceso, validación y protección.

Existen varias tecnologías que permiten gestionar los protocolos y formatos para el

intercambio de información en aplicaciones IoT, entre las cuales sobresalen; MQTT

(Meessage Queue Telemetry Transport), HTTP (Hyper Text Transfer Protocol), DDS (Data

Distribution Service), Web-Socket, etc. La aplicación IoT implementada como parte del

desarrollo de este proyecto se basó en el protocolo MQTT, descrito a continuación.

1.4.1 MQTT (Meessage Queue Telemetry Transport)

MQTT es un protocolo para el transporte de mensajería con una estructura de publicación

/ suscripción, que ofrece una alternativa a las arquitecturas servidor / cliente. Fue

desarrollado por Andy Standord-Clark de IBM y Arlen Nipper de Arcom (ahora Cirrus Link)

en 1999, y en 2003 fue estandarizado por OASIS. MQTT ha tenido una gran acogida en

aplicaciones IoT, gracias a su capacidad para ajustarse a dispositivos de bajos recursos y

enlaces con ancho de banda limitados [32]. La versión más actual de este protocolo es

MQTT 5 ratificada por OASIS en marzo de 2019. A continuación, se hace una descripción

breve de las principales características de funcionamiento del protocolo MQTT.

Modelo Publicación/Suscripción en MQTT

El modelo Pub/Sub representa una opción a las arquitecturas tradicionales cliente/servidor,

en la que los clientes establecen comunicación en forma directa con un punto final. En el

modelo Pub/Sub tanto los clientes que transmiten mensajes (Publicadores) como los

Capítulo 1 57

clientes que los reciben (Subscriptores), están completamente desacoplados, es decir; no

establecen una conexión directa en ningún momento, de hecho, ninguno es consciente de

la existencia del otro. El intercambio de información entre Publicadores y subscriptores se

hace por medio de un tercer elemento llamado Broker [32]. La función del Broker es realizar

un filtrado de los mensajes enviados por los publicadores, para distribuirlos a los

subscriptores correspondientes.

Arquitectura del protocolo MQTT

Son dos los elementos que definen la arquitectura del protocolo MQTT (Figura 1-18):

- Clientes MQTT: tanto los subscriptores como los publicadores son clientes en la

arquitectura MQTT. Hace referencia a cualquier dispositivo o aplicación, que puede

ejecutar una biblioteca MQTT, y por lo tanto puede conectarse a un Broker MQTT

por medio de una red. En forma resumida; cualquier dispositivo o aplicación que

pueda hablar MQTT sobre una pila TCP/IP se denomina cliente MQTT. Por otra

parte, es importante resaltar que las capacidades de publicación y suscripción,

pueden ser implementadas para el mismo cliente.

- Broker MQTT: el Broker es el núcleo del modelo Pub/Sub. Gracias a la simplicidad

en la estructura de los mensajes MQTT, un Broker puede soportar hasta miles de

clientes comunicándose simultáneamente. La función del Broker es recibir todos

los mensajes enviados por los publicadores, filtrarlos y determinar a qué

subscriptores debe enviarlos. Además, el Broker gestiona las subscripciones,

autenticaciones, finalizaciones y guarda los mensajes de los clientes que tienen

sesiones persistentes, para evitar la pérdida de mensajes en caso de que sea

necesario. Es de vital importancia que el Broker sea altamente escalable e

integrable con aplicaciones backend, ya que es el Broker quien está expuesto en

todo momento a Internet, y necesita enviar mensajes a las aplicaciones de análisis

y procesamiento posteriores [32].

Figura 1-18: Ejemplo del modelo Pub/Sub MQTT para sensores Iot [33].



Calidad del servicio (QoS)

El nivel de Calidad de servicio (QoS) hace referencia a la configuración aplicada tanto

en el publicador, como en el suscriptor MQTT, que permite definir el nivel de garantía

que tendrá la entrega de mensajes. Se tienen 3 niveles de QoS en MQTT [32]:

- Nivel 0: los mensajes son transmitidos como máximo una vez, por lo tanto, no son

almacenados por el publicador o por el suscriptor (Figura 1-19). Así pues, no hay

garantía de la llegada del mensaje.

Figura 1-19: Publicación de mensaje con nivel de servicio QoS 0.

- Nivel 1: los mensajes son transmitidos al menos una vez. El publicador almacena

el mensaje, hasta que recibe como respuesta del suscriptor un mensaje de

comando PUBACK (Figura 1-20), que contiene el identificador único del mensaje

PUBLISH (packetID). De esta forma, se garantiza que el mensaje se transmita al

menos una vez. Si el publicador no recibe un mensaje PUBACK en un tiempo

definido, vuelve a enviar el mensaje PUBLISH incluyendo un indicador de duplicado

(DUP). Por lo tanto, el mensaje tiene garantía de llegada y podría llegar a ser

enviado más de una vez.


- Nivel 2: el mensaje es transmitido exactamente una vez. Este es el nivel de servicio

más lento y más seguro. En el momento en que un suscriptor recibe un mensaje

PUBLISH QoS 2 que viene de un publicador, lo procesa y responde con un mensaje

de comando PUBREC. Si el suscriptor no recibe el mensaje PUBREC, vueleve a

enviar el mensaje PUBLISH con un indicador de duplicado (DUP), hasta que recibe

Capítulo 1 59

el mensaje PUBREC. Una vez el suscriptor recibe el mensaje PUBREC, descarta

el mensaje PUBLISH inicial, almacena el mensaje PUBREC y responde con un

mensaje PUBREL. Una vez el suscriptor recibe el mensaje PUBREL descarta todos

los estados almacenados y responde con un mensaje PUBCOMP, además,

almacena el mensaje PUBLISH con packetID original, evitando así procesar el

mismo mensaje 2 veces (Figura 1-21).


Tópicos

En MQTT, un tópico hace referencia a una cadena UTF-8 que le permite al Broker filtrar

los mensajes recibidos para identificar a que clientes debe reenviarlos. Un tópico está

compuesto por uno o más niveles, que se especifican dentro de su sintaxis por medio

de una barra inclinada (separador de nivel del tópico). En la Figura 1-22 se muestra un

ejemplo de la sintaxis para un tópico de 3 niveles.

Figura 1-22: Ejemplo de un topico MQTT de 3 niveles.

Existen tres comodines que se pueden utilizar para suscribirse a varios tópicos

simultáneamente:

- Nivel único “+”: reemplaza un nivel dentro del tópico. Por ejemplo, el tópico

LabSIR/+/Nsecuencias, será equivalente al tópico mostrado en la Figura 1-22.

- Multinivel “#”: debe colocarse como el ultimo carácter del tópico. Implica la

suscripción a todos los tópicos que estén en niveles subsecuentes del nivel

reemplazado. Tomando como ejemplo el tópico de la Figura 1-22: el tópico

LabSIR/#, permitirá suscribirse a los mensajes publicados con los tópicos

LabSIR/RobotReal y LabSIR/RobotReal/Nsecuencias.



- Todos los niveles “+/#”: permite suscribirse a todos los tópicos publicados.

1.5 Contextualización del proyecto

En esta sección se hace una descripción general de las condiciones locativas y

tecnológicas del Laboratorio de Automatización de Maquinas (LabAuto), y el laboratorio de

Sistemas Inteligentes Robotizados (LabSIR) de la Universidad Nacional de Colombia sede

Bogotá, con el fin de ofrecer una visión general del contexto en el cual se desarrolló este

proyecto.

Figura 1-23: Laboratorio LabSIR, Universidad Nacional de Colombia [34].

En la actualidad, El laboratorio de robótica LabSIR, cuenta con los 2 robots IRB 140 de la

marca ABB, mostrados en la Figura 1-23. Dichos robots son utilizados para las prácticas

de laboratorio realizadas por parte de los estudiantes, en asignaturas de los programas

adscritos a la facultad de Ingeniería Mecánica y Mecatrónica y la facultad de ingeniería

Eléctrica y Electrónica de la universidad.

El controlador con el que se cuenta para cada robot, es el IRC5 ABB, en el cual se han

instalado módulos de I/O, tarjetas de comunicación, entre otros dispositivos. Actualmente

la programación de los robots se hace desde el Flex Pendant del controlador o en software

externo (por ejemplo, RAPID de Robot Studio), usando los computadores disponibles

dentro del laboratorio LabSIR.

Por otra parte, el laboratorio LabAuto cuenta con 5 PAC’s modulares Compac LOGIX 5370

L3 – 1769 – L30ELRM de la marca Allen Bradley. También cuenta con 2 pantallas HMI

View Plus 1000 de Allen Bradley (Figura 1-24).

Capítulo 1 61

Figura 1-24: Estación de trabajo y HMI Allen Bradley. LabAuto UNAL.

Los PAC’s y las pantallas se encuentran conectadas en una topología de anillo, por medio

de switches industriales ubicados en cada estación de trabajo. Cada PAC y HMI cuenta

con una IP fija asignada por la universidad, y antes del desarrollo de este proyecto se

encontraban bajo un ROUTER TP-LINK (que fue puesto provisionalmente).

Adicionalmente, el Laboratorio de Automatización y Maquinas, cuenta con varios

computadores de escritorio conectados a un switch común a los equipos industriales

(PAC’s y HMI’s), desde los cuales se realiza la programación y configuración de los

mismos.

Los equipos ubicados en LabAuto, cuentan con direcciones IP estáticas dentro de un rango

asignado por parte de la universidad. Los mismos, fueron conectados a la red de la

universidad por medio de un switch. En un intento por crear una red LAN independiente

para LabAuto, usuarios del laboratorio instalaron un router de uso residencial. El servidor

DHCP de la universidad configura dicho router con una IP dinámica, haciendo que cada

vez que se quiera implementar una aplicación de comunicaciones industriales entre

laboratorios, se deba hacer una reconfiguración de las direcciones IP del equipo. Por otra

parte, los robots IRB 140 ABB ubicados dentro de LabSIR se encuentran completamente

incomunicados con la red de la universidad y con los demás equipos disponibles en el

laboratorio. Actualmente el control y la programación de los robots IRB 140 de LabSIR es

realizado de forma local con controladores IRC5 ABB, ya sea por medio del Flex Pendant

(Control manual) o por medio de software externo (Robot Studio).

Por medio de este proyecto se implementaron las adecuaciones, configuraciones y los

desarrollos necesarios para permitir que los usuarios de los dispositivos de monitorización

y control ubicados en LabAuto, así como los usuarios de computadores o dispositivos



móviles con sistema operativo Android conectados a la red de la universidad, envíen

comandos de activación y reciban información de estado, sobre la ejecución de las rutinas

de movimiento programadas en los robots industriales ubicados en LabSIR.

Adicionalmente, se desarrolló una aplicación IoT que permite a los usuarios realizar tareas

de monitorización y control sobre el sistema implementado, desde cualquier ubicación

dentro o fuera de la universidad, haciendo uso de una interfaz Web creada para este

propósito.

2. Programación de los robots industriales

En este capítulo se hace una descripción breve de las características funcionales de los

robots IRB 140 ABB utilizados para la implementación de este proyecto. Por otra parte, se

muestran los detalles más importantes de la programación realizada en uno de los robots

ABB de LabSIR, que se desarrolló con el objetivo de permitir la activación de rutinas de

movimiento de forma externa, haciendo uso del estándar de comunicación OPC.

2.1 El robot IRB 140 y el controlador IRC 5 de ABB

El IRB 140 (Figura 2-1 a) es un robot industrial de 6 ejes de la marca ABB, desarrollado

para industrias de fabricación que usan sistemas automatizados flexibles basados en

robots [35]. El robot está equipado con el controlador IRC5 (Figura 2-1 b) y el software de

control de robots RobotWare para M2004, que permite administrar el sistema de robot,

incluyendo el desarrollo y la ejecución de programas de aplicación, el control de los

movimientos, las comunicaciones, etc.

Figura 2-1: (a) Robot IRB 140 [35] (b) Controlador IRC 5 [36].

Para más información sobre las características técnicas del robot IRB 140 y del controlador

IRC 5, consulte [35] y [36].

(a) (b)



2.1.2 Espacio de trabajo del robot IRB 140

La Figura 2-2 y la Tabla 2-1, muestran las posiciones extremas del robot IRB 140 y los

límites de movimiento de sus ejes respectivamente.

Figura 2-2: Posiciones extremas Robot IRB 140 (todas las medidas en mm) [35].

Tabla 2-1: Limites de movimiento de ejes robot IRB 140 [35].

Tipo de movimiento Área de movimiento

Eje 1: Movimiento de rotación De +180° a -180°

Eje 2: Movimiento del brazo De +110° a -90°

Eje 3: Movimiento del brazo De +50° a -230°

Eje 4: Movimiento de la muñeca De +200° a -200° de forma predeterminada Ampliables por configuración en software

Eje 5: Movimiento de doblado De +120° a -120°

Eje 6: Movimiento de giro De +400° a -400° de forma predeterminada Ampliables por configuración en software

2.1.3 Comunicaciones del controlador IRC 5

El controlador IRC 5 cuenta con dos puertos de comunicación Ethernet (uno de los puertos

está destinado a servicio y no puede ser usado para funcionalidades de red permanentes)

que cumplen con el estándar IEEE 802.3. Las velocidades de transmisión disponibles son

10 Mbit/s y 100 Mbit/s ajustadas de forma automática por el controlador. La comunicación

incluye el protocolo TCP/IP, y permite realizar configuraciones en la red como:

- DNS y DHCP.

- Acceso a archivos por medio de cliente FTP/NFS y servidor FTP.

- Control y/o monitorización por medio de estándar OPC.

Capítulo 3 65

- Arranque/actualización del software del controlador por medio de la red, o haciendo

uso de un PC externo.

- Comunicación con RobotStudio.

Adicionalmente, el controlador cuenta con un canal serie RS232 que puede ser utilizado

para comunicación con impresoras, terminales, ordenadores, etc. El canal serie tiene una

velocidad de transmisión máxima de 38,4 Kbit/s.

2.1.4 El FlexPendant

Todas las operaciones de control, configuración y programación pueden ser realizadas por

medio del FlexPendant portátil mostrado en la Figura 2-3. la Tabla 2-2 contiene la

información básica de la distribución física de cada una de sus partes.

Figura 2-3: Partes del FlexPendant [36].

Tabla 2-2: Elementos del FlexPendant [36].

Pos Elemento Descripción

A Pantalla táctil

Pantalla a color de 6,5 in. Permite la selección e introducción de datos

por parte del usuario. Permite la apertura de múltiples pantallas

simultáneamente.

B Teclas programables Cuatro teclas configurables por el usuario.

C Botón de paro de emergencia Cuando se presiona el robot se detiene inmediatamente.

D Joystick Permite mover el robot manualmente.

E Teclas de ejecución de programas Permiten iniciar, detener y ejecutar paso a paso los programas.

F Conexión de memoria USB Puerto USB tipo A

G Alojamiento de puntero El puntero es un lápiz que facilita el uso de la pantalla táctil.



2.1.5 RobotStudio

RobotStudio es una aplicación para PC que permite realizar el manejo de datos de

configuración, gestión y simulación de programas, documentación en línea, acceso remoto

y actuación directa sobre los datos del IRC5 [36]. Entre las funciones incluidas en el

paquete completo de RobotStudio sobresalen:

- System Builder; que permite crear y mantener sistemas en un PC externo para

luego pasarlos al controlador.

- Editor de configuraciones; que permite editar los parámetros del sistema.

- Editor de programas; para realizar programación en línea.

- Grabador de eventos; para grabación y monitorización de los eventos del robot.

- Opciones para hacer copias de seguridad y restablecimiento del sistema.

- Herramientas de administración de usuarios.

- Programación y simulación de manipuladores robóticos fuera de línea.

- Opciones para la calibración de Herramientas y modelado de piezas.

- FlexPendant virtual.

2.1.6 Lenguaje y entorno RAPID

RAPID (Robotics Application Programming Interactive Dialogue) es un lenguaje de

programación de alto nivel desarrollado por ABB, e introducido en 1994 con el fin de

permitir a los usuarios de robots industriales ABB programar su funcionamiento de una

forma sencilla, flexible y potente [36].

2.1.6.1 Estructura de los programas RAPID

Los programas RAPID se guardan en la memoria de programas del controlador. La

memoria de programas contiene el programa y los módulos de sistema (Figura 2-4). El

programa puede estar dividido en módulos de programa; que a su vez pueden contener

una o varias rutinas y los datos del programa. Uno de los módulos de programa, contiene

la rutina principal denominada (rutina main), que es el punto de entrada del procedimiento.

Por otra parte, los módulos de sistema; permiten definir datos y rutinas comunes y

especificas del sistema. Así, cualquier cambio que se haga en un módulo de sistema,

Capítulo 3 67

afectara a todos los programas guardados en la memoria de programas del controlador.

Para información sobre la creación de módulos en RAPID consulte [37].

Figura 2-4: Estructura de la memoria de programas en RAPID [37].

2.2 Instrucciones de movimiento

Las instrucciones básicas de movimiento del robot, se programan especificando las

características de la posición (del TCP; Tool Center Point) que se desea alcanzar. La

trayectoria entre posiciones es calculada automáticamente por el robot, teniendo como

base el tipo de instrucción de posicionamiento programada [37]. En la Tabla 2-3 se

muestran algunas de las instrucciones básicas de posicionamiento.

Tabla 2-3: Instrucciones de posicionamiento en lenguaje RAPID [37].

Instrucción Descripción

MoveC Mover el TCP (Tool Center Point ) a lo largo de una trayectoria circular

MoveJ Movimiento de ejes

MoveL Mover el TCP (Tool Center Point) a lo largo de una trayectoria lineal

MoveAbsJ Movimiento absoluto de ejes

MoveExtJ Mover un eje externo lineal o giratorio sin TCP (Tool Center Point)

MoveCSyncMover el robot en una trayectoria circular y ejecutar un

procedimiento de RAPID

MoveJSyncMover el robot con un movimiento de ejes y ejecutar un

procedimiento de RAPID

MoveLSyncMover el robot de forma lineal y ejecutar un procedimiento de

RAPID



Por otra parte, la Tabla 2-4 contiene los argumentos que deben especificarse en una

instrucción de posicionamiento. Para información acerca de la sintaxis de programación de

las instrucciones de posicionamiento, consulte [37].

Tabla 2-4: Argumentos de una instrucción de posicionamiento RAPID [37].

2.3 Programación de las rutinas de movimiento

Para el desarrollo de la programación realizada en este proyecto, se utilizó el software

RobotStudio V6.06 con licencia académica. El programa desarrollado consiste en una

secuencia de movimiento Pick & Place doble con activación/desactivación externa por

medio de interrupciones. La secuencia consta de catorce posiciones estructuradas en tres

rutinas denominadas; Tomar Objeto, Dejar Izquierda y Dejar Derecha (por simplicidad,

dichas rutinas están contenidas en un único modulo). El orden de ejecución de las rutinas

y el diagrama de flujo de la rutina principal, se muestran en la Figura 2-5 y Figura 2-6

respectivamente.

Figura 2-5: Orden de ejecución de la secuencia Pick & Place doble programada.

Argumento Descripción

Datos de posición

Posición final del robot y de los ejes externos con respecto al

sistema de coordenadas de referencia. Dicha posición esta

guardada en un dato de tipo Pos Data

Datos de velocidad Velocidad deseada

Datos de zona Exactitud de la posición

Datos de la herramienta

Selección de la herramienta. Dicha herramienta es creada con

anterioridad y tiene definida toda la información referente a;

peso, posición del TCP, etc. Los datos de la herramienta están

guardados en un dato de tipo Tool Data

Datos de objeto tratado Selección del sistema de coordenadas de referencia actual

Capítulo 3 69

En la Tabla 2-5 se muestran las variables utilizadas en la programación de la secuencia.

Tabla 2-5: Variables utilizadas en la programación de la secuencia Pick & Place doble.

En las siguientes secciones se pueden observar los diagramas de flujo que describen el

funcionamiento de cada una de las rutinas programadas, con el fin de lograr la secuencia

de movimiento mostrada en la Figura 2-5. Para acceder al código de programación

desarrollado para esta aplicación consulte el anexo A.

Nombre de la variable Tipo Var Tipo Dato Descripción

Counter PERS intnum

Variable que se inicializa en el numero de

secuencias programadas por el usuario, y tiene un

decremento cada vez que el robot ejecuta una

secuencia

EnMov PERS intnumVariable usada para indicar que el robot esta en

movimiento

DO1 Digital out BooleanSeñal digital virtual. Es el comando de inicio de la

secuencia.

PAUSEING VAR intnum

Variable que activa la interrupción externa

PAUSARSECUENCIA. Su valor depende de la señal

digital virtual DO2

STOPING VAR intnum


DETENERSECUENCIA. Su valor depende de la señal

digital virtual DO3

RESETCONT VAR intnum


RESETCONT. Su valor depende de la señal digital

virtual DO4

PARAR PERS intnumVariable de control usada para detener la secuencia

en ejecución

CounterTotal PERS intnumVariable que almacena el numero total de

secuencias ejecutadas por el robot

CounterStop PERS intnumVariable que almacena el numero total de paradas

realizadas por el/los usuarios

CounterPause PERS intnumVariable que almacena el numero total de pausas

realizadas por el/los usuarios

HOME PERS intnumVariable usada para indicar que el robot esta en la

posición de Target_10

HOME1 PERS intnumVariable usada para indicar que el robot esta en una

posición intermedia entre Target_10 y Target_20

HOME2 PERS intnumVariable usada para indicar que el robot esta en la


IZQ2 PERS intnumVariable usada para indicar que el robot esta en la


IZQ4 PERS intnumVariable usada para indicar que el robot esta en la


DER2 PERS intnumVariable usada para indicar que el robot esta en la


DER4 PERS intnumVariable usada para indicar que el robot esta en la




2.3.1 Rutina principal (main)

INICIO

HOME = 1

PARAR = 1? NO

SI

Habilitar interrupciones externas (OPC)

PAUSARSECUENCIA

DETENERSECUENCIA

DO2 INTERRESET

TomarObjeto

DejarIzquierda

DejarDerecha

Counter --

CounterTotal ++

VOLVERAHOME:

PARAR = 0

MoveL Target_10

EnMov = 0

HOME = 1

HOME1 = 0

HOME2 = 0

DER2 = 0

IZQ2 = 0

DER4 = 0

IZQ4 = 0

NO PARAR = 1?

SI

NO PARAR = 1?

SI

SI

NO DO1 = 1?

Counter = AO1

SI

NO Counter > 0?

FIN

Figura 2-6: Diagrama de flujo de la rutina main secuencia Pick & Place doble.

NO

SI

PARAR = 1?

Nota:

La rutina main fue programada para repetirse

en bucle infinito. Para detener su ejecución, el

usuario puede utilizar las teclas de ejecución de

programas del FlexPendant (Figura 2-3).

Capítulo 3 71

2.3.2 Rutina Tomar Objeto

Tabla 2-6: Instrucciones de movimiento para la rutina TomarObjeto.

Posición

Robtarget Target_10 Target_20

Instrucción RAPID MoveL MoveL

Velocidad v500 v500

Zona de precisión z5 z5

Sistema Coordenado World World

TomarObjeto

EnMov = 1

PARAR = 1 NO

MoveL Target_10

HOME = 1

IZQ2 = 0

DER2 = 0

PARAR = 1 NO

MoveL Target_20

HOME2 = 1

HOME = 0

PARAR = 1 NO

MoveL Target_10

HOME = 1

HOME2 = 0

FIN

Figura 2-7: Diagrama de flujo de la rutina TomarObjeto secuencia Pick & Place doble.



2.3.3 Rutina Dejar Izquierda

Tabla 2-7: Instrucciones de movimiento para la rutina DejarIzquierda.

Posición



Velocidad v500 v500



DejarIzquierda

EnMov = 1

PARAR = 1 NO

MoveL Target_30

IZQ2 = 1

HOME = 0

PARAR = 1 NO

MoveL Target_40

IZQ4 = 1

IZQ2 = 0

PARAR = 1 NO

MoveL Target_30

IZQ2 = 1

IZQ4 = 0

FIN

Figura 2-8: Diagrama de flujo de la rutina DejarIzquierda secuencia Pick & Place doble.

Capítulo 3 73

2.3.4 Rutina Dejar Derecha

Tabla 2-8: Instrucciones de movimiento para la rutina DejarDerecha.

Posición



Velocidad v500 v500



DejarDerecha

EnMov = 1

PARAR = 1 NO

MoveL Target_50

DER2 = 1

HOME = 0

PARAR = 1 NO

MoveL Target_60

DER4 = 1

DER2 = 0

PARAR = 1 NO

MoveL Target_50

DER2 = 1

DER4 = 0

FIN

Figura 2-9: Diagrama de flujo de la rutina DejarDerecha secuencia Pick & Place doble.



2.3.5 Interrupciones externas Detener, Pausar y Reset

Las acciones para detener secuencia, pausar secuencia y reinicio de contadores, fueron

programadas haciendo uso de interrupciones externas. De esta forma, el usuario del

sistema, puede ejecutar dichas acciones en el robot, independientemente del punto en el

que se encuentre el puntero del programa.

En el lenguaje RAPID, las interrupciones permiten ejecutar el contenido de un tipo de rutina

especial denominada TRAP. Hay tres tipos de eventos que permiten activar una rutina

TRAP; el cambio de valor de una entrada o salida a 1 o a 0, el transcurso de un intervalo

de tiempo tras hacer una petición de interrupción, y la llegada a una posición especifica.

En la aplicación aquí descrita, se utilizó la activación de interrupciones por medio del

cambio de las salidas digitales virtuales DO2, DO3 y DO4, para activar las rutinas TRAP;

PAUSARSECUENCIA, DETENERSECUENCIA Y INTERRESET respectivamente. Las

Figura 2-10 (a), (b) y (c) muestran el contenido de las rutinas TRAP utilizadas en esta

aplicación. Para más información acerca de las interrupciones en RAPID consulte [37].

PAUSARSECUENCIA

EnMov = 0

StopMove

DO2 = 1? SI

CounterPause ++

StartMove

Counter > 0?

NO

FIN

EnMov = 1

DETENERSECUENCIA

FIN

INTERRESET

CounterTotal = 0

CounterStop = 0

CounterPause = 0

PARAR = 1

CounterStop ++

FIN

SI

NO

(a)

(b)

(c)

Figura 2-10: Diagramas de flujo de las rutinas TRAP utilizadas para ejecutar las acciones (a) pausar secuencia, (b) detener secuencia y (c) reestablecer contadores.

Capítulo 3 75

3. Sistema SCADA e implementación de las comunicaciones por estándar OPC

En este capítulo se presentan las herramientas de software utilizadas para la

implementación del sistema SCADA y el HMI desarrollados en este proyecto. Por otra

parte, se hace una descripción detallada de las funcionalidades incorporadas en las

interfaces gráficas, así como de la arquitectura de comunicaciones implementada para

lograr el intercambio de información entre los equipos de monitorización y control de la

marca Allen Bradley ubicados en LabAuto, y los robots industriales IRB 140 de la marca

ABB ubicados el LabSIR.

3.1 Softwares de desarrollo utilizados

Con el fin de ofrecer una visión general de las plataformas en las que se implementaron

los desarrollos descritos en secciones posteriores de este capítulo, a continuación, se hace

una presentación resumida de las herramientas de software que fueron utilizadas con tal

propósito.

3.1.1 Software SCADA Ignition 8

Ignition es una herramienta de software basada en servicios Web multiplataforma,

desarrollada por Inductive Automation y lanzada al mercado en 2010, que incorpora

características de software SCADA, MES, IIoT (Industrial IoT), HMI, ERP, Industrial Mobile,

etc. En la actualidad Ignition está disponible en su versión 8.0.16 y ha sido anunciada la

versión 8.1 para finales de 2020. Ignition se ejecuta haciendo uso de navegadores Web,

por lo que puede utilizarse sobre los sistemas operativos más comunes. Por otra parte, no

tiene un límite en cuanto al número de usuarios y/o dispositivos que pueden conectarse



simultáneamente a las aplicaciones desarrolladas en computadores de escritorio, pantallas

industriales, o pantallas móviles [38].

Ignition es un software modular, que permite la instalación de múltiples funcionalidades

adicionales al paquete de software básico. El paquete básico está disponible en una

versión de prueba, que puede ser utilizada de forma continua por un periodo de 2 horas.

Una vez transcurrido este tiempo, todos los servicios deben ser reiniciados para poder

disponer de un nuevo periodo de prueba de dos horas. Inductive Automation y algunos de

sus socios estratégicos como Cirrus Link, ponen a disposición de sus clientes módulos de

software que permiten desarrollar aplicaciones específicas como; servidores o clientes

OPC, Inyectores IoT, servidores MQTT, etc.

Así pues, la disponibilidad de una versión gratuita y la versatilidad para el desarrollo de

múltiples aplicaciones en el entorno de la Automatización Industrial y de la industria 4.0

que ofrece Ignition, se convirtieron en los factores decisivos para seleccionarlo como el

software de desarrollo principal en la implementación de este proyecto.

3.1.2 Softwares de Rockwell Automation

Son dos los equipos de Allen Bradley utilizados en este proyecto; el primero es un PAC

modular Compac LOGIX 5370 L3 – 1769 – L30ELRM y el segundo es una pantalla HMI

Panel View Plus 1000. Con el fin de desarrollar la configuración y programación de dichos

equipos se utilizaron las siguientes herramientas de software:

Studio 5000 Logix Designer: software desarrollado por Rockwell Automation para la

configuración, mantenimiento y programación de la familia de controladores Allen

Bradley Logix5000 (para este caso, el controlador utilizado es el Compac LOGIX 5370

L3 – 1769 – L30ELRM). Para la aplicación desarrollada en este proyecto se usó la

versión 21 de este software.

Factory Talk View Studio Machine Edition: es un software desarrollado por Rockwell

Automation para la configuración, mantenimiento y programación de aplicaciones con

interfaz de operador a nivel de máquina, soportadas en PC o en dispositivos Panel

View Plus de Allen Bradley. En este proyecto se utilizó la versión 9 de este software.

Capítulo 3 77

SoftLogix 5800: es un software desarrollado por Rockwell Automation para la

virtualización de controladores Allen Bradley, que permite realizar simulaciones en

línea de CPU’s, módulos I/O, conexión a redes abiertas (Ethernet/IP, ControlNet y

DeviceNet) y juego de herramientas backplane virtual. Para la aplicación desarrollada

en este proyecto se usó la versión 21 de este software.

3.1.3 IRC5 OPC Server

IRC5 OPC Server es una herramienta de software desarrollada por el grupo ABB, con el

objetivo de permitir la integración de los controladores IRC5 con las aplicaciones y

protocolos pertenecientes al nivel 3 del modelo CIM (Figura 1-1) [39]. Actualmente el

software está disponible en dos de las especificaciones de OPC Foundation; IRC5 OPC

DA Server V6.11 y IRC5 OPC UA Server V1.0 (lanzada en junio de 2020).

El servidor OPC IRC5 cuenta con los drivers específicos para la conexión de controladores

IRC5, por lo tanto, permite exponer la información de dichos controladores para que pueda

ser consumida por los clientes OPC u otros servidores OPC. El producto tiene dos

componentes:

- Un servidor OPC que se ejecuta en segundo plano, encargado de gestionar y

administrar la transferencia bidireccional de información con los controladores IRC5

que se encuentren conectados.

- Una interfaz de usuario que permite gestionar, autorizar y configurar las conexiones

con los controladores IRC5 que tendrán acceso al servidor. Entre las

configuraciones se tiene la posibilidad de establecer credenciales de seguridad,

asignar los alias a los controladores, configurar la taza de encuesta, etc.

Es importante resaltar que el IRC5 OPC Server no cuenta con un cliente OPC, por lo tanto,

es necesario desarrollar un cliente OPC externo (por ejemplo, en un sistema SCADA o un

dispositivo HMI con especificaciones OPC) para poder realizar acciones de

lectura/escritura sobre los controladores IRC5 conectados al servidor. Para más

información acerca de las prestaciones y limitantes del IRC5 OPC Server consulte [39].



3.2 Arquitectura de red implementada

Luego de hacer las solicitudes correspondientes a la OTIC (Oficina de Tecnologías de la

Información y las Comunicaciones) de la Universidad Nacional de Colombia sede Bogotá,

fueron asignadas las direcciones IP para los controladores IRC5 ubicados en LabSIR (ver

Tabla 3-1). Por otra parte, y teniendo en cuenta las recomendaciones de la OTIC, se realizó

la instalación de un switch de tipo industrial (propiedad de la universidad) en el laboratorio

LabSIR. Así mismo, se retiró el router de uso residencial que se encontraba instalado en

el laboratorio LabAuto. La arquitectura de red entre los dos laboratorios quedo configurada

como se muestra en la Figura 3-1.

Figura 3-1: Arquitectura de red entre los laboratorios LabAuto y LabSIR.

La Tabla 3-1 muestra las direcciones IP de los equipos que se utilizaron para la

implementación de este proyecto.

Tabla 3-1: Direcciones IP de los equipos mostrados en la Figura 3-1.

Equipo Dirección IP

PAC Allen Bradley #8 10.203.3.253

Panel View Plus 1000 #2 10.203.3.245

IRC5 ABB 168.176.26.213

PC's LabAuto Asignadas dinámicamente

PC's LabSIR Asignadas dinámicamente

Capítulo 3 79

Figura 3-2: Arquitectura de comunicaciones del sistema implementado.

3.3 Arquitectura de comunicaciones implementada

Como se mencionó en secciones anteriores, las comunicaciones entre las aplicaciones

implementadas en este proyecto fueron realizadas utilizando el estándar OPC. Así pues,

las comunicaciones están basadas en una arquitectura cliente/servidor (Figura 3-2),

compuesta por:

Servidores OPC: se utilizaron dos servidores OPC:

- IRC5 OPC Server: incluye los drivers necesarios para intercambiar información con

controladores IRC 5 ABB, por medio de Ethernet TCP/IP. En este proyecto se utilizó

la especificación OPC DA en su versión 6.11.

- Ignition OPC UA Server: es un módulo de software disponible en Ignition. Permite

crear un servidor OPC UA que incluye los drives necesarios para intercambiar

información con dispositivos Allen-Bradley por medio de Ethernet.

Cliente OPC: se tiene un único cliente OPC, embebido en el sistema SCADA que se

desarrolló sobre la plataforma Ignition 8.0.16. Este cliente OPC se ejecuta dentro del

computador que contiene la aplicación. De esta forma, los usuarios de las interfaces

gráficas, pueden intercambiar información con los servidores OPC a través del cliente

OPC.



3.3.1 Flujo de datos del sistema implementado

El sistema mostrado en la Figura 3-2 permite la interacción de los usuarios desde tres

terminales distintos; un HMI ubicado en LabAuto, la interfaz de usuario del sistema SCADA

(corriendo en un PC ubicado en LabAuto) y la interfaz para usuarios de dispositivos Android

(a la cual se puede acceder desde cualquier ubicación que este dentro de la red de la

universidad). En esta sección se hace una descripción detallada de cómo se realiza el flujo

de datos entre las distintas interfaces de usuario y el robot (virtual o real).

3.3.1.1 Flujo de datos para usuarios del sistema SCADA

El sistema SCADA implementado se ejecuta desde un PC ubicado en LabAuto (sin

embargo, los desarrollos pueden migrarse a un computador conectado a la red de la

universidad, con cualquier ubicación dentro de la misma). El usuario puede interactuar con

el robot real ubicado en LabSIR, o con un robot virtual simulado en Robot Studio siguiendo

el flujo de datos mostrado en la Figura 3-3.

A continuación, se describe la forma en la que se realiza el intercambio de información en

cada una de las etapas de la arquitectura mostrada en la Figura 3-3.

Figura 3-3: Flujo de datos entre el sistema SCADA implementado y los robots ABB

PC LabAuto LabSIR

1 1 4 4

3 2 2 3

Capítulo 3 81

1. El cliente OPC de Ignition y la interfaz gráfica del SCADA se ejecutan en el mismo

PC (ubicado en LabAuto), y se conectan directamente por medio del Gateway de

Ignition que corre en segundo plano. Por otra parte, el Gateway de Ignition permite

la comunicación entre un terminal Android y el cliente OPC de Ignition, por medio

del protocolo HTTP a través del puerto 8088. Los dispositivos Android deben tener

instalada la aplicación Ignition Perspective para poder acceder a la interfaz gráfica,

y adicionalmente, deben estar conectados a la misma red que el PC en el que se

ejecuta el sistema SCADA. El servidor IRC5 OPC DA se ejecuta en el PC que

contiene al sistema SCADA, pero no está embebido en la misma aplicación. Por lo

tanto, la comunicación entre el cliente OPC de Ignition y el servidor OPC IRC5 se

realiza por medio del protocolo TCP, haciendo uso de la tecnología DCOM de

Microsoft disponible en sistemas operativos Windows.

De esta forma, cuando el usuario ejecuta una acción de mando desde la interfaz

gráfica del SCADA, o desde la interfaz gráfica para dispositivos Android, la acción

de mando es recibida por el cliente OPC de Ignition, que la escribe en un tag de

tipo OPC asociado directamente con el servidor OPC IRC5. De esta forma, las

acciones de mando ingresadas por los usuarios de las interfaces graficas del

sistema, se convierten en valores de tag recibidos por el servidor OPC IRC5.

2. El servidor OPC IRC5 incluye los drivers necesarios para realizar el intercambio de

información bidireccional con el Controlador IRC5. La comunicación con el

controlador IRC5 físico (ubicado en LabSIR), se realiza por medio de Ethernet

TCP/IP, gracias a la opción PC Interface de ABB, que proporciona una interfaz de

comunicaciones entre el controlador del robot y los PCs conectados a la red. El

software Robot Studio se ejecuta dentro del mismo PC que contiene al sistema

SCADA, y la comunicación entre el servidor OPC IRC5 y el controlador IRC5 virtual

se realiza bajo las mismas especificaciones usadas para la comunicación con el

controlador IRC5 físico.

De esta forma, el servidor OPC IRC5 transmite las acciones de mando ingresadas

por el usuario desde la interfaz gráfica del SCADA, para que puedan ser

procesadas por el controlador IRC5 (físico o virtual). Por último, el controlador IRC5

hace que las acciones de mando sean ejecutadas por el robot IRB 140.



3. Una vez establecida la conexión entre el servidor OPC IRC5 y el controlador IRC5

(real o virtual), la comunicación es bidireccional. Por lo tanto, el servidor OPC IRC5

tiene acceso a todas las variables de programa y a la mayoría de las variables de

sistema del controlador IRC5.

4. La comunicación entre el cliente OPC y el servidor OPC IRC5 es bidireccional. Por

lo tanto, el valor de las variables de programa y de sistema consideradas

relevantes, son actualizadas y están disponibles para el cliente OPC, que las

convierte en valores de tag. De esta forma, los usuarios de las interfaces graficas

podrán tener acceso a la información de estado del controlador IRC5 en cualquier

momento.

3.3.1.2 Flujo de datos para usuarios del HMI

La HMI implementada se ejecuta en un Panel View Plus 1000 de Allen Bradley ubicado en

LabAuto. El usuario puede interactuar con el robot real ubicado en LabSIR, o con un robot

virtual simulado en Robot Studio siguiendo el flujo de datos mostrado en la Figura 3-4.

A continuación, se describe la forma en la que se realiza el intercambio de información en

cada una de las etapas de la arquitectura mostrada en la Figura 3-4.

1. La HMI desarrollada en el Panel View Plus 1000 se comunica con el PAC Compac

LOGIX 5370 L3 – 1769 – L30ELRM por medio de Ethernet/IP. Ambos dispositivos

1

6

2 5 3 4 3 4

LabAUTO LabSIR PC LabAuto

Figura 3-4: Flujo de datos entre la HMI implementada y los robots ABB

Capítulo 3 83

están ubicados en LabAuto, y ya que ambos equipos son del mismo fabricante

(Allen Bradley), no se requieren herramientas de software intermediarias para su

comunicación. Las variables de programa existentes en el PAC, son accesibles

desde la HMI. De esta forma, cuando el usuario ingresa acciones de mando desde

la HMI, afecta directamente las variables de programa del PAC, lo que permite su

procesamiento.

2. Se tiene un servidor bajo especificación OPC UA embebido en el sistema SCADA.

Dicho servidor fue creado en el Gateway de Ignition y contiene los drivers

necesarios para realizar el intercambio de información con controladores Allen

Bradley mediante Ethernet/IP. Por lo tanto, el servidor tiene acceso para hacer

acciones de lectura/escritura en todas las variables de programa existentes en el

PAC. De esta forma, las acciones de mando ingresadas por el usuario en la HMI,

son transmitidas por el PAC al servidor OPC UA por medio de las variables de

programa.

3. El cliente OPC de Ignition se conecta al servidor OPC UA de forma automática por

medio de una URL que contiene la dirección IP y el puerto de transmisión, o el Local

Host del servidor OPC UA denominada End Point. De esta forma, el cliente OPC

puede acceder a todas las variables de programa del PAC por medio del servidor

OPC UA. Así pues, en la aplicación implementada; el cliente OPC recibe las

acciones de mando ingresadas por el usuario desde la HMI y las convierte en

valores de tag.

Adicionalmente se creó un script en el diseñador de Ignition, que detecta cuando

ocurre un cambio en el valor de uno de los tags asociados al servidor OPC UA, y

escribe dicho valor en el tag correspondiente asociado al servidor OPC IRC5. Por

último, el servidor OPC IRC5 escribe dichos valores de tag en las variables de

programa del controlador IRC5 (físico o virtual), para que pueda procesarlas,

haciendo que el robot IRB140 las ejecute.

4. Las comunicaciones establecidas entre el controlador IRC5 y el servidor OPC IRC5,

son bidireccionales. Por lo tanto, el servidor OPC IRC5 tiene acceso a todas las

variables de programa y a la mayoría de las variables de sistema del controlador



IRC5, y las transmite en tiempo real al cliente OPC, que las convierte en valores de

tag.

5. El cliente OPC transmite el estado de las variables de programa y de sistema del

controlador IRC5 a la interfaz gráfica del SCADA. Y de la misma forma descrita en

la etapa 3, se programó un script que detecta cuando ocurre un cambio de valor en

uno de los tags asociados al servidor OPC IRC5, y escribe dicho valor en el tag

correspondiente asociado al servidor OPC UA, que a su vez actualiza la variable

de programa correspondiente dentro del PAC.

6. Dado que las variables de programa del PAC son accesibles de forma directa en la

HMI, el usuario puede visualizar el estado de las variables de programa y de

sistema del controlador IRC5 en la HMI.

Capítulo 3 85

3.4 Interfaces graficas del sistema

El sistema SCADA desarrollado para este proyecto se implementó haciendo uso de la

herramienta de software Perspective disponible en el Diseñador de Ignition, en su versión

8.0.16. Las interfaces gráficas del sistema incluyen funcionalidades de visualización,

mando y supervisión del estado de las variables de programa del controlador IRC5 (físico

o virtual). En esta sección se hace una descripción detallada de cada una de las

funcionalidades incluidas en las interfaces gráficas del sistema SCADA implementado.

3.4.1 Interfaz gráfica para PC y dispositivos Android

La interfaz grafica principal del sistema, se ejecuta en el PC que contiene al SCADA y

consta de cuatro pantallas que pueden ser seleccionadas por el usuario a traves de un

menu de seleccion. A continuacion se describen las funcionalidades incorporadas en cada

una de las pantallas que lo conforman.

Interfaz gráfica general

La interfaz gráfica general mostrada en la Figura 3-5, permite al usuario del sistema

ingresar acciones de mando y visualizar el estado, tanto del robot físico ubicado en

LabSIR, como del robot virtual simulado en Robot Studio.

Figura 3-5: Interfaz gráfica general del sistema SCADA.

1 2

3

4

5

6

7 8

9 10

11 12



La Tabla 3-2 muestra la función que cumple cada elemento mostrado en la Figura 3-5.

Tabla 3-2: Elementos de mando y monitorización interfaz gráfica general.

Interfaces gráficas independientes para el robot virtual y el robot real

Se desarrollaron dos interfaces graficas adicionales que permiten realizar acciones de

mando y visualizar el estado del robot físico ubicado en LabSIR, y del robot virtual

simulado en Robot Studio de forma independiente. En la Figura 3 6 se muestra la

interfaz gráfica desarrollada para el robot virtual, sin embargo, es importante resaltar

que la interfaz gráfica desarrollada para el robot real cuenta con los mismos elementos.

En la Tabla 3 3 se puede observar la función que cumple cada elemento de la interfaz

gráfica mostrada en la Figura 3-6.

Item NombreVariable de programa

asociada (Tabla 2-5)Descripción

1 Enable Robot Virtual NA

Es una Check Box con auto retención. Esta opción debe estar seleccionada

para que las acciones de mando ingresadas por el usuario se ejecuten en

el robot virtual simulado en Robot Studio

2 Enable Robot Real NA



el robot físico ubicado en LabSIR

3 Numero de secuencias CounterEs un Numeric Input. Permite que el usuario ingrese el numero de

secuencias que el robot (virtual y real) debe ejecutar

4 Start general DO1Es un pulsador sin auto retención. Permite al usuario iniciar la ejecución

de la secuencia de movimiento en el robot (virtual y real)

5 Pause general PAUSEING

Es un interruptor con auto retención. Permite al usuario pausar la

ejecución de la secuencia de movimiento del robot (virtual y real),

deteniéndolo de forma inmediata sin importar su posición

6 Stop general STOPING

Es un pulsador sin auto retención. Permite al usuario detener la ejecución

de la secuencia de movimiento en el robot (virtual y real) una vez alcance

un Target. Luego envía el robot a la posición Home (Target_10)

7 Robot virtual activo EnMovEs un piloto de señalización. Permite al usuario visualizar cuando el robot

virtual esta en movimiento

8 Robot real activo EnMovEs un piloto de señalización. Permite al usuario visualizar cuando el robot

real esta en movimiento

9 Selector de contador NAEs una Lista de Selección. Permite al usuario seleccionar el contador que

desea visualizar en pantalla (virtual o real)

10 Secuencias faltantes CounterEs un Display Led. Permite al usuario visualizar en pantalla el numero de

secuencias que le quedan por ejecutar al robot (virtual o real)

11 Reset de contadores RESETCONT

Es un pulsador sin retención. Permite al usuario reiniciar los contadores;

CounterTotal, CounterStop, CounterPause. El reset solo es posible si

Contraseña contiene un valor valido.

12 Contraseña NAEs un Text Input. Permite al usuario ingresar una contraseña de validación

para obtener permiso de reiniciar los contadores.

Capítulo 3 87

Figura 3-6: Interfaz gráfica para robot virtual (la interfaz gráfica del robot real cuenta con los mismos elementos).

Tabla 3-3: Elementos de mando y monitorización interfaz gráfica del robot virtual.

Item NombreVariable de programa

asociada (Tabla 2-5)Descripción

1 Enable Robot Virtual NA



el robot virtual simulado en Robot Studio

2 Numero de secuencias CounterEs un Numeric Input. Permite que el usuario ingrese el numero de

secuencias que el robot virtual debe ejecutar

3 Start virtual DO1Es un pulsador sin auto retención. Permite al usuario iniciar la ejecución

de la secuencia de movimiento en el robot virtual

4 Pause virtual PAUSEING

Es un interruptor con auto retención. Permite al usuario pausar la

ejecución de la secuencia de movimiento del robot virtual, deteniéndolo

de forma inmediata sin importar su posición

5 Stop virtual STOPING


de la secuencia de movimiento en el robot virtual una vez alcance un

Target. Luego envía el robot a la posición Home (Target_10)

6 Secuencias faltantes CounterEs un Display Led. Permite al usuario visualizar en pantalla el numero de

secuencias que le quedan por ejecutar al robot virtual

7 Robot virtual activo EnMovEs un piloto de señalización. Permite al usuario visualizar cuando el robot

virtual esta en movimiento

8 Visualizador

HOME, HOME1,

HOME2, IZQ2, IZQ4,

DER2, DER4

Es un Image Output. Permite al usuario visualizar las posiciones que acaba

de completar el robot a medida que las va alcanzando

1

3

4

5

2

6

7

8



Visualización de históricos del sistema

Con el objetivo de integrar herramientas de análisis, respecto a la eficiencia en el uso

del sistema implementado, se incluyeron gráficos que permiten observar el número

total de secuencias que se han ejecutado en el robot, versus el número de paradas y

el número de pausas que los usuarios realizaron en un intervalo de tiempo que es

configurable (Figura 3-7).

Figura 3-7: Visualización de históricos sobre el uso del robot.

Los gráficos mostrados en la Figura 3-7 permiten a usuarios de los niveles 3 y 4 del

modelo CIM (Figura 1-1), analizar dos aspectos:

- El cumplimiento o no, del número de rutinas previstas para ser ejecutadas por el

robot en un intervalo de tiempo definido.

- El número de veces que el operador del sistema realizo paradas o pausas no

programadas del robot, para identificar posibles fallas del proceso o errores de

operación.

Como es de esperarse, el restablecimiento de los contadores debe restringirse para

que no pueda ser realizado por personal no autorizado, ya que es un indicador de

calidad de la operación del sistema. Por esta razón, el restablecimiento de los

contadores solo puede ser ejecutado en las interfaces gráficas, por personal que

cuente con una contraseña válida para realizar esta acción (ver ítem 12 de la Figura

3-5).

Capítulo 3 89

Gestión de alarmas del sistema

Se incluyeron dos alarmas en el sistema:

- Un piloto de señalización que le indica al operador, cuando el robot está en

movimiento y cuando está detenido (ver ítems 7 y 8 de la Figura 3-5).

- Una alarma implementada en Ignition Perspective, que le indica al operador cuando

el robot ha ejecutado un determinado número de secuencias y requiere que se

realicen actividades de mantenimiento. Adicionalmente, se envía un correo

electrónico al personal que corresponda, informándoles cuando se presente la

alarma y cuando sea retirada del sistema.

El piloto que indica el movimiento del robot, se encuentra incluido en las interfaces

graficas mostradas en las Figura 3-5Figura 3-6. Por otra parte, la alarma que indica la

necesidad de realizar un mantenimiento programado, se muestra en una pantalla

independiente (Figura 3-8), a la que los usuarios pueden acceder por medio del menú

de selección.

Figura 3-8: Pantalla de alarmas del sistema SCADA.

3.4.2 Interfaz gráfica HMI

En la interfaz grafica desarrollada para la HMI ubicada en LabAuto, se icluyeron todas las

funcionalidades de visualizacion y mando incorporadas en las interfaces graficas del

sistema SCADA. Sin embargo no se incluyeron las funcionalidades para visualizacion de

historicos, ni la alarma de mantenimiento.



A continuación, se muestran las pantallas desarrolladas en el HMI de LabAuto. En la Figura

3-9 se muestra la pantalla de inicio, que cuenta con tres opciones que permiten navegar

por la HMI general del sistema, la HMI para el robot virtual y la HMI para el robot real.

Adicionalmente, se tiene una cuarta opción denominada Shutdown, que permite terminar

la ejecución de la aplicación.

Figura 3-9: Pantalla de inicio, HMI LabAuto.

En la Figura 3-10 se muestra la HMI general. Incluye cada una de las funcionalidades

incorporadas en la interfaz gráfica general del sistema SCADA (Figura 3-5).

Adicionalmente, cuenta con un menú de selección que permite al usuario navegar entre

las distintas pantallas.

Figura 3-10: Pantalla general, HMI LabAuto.

Capítulo 3 91

Por último, en la Figura 3-11 se muestra la HMI desarrollada para el robot virtual.

Nuevamente, se incluyeron todas las funcionalidades de la interfaz gráfica desarrollada

para el robot virtual en el sistema SCADA (Figura 3-6). De igual forma, se incluyó un menú

de selección que permite al usuario navegar entre pantallas.

Figura 3-11: Pantalla para el robot virtual, HMI LabAuto (la pantalla desarrollada para el robot real cuenta con las mismas funcionalidades).

4. Integración con plataforma IoT

En este capítulo se presenta un resumen de las herramientas de software, utilizadas para

la integración de las aplicaciones desarrolladas en este proyecto con las tecnologías IoT.

Por otra parte, se hace una descripción detallada de la arquitectura de comunicaciones

implementada y de las funcionalidades incluidas en los desarrollos implementados.

4.1 Herramientas de software utilizadas

En esta sección se hace una descripción resumida de las herramientas de software

utilizadas, con el objetivo de integrar los desarrollos descritos en los capítulos 2 y 3, con

las tecnologías IoT de la denominada Industria 4.0.

4.1.1 IBM Watson IoT Plataform

IBM Watson IoT Plataform es un servicio ofrecido por IBM (International Business

Machines) contenido y gestionado por completo en cloud. IBM Watson ofrece una gran

diversidad de funcionalidades que permiten el registro de dispositivos utilizados en

aplicaciones IoT, así como la gestión de la conectividad y el control de los mismos, y la

visualización y almacenamiento de sus datos [40].

Uno de los aspectos más importantes a tener en cuenta para el desarrollo de aplicaciones

IoT e IIoT, es la seguridad de la información que ofrecen las plataformas cloud que las

alojan. En este sentido, IBM Watson implementa y mantiene en cada uno de sus servicios

cloud, medidas de seguridad para la información y los datos, con certificaciones anuales

de las normas ISO 27001 y SSAE SOC 2 para cada uno de sus servicios [41].

Algunos de los servicios IoT que IBM ofrece, cuentan con versiones gratuitas de prueba

con alojamiento en cloud limitado. Este es el caso del servicio Internet of Things Plataform

utilizado para el desarrollo de este proyecto. A continuación, se describen las

características básicas de este servicio.

Capítulo 4 93

4.1.1.1 Internet of Things Plataform

Internet of Things Plataform es un servicio que actúa como el concentrador de información

de IBM Watson IoT, facilitando la conexión y el intercambio de datos con los Gateways y

dispositivos especificados por integradores. Este servicio cuenta con paneles de control en

la consola web que facilitan la supervisión de datos IoT y su análisis en tiempo real. Por

supuesto, la plataforma permite implementar la conexión con aplicaciones (internas o

externas) utilizando mensajería y API REST, por lo que es el desarrollador quien impone

el límite de mejora y personalización de la experiencia de usuario [42]. La Figura 4-1

muestra la arquitectura de comunicaciones básica para este servicio.

Figura 4-1: Arquitectura de comunicaciones IBM Watson IoT Plataform [42].

4.1.2 EMQX Broker

EMQX es un Broker MQTT de código abierto desarrollado en la plataforma Erlang / OTP.

Incorpora prestaciones que permiten el acceso masivo de clientes y el intercambio de

mensajes (con dichos clientes, o con otros Brokers) mediante una estructura publicación /

suscripción [43]. Por otra parte, EMQX es compatible con los principales protocolos de



comunicación IoT, como; MQTT, CoAP, LwM2M, LoraWAN, etc. Además, es compatible

con el protocolo MQTT V3.1 / V3.1.1 y V5.0, por lo que permite la conexión de cualquier

dispositivo que soporte dicha tecnología. La versión de EMQX utilizada en este proyecto

es la 4.0.10.

A continuación, se enuncian las características principales de EMQX por las cuales fue

seleccionado para la implementación de este proyecto:

- Completa compatibilidad con los protocolos MQTT V3.1 / V3.1.1 y V5.0 y cuenta

con soporte para calidades de servicio QoS0, QoS1, QoS2.

- Garantía de seguridad a través de TLS / DTLS y certificado X.509.

- Se puede ejecutar desde equipos informáticos de borde x86 / ARM y desde

alojamientos cloud privados, híbridos y públicos. Es compatible con los principales

sistemas operativos; Linux, Windows, FreeBSD y Mac OS. Además, se puede

implementar en contenedores como Docker, Kubernetes y Swarm.

- Cuenta con una versión de prueba gratuita que, aunque no cuenta con todas sus

funcionalidades, es ideal para el desarrollo de pruebas y proyectos académicos.

4.1.3 Módulos MQTT Engine y MQTT Distributor

MQTT Engine es un módulo desarrollado por Cirrus Link, como complemento para el

software SCADA Ignition 8. MQTT Engine está enfocado a la integración de sistemas

SCADA desarrollados en la plataforma Ignition de Inductive Automation con plataformas

IoT e IIoT, basadas en servicios de mensajería. Este módulo usa puertas de enlace que

permiten realizar un sondeo de protocolo propietario en el borde de la red del sistema

SCADA, de esta forma se crea un canal de transmisión para todos los datos del mismo.

Por otra parte, el módulo MQTT Distributor de Cirrus Link, permite la creación de un

servidor MQTT que se ejecuta desde el Gateway de Ignition 8. Gracias a este servidor

todos los equipos y aplicaciones usadas como nodo de borde con soporte para protocolo

MQTT y compatibilidad con las especificaciones de Cirrus Link, pueden establecer

comunicación de forma directa con esta infraestructura y acceder a los datos del sistema

SCADA disponibles gracias al módulo MQTT Engine [43]. Entre las ventajas que tiene el

uso de estos módulos sobresalen:

Capítulo 4 95

- Mejoras en el rendimiento y la eficiencia para intercambiar datos; gracias a que el

sondeo se realiza en el borde de la red, logrando que los equipos que soporten

MQTT publiquen información de forma directa.

- Disponibilidad de utilidades de código abierto que permiten incorporar en la

infraestructura de comunicaciones equipos de terceros.

- Creación de tags por autoaprendizaje. Cuando MQTT Engine se suscribe a las

puertas de enlace de borde por medio de MQTT Distributor, detecta

automáticamente todas los tags de datos y los crea dentro de Ignition para que

puedan ser utilizados por el desarrollador.

- Creación de tags que contienen las métricas sobre el estado de la infraestructura

de comunicaciones de forma automática.

4.1.4 Node.js

Node.js es un entorno orientado a eventos asíncronos, diseñado para realizar la ejecución

de código JavaScript en tiempo real. Node.js no está restringido para ser ejecutado en un

navegador, sino que se puede ejecutar en un ordenador como si se tratara de una

aplicación independiente. El enfoque de Node.js no son las operaciones que exijan una

capacidad de procesamiento alta, más bien, está dirigido a la ejecución de aplicaciones de

red rápidas, ya que puede mantener un alto rendimiento mientras maneja una gran

cantidad de conexiones [45].

Este entorno está basado en un modelo de entradas (solicitudes) y salidas (respuestas)

sin bloqueo de salida. Además, no se necesita una llamada de bloqueo para iniciar el bucle

de eventos, ya que el mismo inicia después de ejecutar el script de entrada y termina

cuando ya no hay devoluciones de llamada [45]. Node.js está completamente controlado

por eventos asíncronos, por lo tanto, cuando se presenta algún tipo de solicitud se genera

un evento y es procesado por el servidor, y si se requiere un bloqueo de salida no se

detiene la ejecución, sino que se crea una función de devolución de llamada. De esta

forma, el servidor puede procesar nuevos eventos (incluyendo nuevas solicitudes), y

continuara trabajando en la devolución de llamada una vez cuente con la disponibilidad

para hacerlo. Esto implica que el servidor puede manejar una gran cantidad de solicitudes

simultaneas y, además, no necesita crear más de un subproceso, reduciendo la carga de

procesamiento. Para más información sobre las prestaciones de Node.js, consulte [45].



4.2 Arquitectura de comunicaciones implementada

En la Figura 4-2, se muestra la implementación realizada para integrar la arquitectura

mostrada en la Figura 3-2 con las tecnologías descritas en la sección anterior.

Figura 4-2: Arquitectura de comunicaciones IoT implementada.

El objetivo de la implementación mostrada en la Figura 4-2, es incorporar una interfaz

gráfica que permita al usuario del sistema realizar las tareas de mando y supervisión

descritas en el capítulo 3, desde cualquier dispositivo capaz de ejecutar un navegador web

y que cuente con conexión a Internet, sin importar su ubicación.

La arquitectura de comunicaciones mostrada en la Figura 3-2, sigue funcionando como se

describió en la sección 3.3.1. Para lograr la integración del sistema con la plataforma IoT

de IBM, se utilizaron los módulos MQTT Engine y MQTT Distributor en la plataforma

Ignition. El servidor MQTT fue creado y configurado desde el Gateway de Ignition, y no

está comunicado directamente con los servidores OPC. Por lo tanto, la relación entre las

dos infraestructuras se logra realizando acciones de lectura/escritura entre sus Tags.

4.2.1 Flujo de datos para usuarios web

Los usuarios de la interfaz gráfica web, pueden acceder a la misma desde cualquier

dispositivo que cuente con una conexión a Internet y sea capaz de ejecutar un navegador

Capítulo 4 97

web. El flujo de datos con el cual se realiza el intercambio de información entre dichos

usuarios y el robot IRB 140 (real o virtual), se muestra en la Figura 4-3.

Figura 4-3: Flujo de datos para usuarios de interfaz gráfica web.

A continuación se describe cada una de las etapas del flujo de datos mostrada en la Figura

4-3.

1. Comunicación entre la plataforma IoT de IBM y el Broker MQTT EMQX

Las comunicaciones entre estas dos plataformas están basadas en una arquitectura

publicador/suscriptor. El Broker EMQX fue configurado para escuchar clientes MQTT

usando los puertos TCP, de la siguiente forma:

- Protocolo MQTT: a través del puerto 1883.

- MQTT/WebSockets: a través del puerto 8083.

- MQTT/SSL: a través del puerto 8883.

- MQTT/WSS: a través del puerto 8084.

La aplicación creada en IBM, hace las veces de cliente MQTT. Es el cliente quien se

encarga de establecer comunicación por primera vez con el Broker MQTT usando un

mensaje de comando CONNECT que debe contener como mínimo los atributos del

formato JSON mostrado en la Figura 4-4.

1

5

6

2

3 4 3 4



Figura 4-4: Mensaje CONNECT requerido por EMQX Broker.

Si todos los atributos son validados, el Broker responde con un mensaje de comando

CONNACK. Dicho mensaje contiene los dos atributos mostrados en la Figura 4-5.

Figura 4-5: Mensaje CONNACK para confirmación de conexión con el Broker MQTT.

Si el código de retorno es 0 la conexión se estableció correctamente. Si el código de

retorno esta entre 1 y 5 la conexión fue rechazada por incumplir algún parámetro de la

especificación MQTT. Una vez la comunicación es establecida, el Broker estará a la

espera de recibir mensajes por parte del cliente MQTT.

De esta forma, cuando el usuario ingresa una acción de mando desde la interfaz gráfica

web, se publica un mensaje con el formato mostrado en la Figura 4-6, y dicho mensaje

es recibido por el Broker EMQX.

Figura 4-6: Formato de publicación de la interfaz web.

Por supuesto, el valor asociado a los atributos del objeto mostrado en la Figura 4 6,

dependerá de la acción de mando realizada por el usuario en la interfaz web.

Capítulo 4 99

2. Comunicación entre el Broker MQTT EMQX y los módulos MQTT

Los módulos MQTT Engine y MQTT Distributor, permiten la creación de un servidor

MQTT usando el Gateway de Ignition. Para establecer comunicación entre una

aplicación externa y el servidor MQTT creado en Ignition, es necesario contar con una

aplicación de borde que permita suscribir un cliente MQTT, bajo las especificaciones

requeridas por el servidor. Para la implementación de este proyecto, se desarrolló una

aplicación programada en JavaScript bajo las especificaciones de mensajería

requeridas por los módulos MQTT, que es ejecutada sobre el entorno Node.js.

La aplicación de borde se suscribe al Broker MQTT EMQX, y publica en el servidor

MQTT cada mensaje que recibe del Broker con el formato mostrado en la Figura 4-7.

Figura 4-7: Formato de mensaje requerido para publicación en MQTT Engine.

La estructura mostrada en la Figura 4-7, contiene los atributos de mensaje requeridos

por la especificación de los módulos MQTT Engine y MQTT Distributor, para realizar la

escritura en los tags asociados con los mismos. De esta forma, las acciones de mando

ingresadas por el usuario en la interfaz gráfica web, son escritas en los tags asociados

al servidor MQTT creado en Ignition.

Como ya se ha mencionado, el servidor MQTT creado en Ignition no está comunicado

directamente con los servidores OPC descritos en el capítulo 3. Por lo tanto, para que

las acciones de mando ingresadas por el usuario en la interfaz web, afecten a las

variables de programa del robot, se realizó la escritura directa entre tags. Es decir; se

programó un Script en el diseñador de Ignition, que detecta cuando ocurre un cambio

10

0



de valor en uno de los tags asociados al servidor MQTT y escribe ese valor en el

respectivo tag asociado a al servidor OPC IRC5.

3. Comunicación entre el servidor OPC IRC5 y el controlador IRC5

Una vez las acciones de mando ingresadas por el usuario en la interfaz web, son

escritas en los tags asociados con el servidor OPC IRC5. El mismo escribe dichas

acciones de mando en las variables de programa del controlador IRC5, siguiendo el

mismo proceso descrito en la etapa 2 de la sección 3.1.1.1, por lo que el robot IRB 140

(real o virtual) las ejecuta.

4. Comunicación entre el controlador IRC5 y el servidor OPC IRC5

Como ya se ha mencionado, la comunicación entre el servidor OPC IRC5 y el

controlador IRC5 es bidireccional. Por lo tanto, el servidor OPC IRC5 tiene acceso a

todas las variables de programa y a la mayoría de las variables de sistema del

controlador IRC5. De esta forma, los valores de dichas variables son escritos en tags

creados previamente en el diseñador de Ignition. Por último, cada vez que el valor de

uno de los tags asociados al servidor OPC IRC5 cambia, un script programado en el

diseñador de Ignition escribe dicho valor en el tag correspondiente del servidor MQTT.

5. Comunicación entre los módulos MQTT y el Broker EMQX

El servidor MQTT contiene en sus tags asociados, el estado actualizado de las

variables del robot (etapa 4). El cliente MQTT de la aplicación de borde recibe el valor

de dichos tags, con el formato mostrado en la Figura 4-7 y los publica en el Broker

EMQX.

6. Comunicación entre el Broker EMQX y la plataforma IoT de IBM

El cliente MQTT contenido en la aplicación IoT de IBM, está suscrito a cada uno de los

tópicos que contienen la información de los tags del servidor MQTT de Ignition. Por lo

tanto, el cliente MQTT recibe cada uno de los mensajes que publica el Broker EMQX,

y la carga útil de dichos mensajes es convertida por la aplicación IoT, en datos para la

visualización y monitorización del sistema desde la interfaz gráfica web. De esta forma,

el usuario de la interfaz web tiene acceso a toda la información de estado robot IRB

140 (físico o virtual) incluida en la misma.

Capítulo 4 101

4.3 Interfaz gráfica IoT

El usuario de la interfaz gráfica web, puede acceder a la misma desde cualquier dispositivo

que permita ejecutar un navegador web y cuente con una conexión a Internet,

independientemente de su ubicación. La interfaz está conformada por tres bloques

incorporados en una sola pantalla, tal como se muestra en la Figura 4-8. A continuación,

se describen los elementos que conforman dicha interfaz.

Figura 4-8: Interfaz gráfica desarrollada en plataforma IoT de IBM.

HMI general

El bloque mostrado en la Figura 4-9 se denomina HMI general, e incorpora las acciones

de mando y monitorización básicas del sistema, tanto para el robot real como para el

robot virtual.

Figura 4-9: Bloque HMI General. Interfaz gráfica web.

1

2

3

4

5

6 7

8

9

10

2



En la Tabla 4-1 se muestran las características y funcionalidades de cada uno de los

elementos de la interfaz gráfica mostrada en la Figura 4-9.

Tabla 4-1: Elementos de mando y monitorización de la interfaz gráfica web.

HMI VIRTUAL ROBOT y HMI REAL ROBOT

Estos dos bloques mostrados en la Figura 4-10, incorporan las mismas funcionalidades

de visualización de históricos descritas en la sección 3.4.1.

Ítem NombreVariable de programa

asociada (Tabla 2 - 5)Descripción

1

Número de secuencias

para el robot virtual y el

robot real

Counter

Esta compuesto por un texto fijo una entrada numérica y un pulsador sin

auto retención. El usuario ingresa el numero de secuencias que el robot

(virtual y real) debe ejecutar, posteriormente se debe presionar el pulsador

APPLY para aplicar los cambios.

2Indicador de movimiento

para el robot virtual EnMov

Esta compuesto por un texto dinámico y un piloto de señalización. El texto y

el color del piloto cambia cuando el robot virtual esta en movimiento.

3Indicador de movimiento

para el robot real EnMov

Esta compuesto por un texto dinámico y un piloto de señalización. El texto y

el color del piloto cambia cuando el robot real esta en movimiento.

Habilitar robot virtual NA

Esta compuesto por un pulsador con auto retención y un Check Box de

señalización. Las acciones de mando ingresadas por el usuario, solo tendrán

efecto en el robot virtual si esta opción esta seleccionada.

Habilitar robot real NA

Esta compuesto por un pulsador con auto retención y un Check Box de

señalización. Las acciones de mando ingresadas por el usuario, solo tendrán

efecto en el robot real si esta opción esta seleccionada.

Start robot virtual y/o

robot realDO1

Es un pulsador sin auto retención. Permite al usuario iniciar la ejecución de

las secuencias de movimiento en el robot (virtual y/o real).

Stop robot virtual y/o

robot realPAUSEING


de las secuencias de movimiento en el robot (virtual y/o real). El robot

volverá a posición Home.

Pause robot virtual y/o

robot realSTOPING

Es un pulsador con auto retención. Permite al usuario pausar la ejecución de

las secuencias de movimiento en el robot (virtual y/o real). El robot

continuara justo en la posición donde se detuvo cuando el usuario reanude

el movimiento.

6 Selector de contador NA

Es un menú de selección desplegable. Permite al usuario seleccionar que

contador de secuencias faltantes quiere visualizar. Contiene dos opciones;

contador virtual y contador real.

7Indicador de secuencias

faltantesCounter

Es un display de visualización tipo Gauge. Permite al usuario visualizar el

numero de secuencias faltantes para ser ejecutadas por el robot (real o

virtual). El para escoger entre el robot virtual o el robot real, el usuario

deberá realizar la selección en el selector de contador.

8Restablecimiento de

contadoresRESETCONT

Esta conformado por una entrada de texto con ocultamiento de caracteres,

un pulsador de validación y un pulsador de borrado. Permite al usuario

realizar el restablecimiento de todos los contadores del sistema, siempre y

cuando ingrese la contraseña de autorización.

9Mensaje de validación de

contraseñasNA

Es un texto dinámico. El valor por defecto del texto es ENTER PASSWORD. Si

el usuario ingresa una contraseña errónea para reestablecer los contadores

el texto cambiara a INVALID PASSWORD. Cuando el usuario ingresa la

contraseña correcta el texto lo valida con un RESET OK.

5

4

Capítulo 4 103

Figura 4-10: Bloques de visualización de históricos. Interfaz gráfica web.

En la Tabla 4-2 se muestran las características y funcionalidades de cada uno de los

elementos de los bloques de visualización mostrados en la Figura 4-10.

Tabla 4-2: Elementos de visualización de históricos para la interfaz gráfica web.

Por último, es importante resaltar la interoperabilidad entre las interfaces graficas

desarrolladas para este proyecto. Es decir; cada una de las acciones de mando ingresadas

por el usuario en cualquiera de las interfaces graficas descritas en los capítulos 3 y 4,

afectarán a todo el sistema implementado y se verán reflejadas en los elementos de

monitorización y visualización creados en las diferentes interfaces gráficas.

Ítem NombreVariable de programa

asociada (Tabla 2 - 5)Descripción

1Número total de secuencias

ejecutadas por el robot virtualCounterTotal

Es un grafico de línea. Permite al usuario visualizar el histórico del numero

total acumulado de secuencias que ha ejecutado el robot virtual, y la hora y

fecha exacta en la que se realizaron las mismas.

2

Número total de pausas y

paradas realizadas en el robot

virtual

CounterStop,

CounterPause


total acumulado de pausas y paradas que el operador a realizado en el robot

virtual, y la hora y fecha exacta en la que se realizaron las mismas.

3Número total de secuencias

ejecutadas por el robot realCounterTotal


total acumulado de secuencias que ha ejecutado el robot real, y la hora y

fecha exacta en la que se realizaron las mismas.

4

Número total de pausas y

paradas realizadas en el robot

real

CounterStop,

CounterPause


total acumulado de pausas y paradas que el operador a realizado en el robot

virtual, y la hora y fecha exacta en la que se realizaron las mismas.

1

2 4

3

5. Conclusiones y recomendaciones

5.1 Conclusiones

Los principales fabricantes de dispositivos para la automatización, el control y la

supervisión de procesos industriales, desarrollan los drivers que permiten la comunicación

con sus dispositivos, cumpliendo con las especificaciones definidas por la OPC

Foundation. En la actualidad, existen múltiples herramientas de software gratuitas, o de

pago, que permiten la creación de servidores y clientes OPC, sin la necesidad de

implementar desarrollos complejos y de alto costo. Por otra parte, los desarrollos basados

en protocolos de mensajería MQTT, permiten el desacople de los dispositivos

pertenecientes a sistemas industriales automatizados, así como su integración con las

tecnologías IIoT, de la denominada industria 4.0. Por lo tanto, aunque la implementación

de aplicaciones que faciliten la integración de las dos tecnologías, implique la necesidad

de realizar desarrollos con un nivel de complejidad mayor, como resultado se obtendrá un

sistema fiable, con bajos requerimientos de procesamiento y ancho de banda, que

permitirá la integración de una gran diversidad de dispositivos de uso industrial, mejorando

la escalabilidad de los sistemas.

La plataforma de software SCADA; Ignition 8.0.16 de Inductive Automation, fue

seleccionada como el eje central de las comunicaciones entre los dispositivos y las

aplicaciones desarrolladas para el proyecto presentado en este documento. Esta

plataforma incorpora funcionalidades que permiten la creación de clientes y servidores

basados en las especificaciones OPC DA y OPC UA, lo cual la convierte en una

herramienta muy potente para lograr la integración entre diversas plataformas industriales

de múltiples fabricantes, permitiendo el intercambio de información entre las mismas, en

forma sencilla y segura, sin la necesidad de realizar el desarrollo de software adicional de

alto costo y que en general requiere de mucho tiempo.

10

6

Título de la tesis o trabajo de investigación

La OPC Foundation se encarga de la creación y mantenimiento de las especificaciones

OPC. Las especificaciones OPC Classic están basadas en las tecnologías COM y DCOM

de Microsoft, y están restringidas para ser usadas en sistemas operativos Windows. Para

solucionar este inconveniente, la OPC Foundation creo la especificación OPC UA que

incorpora todas las funcionalidades de OPC Classic y puede ser utilizada en la mayoría de

sistemas operativos. Sin embargo, muchos de los fabricantes de plataformas y dispositivos

industriales, no han implementado los desarrollos necesarios para que los mismos sean

compatibles con la especificación OPC UA, por lo tanto, es de vital importancia que el

profesional de automatización conozca y comprenda en detalle las características de

funcionamiento, tanto de las especificaciones OPC Classic, como de la especificación OPC

UA. Por otra parte, es importante resaltar que el estándar OPC es una solución basada en

software, lo cual implica que su desempeño en términos de tiempo de repuesta y fiabilidad

están limitados. Así pues, la conveniencia de la implementación del estándar OPC, deberá

ser evaluada teniendo en cuenta las necesidades del proceso y los requerimientos de

velocidad y fiabilidad en las comunicaciones del mismo.

La secuencia de movimiento Pick & Place doble desarrollada para este proyecto, fue

programada haciendo uso del software Robot Studio de ABB. Esta fue una herramienta

muy valiosa, ya que permitió que la programación de la secuencia de movimiento pudiera

ser probada de forma previa a su implementación, en uno de los robots IRB 140 ABB de

LabSIR. Así mismo, gracias a la funcionalidad PC Interface disponible en Robot Studio,

fue posible realizar las pruebas preliminares de las comunicaciones entre las diferentes

aplicaciones desarrolladas para este proyecto, sin la necesidad de acceder a los equipos

de los laboratorios, más que para las implementaciones finales. De esta forma, se

desarrollaron interfaces graficas en un PC (sistema SCADA) y en un HMI Panel View Plus

1000 ubicados en LabAuto, que permiten a los usuarios realizar tareas de control y

supervisión, tanto en un manipulador robótico virtual IRB140 simulado en Robot Studio,

como en uno de los robots IRB 140 existentes en LabSIR, cumpliendo con los objetivos

planteados para el proyecto, con un tiempo de intervención mínimo en la planta.

Por último, se realizaron los desarrollos necesarios para integrar el sistema implementado

con una plataforma IoT, permitiendo que los usuarios del mismo, realicen funciones de

supervisión, control y visualización de indicadores sobre la calidad en la operación del

Conclusiones 107

sistema, desde una interfaz gráfica alojada en cloud. Las comunicaciones entre el sistema

SCADA y la plataforma IoT, fueron implementadas por medio del protocolo basado en

mensajería MQTT, que representa un mecanismo de comunicación fiable, de bajo costo,

con bajos requerimientos de ancho de banda y que no necesita una gran capacidad de

procesamiento. Sin embargo, es importante resaltar que la implementación de este tipo de

desarrollos, requieren conocimientos de programación y de las especificaciones exigidas

por las plataformas industriales con las cuales se quiere establecer comunicación, lo que

en general se traduce en tiempos de implementación elevados. Por lo tanto, es de vital

importancia realizar un análisis de las ventajas que puede traer la implementación de

servicios IoT a cada proceso en específico, para así evitar incorporar tecnologías que

pueden ser complejas, y no necesariamente representan una mejora significativa en el

proceso.

5.2 Recomendaciones

La arquitectura de comunicaciones y el sistema SCADA implementado, pueden ser

ampliados para permitir la comunicación con otros laboratorios de la Facultad de Ingeniería

de la Universidad Nacional de Colombia sede Bogotá. En un trabajo futuro, podría

considerarse incorporar en el sistema implementado, el Laboratorio de Instrumentación

Supervisión y Control (Lisc), perteneciente a la Facultad de Ingeniería Eléctrica y

Electrónica de la universidad. Dicho laboratorio cuenta con diversos dispositivos de uso

industrial, que lo convierten en el candidato perfecto para hacer parte del sistema

implementado.

Como parte de este proyecto, se realizó la integración del sistema con el servicio Internet

of Things de IBM. Existen múltiples plataformas como; AWS de Amazon, Azure de

Microsoft, o Google Cloud, que permiten realizar este tipo de desarrollos con variantes de

funcionamiento, o incluso, con la posibilidad de adquirir una máquina virtual en línea y un

dominio web que permitan implementar desarrollos con un nivel de complejidad más alto.

En futuros trabajos, se recomienda realizar un análisis de las funcionalidades que los

diferentes proveedores de servicios web ofrecen, para seleccionar el más conveniente ante

futuras ampliaciones del sistema.

Bibliografía

[1] Jordi, M. (17 de 03 de 2002). “Automatización y comunicaciones industriales - Escuela

Universitaria de Ingeniería Técnica Industrial de Zaragoza” Recuperado el 8 de julio

de 2020 de http://automata.cps.unizar.es/bibliotecaschneider/AUT/COMM.pdf

[2] Contreras, L., Tristancho, J., Vargas, L. (2015). AUTOMATIZACIÓN EN NIVEL DE

CONTROL DE PLANTA MEDIANTE EL USO DE HERRAMIENTAS LIBRES Y

COMPUTACIÓN. Redes de Ingeniería, Vol 6 (Edición especial), Pags. 41-46

[3] Sirgo, J. (18 de 04 de 2006). “Comunicaciones Industriales – Universidad de Oviedo –

Ingeniería de Sistemas y Automática”. Recuperado el 9 de enero de 2020 de

http://isa.uniovi.es/docencia/iea/teoria/comunicacionesindustrialesdocumento.pdf

[4] Hansson, A. (9 de junio de 2020). Estudio anual sobre el mercado de redes industriales.

AUTOMÁTICA E INSTRUMENTACIÓN. Recuperado el 12 de Julio de 2020 de

http://www.automaticaeinstrumentacion.com/es/notices/2020/06/ethernet-

industrial-aumenta-su-cuota-de-mercado-64-mientras-caen-los-buses-de-campo-

30-46672.php#.XwtxByhKjIV

[5] Rodriguez Penin, A., Sistemas SCADA 2ª edición, (2007), Barcelona España,

MARCOMBO EDICIONES TÉCNICAS

[6] LÓPEZ I SEUBA, M., Internet de las cosas – La transformación digital de la

sociedad, (2019), Igarsa España, Ra - Ma

11

0


[7] SISCO ISBG, EVANS, D. (04 de 2011). “The Internet of Things: How the Next Evolution

of the Internet is Changing everything”. Recuperado el 12 de febrero de 2020 de

https://www.cisco.com/c/dam/en_us/about/ac79/docs/innov/IoT_IBSG_0411FINAL.

pdf

[8] PEREZ, R., NAVAJAS, S,. TERRY, E. (2019). “IOT EN ALC 2019: Tomando un pulso

al Internet de las Cosas en América Latina y el Caribe” Mar 2019. Recuperado el 9

de enero de 2020 de

https://publications.iadb.org/publications/spanish/document/IoT_en_ALC_2019_To

mando_el_pulso_al_Internet_de_las_Cosas_en_Am%C3%A9rica_Latina_y_el_Ca

ribe_es.pdf

[9] Nof, S,Y (Ed.). (2009). Springer Handbook of Automation. Springer

[10] M.P. Groover (2005). Automation, Production Systems and Computer-Integrated

Manufacturing. Pearson

[11] Alberto, B. Pablo, SS. Rebeca, H (2020). Introducción a la automática. Bookdown.

https://bookdown.org/alberto_brunete/intro_automatica/

[12] Emilio García, M. (2001). Automatización de procesos industriales. Alfaomega

[13] Salazar, C., Correa, L. (2011). Buses de campo y protocolos en redes industriales.

Ventana Informática, Volumen 25, 83 – 109.

http://revistasum.umanizales.edu.co/ojs/index.php/ventanainformatica/article/down

load/126/184

[14] Ortiz, A. (2018). Programación de PLC, HMI y comunicaciones en la industria.

Programa editorial Universidad Autónoma de Occidente

[15] Caicedo, J., Varón, A., Felix, D. (2015). Redes industriales. Revista Vector, 7, 12 –

17. http://vip.ucaldas.edu.co/vector/downloads/Vector7_3.pdf

Bibliografía 111

[16] Ortiz, A. (2018). Programación de PLC, HMI y comunicaciones en la industria.

Programa editorial Universidad Autónoma de Occidente

[17] Oliva, N. (2013). Redes de comunicaciones industriales. Uned publicaciones

[18] Andrew, S., David, J (2011). Redes de computadoras. PEARSON

[19] Oracle. (2010). Modelo de arquitectura del protocolo TCP/IP. Recuperado el 8 de

agosto de 2020 de https://docs.oracle.com/cd/E19957-01/820-2981/ipov-10/

[20] Comer, D. (2009). Computer Networks and Internets fifth ed. PEARSON

[21] Spurgeon, C., Zimmerman, J. (2014). Ethernet the definitive guide second ed.

O’REILLY

[22] IBM i. (2014). Protocolo de configuración dinámica de hosts (DHCP). Recuperado el

11 de junio de 2020 de

https://www.ibm.com/support/knowledgecenter/es/ssw_ibm_i_72/rzakg/rzakgpdf.pd

f

[23] Pérez, E. (2015). Los sistemas SCADA en la automatización industrial, vol 28, 3 – 14.

https://dialnet.unirioja.es/descarga/articulo/5280242.pdf

[24] Pérez, A. (2016). Sistema OPC para automatización mediante redes de estado [Tesis

de maestría, Universidad de Sevilla]. e-REDING trabajos y proyectos fin de estudios

de la E.T.S.I.

[25] Kominek, D. (2009). OPC: ¿De qué se trata, y cómo funciona?.

https://www.interempresas.net/FeriaVirtual/Catalogos_y_documentos/220446/Gui

a-para-entender-la-tecnologia-OPC.pdf

11

2


[26] OPC Foundation. (2020). Portal OPC Foundation. Recuperado el 15 de junio de 2020

de https://opcfoundation.org/

[27] D. Uckelmann., M. Harrison., F. Michahelles. (2011). An architectural apporach

towards the future internet of things, Springer

[28] P. Guillemin., S. Gusmeroli., H. Sundmaeker., A. Bassi. (2009). Internet of Things

Strategic Research Roadmap.

https://www.researchgate.net/publication/267566519_Internet_of_Things_Strategi

c_Research_Roadmap

[29] Serpanos, D., Wolf, M. (2017). Internet of Things (IoT) Systems: Architectures,

Algorithms, Methodologies, Springer

[30] Rueda, J., Talavera, J. (2017). Similitudes y diferencias entre Redes de Sensores

Inalámbricas e Internet de las Cosas: hacia una postura clarificadora. Revista

Colombiana de Computación, Volumen 18 No 2, 58 – 74.

https://revistas.unab.edu.co/index.php/rcc/article/view/3218

[31] Gonzáles, . (2017). IoT: Dispositivos, tecnologías de transporte y aplicaciones. [Tesis

de maestría, Universitat Oberta de Catalunya]. Repositorio Institucional (O2) UOC

[32] MQTT.org. (2020). Portal MQTT.org. Recuperado el 19 de junio de 2020 de

https://mqtt.org/

[33] IBM Developer. (2017). Portal IBM Developer. Recuperado el 20 de junio de 2020 de

https://developer.ibm.com/es/technologies/iot/articles/iot-mqtt-why-good-for-iot/

[34] Domenech, J. (2015). La Universidad Nacional de Colombia estrena un laboratorio de

robótica. Recuperado el 21 de junio de 2020 de https://www.siliconweek.com/e-

innovation/la-universidad-nacional-de-colombia-estrena-un-laboratorio-de-

robotica-63413

Bibliografía 113

[35] ABB Robotics. (2004). Especificaciones del producto robot articulado IRB 140.

https://library.e.abb.com/public/4c9f370fc8f37781c1257b4b0051c907/3HAC10319

-1_rev4_es_library.pdf

[36] ABB Robotics. (2013). Especificaciones del producto Controller IRC5 with

FlexPendant..https://library.e.abb.com/public/2b5b950d68a0503cc1257c0c003cb7

03/3HAC041344-es.pdf

[37] ABB Robotics. (2007). Manual de referencia técnica - Descripcion general de RAPID..

http://euloxio.myds.me/dok/manual/robot/abb/rapid_manual_descripcion.pdf

[38] Inductive Automation. (2019). Portal Inductive Automation. Recuperado el 10 de julio

de 2020 de https://inductiveautomation.com/ignition/

[39] ABB Developer Center. (2020). Portal ABB Developer Center. Recuperado el 12 de

julio de 2020 de https://developercenter.robotstudio.com/

[40] IBM Watson. (2020). IBM Watson IoT Platform. Recuperado el 20 de julio de 2020 de

https://www.ibm.com/es-es/marketplace/internet-of-things-cloud#:~:text=IBM%20

Watson%20IoT%20Platform%20es,del%20Internet%20de%20las%20cosas.

[41] IBM. (2018). Seguridad de los datos y fundamentos de privacidad en los servicios de

cloud de IBM. https://www-03.ibm.com/software/sla/sladb.nsf/pdf/7745WW3/ $file/

Z126-7745-WW-3_05-2018_es_ES.pdf

[42] IBM Cloud. (2020). Portal de Login. Recuperado el 20 de julio de 2020 de

https://cloud.ibm.com/

[43] EMQX. (2020). Portal EMQ. Recuperado el 2 de agosto de 2020 de

https://www.emqx.io/

11

4


[44] Cirrus Link SOLUTIONS. (2020). Modulos Ignition Cirrus Link. Recuperado el 4 de

agosto de 2020 de https://www.cirrus-link.com/mqtt-software-for-iiot-scada/#

[45] Nodejs.org. (2020). Portal Node.js. Recuperado el 3 de junio de 2020 de

https://nodejs.org/es/

Ronald Uriel Grosso Barrera - repositorio.unal.edu.co

Documents

Transcript of Ronald Uriel Grosso Barrera - repositorio.unal.edu.co