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
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
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
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.
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
Figura 1-20: Publicación de mensaje con nivel de servicio QoS 1. ................................. 58
Figura 1-21: Publicación de mensaje con nivel de servicio QoS 2. ................................. 59
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
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.
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
ubicados en el Laboratorio de Automatización Industrial y los robots ABB ubicados en el LabSIR.
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
26 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.
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).
28 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.
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.
30 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 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.
32 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.
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
34 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 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.
36 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 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
38 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.
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]:
40 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.
- 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:
42 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.
- 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
44 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.
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).
46 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.
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).
48 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.
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].
50 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.
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
52 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.
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].
54 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.
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.
56 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.
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].
58 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.
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.
Figura 1-20: Publicación de mensaje con nivel de servicio QoS 1.
- 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).
Figura 1-21: Publicación de mensaje con nivel de servicio QoS 2.
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.
60 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.
- 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
62 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.
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)
64 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.
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.
66 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.
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
68 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.
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
Variable que activa la interrupción externa
DETENERSECUENCIA. Su valor depende de la señal
digital virtual DO3
RESETCONT VAR intnum
Variable que activa la interrupción externa
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
posición de Target_20
IZQ2 PERS intnumVariable usada para indicar que el robot esta en la
posición de Target_30
IZQ4 PERS intnumVariable usada para indicar que el robot esta en la
posición de Target_40
DER2 PERS intnumVariable usada para indicar que el robot esta en la
posición de Target_50
DER4 PERS intnumVariable usada para indicar que el robot esta en la
posición de Target_60
70 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.
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.
72 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.
2.3.3 Rutina Dejar Izquierda
Tabla 2-7: Instrucciones de movimiento para la rutina DejarIzquierda.
Posición
Robtarget Target_30 Target_40
Instrucción RAPID MoveL MoveL
Velocidad v500 v500
Zona de precisión z5 z5
Sistema Coordenado World World
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
Robtarget Target_50 Target_60
Instrucción RAPID MoveL MoveL
Velocidad v500 v500
Zona de precisión z5 z5
Sistema Coordenado World World
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.
74 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.
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
76 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.
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].
78 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.
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.
80 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.
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.
82 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.
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
84 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.
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
86 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.
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
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 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
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 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
Es un pulsador sin auto retención. Permite al usuario detener la ejecución
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
88 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.
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.
90 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.
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
94 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.
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].
96 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.
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
98 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.
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
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.
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
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.
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
Es un pulsador sin auto retención. Permite al usuario detener la ejecución
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
Es un grafico de línea. Permite al usuario visualizar el histórico del numero
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
Es un grafico de línea. Permite al usuario visualizar el histórico del numero
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
Es un grafico de línea. Permite al usuario visualizar el histórico del numero
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
Título de la tesis o trabajo de investigación
[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.
[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
Título de la tesis o trabajo de investigación
[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
Título de la tesis o trabajo de investigación
[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/