UNIVERSIDAD SIMÓN BOLÍVAR

DECANATO DE ESTUDIOS PROFESIONALES

COORDINACIÓN DE INGENIERÍA ELECTRÓNICA

DISEÑO Y DESARROLLO DE MÓDULOS ELECTRÓNICOS

PARA LA INTERCONEXIÓN DE EQUIPOS INDUSTRIALES CON LA
WEB A TRAVÉS DE LOS PROTOCOLOS MODBUS Y MQTT

Por:
Pablo Alonso Velásquez Garrido

INFORME DE PASANTÍA
Presentado ante la Ilustre Universidad Simón Bolívar
como requisito parcial para optar al título de
Ingeniero Electrónico

Sartenejas, Enero de 2018



UNIVERSIDAD SIMÓN BOLÍVAR

DECANATO DE ESTUDIOS PROFESIONALES
COORDINACIÓN DE INGENIERÍA ELECTRÓNICA

DISEÑO Y DESARROLLO DE MÓDULOS ELECTRÓNICOS

PARA LA INTERCONEXIÓN DE EQUIPOS INDUSTRIALES CON LA
WEB A TRAVÉS DE LOS PROTOCOLOS MODBUS Y MQTT

Por:
Pablo Alonso Velásquez Garrido

Realizado con la asesoría de:

Tutor Académico: Prof. Orlando Trejo

Tutor Industrial: Ing. Luis Rincones

INFORME DE PASANTÍA
Presentado ante la Ilustre Universidad Simón Bolívar
como requisito parcial para optar al título de
Ingeniero Electrónico

Sartenejas, Enero de 201



UNIVERSIDAD SIMÓN BOLÍVAR

DECANATO DE ESTUDIOS PROFESIONALES
COORDINACIÓN DE INGENIERÍA ELECTRÓNICA

DISEÑO Y DESARROLLO DE MÓDULOS ELECTRÓNICOS

PARA LA INTERCONEXIÓN DE EQUIPOS INDUSTRIALES CON LA
WEB A TRAVÉS DE LOS PROTOCOLOS MODBUS Y MQTT
INFORME DE PASANTÍA
Realizado Por: Pablo A. Velásquez Garrido
Con la asesoría de: Prof. Orlando Trejo e Ing. Luis Rincones

RESUMEN

El presente informe describe el trabajo de pasantía para el diseño y desarrollo de una tarjeta
de adquisición de datos para la interconexión de equipos industriales con la web a través del
monitoreo de variables provenientes de sensores industriales y otros dispositivos mediante los
protocolos de comunicación ModBus y MQTT. El Hardware está fundamentado en un
microcontrolador Atmel SAMD21G, basado en arquitectura ARM, compatible con la plataforma
de desarrollo Arduino IDE y IoT. El proyecto incluye una Aplicación de escritorio, diseñada para
ejecutarse desde cualquier computador, representando de este manera una interacción directa. La
funcionabilidad del prototipo fue verificada al monitorear señales analógicas de 4-20 mA, señales
digitales de 0-24 V, datos obtenidos de esclavos ModBus en la misma red, los cuales fueron
publicados posteriormente en la “Nube”. Finalmente, se verificó el consumo de potencia del
dispositivo, obteniéndose un valor de aproximadamente 30 mA @ 24 V. De este modo, el
prototipo desarrollado, al ser incorporado en un proceso industrial, aporta la capacidad de
transmitir los datos de los equipos en planta a la Internet, para luego ser monitoreados desde
cualquier parte del mundo.
Palabras claves: Adquisición de datos, PCB, Microcontrolador, ModBus, Sensores, Señales
industriales, IoT, la Nube.

DEDICATORIA

A mis amados padres, José Jesús y Ana Elizabeth, por su invalorable amor y confianza durante
todas las etapas de mi vida.

A mi hermana Keyla, a mi hermano José Jesús, por su constante apoyo y servir de ejemplo a
seguir.

“Uno de los grandes descubrimientos que un hombre puede

hacer, una de sus grandes sorpresas, es encontrar que
puede hacer lo que temía que no podía hacer”.
Henry Ford

vi


ÍNDICE GENERAL

Pag.

ÍNDICE DE TABLAS …………………………………………………………. x

ÍNDICE DE FIGURAS ……………………………………………………….. xi
LISTA DE SÍMBOLOS ……………………………………………………….. xiii
LISTA DE ABREVIATURAS ………………………………………………… xiv
INTRODUCCIÓN ……………………………………………………………... 1
Antecedentes …………………………………………………………………… 1
Justificación e importancia del trabajo ………………………………………… 1
Planteamiento del problema ……………………………………………………. 2
Objetivo General ……………………………………………………………….. 2
Objetivos Específicos ………………………………………………………….. 2
CAPÍTULO 1 …………………………………………………………………... 3
DESCRIPCIÓN DE LA EMPRESA LS INNOVACIONES C.A. ……………. 3
Generalidades ………………………………………………………………….. 3
Misión ………………………………………………………………………….. 3
Visión …………………………………………………………………………... 4
Productos y soluciones …………………………………………………………. 4
CAPÍTULO 2 …………………………………………………………………... 6
FUNDAMENTOS TEORICOS ………………………………………………... 6
2.1 Internet de las cosas (IoT) ……………………………………………………… 6
2.1.1 Descripción General …………………………………………………………… 6
2.1.2 Modelos de Comunicación del IoT y sus Aplicaciones ……………………… 7
2.1.3 Desafíos y barreras para el IoT ………………………………………………… 10
2.2 Protocolo de Comunicación Industrial ModBus ………………………………. 11
2.2.1 Las Transacciones en ModBus ………………………………………………… 13
2.2.2 Modos de Transmisión en Serie ……………………………………………….. 15
2.2.2.1 Modo de Transmisión RTU ……………………………………………………. 15
2.2.3 Modo de Transmisión TCP/IP ……..…………………………………………... 17
2.2.4 El Ciclo Solicitud/Respuesta …………………………………………………... 20
2.2.4.1 Campo de Dirección …………………………………………………………… 21
2.2.4.2 Campo de Códigos de Función ………………………………………………… 21
2.2.5 Funciones de Datos y Control ModBus ………………………………………... 24
…………………………………………….

vii


2.2.5.1 Códigos de Función de Acceso de Datos ….…………………………………… 24

2.2.5.2 Códigos de Función de Diagnóstico …………………………………………… 24
2.2.5.3 Otras Funciones ………………………………………………………………... 25
2.3 Protocolo de Comunicación Web MQTT ……………………………………… 25
2.4 Descripción General del Sistema a Monitorear ..………………………………. 26
2.4.1 Sensores ………………………………………………………………………... 30
2.4.2 Red de Datos …………………………………………………………………… 31
2.5 Software SCADA ……………………………………………………………… 31
2.6 PLC …………………………………………………………………………….. 33
2.7 Microcontroladores Atmel ……….…………………………………………….. 35
2.8 Programación de MCU con Arduino IDE ……………………………………... 36
2.9 Aplicación (App) de escritorio en Windows ….……………………….............. 37
2.9.1 Visual Estudio IDE …………………………………………………………….. 38
2.9.2 Framework.NET ……………………………………………………………….. 38
CAPÍTULO 3 ………………………………………………………………….. 40
DISEÑO, DESARROLLO E IMPLEMENTACIÓN DEL PCB ……………… 40
3.1 El MCU Atmel SAMD21G ……………………………………………………. 40
3.2 Pruebas experimentales ………………………………………………………… 41
3.2.1 Modulo Ethernet (Circuito integrado WIZnet W5500) ………………………... 42
3.2.2 Circuito para Comunicación Serial (Transceptor EXAR SP330E) …...……….. 43
3.2.3 Circuito de acondicionamiento para entradas Analógicas y Digitales
Industriales …………………………………………........................................... 45
3.2.3.1 El Amplificador Operacional MCP 6004 ……………………………………… 45
3.2.3.2 El Optoacoplador TLP 293-4 ………………………………………………….. 46
3.2.4 Módulo RTC PCF8523T ………………………………………………………. 47
3.2.5 Memoria EEPROM 24AA025E48T …………………………………………… 48
3.2.6 Memoria EEPROM 24AA64 ………………………………………………….. 49
3.3 Diseño del PCB en Eagle CAD ………………………………………………... 50
3.3.1 Selección del encapsulado ……………………………………………………... 50
3.3.2 Diagrama electrónico del PCB ………………………………………………… 51
3.3.3 Layout del PCB ………………………………………………………………… 52
3.4 Ensamblaje del PCB …………………………………………………………… 53
3.5 Firmware del PCB ……………………………………………………………... 53
CAPÍTULO 4 ………………………………………………………………….. 58
DESARROLLO E IMPLEMENTACIÓN DE LA APLICACIÓN DE
ESCRITORIO ………………………………………………………………….. 58
4.1 Descripción del Funcionamiento de la App de escritorio ……...………………. 58

viii


4.2 Programación de la App de escritorio ………………………………………….. 59

CAPÍTULO 5 ………………………………………………………………….. 62
RESULTADOS Y ANÁLISIS ………………………………………………… 62
5.1 Bootloader del microcontrolador (MCU) …...…………………………………. 62
5.2 Módulo ETHERNET …………………………………………………………... 64
5.3 Entradas Analógicas …………………………………………………………… 64
5.4 Entradas Digitales ……………………………………………………………… 65
5.5 Módulo RTC …………………………………………………………………… 66
5.6 Memorias EEPROM …...………………………………………………………. 67
5.7 Módulo de Comunicación Serial ………………………………………………. 67
5.8 Comunicación App – PCB ………..…………………………………………… 68
5.9 Comunicación ModBus ………………………………………………………... 69
5.10 Comunicación MQTT ………………………………………………………….. 70
5.11 Consumo de potencia del PCB ………………………………………………… 71
5.12 Módulo de Radio Frecuencia (RF) para futuras aplicaciones …………………. 72
CONCLUSIONES Y RECOMENDACIONES ……………………………….. 74
REFERENCIAS ……………………………………………………………….. 76
APENDICES …………………………………………………………………... 79

ix


ÍNDICE DE TABLAS

Pag.

Tabla 2.1 Datos en un dispositivo de una red ModBus ………………………………… 14

Tabla 2.2 Referencia de los datos en los controladores ModBus …..…………………... 14
Tabla 2.3 Formato para cada Byte en el modo RTU …………………………………… 16
Tabla 2.4 Consulta del maestro con modo de transmisión RTU ……………………….. 17
Tabla 2.5 Estructura de mensajes en ModBus TCP ……………………………………. 19
Tabla 2.6 Definición de Códigos de Función Pública disponibles en el Protocolo
ModBus [4] ………………………………………………………………….. 23

ÍNDICE DE FIGURAS

Pag.

Figura 2.1 Diagrama del Modelo de Comunicación Dispositivo – Dispositivo ……… 7

Figura 2.2 Diagrama del Modelo de Comunicación Dispositivo – Internet …………..
……………………………… 8
Figura 2.3 Diagrama del Modelo de Comunicación Dispositivo – Puerta de Enlace de
Capa de Aplicación ALG …………………………………………………. 9
Figura 2.4 Diagrama del Modelo de Intercambio de Datos a través del Back End
Dispositivo
(Interfaz de –programación)
Puerta de Enlace de Capa de Aplicación ALG
…...................................................................... 10
Figura 2.5 Marco General ModBus …………………………………………………... 12
Figura 2.6 Arquitectura de red ModBus [3] …..……………………………………… 12
Figura 2.7 Trama en el modo de transmisión RTU …………………………………... 16
Figura 2.8 Orden de bits en el modo de transmisión RTU …………………………… 17
Figura 2.9 Encabezado de una trama ModBus TCP/IP ………………………………. 18
Figura 2.10 El ciclo de Solicitud/Respuesta (Maestro – Esclavo) [4] ...……………….. 20
Figura 2.11 Categorías Códigos de Función ModBus [4] ……..………………………. 22
Figura 2.12 Plataforma indConnect [6] …..……………………………………………. 27
Figura 2.13 Ejemplo de una aplicación web concerniente a los datos de una Estación
de bombeo en la plataforma indConnect [6] …..………………………….. 28
Figura 2.14 Vista comercial del PCB (Modulo indConnect LINK) …………………… 29
Figura 2.15 Enfoque del PCB en la industria ………………………………………….. 29
Figura 2.16 Esquema general de la aplicación del PCB en la industria ……………….. 30
Figura 2.17 Estructura genérica de un MCU ……………...…………………………… 35
Figura 3.1 Pin Out del microcontrolador Atmel SAMD21G18 [8] ….………………. 41
Figura 3.2 Asignación de pines/Diagrama de bloques del WIZnet W5500 [9] ..…….. 43
Figura 3.3 Diagrama de bloques de los modos RS-232 y RS-485 Half-Duplex del
Transceptor SP330E [10] …………………………………………………. 44
Figura 3.4 Aplicación del Amplificador Operacional MCP6004 como No-Inversor
[11] ………………………………………………………………………... 46
Figura 3.5 Pin Out del Optoacoplador TLP293-4 [12] ……………………………….. 46
Figura 3.6 Diagrama de bloque del Integrado PCF8523 [13] …..……………………. 47
Figura 3.7 Diagrama de bloques de la memoria EEPROM 24AA025E48 [14] ……… 48
Figura 3.8 Diagrama de bloque de la memoria EEPROM 24AA64 [15] …………….. 50
Figura 3.9 Vistas tridimensionales del encapsulado Phoenix Contact MEMAX 22,5
2-2 KMGY-2713625 utilizada en el proyecto [16] ……………………….. 51
Figura 3.10 Muestra de una hoja del esquemático desarrollado en este proyecto ……... 52

xi


Figura 3.11 Layout (diseño) del PCB desarrollado en este proyecto ………………….. 53
Figura 3.12 Vista de la capa superior del PCB ………...………………………………. 54
Figura 3.13 Vista de la capa inferior del PCB ………………….……………………… 55
Figura 3.14 Vista del PCB dentro del encapsulado seleccionado ……………………… 55
Figura 3.15 Diagrama de flujo del firmware del PCB diseñado ……………………….. 57
Figura 4.1 Diagrama general del funcionamiento de la aplicación de escritorio …….. 59
Figura 4.2 Ventana de inicio de la aplicación de escritorio …………………………... 60
Figura 4.3 Ventana principal de la aplicación de escritorio (sin proyecto aún creado) 60
Figura 4.4 Ejemplo de la ventana principal, en este caso, mostrando la pestaña para
configurar las entradas (pestaña “I/O”) …….……………………………. 61
Figura 4.5 Ejemplo del comienzo de un archivo de configuración .cfg creado por la
aplicación de escritorio …………………………………………………… 61
Figura 5.1 Resistencias (R104 y R105) que deben ser removidas para utilizar el
depurador de la tarjeta Arduino Zero de manera independiente [18] ... 63
Figura 5.2 Conexión del PCB a un transmisor de 2 hilos (señal analógica) …………. 65
Figura 5.3 Conexión de un suiche (entrada digital industrial) al PCB …………………. 66
Figura 5.4 Interfaz del programa RealTerm utilizado en este proyecto para las
pruebas de la comunicación serial …………………………………………………… 67
Figura 5.5 Interfaz del simulador ModScan ..…………………………………………………….. 69
Figura 5.6 Interfaz del simulador ModSim .………………………………………………………. 70
Figura 5.7 Mensajes JSON publicados en el servidor HiveMQ, observados en la App
MQTTLens ………………………………………………………………... 71
Figura 5.8 Esquema de la aplicación del PCB en modo distribuido en la Industria ….. 72

xii


LISTA DE SÍMBOLOS

°C Grados Centígrados. Unidad de Temperatura.

B Bite. Conjunto de 8 bits, mínimo elemento de memoria de una computadora.
Bd Baudio. Número de símbolos por segundo en un medio de transmisión digital.
Bit Bit. Unidad de almacenamiento de memoria informática.
GB Gigabite. Unidad de almacenamiento de Información. Equivale a 10# byte.
kB Kilobyte. Unidad de almacenamiento de información. Equivale a 10$ byte.
Kbit Kilobit. Unidad de tráfico de información. Equivale a 10$ bits.
kbps Kilobit por segundo. Unidad velocidad de transferencia de información. Equivale a
10$ bit por segundo.
KHz Kilohercio. Unidad de frecuencia; equivale a 10$ Hercios (Hz).
Km Kilometro. Unidad de longitud. Equivale a 10$ m.
kV Kilovoltios. Unidad de tensión eléctrica. Equivale a 1000 Voltios (V).
kW Kilowatt. Unidad de potencia. Equivale a 1000 Watts (W).
kΩ Kiloohmio. Unidad resistencia eléctrica. Equivale a 10$ Ohmio.
mA mili Amperios. Unidad de Intensidad de Corriente. Equivale a 10&$ Amperios (A).
MB Megabytes. Equivale a 10' bytes.
Mbps Megabit por segundo. Unidad velocidad de transferencia de información. Equivale a
10$ kbps.
MHz Megahercio. Unidad de frecuencia; equivale a 10⁶ Hercios (Hz).
mm Milímetro. Unidad de longitud, equivale a una milésima del metro (m).
ms Milisegundo. Unidad de tiempo, equivale a 10&$ segundos.
mV Milivoltios. Unidad de tensión eléctrica. Equivale a 10&$ Voltios (V).
nA Nanoamperio. Unidad de Intensidad de Corriente. Equivale a 10&# Amperios (A).
pF Picofaradio. Unidad de capacidad eléctrica. Equivale a 10&() Faradios (F).
s Segundo. Unidad de tiempo.
V Voltios.
µA Microamperio. Unidad de Intensidad de Corriente. Equivale a 10&' Amperios (A).
Ω Ohmio. Unidad de resistencia eléctrica.

xiii


LISTA DE ABREVIATURAS

ADU: Application Data Unit – Unidad de Aplicación de Datos.

ADC: Analog to Digital Converter – Convertidor Analógico a Digital.
App: Application – Aplicación Informática.
ASCII: American Standard Code for Information Interchange – Código Americano
Estándar para Intercambio de Información.
BCL: Base Class Library – Biblioteca de Clase Unificada.
CANopen: Controller Area Network Open – Controlador de Red de Área Abierto.
CLR: Common Language Runtime – Entorno Tiempo de Ejecución de Lenguaje Común.
CPU: Central Processing Unit – Unidad Central de Procesamiento.
CRC: Ciclic Redundancy Check – Comprobación de Redundancia Cíclica.
DAC: Digital to Analog Converter – Convertidor Digital a Analógico.
DCS: Distributed Control System – Sistema de control Distribuido.
DRIVER: Controlador de Dispositivo.
ESD: Electrostatic Discharge – Descarga Electroestática.
GATEWAY: Puerta de enlace para acceder a una red exterior desde una red local.
GND: Cable de tierra o negativo.
GUI: Graphical User Interface - Constructor de Interfaz Gráfica.
Hex.: Hexadecimal.
HMI: Human Machine Interface – Interface Hombre Máquina.
HTTP: Hypertext Transfer Protocol - Protocolo de Transferencia de Hipertexto.
I/O: Input/Output – Entrada/Salida.
I2C: Inter integrated circuits – Circuito interintegrados.
IAB: Internet Architecture Board - Consejo de Arquitectura de Internet.
IDE: Integrated Development Environment - Ambiente de Desarrollo Integrado.
IEEE: Institute of Electrical and Electronics Engineers – Instituto de Ingeniería Eléctrica y
Electrónica.
IoT: Internet of things - Internet de la cosas.
IP: Internet Protocol – Protocolo de Internet.
IPV4: Internet Protocol version 4 - Protocolo de Internet versión 4.
IPV6: Internet Protocol version 6 - Protocolo de Internet versión 6.
LAN: Local Area Network - Redes de Área Local.
LRC: Longitudinal Redundancy Check - Comprobación de Redundancia Longitudinal.
MABP: ModBus Application Bus Protocol – Protocolo de Aplicación ModBus.
MAC: Media Access Control – Control de Acceso al Medio.

xiv


MCU: Microcontroller Unit – Unidad Microcontrolador.

MIDI Musical Instrument Digital Interface – Interfaz digital de instrumentos
musicales.
MIPS: Forma de medir la potencia de los microcontroladores. Millions of instructions
per second – Millones de instrucciones por Segundo.
MODBUS: Modicon Bus – Bus Modicon.
MTU: Maximum Transmission Unit – Máxima Unidad de Transferencia.
MQTT: Message Queue Telemetry Transport – Transporte Telemétrico de Mensajes en
Cola.
NEMA: National Electrical Manufacturers Association - Asociación Nacional de
Fabricantes Eléctricos.
ON-OFF: Sistema discreto de dos posiciones.
PCB: Printed Circuit Board – Tarjeta de Circuito Impreso.
PDU: Protocol Data Unit – Unidad de Datos del Protocolo.
PLC: Programmable Logic Controller – Controlador Lógico Programable.
PROFIBUS: Process Field Bus – Bus de Campo de Proceso.
PWM: Pulse width modulation – Modulación por ancho de pulso.
RFC: Request for Comments – Solicitud de Comentario.
RS-232: Recommended Standard 232 – Estandar Recomendado 232. Norma intercambio
datos binarios serial entre un terminal y un equipo de comunicación de datos.
RS-422: Recommended Standard 422 – Estandar Recomendado 422. Norma técnica para
señal digital para transmisión de datos serie hasta 10 Mbps a 1200 m.
RS-485: Recommended Standard 485 – Estandar Recomendado 485. Bus diferencial
multipunto, transmisión a altas velocidades en largas distancias (10 Mbps hasta
12 m y 100 kbps en 1200 m) a través de canales ruidosos.
RSSI: Received Signal Strength Indicator – Indicador de Fuerza de la Señal Recibida.
RTU: Remote Terminal Unit – Unidad Terminal Remota.
SCADA: Supervisory Control And Data Acquisition - Adquisición de Datos y
Supervisión de Control.
SPI: Serial Peripheral Interface – Interfaz Serial Periférica.
SRAM: Static Random Access Memory - Memoria Estática de Acceso Aleatorio.
TCP: Transmission Control Protocol – Protocolo de Trasmisión de Control.
TSSOP: Thin Shrink Small Outline Package - Encapsulado de contorno pequeño y
delgado.
UART/USART: Universal Asynchronous Receiver Transmisor/Universal Synchronous
Asynchronous Receiver Transmisor - Transmisor Receptor Asíncrono
Universal/Transmisor Receptor Asincrono Síncrono Universal.
UDP: User Datagram Protocol – Protocolo de Datagramas de Usuarios.
USB: Universal Serial Bus – Bus Universal en Serie.
VDC: Volt Direct Current – Voltaje Corriente Directa.
VDD: Voltage Drain Drain - Voltaje drenador drenador.
VL Pin: Logic supply – Suministro de entradas lógicas.

xv


Vrms: Valor cuadrático medio del Voltaje.

Web: Página con información adaptado a la World Wide Web, se puede acceder mediante
un navegador web.
WiFi: Conexión de dispositivos electrónicos de forma inalámbrica.
WOL: Wake on LAN – Encender Remotamente un Computador.
WPF Windows Presentation Foundation - Fundación de Presentación de Windows.

xvi
 1

INTRODUCCIÓN

Antecedentes
Un sistema de adquisición de datos es un conjunto de dispositivos, líneas e interfaces que
realizan la conexión entre las señales provenientes de dispositivos de campo (ya sean
transductores, interruptores, medidores y controladores que emiten señales eléctricas), y un
computador para que este, mediante un software realice el procesamiento y almacenamiento de la
información [1].

Las tarjetas de adquisición de datos son dispositivos empleados ampliamente como

herramientas para el monitoreo y control de los procesos industriales. Estas posibilitan la toma de
señales provenientes de sensores que registran los cambios en las variables de interés, para
posteriormente procesarlas o generar acciones de control.

Justificación e importancia del trabajo

La existencia de sistemas de adquisición de datos modernos, potentes y confiables ha
permitido grandes avances en el campo de la instrumentación de procesos industriales e incluso
ha incentivado el desarrollo y crecimiento de la instrumentación virtual de los últimos años
sobremanera con el desarrollo reciente del Internet de las Cosas (IoT).

Se pretende además, fortalecer la generación de ideas y propuestas desde las empresas y las
universidades, capaces de competir en diseño, calidad y costos con productos existentes para los
sectores productivos, considerando que aún existe la posibilidad de incursionar con nuevas
tecnologías a pesar de la presencia de equipos de reconocidos fabricantes y de la competencia de
toda índole.

Planteamiento del Problema

La empresa LS Innovaciones C.A. como parte de los servicios y productos ofrecidos, tiene
dentro de sus metas incorporar el uso de tarjetas de adquisición de datos para su comercialización

 2
en un proyecto denominado IndConnect LINK, como solución expedita, sencilla y de bajo costo
en el control de procesos industriales, con la finalidad de responder la pregunta que se hacen los
clientes en el mundo ¿Cómo llevar los datos de su planta a la Internet?

La realización de este proyecto titulado “Diseño y desarrollo de módulos electrónicos para la

interconexión de equipos industriales con la Web” busca desarrollar un dispositivo electrónico
(PCB) capaz de interconectar equipos industriales con la web, creando un puente entre los datos
de planta e Internet, permitiendo de manera segura transmitir la información de sus equipos desde
cualquier lugar del mundo y de ese modo, con la información publicada en Internet, los datos
pueden ser accedidos a través de servicios web haciendo uso de una página web personalizada, o
de manera local a través de un PLC en una región remota o un SCADA directamente en la sala de
control.

Objetivo General
Desarrollar una PCB con interconexión de módulos electrónicos para la comunicación con
equipos industriales y plataformas Web.

Objetivos Específicos
1. Diseñar circuito electrónico de acondicionamiento de entradas analógicas y digitales con
estándar industrial, así como también de módulos accesorios: Memoria EEPROM, RTC,
USB, Ethernet.
2. Diseñar circuito electrónico con capacidad para comunicación industrial (ModBus TCP/IP
y ModBus 232/485).
3. Integrar el protocolo de comunicación industrial ModBus y el protocolo de comunicación
a través de Internet (MQTT) en el PCB a diseñar.
4. Diseñar, programar e integrar el firmware para el funcionamiento del PCB.
5. Diseñar e integrar una aplicación de escritorio de Windows con el propósito de configurar
el PCB.
6. Elaborar un manual de usuario del producto como un todo.

CAPÍTULO 1

DESCRIPCIÓN DE LA EMPRESA LS INNOVACIONES C.A.

1.1. Generalidades
LS Innovaciones C.A., es un empresa fundada en el año 2006 con sede principal en la ciudad
de Caracas, dedicada al desarrollo y puesta en marcha de sistemas de Automatización y
Seguridad, Instrumentación y Construcción, con alto grado de confiabilidad, seguridad, eficiencia
y conocimiento en la búsqueda de nuevas y mejores soluciones.

En el año 2009 recibe su primera certificación de la empresa Rockwell Automation como

proveedor de soluciones (Solution Provider), lo cual la afianza como líder en automatización y
control. Posteriormente esta certificación es ratificada en el año 2012 como Socio Proveedor de
Soluciones del Programa de Rockwell Automation (Solution Provider Partner Network Program).
Entre los años 2013 y 2017, de forma consecutiva la empresa Rockwell Automation la certifica
como Reconocido Integrador de Sistemas para Información (Recognize System Integrator for
Information). Adicionalmente ha recibido otras certificaciones como: Analista de vibración para
el área de monitoreo de condiciones (Vibration Institute) en 2013, Soporte Técnico Región
Andina de Prosoft Technology en 2014, Sistema F&G en 2015 e Integrador de KEPserver y
Thinmanager en 2016 y 2017.

Las herramientas de desarrollo utilizadas por LS Innovaciones C.A., incorpora plataformas

adaptadas a las necesidades del cliente, incluyen la Industria Manufacturera, Petróleo y Gas,
Metalurgia y Metalmecánica, Electrónica, Eléctrica, Sistemas de Monitoreo y Vigilancia por
video, voz y movimiento. Actualmente la empresa cuenta con tres sedes:
• LS Innovaciones ubicada en Caracas, Venezuela.
• WiSoft ubicada en Ciudad de Panamá, Panamá.
• PFsolve ubicada en Houston, Texas, USA.

 4
1.2. Misión
Brindar soluciones a sus clientes en cuanto a aplicaciones de sistemas de automatización y
seguridad, instrumentación y construcción, con especial atención a la seguridad y ambiente en el
entorno social que nos rodea.

1.3. Visión
Innovar en soluciones, respetando y cuidando el ambiente, seguridad en el trabajo realizado,
responsabilidad social con el entorno, mejoramiento continuo y compromiso y responsabilidad
con nuestros clientes y asociados.

1.4. Productos, Soluciones, Proyectos y Servicios

LS Innovaciones C.A. ofrece productos completamente configurables que permiten al cliente
adaptarlos a sus requerimientos particulares. Ofrece a la industria soluciones inteligentes, seguras
y confiables con el fin de mejorar la eficiencia, productividad y calidad de los procesos haciendo
el mundo más sostenible. Estos productos, atienden las necesidades desde la perspectiva de las
plantas de producción, buscando conectarlas, desde el sensor o dispositivo de medición hasta
llevarlas a la red. Dentro de los principales productos ofrecidos por LS Innovaciones C.A.
podemos mencionar:
• Sistemas de Monitoreo de condiciones
• Fire & Gas con ASH Logic
• Power House
• Control de Hornos y Calderas
• Sistemas de monitoreo de Control Remoto
• Sistemas de Fiscalización
• IndConnect Lite

De igual modo LS Innovaciones C.A. ofrece soluciones para minimizar riesgos y aumentar
la productividad de cada uno de sus clientes, para lo cual ofrece soluciones como:

• Sistemas de Control
• Sistemas de Detección de Fuego y Gas
• Sistemas SCADA
• Sistemas de Control Distribuidos

 5
• Sistemas de Monitoreo de Vibraciones
• Centro de Control de Motores
• Coordinación de Protecciones
• Transferencia Automática
• Sistemas de control de energía
• Data Center

Los Proyectos y Servicios ofrecidos y atendidos por LS Innovaciones abarcan:

• Servicios de consultoría, para apoyo y coordinación de proyectos
• Evaluación presencial para la elaboración de soluciones para su empresa
• Servicio de soporte técnico y asistencia personalizada
• Servicios integrados de asistencia y mantenimiento, tanto preventivo como correctivo
• Proyectos de Ingeniería, Procura y Construcción (IPC) en la industria energética
• Proyectos de cálculo y revisión de Sistemas Instrumentados de Seguridad
• Proyectos en diseño, construcción e implementación de soluciones con sistemas PLCs,
SCADA Y DCS
• Diseño e instalación de RTUs (Remote Terminal Unit - Unidad Terminal Remota)
• Instalación de Sistemas de Seguridad, Sistemas de Detección de Fuego y Gas

CAPÍTULO 2

FUNDAMENTOS TEÓRICOS

2.1. Internet de las cosas (IoT)

El término “Internet de las Cosas” (IoT) fue empleado por primera vez en 1999 por el
pionero británico Kevin Ashton para describir un sistema en el cual los objetos del mundo físico
se podían conectar a Internet por medio de sensores. Hoy en día, el término se ha popularizado
para describir escenarios en los que la conectividad a Internet y la capacidad de cómputo se
extienden a una variedad de objetos, dispositivos, sensores y artículos de uso diario.

2.1.1. Descripción General

Por lo general, el término IoT se refiere a escenarios en los que la conectividad de red y la
capacidad de cómputo se extienden a objetos, sensores y artículos de uso diario que
habitualmente no se consideran computadoras, permitiendo que estos dispositivos generen,
intercambien y consuman datos con una mínima intervención humana.

El concepto de combinar computadoras, sensores y redes para monitorear y controlar

diferentes dispositivos ha existido durante décadas. Sin embargo, la reciente confluencia de
diferentes tendencias del mercado tecnológico está permitiendo que la Internet de las Cosas esté
cada vez más cerca de ser una realidad generalizada. Estas tendencias incluyen la conectividad
omnipresente, la adopción generalizada de redes basadas en el protocolo IP, la economía en la
capacidad de cómputo, la miniaturización, los avances en el análisis de datos y el surgimiento de
la computación en la nube.

En este trabajo de investigación, consideramos la definición de la IAB (Internet Architecture

Board - Consejo de Arquitectura de Internet), establecido en “Architectural Considerations in

 7
Smart Object Networking – Consideraciones Arquitectónicas en Redes de Objetos Inteligentes’’
[2], donde definen a la IoT como: “El término que denota una tendencia en que un gran número
de dispositivos embebidos utilizan los servicios de comunicación que ofrecen los protocolos de
Internet. A estos dispositivos suelen llamarles “objetos inteligentes’’ y no son operados
directamente por un ser humano, sino que existen como componentes en edificios o vehículos o
están distribuidos en el entorno”.

2.1.2. Modelos de Comunicación del IoT y sus aplicaciones

Desde el punto de vista operativo, debemos conocer cómo se conectan y comunican los
dispositivos de la IoT en términos de sus modelos de comunicación. En marzo de 2015, la IAB
dio a conocer un documento para guiar la creación de redes de objetos inteligentes, que describe
un marco de cuatro modelos de comunicación comunes que utilizan los dispositivos de la IoT [2].
Los cuatro modelos básicos de comunicación muestran las estrategias de diseño subyacentes
utilizadas para permitir que los dispositivos de la I/O (Imput Output - Entrada Salida) se
comuniquen, y cuyas características principales se explican a continuación.

1) Modelo de Comunicación Dispositivo - Dispositivo

Este modelo representa dos o más dispositivos que se conectan y se comunican directamente
entre sí y no a través de un servidor como intermediario. Estos dispositivos se comunican sobre
muchos tipos de redes, entre ellas las redes IP o la Internet. Sin embargo, para establecer
comunicaciones directas de dispositivo a dispositivo, muchas veces se utilizan protocolos como
Bluetooth, Z-Wave o ZigBee, como se muestra en la Figura 2.1.

Figura 2.1 Diagrama del Modelo de Comunicación Dispositivo – Dispositivo.

 8
El modelo de comunicación dispositivo a dispositivo encaja bien en aplicaciones de
domótica o telemetría, en las que los dispositivos intercambian pequeños paquetes de datos a baja
velocidad y cada cierto tiempo. Los dispositivos para la IoT residenciales (bombillas de luz,
interruptores, termostatos y cerraduras) normalmente envían pequeñas cantidades de información
(por ejemplo, un mensaje del estado de bloqueo de una puerta o un comando para encender una
bombilla de luz) en un escenario de automatización del hogar.

2) Modelo de Comunicación Dispositivo - Internet

Es un modelo de comunicación donde el dispositivo de la IoT se conecta directamente a un
servicio en la nube 1 , como por ejemplo un proveedor de servicios de aplicaciones para
intercambiar datos y controlar el tráfico de mensajes. Este enfoque suele aprovechar los
mecanismos de comunicación existentes (por ejemplo, conexiones WiFi o Ethernet cableadas)
para establecer conexión entre el dispositivo y la red IP, que luego se conecta con el servicio en la
nube.

En este modelo encajan todas aquellas aplicaciones en las que el dispositivo IoT tiene
capacidad suficiente para conectar directamente con algún servicio en la nube, con el que
comparte datos para que sean analizados por algoritmos o enviar comandos de control para
actuar directamente sobre el dispositivo. Esto se ilustra en la Figura 2.2.

Figura 2.2. Diagrama de Modelo de Comunicación Dispositivo – Internet.

1 La nube de Internet es un nuevo modelo de uso de los equipos informáticos. Traslada y almacena parte de archivos
y programas a un conjunto de servidores a los que puedes acceder a través de Internet.

 9
Para que esto sea posible, el dispositivo debe contener el hardware específico que permita
conectarse vía Ethernet o WiFi y tener recursos suficientes para albergar una pila TCP/IP.
Ejemplos de este tipo de comunicación la vemos en electrodomésticos de alta gama, como una
Smart Tv (Tv inteligente).

3) Modelo de Comunicación Dispositivo – ALG (Application Level Gateway - Puerta de Enlace

de Capa de Aplicación)
Para éste modelo el dispositivo de la IoT se conecta a través del servicio ALG a fin de llegar
a un servicio en la nube. Lo que significa que hay un software de Aplicación (App) corriendo en
un dispositivo de puerta de enlace local, que actúa como intermediario entre el dispositivo y el
servicio en la nube y que provee seguridad y otras funcionalidades tales como traducción de
protocolos o datos.

Este es el modelo de comunicación más utilizado en IoT, hay varios dispositivos que se
utilizan hoy en día como ALG. Uno de los más populares y flexibles son los smartphones
(teléfono inteligente), capaces de conectar dispositivos IoT e Internet a través de alguna App,
aprovechando la conexión a Internet que traen de serie. Este modelo se muestra en la Figura 2.3.

Figura 2.3. Diagrama del Modelo de Comunicación

Dispositivo – Puerta de Enlace Capa de Aplicación ALG.

 10
4) Modelo de Intercambio de Datos a través del Back End (Interfaz de programación)
Este modelo es la arquitectura de comunicación soporte de los servicios en Internet que
permiten a los usuarios recolectar datos de sus dispositivos IoT, analizarlos y tomar decisiones
inteligentes. A menudo, estos servicios permiten compartir datos con otros servicios. A nivel
empresarial, está directamente relacionado con el Big Data (Datos a gran escala) y el Business
Intelligence (Inteligencia de negocios).

El objetivo principal de este modelo es conseguir interoperabilidad entre los diferentes

servicios en la nube, en un mundo que tiende a compartir toneladas de gigabytes (GB) de datos
de todo tipo por las redes, sin que apenas nos enteremos. La Figura 2.4 muestra una
representación de éste diseño.

Figura 2.4. Diagrama del Modelo de Intercambio de Datos a

través del Back End (Interfaz de programación).

2.1.3. Desafíos y barreras para el IoT

A pesar de las bondades ofrecidas por el IoT, existen desafíos y barreras que podrían retrasar
su desarrollo, entre estos resaltan la implementación de IPv6, la energía para alimentar los
sensores y el acuerdo sobre normas, lo cual detallamos a continuación:
• Implementación de IPv6: En febrero de 2010, se agotaron las direcciones IPv4 del mundo.
Esto afecta el progreso del IoT, puesto que los posibles miles de millones de sensores
necesitarán direcciones IP exclusivas. Considerando que IPv6 facilita la administración de las

 11
redes por sus capacidades de autoconfiguración y características de seguridad mejoradas, su
implementación es impostergable.
• Energía para los sensores: Para que IoT alcance su máximo potencial, los sensores deberán ser
autosustentables. Pues no se podrán cambiar las baterías de miles de millones de dispositivos
implementados en todo el planeta e incluso en el espacio, lo que requiere encontrar una forma
de que los sensores generen electricidad a partir de elementos medioambientales o de otro
tipo, tales como las vibraciones, la luz, corrientes de aire, etc.
• Normas: Si bien se han realizado grandes progresos en cuanto a las normas y regulaciones, se
necesita profundizar aún más, especialmente en áreas de seguridad, privacidad, arquitectura y
comunicaciones. IEEE (Institute of Electrical and Electronics Engineers – Instituto de
Ingeniería Eléctrica y Electrónica) es una de las organizaciones que actualmente trabajan para
evitar estas dificultades, con la tarea de garantizar que los paquetes de IPv6 se puedan
direccionar a través de tipos de red diferentes.

2.2. Protocolo de Comunicación Industrial ModBus

ModBus es un protocolo industrial desarrollado en 1979 por Modicon (Modular Digital
Controller – Controlador Modular Digital) (Actualmente Schneider Electric) para hacer posible
la comunicación entre dispositivos de automatización. Fue implementado como un protocolo al
nivel de la aplicación con la finalidad de transferir datos utilizando:
• TCP/IP sobre Ethernet
• Transmisión en serie asíncrona en diferentes medios (cables, fibra óptica, Infra-rojo, radio)
• UDP (User Datagram Protocol – Protocolo de Datagramas de Usuarios)
• ModBus Plus (Red de paso de alta velocidad)

El protocolo ModBus es el lenguaje común utilizado por todos los controladores Modicon.
Este define una estructura de mensajes que los controladores reconocerán y utilizarán,
independientemente del tipo de redes sobre las que se comuniquen. Describe el proceso que un
controlador utiliza para solicitar acceso a otro dispositivo, cómo responderá a las solicitudes de
los otros dispositivos y cómo se detectarán y notificarán los errores. Establece un formato común
para el diseño y el contenido de los campos de mensaje. ModBus define una PDU (Protocol Data
Unit - Unidad de Datos de Protocolo) independiente de las capas de comunicación subyacentes.
El mapeo del protocolo ModBus en buses o redes específicos puede introducir algunos campos

 12
adicionales en la ADU (Aplication Data Unit - Unidad de Datos de Aplicación) tal como se
indica en la Figura 2.5.

ADU
Dirección Adicional Código Función Datos Chequeo de Error
LRC/CRC

PDU

Figura 2.5. Marco General ModBus.

Su especificación abierta permite la comunicación entre todos los tipos de arquitectura de

red. Dispositivos, como: PLC (Programmable Logic Controller – Controlador Lógico
Programable), HMI (Human Machine Interface – Interfaz Hombre Máquina), Panel de control,
Driver (Controlador), Control de movimiento, I/O (Input/Output- Entrada/Salida), pueden
utilizar el protocolo ModBus para iniciar una operación remota. La misma comunicación se
puede realizar tanto en línea serial como en redes. Las entradas permiten una comunicación entre
varios tipos de buses o red usando el protocolo ModBus. Tal como se muestra en la Figura 2.6.

Figura 2.6. Arquitectura de red ModBus [3].

 13
ModBus proporciona el estándar interno que utilizan los controladores Modicon para
analizar mensajes. Durante las comunicaciones en una red ModBus, el protocolo determina cómo
cada controlador conocerá su dirección de dispositivo, reconocerá un mensaje dirigido a ella,
determinará el tipo de acción que se tomará y extraerá cualquier dato u otra información
contenida en el mensaje. Si se requiere una respuesta, el controlador construirá el mensaje de
respuesta y lo enviará usando el protocolo.

2.2.1. Las transacciones en ModBus

ModBus es un protocolo de mensajería de capa de aplicación, situado en el nivel 7 del
modelo OSI (Open System Interconnection - Modelo de interconexión de sistemas abiertos), que
proporciona comunicación entre dispositivos conectados en diferentes tipos de buses o redes
enmarcada en el concepto de bus de Campo de Control y como tal, su topología es maestro-
esclavo con una estructura de bus lineal donde solo existe un maestro, el cual controla el acceso
al medio y monitorea el funcionamiento de la red, y uno o más dispositivos programables que
actúan como esclavos que pueden ser hasta 247 y que responden y proceden según lo requerido
por el maestro. Los esclavos se limitan a retornar los datos solicitados o a ejecutar la acción
indicada por el maestro. La comunicación del maestro hacia los esclavos puede ser de dos tipos:
§ Peer to Peer (Punto a Punto): en la que se establece la comunicación “maestro - esclavo”, el
maestro solicita información y el esclavo responde.
§ Broadcast (Difusión amplia): en la que se establece comunicación “maestro - todos los
esclavos”, el maestro envía un comando a todos los esclavos de la red sin esperar respuesta.

La comunicación se da en forma serial asíncrona bajo los estándares RS-232 ó RS-485 para
enlace half duplex (semi-duplex)2 y RS-422 para enlace full duplex (dúplex)3, utiliza diferentes
medios físicos como son los de soporte metálico (cables), radio frecuencia (RF), fibra óptica o
infra rojo cuya velocidad de transmisión oscila entre los 75 y 19200 Baudios.

Estos mensajes son conocidos como tramas y están constituidos por un conjunto de
caracteres que tienen una longitud de las tramas variables, pero acotadas a un máximo de 256
caracteres. Estas tramas contienen los datos necesarios para reconocer el origen y objetivo de

2
Half-duplex (Semi-dúplex): transmisión en ambas direcciones, solo una dirección a la vez. Transmisor y receptor
comparten una sola frecuencia.
3
Full dúplex (Dúplex): transmisión en ambas direcciones, simultáneamente por el mismo canal. Dos frecuencias una
para transmitir y otra para recibir.

 14
cada mensaje puesto en el bus por alguno de los dispositivos y que luego le servirá a un
dispositivo receptor para hacer la validación y la posterior toma de decisiones.

El protocolo ModBus maneja básicamente dos tipos de datos: bits individuales y palabras de
16 bits. Los bits individuales corresponden a entradas o salidas discretas con estados On/Off y las
palabras a registros de entrada o salida cuyos estados indican un valor análogo. En la Tabla 2.1
se presentan estos tipos de datos.

Tabla 2.1. Datos en un dispositivo de una red ModBus

SECTOR FORMATO TIPO DE COMENTARIO

ACCESO
Salidas discretas (Coils) Bits individuales Lectura-Escritura Modificables programa de
Aplicación
Entradas discretas (Inputs) Bits Individuales Solo lectura Suministrados por un sistema
de E/S
Registros de entrada (Inputs register) Palabras de 16 bits Solo lectura Suministrados por un sistema
de E/S
Registros de salida (Holding register) Palabras de 16 bits Lectura-Escritura Modificables programa de
Aplicación

Estos datos pueden ser modificados sólo si son salidas del controlador programable. La
entradas no tiene la posibilidad de ser cambiadas por un software de aplicación ya que hacen
referencia a estados externos de los controladores.

En la Tabla 2.2, se muestra una referencia de los datos manejados por los controladores.

Tabla 2.2. Referencia de los datos en los controladores ModBus

SECTOR INFORMACIÓN REFERENCIA

Salidas discretas (Coils) Salida digital 0X
Entradas discretas (Inputs) Entrada digital 1X
Registros de entrada (Inputs register) Valores analógicos 3X
Registros de salida (Holding register) Entradas analógicas 4X

En su definición inicial el protocolo ModBus era una especificación de tramas, mensajes y

funciones utilizada para la comunicación entre los PLCs de la empresa Modicon. En la actualidad
este protocolo ha sido acogido y actualizado convirtiéndose de hecho en un estándar para la

 15
automatización de la industria gracias a su particular estructura de mensajes que opera con
direcciones de memoria y no variables concretas, haciéndolo aceptable a diferentes dispositivos.
También debido a su especificación realmente abierta que permite comprender en toda su
extensión la forma en que se lleva a cabo la transacción de mensajes y el flujo de información
con lo cual ha sido posible la programación de equipos que lo ejecuten y puedan formar parte de
una red ModBus.

2.2.2. Modos de transmisión en Serie

El protocolo ModBus posee dos modos de comunicación serial conocidas como ASCII
(American Standard Code for Information Interchange – Código Estándar Americano para
Intercambio de Información) y RTU (Remote Terminal Unit – Unidad Terminal Remota), para el
intercambio de mensajes entre los diferentes dispositivos que conforman la red.

Los controladores pueden configurarse para comunicarse en redes ModBus con cualquiera
de los dos modos de transmisión: ASCII o RTU. Los usuarios seleccionan el modo deseado,
junto con los parámetros de comunicación del puerto serie (velocidad en baudios, modo de
paridad, etc.) durante la configuración de cada controlador. Los parámetros de modo y serie
deben ser los mismos para todos los dispositivos de una red ModBus. La selección del modo
ASCII o RTU pertenece únicamente a las redes ModBus estándar. Define el contenido de bits de
los campos de mensaje transmitidos en serie en dichas redes. Determina cómo la información
será empaquetada en los campos de mensaje y decodificada. El modo y los parámetros del puerto
serie tienen que ser los mismos para todos los dispositivos a fin de garantizar en primera instancia
el buen funcionamiento de la red. A continuación desarrollamos el modo de transmisión RTU por
ser el modo de transmisión en serie utilizado en el proyecto.

2.2.2.1. Modo de transmisión RTU

Cuando los controladores se configuran para comunicarse en una red ModBus mediante el
modo de transmisión RTU, cada byte de 8 bits en un mensaje contiene dos caracteres de 4 bit
hexadecimales (Hex.). Cada mensaje debe ser transmitido en un flujo continuo. En la Figura 2.7
se muestra la estructura (trama) de un mensaje enviado utilizando el modo RTU. Los mensajes
comienzan con un intervalo de silencio de 3,5 veces el tiempo necesario para enviar un carácter
lo cual se indica como T1-T2-T3-T4. Después de este silencio el primer campo transmitido es la
dirección del esclavo, cuya longitud es de ocho bits.

 16
INICIO DIRECCIÓN FUNCIÓN DATOS CRC FIN

T1-T2-T3-T4
N
8 bits 8 bits n*8 bits 16 bits T1-T2-T3-T4

Figura 2.7. Trama en el modo de transmisión RTU.

De igual modo se cuenta con ocho bits para enviar el código de función, múltiplos enteros de
ocho bits para los datos si son necesarios y dieciséis para el CRC (Cyclic Redundancy Check –
Chequeo Cíclico Redundante). La trama terminará con un silencio de al menos 3,5 veces el
tiempo necesario para enviar un carácter.

Además del tiempo que limita el inicio y el fin de una trama, en el modo de transmisión RTU
se debe considerar, el tiempo que transcurre entre la llegada de caracteres consecutivos. Este
tiempo se ha definido para que sea máximo de 1,5 veces el Tiempo necesario para enviar un
carácter (Tc). Si entre el fin de un carácter y el comienzo de otro, transcurre un tiempo mayor que
1,5Tc y menor que 3,5Tc se producirá una situación de error en la transmisión y el dispositivo
receptor debe ignorar la trama. Cuando se produce este error los esclavos no enviaran ningún
mensaje de respuesta.

El formato para cada byte en el modo RTU, se muestra en la Tabla 2.3.

Tabla 2.3. Formato para cada Byte en el modo RTU

SISTEMA DE CODIFICACIÓN: 8 BITS BINARIOS, HEXADECIMAL 0-9, A-F

Dos caracteres Hex. en cada campo de 8 bits del mensaje
Bits por Byte: 1 bit de inicio
8 bits de datos, el bit menos significativo se envía primero
1 bit para paridad, si se usa bit de paridad
1 bit de parada si se usa paridad y 2 bits si no se usa paridad
Campo de verificación de errores: Chequeo Cíclico Redundante (CRC)


De esto se deduce que los caracteres para el modo de transmisión RTU tiene una longitud de
once bits. En la Figura 2.4 se muestra gráficamente el orden en el que se envía cada carácter de la
trama en el modo de transmisión RTU.

 17
CON CHEQUEO DE PARIDAD
INICIO 1 2 3 4 5 6 7 8 PAR FIN
SIN CHEQUEO DE PARIDAD
INICIO 1 2 3 4 5 6 7 8 FIN FIN

Figura 2.8. Orden de bits en el modo de transmisión RTU.

Un ejemplo de petición de tres datos se muestra en la Tabla 2.4, en la cual se observa como
se construye la consulta en el formato RTU. El maestro le pide al esclavo que envíe tres registros
a partir del registro 006B (107d).

Tabla 2.4. Consulta del maestro con modo de transmisión RTU

CONSULTA
Ejemplo RTU
Nombre del Campo (Hex.) Campo de 8-Bit
Cabecera Ninguno
Dirección esclavo 06 0000 0110
Función 03 0000 0011
Dirección Inicio (Hi) 00 0000 0000
Dirección Inicio (Lo) 6B 0110 1011
No. de Registro (Hi) 00 0000 0000
No. de Registro (Lo) 03 0000 0011
Chequeo de errores CRC (16 bits)
Fin de la Trama Ninguno
Total Bytes: 8

2.2.3. Modo de transmisión TCP/IP

ModBus TCP/IP es el Protocolo de Control de Transmisión y Protocolo de Internet, que
proporciona el medio de transmisión para la mensajería ModBus TCP/IP, es simplemente el
protocolo ModBus RTU con una interfaz TCP que funciona en Ethernet.

La función principal de TCP es asegurar que todos los paquetes de datos se reciban, mientras
que IP garantiza que los mensajes sean dirigidos y enrutados. La combinación TCP/IP es

 18
simplemente un protocolo de transporte, y no define qué significa el dato o cómo se interpretarán
los datos, lo cual es el objetivo del protocolo de aplicación ModBus. ModBus TCP/IP utiliza
TCP/IP y Ethernet para transportar los datos de la estructura de mensajes entre dispositivos
compatibles, combina una red física (Ethernet), un estándar de red (TCP/IP) y un método
estándar de representación de datos ModBus como protocolo de aplicación.

El mensaje ModBus TCP/IP es simplemente una comunicación ModBus encapsulada en una

envoltura Ethernet TCP/IP. Así, ModBus TCP incorpora una trama de datos ModBus estándar en
una trama TCP, sin la suma de comprobación ModBus, como se muestra en la Figura 2.9.

MENSAJE MODBUS RTU

ID CÓDIGO DE
DATOS CRC
ESCLAVO FUNCIÓN

ENCABEZADO MBAP MODBUS TCP/IP PDU

ID ID CÓDIGO DE
LONGITUD ID UNIDAD DATOS
TRANSACCIÓN PROTOCOLO FUNCIÓN

MODBUS TCP/IP ADU

Figura 2.9. Encabezado de una trama ModBus TCP/IP.

Los comandos ModBus y datos de usuario están encapsulados en el contenedor de datos de

una trama TCP/IP sin ser modificados de ninguna manera. Sin embargo, no se utiliza el campo de
comprobación de errores de ModBus (CRC), ya que los métodos estándar de verificación de la
capa de enlace TCP/IP Ethernet se utilizan para garantizar la integridad de los datos.

Además, el campo de dirección de trama ModBus es suplantado por el identificador de

unidad en ModBus TCP/IP, y pasa a formar parte del MABP (ModBus Aplication Bus Protocol –
Protocolo de Aplicación ModBus).

El encabezado MABP tiene 7 bytes de longitud e incluye los siguientes campos:

• Identificador de transacción: 2 bytes establecidos por el Cliente para identificar de forma
exclusiva cada solicitud. Estos bytes son repetidos por el servidor ya que sus respuestas no
pueden ser recibidas en el mismo orden que las solicitudes.
• Identificador de protocolo: 2 bytes establecidos por el cliente, siempre = 00 00

 19
• Longitud: 2 bytes que identifican el número de bytes en el mensaje a seguir.
• Identificador de unidad: 1 byte establecido por el Cliente y repetido por el Servidor para la
identificación de un esclavo remoto conectado en una línea serie o en otros buses.

De esta forma, un mensaje ModBus TCP completo posee una estructura como se muestra en
la Tabla 2.5.

Tabla 2.5. Estructura de mensajes en ModBus TCP

POSICIÓN DE BYTE SIGNIFICADO

Byte 0 Identificador de transacción. Copiado por el servidor- normalmente 0.
Byte 1 Identificador de transacción. Copiado por el servidor -normalmente 0.
Byte 2 Identificador de protocolo = 0.
Byte 3 Identificador de protocolo = 0.
Byte 4 Campo de longitud (byte alto) = 0. Los mensajes son menores a 256.
Byte 5 Campo de longitud (byte bajo). Número de bytes siguientes.
Byte 6 Identificador de unidad (previamente *dirección esclavo*).
Byte 7 Código de función MODBUS.
Byte 8 a más Los datos necesarios.

Por ejemplo, una solicitud equivalente a esta trama de RTU de ModBus, sería:
11 03 006B 0003 7687

Y su equivalente en ModBus TCP, sería:

0001 0000 0006 11 03 006B 0003

Donde:

0001: Identificador de transacción

0000: Identificador de protocolo
0006: Longitud del mensaje (6 bytes a seguir)
11: El identificador de la unidad (17 = 11 Hex.)
03: El código de función (leer los registros de retención de salida analógica)
006B: Dirección de datos del primer registro solicitado (40108 - 40001 = 107 = 6B Hex.)
0003: El número total de registros solicitados. (Leer 3 registros 40108 a 40110)

 20
La ADU ModBus TCP/IP completa, está incrustada en el campo de datos de una trama TCP
estándar y enviada a través de TCP al Puerto de Sistema 502 4 , reservado para aplicaciones
ModBus, mediante el cual los clientes y servidores ModBus TCP/IP escuchan y reciben datos
ModBus. La unión del protocolo de aplicación ModBus con la transmisión Ethernet forma un
poderoso estándar de comunicación industrial en ModBus TCP/IP.

2.2.4. El ciclo Solicitud/Respuesta

En una red de dispositivos conectados mediante el protocolo ModBus no se pueden tener
dispositivos utilizando diferentes modos de transmisión. Los intercambios de mensajes cumplen
un Ciclo de Solicitud/Respuesta, lo cual se logra mediante tramas tal como se muestra en la
Figura 2.12., donde se observa que la estructura de la trama enviada por el maestro al esclavo es
similar al enviado por el esclavo al maestro. Estas tramas deben contener:
(1) Campo de Dirección
(2) Campo Código de Función
(3) Campo de Datos
(4) Campo de Chequeo de Errores.

Mensaje de pregunta del maestro

Dirección del dispositivo Dirección del dispositivo

Código de función Código de función

8 bits 8 bits
Bytes de datos Bytes de datos

Chequeo de error Chequeo de error

Mensaje de respuesta del esclavo

Figura 2.10. El ciclo de Solicitud/Respuesta (Maestro – Esclavo) [4].

4
Puerto por defecto al cual direccionar datos de ModBus TCP.

 21
2.2.4.1. Campo de dirección
ModBus es un protocolo multipunto, el maestro puede comunicarse a múltiples esclavos
utilizando la misma línea de comunicación. Cada esclavo debe tener una identificación única e
irrepetible dentro de la red con la que los dispositivos identificaran el destino y el origen de los
mensajes que sean puestos en el bus. Duplicar esta dirección puede producir colisiones en el bus
o conflictos en la red que conlleven a un flujo de datos no fiables con las posteriores
consecuencias negativas en lo que se quiere comunicar. Todas las direcciones de datos de los
mensajes ModBus se hacen referencia a cero. La primera aparición de un elemento de datos se
trata como el número de ítem cero. Por ejemplo:
§ La bobina (Coil) conocida como “Bobina 1” en un controlador programable se dirige como
bobina 0000 en el campo de dirección de datos de un mensaje ModBus.
§ La bobina 127 decimal se dirige como la bobina 007E Hex. (126 decimal).
§ El registro de retención 40001 se dirige como el registro 0000 en el campo de dirección de
datos del mensaje. El campo de código de función ya especifica una operación “Holding
Register” (Registros de Lectura/Escritura). Así, la referencia “4XXXX” está implícita.
§ El registro de retención 40108 se dirige como el registro 006B Hex. (107 decimal).

El campo de dirección es utilizado por los esclavos para colocar en él su propia dirección y
permitirle al maestro identificar qué esclavo a puesto en el bus un mensaje de respuesta.

2.2.4.2. Campo de códigos de función

Cada función permite transmitir órdenes a un esclavo. Existen dos tipos básicos de ordenes,
(1) Ordenes de Lectura/Escritura de datos en los registros o en la memoria del esclavo y (2)
Ordenes de Control (Run/Stop, carga y descarga de programas, verificación de contadores, etc.)

Hay tres categorías de códigos de funciones ModBus, estas son:

• Códigos de Función Pública
− Están bien definidos
− Garantizados para ser únicos
− Validado por Modbus.org
− Documentados públicamente
− Disponen de pruebas de conformidad

 22
− Incluye tanto los códigos de función públicos asignados definidos, como la función no
asignada
− Códigos reservados para uso futuro
• Códigos de Función Definidos por el Usuario
− Existen dos rangos de códigos definidos por el usuario, de 65 a 72 y de 100 a 110 decimal
− El Usuario puede implementar un código de función no soportado por la especificación
− No hay garantía de que el uso del código de función seleccionado sea único
− Si el usuario desea volver a colocar la funcionalidad como un código de función pública,
debe iniciar una RFC (Request For Comments – Solicitud de Comentario) para introducir el
cambio en la categoría pública y tener un nuevo código de función público asignado
− La organización ModBus se reserva expresamente el derecho de desarrollar el RFC
propuesto
• Códigos de Función Reservados
− Códigos utilizados por algunas empresas para productos y no disponibles para uso público

El Campo de Código de Función de una trama cuando se utiliza el modo de transmisión RTU
contiene ocho bits. Los códigos válidos están en el rango decimal de 1 …255. Cuando el maestro
envía un mensaje de petición a un dispositivo esclavo, el campo de código de función le dice al
esclavo que tipo de acción debe ejecutar. Algunos ejemplos de funciones son: leer o forzar los
estados On/Off de un grupo de salidas discretas, leer o forzar el contenido de un grupo de
registros, leer el estado de diagnóstico del esclavo, etc. En la Figura 2.11. se muestran las
categorías de códigos de función ModBus.

127
CÓDIGOS DE FUNCIÓN PÚBLICA

110 CÓDIGOS DE FUNCIÓN DEFINIDOS

100 POR EL USUARIO

CÓDIGOS DE FUNCIÓN PÚBLICA

72 CÓDIGOS DE FUNCIÓN DEFINIDOS

65 POR EL USUARIO

CÓDIGOS DE FUNCIÓN PÚBLICA

1

Figura 2.11. Categorías Códigos de Función ModBus [4].

 23
Cuando el esclavo responde usa el campo de código de función en el mensaje de respuesta
para indicar si es una respuesta normal o si ha ocurrido alguna excepción.

Un mensaje del maestro al esclavo para leer un grupo de registros de salida tendría el
siguiente código de función en el modo de transmisión RTU: 0000 0011 (Hex. 03). Si el
dispositivo esclavo puede ejecutar la acción solicitada, el código de función en el mensaje de
respuesta es igual al enviado en la solicitud.

En caso contrario, si hay una excepción, el contenido del campo del código de función será:
1000 0011 (Hex. 83). Además, el esclavo coloca un código en el campo de datos del mensaje de
respuesta, que le informa al maestro que tipo de error se produjo o la razón de la excepción. En la
Tabla 2.6. se muestra la definición de los códigos de función pública disponibles en el protocolo
ModBus.

Tabla 2.6. Definición de Códigos de Función Pública disponibles Protocolo ModBus [4]

CÓDIGO DE FUNCIÓN
CÓD. SUB CÓD. (Hex.)
Entradas físicas Discretas Leer entradas discretas 02 02
A Acceso Bits internos Leer Bobinas 01 01
C Bits O Escribir Bobina simple 05 05
C Bobinas Físicas Escribir Bobinas Múltiples 15 0F
E Registros Entrada Física Leer Registro de Entrada 04 04
S Leer Registros de Retención 03 03
O Acceso Registros Internos Escribir Registro Simple 06 06
16 O Escribir Múltiples Registros 16 10
D Bits Registros de Leer/Escribir Múltiples Registros 23 17
A Salidas Físicas Mascara Escribir Registro 22 16
T Leer FIFO queue 24 18
O Leer Archivo de Registro 20 14
S Acceso Registro de Archivos Escribir Archivo de Registro 21 15
Leer Estatus de Excepción 07 07
Diagnóstico 08 00-18,20 08
Contador de Eventos Get Com 11 0B
Diagnóstico Registro de Eventos Get Com 12 0C
ID del Servidor de Informes 17 11
Leer Identificación Dispositivo 43 14 2B
Otros Interfaz Encapsulada Transporte 43 13,14 2B
Referencia General CANopen 43 13 2B

 24
2.2.5. Funciones de datos y control ModBus
A continuación se indican los códigos según corresponde:

2.2.5.1 Códigos de función de acceso de datos

• Leer Bobina (Read Coil) [01 0X01]
• Leer Entradas Discretas (Read Multiple Coils) [02 (0X02)]
• Leer Registros de Retención (Read Holding Registers) [03 (0X03)]
• Leer Registros de Entrada (Read Input Registers) [04 (0X04)]
• Escribir Bobina Simple (Write Single Coil) [05 (0X05)]
• Escribir un Registro Único (Write Holding Register) [06 (0X06)]
• Escribir Varias Bobinas (Write Multiple Coils) [15 (0X0F)
• Escribir Varios Registros (Write Multiple Registers) [16 (0X10)]
• Registro de Lectura de Archivos [20 (0X14)]
• Grabar Registro de Archivo [21 (0X15)]
• Máscara Escribir Registro [22 (0X16)]
• Leer/Escribir Múltiples Registros [23 (0X17)]
• Leer la Cola “Primero entra, Primero sale” FIFO (First in, First out) [24 (0X18)]

2.2.5.2 Códigos de función de diagnóstico

• Estado de Excepción de Lectura (Sólo línea serial) [07 (0X07)]
• Diagnóstico (Sólo línea serial) [08 (0X08)]
o Los Códigos de Sub-función Soportados por los Dispositivos de Línea Serial
− 00 Datos de Consulta de Devolución
− 01 Opción de Reinicio de Comunicaciones
− 02 Registro de Diagnóstico de Devoluciones
− 03 Cambio del Delimitador de Entrada ASCII
− 04 Forzar el Modo de Solo Escuchar
− 10 Contadores Claros y Registro de Diagnóstico [0A Hex.]
− 11 Recuento de Mensajes de bus de Retorno [0B Hex.]
− 12 Error de Comunicación de Bus de Retorno [0C Hex.]
− 13 Retorno del Error de Excepción de Bus de Retorno [0D Hex.]

 25
− 14 Devolver el Número de Mensajes del Servidor [0E Hex.]
− 15 Servidor de Devolución sin Contador de Respuesta [0F Hex.]
− 16 Retorno Servidor Reconocimiento Negativo (NAK Count) [10 Hex.]
− 17 Retorno de la Cuenta Ocupada del Servidor [11 Hex.]
− 18 Retorno del Recuento de Caracteres del bus [12 Hex.]
− 20 Contador e Indicador de Desbordamiento [14 Hex.]
• Obtener Contador de Eventos de Comunicación (Sólo línea serial) [11 (0X0B)]
• Obtener Registro de Eventos de Comunicación (Sólo línea serial) [12 (0X0C)]
• ID de Servidor de Informes (Sólo línea serial) [17 (0X11)]
• Leer la Identificación del Dispositivo 43/14 [0X2B/0X0E]

2.2.5.3 Otras Funciones

• Transporte de Interfaz Encapsulado [43 (0X2B)]
• Solicitud Referencia Gen. CANopen y Respuesta PDU [43/13 (0X2B/0X0D)]

2.3. Protocolo de Comunicación Web MQTT

MQTT (Message Queue Telemetry Transport – Transporte Telemétrico de Mensajes en
Cola), es un protocolo usado para la comunicación machine-to-machine (máquina a
máquina) (M2M) en el Internet de las Cosas (IoT). Este protocolo está orientado a la
comunicación de sensores, dado que consume muy poco ancho de banda.

El protocolo se ejecuta sobre TCP/IP, o sobre otros protocolos de red que proporcionan
conexiones bidireccionales ordenadas, sin pérdidas. En Octubre de 2014 se aprobó el MQTT
Versión 3.1.1. como una norma OASIS [5]. Sus características incluyen:
• Uso del patrón de mensaje de publicación/suscripción que proporciona una distribución de
mensajes de uno a varios y desacoplamiento de aplicaciones.
• Un transporte de mensajería que es agnóstico para el contenido de la carga útil. Con tres
cualidades de servicio para el envío de mensajes:
− "A lo sumo una vez", donde los mensajes se entregan de acuerdo con los mejores esfuerzos
del entorno operativo. Se puede producir una pérdida de mensajes. Este nivel podría
utilizarse, por ejemplo, con datos de sensores ambientales en los que no importa si se pierde
una lectura individual, ya que la siguiente será publicada poco después.

 26
− "Por lo menos una vez", donde los mensajes se aseguran para llegar pero los duplicados
pueden ocurrir.
− "Exactamente una vez", donde el mensaje está asegurado para llegar exactamente una vez.
Este nivel podría utilizarse, por ejemplo, con sistemas de facturación en los que los
mensajes duplicados o perdidos podrían dar lugar a que se aplicaran cargos incorrectos.
• Se minimiza un pequeño gasto de transporte y se minimizan los intercambios de protocolos
para reducir el tráfico de red.
• Un mecanismo para notificar a las partes interesadas cuando se produce una desconexión
anormal.

La arquitectura de MQTT sigue una topología de estrella, con un nodo central que hace de
Servidor (Broker) con una capacidad de hasta 10000 clientes. El servidor es el encargado de
gestionar la red y de transmitir los mensajes, para mantener activo el canal, los clientes mandan
periódicamente un paquete y esperan la respuesta del servidor. La comunicación puede ser
cifrada entre otras muchas opciones que aporta a la red una capa extra de seguridad. Este tipo de
arquitectura, permite que la comunicación puede ser de uno a uno o de uno a muchos. La
comunicación se basa en "topics" (tópicos), que el cliente que publica el mensaje crea y los nodos
que deseen recibirlo deben subscribirse a él.

2.4. Descripción General del Sistema a Monitorear

En todo proceso industrial se presentan distintas variables que afectan las entradas o salidas
del proceso. Temperatura, nivel, flujo y presión, son variables comunes en los procesos
industriales. Estas son monitoreadas y controladas por medio de la instrumentación del proceso a
fin de tener un mejor entendimiento de cómo las máquinas y/o equipos en la planta, se están
desempeñando en tiempo real y poder tomar acciones sobre el comportamiento de las mismas.
Los datos en vivo e históricos sobre el desempeño de estas variables ayudan a identificar
problemas técnicos en curso o pronto a ocurrir, y que por tanto pueden ser perjudiciales para la
productividad con los inconvenientes que esto acarrea en perdida de producción, tiempo y dinero,
haciendo onerosos los procesos de mantenimiento y recuperación de maquinas y equipos
dañados. Como parte de sus objetivos comerciales y empresariales, surge como solución a esta
problemática IndConnect de la empresa LS Innovaciones C.A., cuya solución se presenta como
una combinación de hardware y software, capaz de monitorear los distintos sistemas [6], los

 27
cuales en base a la data obtenida y recolectada, permiten al usuario visualizar y analizar toda
la información con el fin de verificar y evaluar el desempeño requerido y necesario para las
operaciones de una planta en específico y en tiempo real.

En la Figura 2.12. se muestra un diagrama descriptivo de la plataforma indConnect de la

empresa LS Innovaciones C.A.

Figura 2.12. Plataforma indConnect [6].

La plataforma indConnect ofrece la posibilidad de llevar los datos de una planta al Internet
de forma segura, pudiendo acceder desde cualquier lugar del mundo a través de una plataforma
Web que se ha desarrollado para ello, desde un PLC remoto o directamente desde un SCADA.
Para esto se dispone de un servidor alojado en la “Nube”, el cual puede actuar como servidor
MQTT, recibiendo y enviando datos desde y hacia cada uno de los equipos mediante IndConnect
Gateway e IndConnect Link, este último es el caso que nos ocupa en este proyecto de pasantía.

En la Figura 2.13. se muestra un ejemplo de aplicación web de la plataforma indConnect, en

la cual se muestra el estado de las variables de la velocidad de bombeo en un sistema de bombas
de una planta.

 28

Figura 2.13. Ejemplo de una aplicación web concerniente a los datos de una
Estación de Bombeo en la plataforma indConnect [6].

Los datos de campo (entradas digitales y analógicas) pueden ser cableados directamente al
modulo indConnect Link (PCB) (Ver Figura 2.14.), el cual tiene la capacidad de procesar estas
señales y enviarlas mediante protocolo ModBus a otros equipos en planta. Adicionalmente, el
PCB puede enviar estos datos a la "Nube", de acuerdo a los siguientes criterios que pueden ser
configurados:
• Porcentaje de variación: las señales analógicas solo se enviarán cuando su variación sea
superior a un porcentaje configurado por el usuario.
• Cambio de estado: las señales digitales solo se enviarán cuando se produzca un cambio de
estado en ellas.

Estos criterios garantizan que el consumo de datos de Internet sea el mínimo posible o
deseable haciendo al sistema más eficiente y confiable en cuanto al uso de recursos [7].

 29

Figura 2.14. Vista comercial del PCB (Módulo indConnect Link).

En la Figura 2.15 se muestra un esquema del enfoque del PCB desarrollado para propósito de
este informe (Módulo indConnect Link) en la industria. Como se puede observar, el PCB se
puede conectar al sensor y a un PLC por protocolo ModBus. Además, el PCB puede estar
conectado por USB a un computador para que así el usuario pueda interactuar con el mismo a
través de la Aplicación (App) de escritorio, también desarrollada y que se discutirá en el Capítulo
4 con más detalles.

Figura 2.15. Enfoque del PCB en la industria.

En la Figura 2.16, se puede observar la aplicación general en la industria del PCB

desarrollado. En esta figura se muestra un diagrama de bloques general con una cantidad “N” de

 30
módulos distribuidos por toda la planta. Cada módulo (representado como “nodo” en la Figura
2.16.) puede estar conectado directamente a varios sensores y además conectado por protocolo
ModBus con otros dispositivos como PLCs; creando de esta manera toda una red de datos
ModBus. Además, puede enviar los datos a la “Nube” por protocolo MQTT como se ha explicado
anteriormente.

Figura 2.16. Esquema general de la aplicación del PCB en la industria.

2.4.1 Sensores
Los sensores son las piezas de hardware que hacen el trabajo crítico de los procesos de
monitoreo, mediciones y recolección de datos. Un sensor convierte el parámetro físico (por
ejemplo: temperatura, presión, humedad, velocidad, etc.) en una señal que puede ser medida
eléctricamente.

Al elegir un sensor se deben considerar algunos criterios, como:

• Precisión
• Condiciones ambientales (existen límites de temperatura/humedad)
• Alcance (límite de medición del sensor)

 31
• Calibración (esencial en los dispositivos de medición, una vez que las lecturas cambien con el
tiempo)
• Poder de decisión (mayor incremento detectado por el sensor)
• Costo
• Repetición (la lectura que varia es repetidamente medida dentro del mismo ambiente)

Según el tipo de salida que se obtiene de los sensores, estos pueden ser:
• Analógicos: cuando entrega como señal de salida voltaje o corriente dentro de un determinado
rango, 0-5 V, 1-10 V, 4-20 mA.
• Digitales: cuando entrega una salida tipo discreta con una determinada cantidad de bits.

2.4.2 Red de Datos

Se conoce como red de datos a la infraestructura que posibilita la transmisión de información
a través del intercambio de datos. Para propósitos de este informe, se entenderá como red de
datos, a una red de datos ModBus donde se tiene un conjunto de dispositivos conectados entre sí
a través de este protocolo de comunicación industrial, tal como el que se muestra en la Figura
2.16.

2.5 Software SCADA

SCADA (Supervisory Control And Data Acquisition - Adquisición de Datos y Supervisión de
Control) es una aplicación software de control de producción que se comunica con los
dispositivos de campo (sensores y actuadores) y controla el proceso de forma automática desde la
pantalla del computador que es configurada por el usuario y puede ser modificada con facilidad.
Proporciona toda la información que se genera en el proceso productivo (supervisión, control de
calidad, control de producción, almacenamiento de datos, etc.) y permite su gestión e
intervención.

Entre los principales servicios que ofrece un Sistema SCADA tenemos:

• Posibilidad de crear paneles de alarma que permite al operador reconocer una parada o
situación de alarma, con registro de incidencias.
• Generación de históricos de señal de planta que pueden ser tabulados para su proceso en una
hoja de cálculo.

 32
• Ejecución de programas que modifiquen o anulen las tareas asociadas al autómata bajo ciertas
condiciones.
• Posibilidad de programación numérica para realizar cálculos aritméticos de elevada resolución
sobre la CPU del computador.

Los principales elementos en un Sistema SCADA son:

• Operador: Persona que monitorea de forma remota la operación de una planta y ejecuta
funciones de control supervisorio.
• Interfaz Hombre-Máquina (HMI): Software encargado de interactuar con el operador del
sistema dándole información y variables de control mediante gráficos, esquemas, pantallas y
menús.
• Unidad Terminal Maestra (MTU): Presenta los datos al operador a través del software HMI,
reúne información de las unidades remotas y trasmite las señales de control a los sitios
distantes. El flujo de datos entre la MTU y las unidades remotas es discontinuo, de baja
velocidad y alta latencia por lo cual los métodos de control son de lazo abierto.
• Medios de comunicación: Permite la comunicación entre la MTU y los dispositivos remotos.
• Unidad Terminal Remota (RTU): Envía señales de control a los actuadores y recibe señales de
los sensores. Recolecta la información de estos dispositivos y transmite los datos a la MTU.
La velocidad de transmisión entre la RTU y los sensores y actuadores es alta, esto posibilita la
implementación de métodos de control de lazo cerrado.
• Instrumentos de campo: Son dispositivos que permiten realizar la automatización o control del
sistema (PLCs, controladores de procesos industriales y actuadores en general), captan la
información de la planta (sensores y alarmas).

Cuando se decide implementar un sistema SCADA se deben considerar 5 fases básicas sobre
su instalación:
• Fase 1: El diseño de la arquitectura del sistema. Incluye el sistema de comunicaciones (Tipo
de bus de campo, distancias, número de E/S, Protocolo del sistema y Drivers).
• Fase 2: Equipamiento de los RTUs, comunicaciones, Equipos HMI y Hardware en general.
Adquisición de un software SCADA adecuado a la arquitectura y sistemas de la planta.
• Fase 3: La instalación del equipo de comunicación y el sistema PC (Personal computer –
Computador personal).

 33
• Fase 4: Programación de equipos de comunicaciones, HMI y software SCADA.
• Fase 5: Puesta a punto para corregir y solucionar problemas de programación, comunicación y
software.

Algunos de los software SCADA, o que incluyen SCADA como parte de ellos, son:
– Aimax, de Design Instruments S.A.
– CUBE, Orsi España S.A.
– FIX, de Intellution
– Lookout, National Instruments
– Monitor Pro, de Schneider Electric
– SCADA InTouch, de LOGITEK
– SYSMAC SCS, de Omron
– Scatt Graph 5000, de ABB
– WinCC, de Siemens

2.6. PLC
Según la NEMA (National Electrical Manufacturers Association - Asociación Nacional de
Fabricantes Eléctricos) un PLC (Programable Logic Controller - Controlador Lógico
Programable) es un dispositivo digital electrónico con una memoria programable para el
almacenamiento de instrucciones que permiten la implementación de funciones especificas
(lógicas, secuenciales, temporizadas, de conteo y aritméticas) con el objeto de controlar máquinas
y procesos.

La plataforma IndConnect tiene en el PLC un importante elemento para el manejo de la

información de los procesos que serán monitoreados, tal como se muestra en la Figura 2.12. Para
ello se vale de su versatilidad en el manejo de las entradas y salidas de información.

La estructura básica del PLC esta compuesta por:

• La CPU (Central Processing Unit – Unidad Central de Procesamiento)
• Las interfaces de entradas
• Las interfaces de salidas

 34
Los PLC están capacitados para almacenar y retirar información mediante dos tipos de
memoria, Memoria de Datos y Memoria de Usuarios, capaces de almacenar:
• Datos del Proceso:
o Señales de entradas y salidas
o Variables internas, de bit y de palabra
o Datos alfanuméricos y constantes
• Datos de Control:
o Instrucciones de usuario, programa
o Configuración del autómata

Los dispositivos de entrada son aquellos que intercambian (o envían) señales con el PLC.
Cada dispositivo de entrada sirve para conocer una condición particular de su entorno, como
temperatura, presión, posición, entre otras.

Entre los dispositivos de entrada podemos encontrar: sensores inductivos, magnéticos,

ópticos, pulsadores, termocuplas, termoresistencias, encoders, etc.

Las entradas se pueden clasificar en:

• Entradas Digitales: son las que pueden tomar sólo dos estados: encendido o apagado, estado
lógico 1 ó 0. Los módulos de entradas digitales trabajan con señales de voltaje por lo general
de 0 y 24 V. Un voltaje de 24 V se interpreta cómo “1” y una de 0 V se interpreta cómo “0”.
• Entradas Analógicas: son las que admiten como señal de entrada valores de corriente
intermedios dentro de un rango de 4-20 mA, convirtiéndola en un número que se guarda en
una posición de la memoria del PLC. Los módulos de entradas analógicas traducen una señal
de corriente que proviene de un sensor de temperatura, velocidad, aceleración, presión,
posición, o cualquier otra magnitud física medible, en un número que el PLC interpreta
mediante un conversor analógico digital.

Los dispositivos de salida son aquellos que responden a las señales que reciben del PLC,
cambiando o modificando su entorno. Entre los dispositivos de salida podemos mencionar:
• Contactores de motor
• Electroválvulas

 35
• Indicadores luminosos o simples relés

Los módulos de salida digital permiten al PLC actuar sobre elementos que admitan órdenes
de tipo encendido - apagado, todo o nada u “on - off”.

Las empresas que piensan en el futuro se encuentran provistas de modernos dispositivos

electrónicos en sus máquinas y procesos de control. En la actualidad, las fábricas automatizadas
deben proporcionar alta confiabilidad, gran eficiencia y flexibilidad lo que consiguen en un
dispositivo PLC.

2.7. Microcontroladores Atmel

Un microcontrolador (MCU) (Microcontroller Unit – Unidad Microcontroladora) es un
circuito integrado programable, capaz de ejecutar las órdenes grabadas en su memoria. Dispone
de una unidad central de procesamiento, memoria y periféricos de entrada/salida.

En el desarrollo del PCB de este trabajo, se utilizó un MCU Atmel debido a sus
características y su compatibilidad con la plataforma de desarrollo Arduino IDE, la cual facilita el
uso de la electrónica y programación de sistemas embebidos en proyectos multidisciplinarios.
Los MCU Atmel ofrecen una mezcla de diseños integrados eficientes e innovadores que son
ideales para los productos inteligentes de hoy en día. En esta era de Internet de las Cosas (IoT),
los MCU constituyen una tecnología clave que alimenta las comunicaciones de máquina a
máquina (M2M). En la Figura 2.17 se muestra un diagrama con la estructura genérica de un
MCU.

Figura 2.17. Estructura genérica de un MCU.

 36
Los MCU Atmel ofrecen arquitecturas optimizadas para baja potencia, conectividad de alta
velocidad, ancho de banda óptimo de datos y un gran soporte de interfaz. Ofrece una amplia
variedad de opciones de configuración, los desarrolladores pueden diseñar soluciones de sistema
completos para todo tipo de aplicaciones.

Las principales series de MCU Atmel, son las siguientes:

• MCU Atmel AVR de 8 y 32 bits.
Estos ofrecen una combinación única de rendimiento, eficiencia de potencia y flexibilidad de
diseño. Se basan en la arquitectura más eficiente en código para la programación de lenguaje
“C” y ensamblaje. Son la elección ideal para diseños que requieren grandes cantidades de
código, ofrecen memorias de programa y datos sustanciales con un rendimiento de hasta 20
MIPS (Millions of instructions per second – Millones de instrucciones por Segundo), con
mínimo consumo de energía.
• MCU Atmel ARM
Es un MCU de 32 bits que puede satisfacer las necesidades de prácticamente cualquier
dispositivo. Flexible y altamente integrado, esta diseñado para optimizar el control del
sistema, conectividad cableada e inalámbrica, gestión de la interfaz de usuario, baja potencia y
facilidad de uso. El microcontrolador SAMD21, utilizado en este proyecto, se encuentra
dentro de los microcontroladores basados en esta arquitectura.
• MCU Atmel 8051
Los MCU Atmel basados en el conjunto de instrucciones 8051 combina la tecnología probada
con las últimas características y funcionalidades. Los desarrolladores pueden elegir entre los
microcontroladores de 8 bits de un solo ciclo de bajo consumo, así como los dispositivos de
socket estándar de la industria (MSC 51), todos ellos con avanzadas tecnologías de memoria
Flash. Los MCU Atmel permiten una amplia gama de aplicaciones los cuales incluyen áreas
como Automatización de edificios, Electrodomésticos, Entretenimiento en el hogar,
Automatización industrial, Iluminación, Energía Inteligente, Electrónica Móvil, Periféricos
para PC y el Internet de las Cosas.

2.8. Programación de MCU con Arduino IDE

El Arduino Software IDE (Arduino Integrated Development Environment – Entorno de
Desarrollo Integrado Arduino) es un entorno de programación que ha sido empacado como un

 37
programa de aplicación; es decir, consiste en un editor de código, un compilador, un depurador y
un GUI (Graphical User Interface - Constructor De Interfaz Gráfica). Además incorpora las
herramientas para cargar el programa ya compilado en la memoria flash del hardware. Su
principal característica es su sencillez y facilidad de uso.

El código fuente del Arduino IDE está disponible en https://github.com/arduino/Arduino/.

Las instrucciones para construir el IDE desde el código fuente que implementa el lenguaje de
programación puede verse en: https://github.com/arduino/Arduino/wiki/Building-Arduino.

La dirección para descargar el Arduino IDE es: https://www.arduino.cc/en/Main/Software.

Además del IDE instalado en local, hay disponible un IDE on-line dentro del entorno Arduino
Create https://create.arduino.cc/. Esta es una plataforma on-line integrada que permite escribir
código, acceder a contenido, configurar tarjetas y compartir proyectos, muy enfocado al Internet
de las Cosas (IoT).

2.9. Aplicación (App) de escritorio en Windows

Las App de escritorio, en Windows por ejemplo, representan el medio mediante el cual se
facilita la comunicación Usuario-Sistema y Sistema-Usuario.

El desarrollo de App de escritorio es un término amplio que se refiere al proceso de escribir

un software que se ejecutará en equipos estándar, como los equipos de escritorio, portátiles o de
uso general. El software en desarrollo puede ser un software de sistema o un software de
aplicación. El software de aplicación está diseñado para realizar una tarea única o un conjunto
relacionado de tareas e incluye, entre otros, los juegos, los procesadores de texto y las
aplicaciones personalizadas para empresas.

En el caso de App de clientes en Windows se conjugan tres modelos principales: C++ para
programar directamente sobre las API de Windows (Windows application programming interface
– Interface de programación de aplicaciones de Windows), código administrado .NET con WPF
(Windows Presentation Foundation - Fundación de Presentación de Windows) y código
administrado .NET con Silverlight para el desarrollo rápido de App.

 38
Puede escribirse para cada uno de estos entornos de programación y otros más con Visual
Studio, el entorno de desarrollo integrado (IDE) de Microsoft.

2.9.1. Visual Studio IDE

Es un entorno de desarrollo integrado (IDE), para sistemas operativos Windows que soporta
múltiples lenguajes de programación, como: C++, C#, C, JavaScript, F# y Visual Basic .NET,
así como entornos de desarrollo web, como ASP.NET, etc.

Visual Studio permite crear sitios y aplicaciones web, así como servicios web en cualquier
entorno que soporte la plataforma .NET. Así, se pueden crear aplicaciones que se comuniquen
entre estaciones de trabajo, páginas web, dispositivos móviles, dispositivos embebidos y
consolas, entre otros. Estas herramientas están diseñadas para trabajar juntas de la forma más
eficiente posible y todas se exponen a través del entorno del IDE de Visual Studio.

Visual Studio funciona y se integra bien con App de terceros como Unity a través de la
extensión Visual Studio Tools para Unity, y Apache Cordova a través de Visual Studio Tools
para Apache Cordova. Incluso se puede extender Visual Studio creando herramientas
personalizadas que realizan tareas especializadas.

Visual Studio sirve para crear muchos tipos de aplicaciones, desde sencillas hasta grandes y
complejos sistemas para empresas y centros de datos. Se pueden crear:
1. Apps que se ejecutan no solo en Windows, sino también en Android y en iOS.
2. Sitios y servicios web basados en ASP.NET, JQuery, AngularJS y otros entornos populares.
3. App para dispositivos y plataformas diversos como Azure, Office, Sharepoint, Hololens,
Kinect e Internet de las cosas.
4. Juegos y App con gráficos avanzados para una variedad de dispositivos Windows.

2.9.2. Framework.NET
El Framework.NET es un entorno de desarrollo para construir, instalar y ejecutar servicios
Web, Aplicaciones de escritorio (App) de Windows y otras aplicaciones. Se compone de cuatro
elementos principales:
• CLR (Common Language Runtime – Entorno en Tiempo de Ejecución de Lenguaje Común)
que es la rutina universal

 39
• Una biblioteca de clases unificada llamada BCL (Base Class Library – Biblioteca de Clase
Unificada)
• ASP.NET con formularios Web, servicios Web XML
• Un subsistema de acceso a datos (ADO.NET)

La biblioteca de clases de .NET Framework proporciona acceso a la funcionalidad del

sistema para el desarrollo de App administradas. Es la base sobre la que se crean las App,
componentes y controles de .NET Framework. La .NET es una parte integral de muchas App que
se ejecutan en Windows y proporciona la funcionalidad común para que dichas App puedan
ejecutarse. Para los desarrolladores de App, .NET Framework facilita un modelo de
programación coherente y completo para crear aplicaciones que ofrezcan experiencias de usuario
visualmente interesantes y una comunicación segura y sin problemas.

CAPÍTULO 3

DISEÑO, DESARROLLO E IMPLEMENTACIÓN DEL PCB

En este capítulo, se discute sobre los componentes que conforman el diseño, así como el
desarrollo del esquemático de los circuitos y el ensamblaje e implementación del PCB. La
empresa LS Innovaciones C.A., preseleccionó componentes para el diseño, entre estos el
microcontrolador (MCU) utilizado. Además, por razones de confidencialidad, no se mostrará con
detalle el esquemático de los circuitos diseñados, ni la programación desarrollada para el
firmware del PCB (Printer Circuit Board – Tarjeta de Circuito Impreso).

3.1 El MCU Atmel SAMD21G18

El Atmel SAMD21 es una serie de MCUs de baja potencia que utilizan un procesador ARM
Cortex M0 + de 32 bits, con un rango de 32 a 64 pines con memoria Flash de hasta 256 KB y 32
KB de SRAM (Static Random Access Memory - Memoria Estática de Acceso Aleatorio).
Funcionan a una frecuencia máxima de 48 MHz. Están diseñados para la migración simple e
intuitiva con módulos periféricos idénticos, código hexadecimal compatible, mapa de direcciones
lineal idéntico y rutas de migración compatibles con pin entre todos los dispositivos de la serie
del producto.

En el proyecto realizado se utilizó el MCU Atmel SAMD21G18 de alto rendimiento que lo

hace ideal para una amplia gama de aplicaciones domóticas, de consumo, de medición e
industriales. Cuenta con 256 KB de memoria flash y 32 KB de SRAM, con una frecuencia de
funcionamiento de hasta 48 MHz, seis módulos de comunicación en serie configurables como
UART/USART, SPI o I ) C, tres temporizadores/contadores de 16 bits, reloj en tiempo real de 32
bits y calendario, 20 canales PWM, un ADC (Analog to Digital Converter – Convertidor

 41
Analógico a Digital) de 14 canales y 12 bits, uno DAC (Digital to Analog Converter –
Convertidor Digital a Analógico) de 10 bit. Fuente de alimentación de 1,62 V a 3,63 V.

Los dispositivos Atmel SAMD21 son compatibles con un conjunto completo de

herramientas de desarrollo de programas y sistemas, incluidos compiladores C, ensambladores de
macros, depuradores/simuladores de programas, programadores y kits de evaluación.

En la Figura 3.1 se muestra el Pin Out (Asignación de pines) del MCU Atmel SAMD21G18
utilizado en el proyecto.

Figura 3.1. Pin Out del microcontrolador Atmel SAMD21G18 [8].

3.2 Pruebas experimentales

Se procedió como primer paso a realizar ciertas pruebas experimentales. Una vez adquirido
el MCU SAMD21G18, seleccionado a priori por la empresa, se procedió a probar y diseñar los
módulos que conformarían el diseño completo del PCB. Como se tenía disposición de una tarjeta
Arduino Zero, la cual está basada en este MCU, se decidió en primera instancia probarla con el
Ethernet Shield Wiz550io (Módulo Ethernet para tarjetas Arduinos desarrollado por empresa

 42
Wiznet) que además se tenía a disposición. De igual forma, se procedieron a realizar pruebas
experimentales en un protoboard de los módulos de RTC (basado en el circuito integrado
PCF8523T), las memorias EEPROM (en este caso la prueba se hizo con el circuito integrado
24LC16B), el circuito para comunicación serial (basado para las pruebas en el integrado
MAX232) conectados a la tarjeta Arduino Zero. Esto se realizó con el fin de verificar el
funcionamiento de estos distintos módulos con un MCU basado en la arquitectura ARM, a
diferencia de la comúnmente usada AVR.

En el caso del circuito de acondicionamiento para las entradas digitales industriales, las
pruebas se realizaron en base al opto-acoplador H11A1 ya que se tenía a disposición para usos en
el protoboard. Sin embargo, para el caso de diseño se decidió usar el circuito integrado TLP293-4
por sus características muy particulares, además de permitir la conexión de hasta 4 entradas. En el
caso del circuito de acondicionamiento para las entradas analógicas, no se realizaron pruebas
experimentales previo al diseño del PCB ya que no se disponían de los componentes electrónicos
necesarios.

3.2.1 Modulo Ethernet (Circuito integrado WIZnet W5500)

El modulo Ethernet seleccionado para el proyecto es un circuito integrado WIZnet W5500,
que permite una conexión al Internet sencilla para sistemas integrados que utilizan SPI (Serial
Peripheral Interface - Interfaz de periféricos en serie) de alta velocidad. Los periféricos SPI del
WIZnet W5500 admiten una velocidad de 80 MHz, lo que permite implementar comunicaciones
de red de alta velocidad. Para reducir el consumo de energía del sistema, el controlador WIZnet
W5500 hace uso de WOL (Wake on LAN – Encender Remotamente un Computador) y un modo
de apagado.

Adicionalmente presenta características de interés para el proyecto, tales como:

• Admite 8 sockets independientes simultáneamente

• Memoria interna de 32 KB para el Buffer Tx/Rx

• Soporte de Negociación Automática (Full y Half duplex, 10 y 100-based)

• Operación de 3,3 V con tolerancia de señal E/S de 5 V

• Salidas LED (Full/Half duplex, Link, Speed, Active)

 43
En la Figura 3.2 se muestra el pin out (asignación de pines) y el Diagrama de Bloques del
WIZnet W5500.

Figura 3.2. Asignación de pines/Diagrama de bloques del WIZnet W5500 [9].

3.2.2 Circuito para Comunicación Serial (Transceptor EXAR SP330E)

La comunicación serial es una de las herramientas más importantes de las que dispone un
MCU. Mediante la misma puede dejar de ser un chip aislado, pues le permite abrirse al mundo,
socializar, interactuar con cualquier dispositivo que también soporte una comunicación serial:
tales como ordenadores, equipos controlados por MIDI, sensores con conexión serial, cámaras,
smartphones, tablets, servidores u otro MCU.

La comunicación serial es la que se utiliza en los protocolos RS-232, RS-422 y RS-485. En

el proyecto utilizamos un transceptor multiprotocolo avanzado compatible con RS-232, RS-485 y
RS-422 de la empresa EXAR Corporation, denominado SP330E.

El Transceptor SP330E posee una interfaz lógica de bajo voltaje variable de hasta 1,65 V.
Opera desde una sola fuente de alimentación, que puede ser de 3,3 V o 5 V, con baja corriente
inactiva. En RS-485/422 las entradas del receptor son de alta impedancia (> 96 kΩ), lo que
permite hasta 256 dispositivos en un solo bus de comunicación (1/8 de unidad de carga).

 44
Adicionalmente presenta las siguientes características que lo hacen ideal para este proyecto:
• Velocidades de datos de 20 Mbps para RS-485 y 1 Mbps para RS-232
• Operación de suministro único de + 3 V a + 5,5 V
• 2 Transmisores, 2 Receptores RS-232
• 1 Transmisor, 1 Receptor RS-485/422
− Configuración completa o half-duplex (semi-duplex)
− 1/8 unidad de carga, hasta 256 receptores en el bus
• VL Pin (Logic supply – Suministro de entradas lógicas) de la interfaz lógica de 1,65 V a 5,5 V
• Protección robusta de ESD (Electrostatic Discharge – Descarga Electroestática)
• Diseño pequeño con encapsulado 24-TSSOP (Thin Shrink Small Outline Package - Paquete de
contorno pequeño y contracción delgada)
• Pin de selección del protocolo a utilizar, es decir, RS-232, RS-485 o RS-422

En la Figura 3.3 se muestran los diagramas de bloques del Transceptor SP330E Modo RS-
485 Half-Duplex y Modo RS-232 utilizados en el proyecto.

Figura 3.3. Diagrama de bloques de los modos RS-232 y RS-485

Half-Duplex del Transceptor SP330E [10].

 45
3.2.3 Circuito de acondicionamiento para entradas Analógicas y Digitales Industriales
En algunos casos, la señal puede ser demasiado pequeña, y sería necesario amplificarla; o
podría contener interferencias que eliminar; ser no lineal y requerir su linealización; ser analógica
y requerir su digitalización; ser digital y convertirla en analógica, etc. Todas estas modificaciones
necesarias según corresponda en el dispositivo que se diseña o maneja, se le denomina con el
término acondicionamiento de señal. De tal modo que para acondicionar la señal, es decir,
hacerla adecuada al requerimiento técnico durante el desarrollo de un dispositivo electrónico, se
requiere de elementos capaces de hacer estos acondicionamientos.

En este proyecto hemos requerido acondicionar ciertas señales necesarias para la

operabilidad del dispositivo en desarrollo. Estas son señales analógicas y digitales industriales.
Una señal analógica industrial es una señal de corriente que se encuentra entre el rango de 4 a
20 mA, mientras que una señal digital industrial es una señal de voltaje entre el rango de 0 a
24 V. Ambas señales, necesitan ser convertidas a señales de voltaje en el rango de 0 a 3,3 V ya
que es el rango de voltaje en que el MCU SAMD21 opera. Para ello, se hizo uso de dos
componentes; el Amplificador Operacional MCP6004 para las señales analógicas y el Opto-
acoplador TLP293-4 para las señales digitales.

3.2.3.1 El Amplificador Operacional MCP6004

El Amplificador Operacional MCP6004, esta diseñado para aplicaciones de uso general.
Posee un ancho de banda de ganancia 1 MHz y un margen de fase de 90° (típico). También
mantiene un margen de fase de 45° (típico) con 500 pF de carga capacitiva. Opera con un solo
voltaje de suministro tan bajo como 1,8 V hasta 5,5 V, mientras consume en reposo 100 µA
(típico). Además, el MCP6004 admite oscilaciones de entradas y salidas rail to rail (riel a riel),
con un rango de entrada de voltaje en modo común de: VDD + 300 mV a VSS – 300 mV.

Esta última característica fue determinante al momento de seleccionar este amplificador

operacional debido a que el voltaje de salida no estaría limitado a gran escala, obteniendo un
máximo 3 V en lugar de 3,3 V, lo cual para la aplicación deseada es aceptable. En la Figura 3.4
se muestra una aplicación típica del Amplificador Operacional MCP6004. Sin embargo, para el
proyecto se usó en modo seguidor de voltaje, donde el voltaje de salida es igual al voltaje de

 46
entrada, esto debido a que la impedancia de entrada de los amplificadores es muy alta y en
consecuencia en esta modalidad, para un caso ideal: 1234 = 167 .

Figura 3.4. Aplicación del Amplificador Operacional MCP6004 como No-Inversor [11].

3.2.3.2 El Optoacoplador TLP293-4

El TLP293-4 es un opto-acoplador de bajo ingreso y alto aislamiento que consiste de un
fototransistor ópticamente acoplado a diodos emisores de infrarrojos. El TLP293-4 garantiza un
alto voltaje de aislamiento (3750 Vrms) y un amplio rango de temperatura de funcionamiento
( 89 = −55 ℃ a 125 ℃ ), y por lo tanto es adecuado para aplicaciones como controladores
programables, conmutación de fuentes de alimentación y transmisiones de datos
simplex/multiplex.

En la Figura 3.5 se muestra la configuración de pin de un optoacoplador TLP293-4 utilizado

en el proyecto.

Figura 3.5. Pin Out del Optoacoplador TLP293-4 [12].

 47
3.2.4 Módulo RTC PCF8523
El circuito integrado PCF8523 es un RTC (Real Time Clock – Reloj en tiempo Real) CMOS
(Complementary metal oxide semiconductor - Semiconductor complementario de óxido metálico)
y un calendario optimizado para bajo consumo de potencia. Los datos se transfieren en serie a
través de un bus I ) C con una velocidad de datos máxima de 1000 kbps. Las funciones de alarma
y temporizador están disponibles con la posibilidad de generar una señal de despertador en un pin
de interrupción. Un registro de desplazamiento permite un ajuste fino del reloj. El RTC PCF8523
tiene un circuito de conmutación de batería de respaldo, que detecta fallas de energía y cambia
automáticamente su voltaje de alimentación por el voltaje que suministra la batería cuando se
produce un corte de energía.

Otras características importante de este dispositivo, son las siguientes:

• Proporciona año, mes, día, día de la semana, horas, minutos y segundos en función de un
cristal de cuarzo de 32768 kHz
• Voltaje de funcionamiento del reloj: 1,0 V a 5,5 V
• Temporizador programable y alarma con capacidad de interrupción

En la Figura 3.6 se muestra el diagrama de bloques del integrado PCF8523.

Figura 3.6. Diagrama de bloque del integrado PCF8523 [13]

 48
3.2.5 Memoria EEPROM 24AA025E48
La EEPROM 24AA025E48, es una memoria PROM eléctricamente borrable de 2 Kbit. El
dispositivo está organizado como dos bloques de memoria de 128 x 8 bits con una interfaz serial
de 2 cables. Tiene una capacidad de escritura de página de 16 bytes. Además, se puede alimentar
con un voltaje entre 1,7 V y 5 V. Otras características adicionales y relevantes de este
componente para la aplicación, son:
• Tecnología CMOS de baja potencia
• Interfaz serial de 2 hilos, compatible con I ) C
• Compatibilidad de reloj de 100 kHz y 400 kHz
• Tiempo de escritura de página 3 ms, típico
• Ciclo de borrado/escritura auto-programado
• Buffer de escritura de página de 16 bytes
• Protección de ESD > 4000 V
• Más de 1 millón de ciclos de borrado/escritura
• Posee pin para protección de escritura por hardware
• Programación de fábrica disponible
• Rangos de temperatura industrial: - 40 °C a + 85 °C

En la Figura 3.7 se muestra el diagrama de bloques de una memoria EEPROM

24AA025E48.

Figura 3.7 Diagrama de bloques de la memoria EEPROM 24AA025E48 [14].

 49
3.2.6 Memoria EEPROM 24AA64
La EEPROM 24AA64, es una memoria PROM eléctricamente borrable de 64 Kbit. El
dispositivo está organizado como ocho bloques de memoria de 1 K x 8 bits con una interfaz en
serie de 2 cables. El diseño de bajo voltaje permite un funcionamiento con voltajes de 1,8 V
a 5 V. Ha sido desarrollada para aplicaciones avanzadas de baja potencia, como comunicaciones
personales o adquisición de datos. La memoria EEPROM 24AA64 además tiene una capacidad
de escritura de página de hasta 32 bytes de datos y está disponible en los encapsulados PDIP
(Plastic Dual In-Line Package – Encapsulado Doble en Línea de Plástico) estándar de 8 pines,
SOIC (Small Outline Integrated Circuit – Circuito Integrado de Esquema Pequeño) de montaje
superficial, TSSOP (Thin Shrink Small Outline Package – Encapsulado de Contorno Pequeño y
Delgado) y MSOP (Mini Small Outline Plastic – Mini Pequeño Esquema de Plástico) lo cual la
hace ideal para este proyecto.

Otras características relevantes de este dispositivo, son las siguientes:

• Tecnología CMOS de baja potencia
• Bus de interfaz en serie de 2 cables, compatible con I ) C
• Conectable en cascada hasta para ocho dispositivos
• Compatibilidad de 100 kHz
• Buffer de escritura de página de hasta 32 bytes
• Tiempo de ciclo de escritura típico de 2 ms para escritura de página
• Protección de ESD > 4000 V
• 1 millón de ciclos de borrado/escritura
• Posee pin para protección de escritura por hardware
• Retención de data > 200 años
• Rangos de temperaturas disponibles
− Industrial: - 40 °C to + 85 °C
− Automotor: - 40 °C to + 125 °C

En la Figura 3.8 se muestra el diagrama de bloque de la memoria EEPROM 24AA64

utilizada en el proyecto.

 50

Figura 3.8. Diagrama de bloque de la memoria EEPROM 24AA64 [15].

3.3 Diseño del PCB en Eagle CAD

El diseño de PCB se realizo con el software EAGLE CAD. El diseño es un proceso de dos
pasos donde primero se trabaja el esquemático de los circuitos electrónicos, y luego se diseña el
PCB conformada por los componentes electrónicos utilizados en el esquemático. Un esquema
bien diseñado es fundamental para el proceso general de diseño de un PCB, pues ayuda a detectar
errores antes de que se fabrique la tarjeta, e incluso después de la fabricación en caso de que algo
no funcione.

3.3.1 Selección del encapsulado

Antes de realizar el Layout (diseño) del PCB, se hizo la selección del encapsulado que
alojaría y por lo tanto protegería al mismo. Conjuntamente con la empresa LS Innovaciones C.A.,
se seleccionó el encapsulado MEMAX 22,5 2-2 KMGY-2713625, fabricado por la empresa
Phoenix Contact. Este es un encapsulado completo con orificios de ventilación, conectores de 5
posiciones y posee un conector para montaje sobre riel tipo DIN.

Sus especificaciones técnicas principales son las siguientes:

1. Material del encapsulado: Poliamida
2. Temperatura de Operación: - 40 °C a + 105 °C
3. Longitud: 99 mm

 51
4. Altura: 114,5 mm
5. Ancho: 22,5 mm

Así, el diseño del PCB se realizó siguiendo estas características dimensionales. En la Figura
3.9 se muestran dos vistas tridimensionales del encapsulado utilizado en este proyecto.

Figura 3.9. Vistas tridimensionales del encapsulado Phoenix Contact

MEMAX 22,5 2-2 KMGY-2713625 utilizada en el proyecto [16].

3.3.2 Diagrama electrónico del PCB

El diagrama electrónico corresponde al esquemático de los circuitos del PCB. Este
esquemático incluye todos los módulos implementados, así como también el circuito de la fuente
de alimentación, el circuito de acondicionamiento del MCU (conformados por capacitores,
cristales y resistencias), entre otros. Como se mencionó al principio de este capítulo, por motivos
de confidencialidad exigidos por la empresa LS Innovaciones C.A. no se mostrará con detalle el
esquemático. Sin embargo, como muestra, en la Figura 3.10 se puede observar una hoja del
esquemático desarrollado. En este caso, el correspondiente a los circuitos para el MCU y la
fuente de alimentación.

 52

Figura 3.10. Muestra de una hoja del esquemático desarrollado en este proyecto.

3.3.3 Layout del PCB

Un Layout de un PCB corresponde a su diseño, incluyendo las pistas de cobre, la
distribución de los componentes, la ubicación ideal de cada circuito integrado, entre otros.
Además, al realizar el diseño se deben considerar ciertos casos especiales, como por ejemplo,
aislar las pistas de cobre de GND (tierra) de circuitos como el del módulo de ethernet para evitar
de esta manera interferencia de ruido proveniente de tierra. Otro ejemplo importante lo representa
el circuito de la fuente de alimentación. En este proyecto, el circuito de la fuente de alimentación
está basado en un circuito integrado. Este circuito integrado generará cierta cantidad de calor. Por
lo tanto, al ubicar el circuito de alimentación se debe considerar, adicionalmente diseñar un
disipador de calor, por ejemplo, usando un área de cobre dentro del PCB. En consecuencia, estos
ejemplos representan algunos casos que se deben evaluar al diseñar, los cuales evitarían errores
de funcionamiento posteriores.

 53
Como se mencionó anteriormente, el Layout (diseño) del PCB se realizó siguiendo las
características dimensionales del encapsulado previamente seleccionado. En la Figura 3.11 se
muestra el diseño realizado en EAGLE CAD.

Figura 3.11. Layout (diseño) del PCB desarrollado en este proyecto.

3.4 Ensamblaje del PCB

Una vez diseñado el PCB, se procedió a fabricarlo con la empresa Seeed Studios, ubicada en
China. Esta empresa, en su página web (https://www.seeedstudio.com/fusion_pcb.html), exige el
cumplimiento de ciertas exigencias mínimas de diseño, las cuales debieron acatarse durante este
proceso y antes de proceder a fabricar el PCB. Entre estos lineamientos, tenemos:
• Ancho de pista o camino de cobre: mínimo 0,152 mm
• Tamaño de las perforaciones metalizadas: mínimo 0,3 mm de diámetro
• Espacio entre pads (superficie de cobre): mínimo 0,4 mm

 54
Posterior a la fabricación del PCB y recepción del mismo, se procedió a realizar la soldadura
de los componentes que conforman el diseño y previamente adquiridos.

El proceso de soldadura de componentes se realizó manual y cuidadosamente mediante el

uso de cautín y en algunos casos, se utilizó la pistola de calor con una temperatura alrededor de
los 250 °C.

En las Figuras 3.12, 3.13 y 3.14 se muestran tres vistas del PCB con los componentes y
conectores soldados.

Figura 3.12. Vista de la capa superior del PCB.

 55

Figura 3.13. Vista de la capa inferior del PCB.

Figura 3.14. Vista del PCB dentro del encapsulado seleccionado.

 56
3.5 Firmware del PCB
El firmware es un bloque de instrucciones de programa (software programado) para
propósitos específicos, grabado en una memoria de tipo no volátil (por ejemplo, ROM,
EEPROM), y que contiene la información, configuración y el sistema básico para controlar los
circuitos electrónicos de un dispositivo. Estas instrucciones fijan la lógica primaria que ejerce el
control de los circuitos de alguna clase de artefacto. En concreto podemos establecer que el
firmware de cualquier dispositivo tecnológico cumple básicamente tres funciones:
1. Otorgar al sistema las rutinas fundamentales de funcionamiento y respuesta con respecto a las
peticiones usuales que recibe y debe satisfacer al usuario.
2. Establecer una sencilla y cómoda interfaz para que, de esta manera, se pueda acometer rápida
y fácilmente la configuración del sistema mediante el uso de una serie determinada de
parámetros.
3. Controlar y gestionar tanto lo que es el arranque del sistema del dispositivo como la
correspondiente iniciación.

El firmware del PCB diseñado y construido en este proyecto consistió de la programación

realizada en lenguaje C en Arduino IDE, el cual define su funcionamiento. Este se diseñó y
desarrolló bajo la siguientes premisas:
• El PCB debe tener la capacidad de procesar las señales analógicas y digitales de los sensores
que se le conecten, y enviar esta data mediante protocolo ModBus.
• El PCB debe enviar datos usando protocolo MQTT (a la "Nube") de acuerdo a los siguientes
criterios:
o Porcentaje de variación: las señales analógicas solo se enviarán cuando su variación sea
superior a un porcentaje configurado por el usuario.
o Cambio de estado: las señales digitales solo se enviarán cuando haya un cambio de estado
en ellas.

En la Figura 3.14 se muestra el diagrama de flujo bajo el cual se diseño el firmware del PCB
construido, el cual cumple con las premisas propuestas anteriormente. Por razones de
confidencialidad, mencionada a comienzo de este capítulo, los códigos del firmware no podrán
mostrarse.

 57

Figura 3.15. Diagrama de flujo del firmware del PCB diseñado.

CAPÍTULO 4

DESARROLLO E IMPLEMENTACIÓN DE LA APLICACIÓN DE ESCRITOTIO

En este capítulo, se discute el desarrollo de la Aplicación (App) de escritorio para Windows,

haciendo uso de Visual Studio IDE. Al igual que en el Capítulo 3, por razones de
confidencialidad, no se mostrará con detalle la programación que conforma el desarrollo y puesta
en marcha de la App.

4.1 Descripción del Funcionamiento de la App de escritorio

La App de escritorio se diseñó y desarrolló con la finalidad de poder interactuar con el PCB
y además poder configurarlo. Para ello, la idea principal se basa en editar los diferentes comando
del maestro ModBus, configurar las respectivas entradas y demás parámetros a fin de crear un
archivo de texto .cfg (extensión para archivos de configuración). Este archivo de texto
básicamente es descargado, desde la App de escritorio, en el PCB vía puerto serial a través del
conector USB. Además, con la App de escritorio el usuario puede tener acceso a una ventana de
diagnóstico donde puede observar la memoria interna del PCB, los errores de los comandos
ModBus (si existen), el número de publicaciones exitosas y fallidas en el broker message
(servidor de mensajería) del MQTT, entre otros. Por lo tanto, como se puede observar, la App de
escritorio denominada comercialmente por la empresa LS Innovaciones C.A. como indConnect
Manager, es una herramienta útil y representa el vínculo directo PCB-USUARIO.

En la Figura 4.1 se muestra un diagrama general del funcionamiento de la App de escritorio.

Como se puede observar, primero se inicializa la aplicación, esto vendría siendo el momento al
abrir o ejecutar la misma. Una vez dentro de la App, el siguiente paso es crear un proyecto o abrir
uno existente (si es el caso). Posteriormente, se procede a seleccionar el tipo de módulo, el
número de entradas, se introduce el nombre deseado por el usuario y posteriormente se puede

 59
agregar y editar los comandos del maestro ModBus, así como también los parámetros del cliente
MQTT o del servidor ModBus (si es el caso). Por último, la etapa final consiste en descargar el
archivo de configuración .cfg, que es creado por la App, vía USB al PCB. Si el usuario lo desea,
puede volver a editar el proyecto actual o crear uno nuevo. Además, el usuario puede
diagnosticar, como se mencionó anteriormente, sobre el PCB o también puede actualizar el
firmware del mismo. En consecuencia, la App provee al usuario diferentes opciones de
interacción con el PCB. En la Figura 4.1 se muestra un diagrama general de la App de escritorio.

Figura 4.1. Diagrama general del funcionamiento de la aplicación de escritorio.

4.2 Programación de la App de escritorio

La programación de la App de escritorio se realizó haciendo uso de la plataforma de
desarrollo Visual Studio IDE, mediante el lenguaje VB.NET. Esta programación se desarrolló
con el objetivo de lograr el funcionamiento mencionado en el subcapítulo anterior. Para ello,
Visual Studio IDE proporciona varias herramientas para el manejo de botones, pestañas,
ventanas, barras de progreso, entre otros.

En las Figuras 4.2, 4.3 y 4.4 se muestran algunas ventanas de la App desarrollada para los
propósitos de este informe. La App cuenta con varias ventanas, cada una para el cumpliendo de
cierto propósito: comandos maestro ModBus, parámetros del cliente MQTT, parámetros del
bróker message (servidor de mensaje) MQTT, descarga de archivo, actualización de firmware,

 60
configuración de los parámetros de cada una de las entradas analógicas/digitales, entre otras. Por
motivos de solo muestra, sólo se proporcionarán algunas App.

Figura 4.2. Ventana de inicio de la aplicación de escritorio.

Figura 4.3. Ventana principal de la aplicación de escritorio (sin proyecto aún creado).

 61

Figura 4.4. Ejemplo de la ventana principal, en este caso, mostrando la

pestaña para configurar las entradas (pestaña “I/O”).

En la Figura 4.5 se muestra un ejemplo del inicio de un archivo de configuración .cfg. Cómo
se mencionó anteriormente, es el objetivo principal de la App de escritorio. Sin el archivo de
configuración, no se puede configurar el PCB de la manera deseada.

Figura 4.5. Ejemplo del comienzo de un archivo de configuración .cfg

creado por la aplicación de escritorio.

CAPÍTULO 5

RESULTADOS Y ANÁLISIS

En este capítulo, se discute y analizan los resultados obtenidos para cada una de las pruebas
realizadas con el fin de evaluar el funcionamiento del PCB desarrollado, el cual fue probado
experimentalmente de acuerdo al bloque funcional correspondiente, tal como se indica a
continuación.

5.1 Bootloader del microcontrolador (MCU)

Un bootloader (cargador de arranque) es un programa que se almacena en una zona de
memoria del MCU y por diseño se ejecuta al momento que se inicializa el MCU mediante un
reset o al alimentarlo. Al inicializarse el MCU, el vector de reset del bootloader se encarga de
redirigir la secuencia del programa al bootloader en la zona alta de la memoria. Una vez que el
cargador de arranque toma el control, verifica si se debe ingresar al “Modo Bootloader”. La orden
de ingresar a este modo es externa y generalmente es originada por el usuario a través de un
software o por medio de una combinación de teclas, lo cual depende del tipo de bootloader que se
está utilizando. Si se recibe la orden de ingresar al modo bootloader el programa entra en un
bucle que le permite recibir órdenes de lectura, escritura y eliminación de datos. Al finalizar el
proceso de lectura-escritura o si no se recibe la orden de ingresar a modo bootloader, se inicializa
el firmware de la aplicación (App) o programa principal, el cual toma el control del MCU hasta
que se vuelva a producir una inicialización del sistema [17].

Por ejemplo, en el caso de la tarjeta Arduino Zero utilizada para las pruebas experimentales
(ver el subcapítulo 3.2), el MCU SAMD21 posee el bootloader pre-instalado o pre-cargado en su
memoria y en consecuencia la tarjeta, una vez descargado algún programa desde el Arduino IDE,

 63
ejecuta las funciones correspondientes, definidas en ese programa principal. En este caso, el
Arduino IDE se encarga de enviar la orden al MCU de entrar al modo bootloader.

Esto significa que el bootloader forma parte esencial del desarrollo del PCB. En el caso de
este proyecto, el MCU SAMD21 no posee el bootloader pre-instalado de fábrica. Existen varias
maneras de cargar el bootloader al SAMD21. La primera se basa en utilizar un Atmel-ICE el cual
es un depurador y programador para MCU de la arquitectura ARM. La segunda forma se basa en
utilizar el depurador de la tarjeta Arduino Zero. Esta última fue la utilizada para el propósito de
este proyecto. Para poder utilizar el depurador de manera independiente, se procedió de desoldar
dos resistencias de 0 Ω que conectan al depurador con el MCU de la tarjeta (ver Figura 5.1).

Figura 5.1 Resistencias (R104 y R105) que deben ser removidas para utilizar el depurador
de la tarjeta Arduino Zero de manera independiente [18].

Una vez removidas las resistencias R104 y R015, se puede descargar el bootloader a través
de la plataforma Arduino IDE, conectando la tarjeta Arduino Zero con el PCB a través de la
interfaz JTAG (Joint Test Action Group – Grupo de Acción de Prueba Conjunta). Esta conexión
se realiza utilizando un conector de 2 x 5 posiciones. Una vez se realizan las conexiones entre
ambos, se alimenta la tarjeta de Arduino Zero con un cable USB y en la plataforma Arduino IDE
se procede a “quemar” el bootloader al MCU. Este procedimiento se utilizó durante el desarrollo
del proyecto, siendo exitoso al descargar el cargador de arranque en varios MCUs.

 64
Además, como se mencionó anteriormente, el MCU debe entrar en modo bootloader para
que el usuario pueda descargarle algún programa (Arduino IDE realiza esta tarea por el usuario).
En base a esta idea, se diseñó y programó la opción de actualización del firmware del PCB en la
aplicación de escritorio. El MCU SAMD21 puede entrar en modo bootloader de dos maneras:
presionando el botón de RESET dos veces seguidas o abriendo y cerrando su puerto serial con
una velocidad de 1200 Bd. Por lo tanto, la aplicación de escritorio envía la orden al MCU de
entrar en modo bootloader (utilizando el puerto serial) y posteriormente descarga el archivo .bin
(archivo binario del programa principal). Para este caso, también se hicieron varias pruebas
resultando todas exitosas, agregando esta opción de gran utilidad a la App de escritorio.

5.2 Módulo Ethernet

Para las pruebas del módulo de Ethernet se utilizó la librería de programación “Ethernet 2”
desarrollada por la empresa Adafruit [19]. En este caso, las pruebas fueron sencillas y básicas. En
primer lugar se verificó la asignación dinámica de direcciones IP por DHCP (Dynamic Host
Configuration Protocol – Protocolo de Configuración Dinámica de Host). Luego, se procedió a
probar la asignación estática de direcciones IP, y finalmente se verificó la asignación de
direcciones IP con diferentes direcciones MAC (Media Access Control – Control de Acceso al
Medio). Todas las pruebas resultaron exitosas.

5.3. Entradas Analógicas

Las entradas analógicas, como se ha mencionado, consisten en señales de corriente entre
4 mA y 20 mA. Para las pruebas, se hizo uso de un multímetro capaz de suministrar corriente y
por lo tanto simular un sensor o transmisor. Debemos resaltar que el multímetro posee dos
modalidades para este propósito: la modalidad “source” (fuente) y “simulate” (simulado). En la
modalidad “source”, el multímetro posee su propia fuente de alimentación, es decir, que equivale
a que el sensor posea una fuente de alimentación externa. En la modalidad “simulate”, el PCB
suministra la alimentación al multímetro (sensor o transmisor). Como se trata de una señal de
corriente, entonces se trata de un lazo de corriente, donde el lazo puede tener su retorno en GND
(tierra) o en 24 V, dependiendo de la modalidad. En la Figura 5.2 se muestra el PCB conectado a
un transmisor de 2 hilos, para este caso, simulado por el multímetro. Entonces, con lo antes
descrito, se tienen dos casos:
• Caso 1: Modalidad “source”, donde el transmisor posee su fuente de alimentación externa y
por ende el lazo de corriente tiene su retorno en GND.

 65
• Caso 2: Modalidad “simulate”, en este el PCB suministra los 24 V al transmisor y por lo tanto
el lazo de corriente tiene su retorno en 24V.

Figura 5.2. Conexión del PCB a un transmisor de 2 hilos (señal analógica).

Una vez definidas estas dos modalidades, se procedió a verificar con corrientes entre 4 mA y
20 mA, obteniéndose voltajes entre 600 mV y 3 V a la entrada del ADC implementado en el
PCB. El voltaje máximo de 3 V se debe a la característica del rail to rail (riel a riel) del
amplificador operacional utilizado, el cual es VDD – 300 mV. Por lo tanto, para una alimentación
de 3,3 V, como en este caso, el máximo voltaje en la salida es de 3 V. Así, para una corriente de
20 mA se obtiene un voltaje de 3 V en lugar de 3,3V (caso ideal). Adicionalmente, cabe resaltar
que en el circuito de acondicionamiento se implementó un termistor para corrientes máximas de
35 mA, como medida de protección contra corriente mayores. Sin embargo, para aplicaciones
industriales, los sensores o transmisores proporcionan señales de corriente de 4-20 mA.

5.4 Entradas Digitales

Las entradas digitales industriales consisten de señales de voltajes de 0 V (OFF) y 24 V
(ON). En la industria, estas señales generalmente provienen de un switch (suiche). Para las
pruebas, se disponía en la empresa de conexiones de 0 V y 24 V. Al conectarlas a las entradas del
PCB, se obtuvieron voltajes de 0 V y 3,3 V, respectivamente, en las salidas del opto-acoplador
TLP293-4, y por ende en las entradas digitales del MCU. De esta manera, 24 V es representado
por un “1” lógico y 0 V por un “0” lógico. En la Figura 5.3 se puede observar la manera de
conectar un suiche de 0-24 V al PCB.

 66

Figura 5.3. Conexión de un suiche (entrada digital industrial) al PCB.

5.5 Módulo RTC

Para las pruebas del módulo RTC PCF8523, se hizo uso de la librería de programación “RTC
Lib”, desarrollada por la empresa Adafruit [20]. Una vez verificada su compatibilidad con MCUs
de la arquitectura ARM, cómo en este caso, se procedió a realizar pruebas de funcionalidad,
como por ejemplo: asignación y actualización de fecha y hora. Además, se verificó la
funcionabilidad del circuito integrado RTC PCF8523 para el modo “back-up” (respaldo), es
decir, haciendo uso de una batería de respaldo de 3 V y desconectando la alimentación del PCB.
De esta manera, se observó que con una batería de respaldo, el RTC PCF8523 no desactualiza la
fecha y hora previamente ajustado en su memoria. Esta modalidad es útil ya que los mensajes
enviados por MQTT al broker poseen el “timestamp” (marca temporal) del momento en que
ocurrieron los cambios de las variables y en consecuencia es necesario que el RTC siempre
mantenga su ajuste.

Sin embargo, en caso de descargarse la batería, se puede reemplazar la misma de manera

sencilla y luego se actualiza el firmware del PCB para reajustar la fecha y hora del reloj.
5.6 Memorias EEPROM
Las pruebas de las memorias EEPROM implementadas en el PCB se realizaron haciendo
uso de la librería de programación “ExtEEPROM”, diseñada y desarrollada por Jack Christensen
[21]. Las pruebas se realizaron con el fin de evaluar la funcionalidad de escritura y lectura de

 67
ambas memorias EEPROM, y ambas resultaron exitosas. Además, como la memoria EEPROM
24AA025E48T posee una dirección MAC única integrada en su memoria, se procedió a leer la
data de las respectivas direcciones de la memoria donde se ubicaba esta dirección MAC; desde la
dirección 0x80 a la dirección 0xFF.

5.7 Módulo de Comunicación Serial

Para las pruebas del módulo de comunicación serial, se trabajó en los dos enfoques: el
protocolo RS-232 y el protocolo RS-485, debido a que ambos son de uso común en la industria.
Como se mencionó en el subcapítulo 3.2.2, el circuito integrado Transceptor EXAR SP330E
posee un pin de selección para ambos protocolos. El hardware se diseñó de manera que con un
“0” lógico el integrado funcionara en modo RS-232, y con un “1” lógico lo hiciera en modo RS-
485. De este manera, mediante el uso del programa RealTerm, para Windows, el cual es un
terminal serial, se probaron ambas modalidades resultando todas las pruebas de manera exitosa.
La Figura 5.4 muestra la interfaz del programa RealTerm utilizado.

Figura 5.4. Interfaz del programa RealTerm utilizado en este proyecto para
las pruebas de la comunicación serial.

5.8 Comunicación App – PCB

La comunicación App – PCB se realiza por medio de un cable micro USB. El usuario puede
realizar tres importantes tareas a través de esta comunicación: (1) Descargar un archivo de

 68
configuración, (2) Obtener información de diagnóstico concerniente al PCB, y (3) Realizar
actualización del firmware.

Como se explicó en el capítulo 4, la App de escritorio es una herramienta útil para proveer
interacción entre el PCB y el usuario. En este sentido, las pruebas realizadas estuvieron
orientadas a evaluar el rendimiento del PCB en conjunto con la App. En primer lugar, se procedió
a probar descargando varios archivos de configuración (.cfg), observando que el PCB respondiera
de manera correcta al leer cada una de las líneas de este archivo y que realizara la configuración
de los respectivos comandos. En este caso, se obtuvo un rendimiento exitoso y satisfactorio, al
lograr y corroborar el comportamiento deseado para la empresa LS Innovaciones C.A., en este
proyecto.

De igual modo, se evaluó el comportamiento de la ventana de diagnóstico de la App al

recibir información del PCB vía serial. Se observó que la frecuencia de actualización de los datos
reflejados en esta ventana es relativamente lenta, con un tiempo de actualización mínimo de
1,5 s. Sin embargo, debemos resaltar que esta frecuencia se debe a la comunicación serial, ya que
no permite tener una actualización en tiempo real, a diferencia de otros modos de transmisión de
datos, como por ejemplo TCP/IP, que si lo permite. Esta comparación se realizó evaluando el
rendimiento de ciertos equipos disponibles en la empresa, como por ejemplo, equipos Prosoft
Technology5, donde la transmisión de datos entre el equipo y la App de escritorio de Prosoft
Technology se lleva a cabo a través del protocolo TCP/IP, resultando en una velocidad de
transmisión relativamente mayor y por ende un tiempo de actualización de datos mayor.

Finalmente, como se mencionó en el subcapítulo 5.1, las pruebas de actualización de

firmware resultaron exitosas, al lograrse descargar varios archivos de programas y concretando
de esta manera otra herramienta útil de la App de escritorio.
5.9 Comunicación ModBus
Para las pruebas de comunicación ModBus, se utilizó como base la librería “MsgModBus”
orientada al protocolo ModBus Ethernet TCP/IP [22], y la librería “ModbusMaster” orientada al

5 ProsoftTechnology es una marca reconocida por ofrecer soluciones de conectividad para enlace de productos de
automatización. Se especializa en el desarrollo de soluciones de comunicación compatibles con los controladores
Allen Bradley y otros fabricantes.


 69
protocolo ModBus RTU desarrollada por Doc Walker [23]. Ambas librerías fueron editadas para
poder adaptarlas al MCU SAMD21, debido a que el mismo está basado en una arquitectura
ARM, a diferencia de los populares MCUs basados en arquitectura AVR.

Las pruebas se realizaron haciendo uso de simuladores maestros/cliente y esclavo/servidor

ModBus. Como simulador maestro/cliente se utilizó el programa para Windows ModScan y
como simulador esclavo/servidor se utilizó el también programa para Windows ModSim.
Básicamente, se realizaron programas en Arduino IDE con el objetivo de probar que todas las
funciones ModBus estuvieran implementadas. Para ambos modos de transmisión ModBus (RTU
y TCP/IP), se probó la funcionabilidad del PCB como maestro/cliente y como esclavo/servidor.
Se obtuvieron resultados satisfactorios, logrando una completa funcionabilidad ModBus del PCB,
incluyendo detección de errores en los comandos maestros. Cabe destacar que además de estos
simuladores, también se realizaron pruebas con equipos industriales, como por ejemplo el
módulo PLX31-EIP-MBS4 de la empresa Prosoft Technology, el cual tiene la opción de ser un
cliente y servidor ModBus TCP/IP simultáneamente, así como también, ser un maestro o esclavo
ModBus RTU. En este caso, las pruebas fueron igual de exitosas, logrando un desempeño
satisfactorio con equipos industriales. Las Figuras 5.5 y 5.6 muestran la interfaz de los
simuladores ModScan y ModSim utilizados.

Figura 5.5. Interfaz del simulador ModScan.

 70

Figura 5.6. Interfaz del simulador ModSim.

5.10 Comunicación MQTT

La comunicación con el servidor MQTT se realizó utilizando la librería de programación
“PubSubClient” desarrollada por Nick O’Leary [24]. Las pruebas se hicieron usando el servidor
público de la empresa LS Innovaciones C.A., HiveMQ [25] el cual posee los siguientes
parámetros:
• Broker: broker.hivemq.com
• Puerto: 1883

Los mensajes enviados por protocolo MQTT se realizaron en base al formato JSON
(JavaScript Object Notation – Notación de objeto JavaScript). Para observar la correcta
recepción del mensaje en formato JSON en el servidor de HiveMQ, se hizo uso de la App
MQTTLens, la cual se puede conectar al servidor MQTT, suscribir a tópicos y publicar mensajes
[26]. El mensaje enviado por MQTT posee tres parámetros:
(1) Número de identificación (Id) de la variable
(2) Valor
(3) Timestamp (marca temporal)

Estos parámetros están reducidos en caracteres para así ahorrar en consumo de bytes.
Dependiendo del número de variables que se está monitoreando, así como también el número de

 71
cambios en dichas variables, el mensaje JSON puede variar en longitud. La longitud máxima
establecida para propósitos de programación es de 1500 caracteres. En las pruebas realizadas, la
máxima longitud obtenida fue alrededor de 350 caracteres, equivalente a 11 cambios
aproximadamente.

Adicionalmente, la librería cuenta con la posibilidad de detectar fallas a la hora de publicar

un mensaje, lo cual es de gran utilidad para hacer diagnósticos con la App de escritorio respecto
al número de mensajes publicados exitosamente y el número de intentos fallidos. En la Figura 5.7
se muestran algunos ejemplos de mensajes JSON enviados por el PCB al servidor.

Figura 5.7. Mensajes JSON publicados en el servidor HiveMQ,

observados en la App MQTTLens.

5.11 Consumo de potencia del PCB

La fuente de alimentación del PCB se diseñó para regular voltajes entre 9-35 V a 3,3 V. De
este modo, mediante el uso de un multímetro se midió el consumo de corriente para un voltaje de
alimentación de 24 V, obteniéndose un consumo de potencia de aproximadamente 30 mA @
24V.

 72
5.12 Módulo de Radio Frecuencia (RF) para futuras aplicaciones
En el PCB, también se integró un módulo de RF. Esto, como una solicitud de la empresa LS
Innovaciones C.A. de explorar la posibilidad de contar con una aplicación en modo distribuido en
planta, es decir, con varios puntos de recolección de datos. En este tipo de aplicación un grupo de
varios PCB se encargan de tomar la información de dispositivos remotos, distribuidos en una
misma área geográfica y enviar la información obtenida hacia un único equipo en la red
(Gateway – Vía) que se encarga de transmitir esa información al Internet mediante el protocolo
MQTT. Cada PCB en modo nodo, posee las funcionalidades descritas en éste informe a
excepción del protocolo MQTT (solo característico del gateway o vía). El protocolo inalámbrico
utilizado es el Lo-Ra (Long Range – Largo Alcance), permitiendo enlaces de 2 a 20 Km (con una
antena direccional), dependiendo de las condiciones geográficas del lugar [27]. De éste modo,
para la prueba con el módulo de RF se utilizó la librería “RadioHead” desarrollada por la
empresa Airspayce [28]. Se procedió a verificar la comunicación entre dos PCB, uno actuando
como nodo y otro como gateway, obteniéndose resultados moderadamente satisfactorios, al tener
señales con un RSSI (Received Signal Strength Indicator – Indicador de Fuerza de la Señal
Recibida) entre -15 y -100. Mientras más cercano a -15, la potencia de la señal recibida es mayor
[29]. Se observó que a mayor distancia, el RSSI disminuía hasta valores alrededor de los – 49
(para las distancias de prueba), lo cual es entendible considerando que a mayor distancia entre los
dispositivos, menor será la potencia de la señal RF recibida. En la Figura 5.8 se muestra el
esquema de la aplicación del PCB en un modo distribuido.

Figura 5.8. Esquema de la aplicación del PCB en modo distribuido en la Industria.

 73
Finalmente, el alcance máximo probado fue de aproximadamente 1,5 Km, en lugares
cercanos a las oficinas de la empresa LS Innovaciones en Caracas. Durante las pruebas de
transmisión y recepción de los mensajes por RF, se presentaron varias fallas de recepción, lo cual
nos indica que se debe trabajar en diseñar y desarrollar un protocolo de comunicación capaz de
adaptarse a estas fallas. Una posible solución potencial es utilizar mensajes de “acknowledge”
(reconocimiento), similares a los utilizados en el protocolo TCP/IP, entre el gateway y los
diferentes nodos de la red.

 74

CONCLUSIONES Y RECOMENDACIONES

El PCB desarrollado cumple con los objetivos trazados en el plan de trabajo, en

consideración de las pruebas realizadas, creando así un puente entre los datos de planta e Internet,
permitiendo de forma segura la transmisión de información de las variables seleccionadas de
equipos en operación desde cualquier lugar del mundo. Con ésta información publicada en
Internet, se puede acceder a los datos a través de servicios web mediante el uso de una página
web personalizada. Estos datos también pueden ser accedidos de manera local a través de un PLC
en una ubicación remota, o un SCADA, mediante el protocolo ModBus.

Una de las características resaltantes del PCB y del proyecto en general, es haber logrado la
interacción PCB-USUARIO, a través de un cable USB y la interfaz desarrollada con la
Aplicación (App) de escritorio. Con esta interfaz, como se indica en los capítulos 4 y 5 del
informe, el usuario puede descargar un archivo de configuración .cfg al PCB, actualizar su
firmware y diagnosticar con base a los datos del mismo, por ejemplo: errores de los comandos
ModBus maestros (si existen), número de mensajes MQTT publicados de manera exitosa, entre
otros. Por ello, esta interacción PCB-USUARIO resulta ser una herramienta muy eficaz.
Adicionalmente, de acuerdo a los resultados señalados en el capítulo 5, el consumo de potencia
medido en el PCB fue de aproximadamente 30 mA @ 24 V, considerado por la empresa LS
Innovaciones C.A., como aceptable. Esto es una característica importante y elemental para un
dispositivo de este tipo.

Se demostró a su vez la versatilidad del firmware del PCB. Su programación en la

plataforma de desarrollo Arduino IDE, posibilita su constante modificación con el objetivo de
satisfacer los requerimientos del cliente. De igual modo, el diseño del hardware también es
versátil, puesto que es susceptible de cambios para su continua mejora y desarrollo.

En general, el desarrollo de ésta solución (PCB) como dispositivo aplicable al Internet de las
cosas (IoT) debe continuar con miras a fortalecer su firmware y hardware, y en consecuencia el

 75
enfoque, como por ejemplo, en un modo distribuido. Esto se mencionó en el subcapítulo 5.12, y
consiste básicamente en tener varios puntos de recolección de información y algunos puntos de
acceso al Internet, para ahorro en consumo de datos, comunicándose entre ellos (PCBs) vía radio
frecuencia (RF). Para lograrlo, se plantean algunas recomendaciones para futuros desarrollos que
a continuación se mencionan, esperando que su incorporación fortalezca el rendimiento de este
proyecto y facilite su comercialización, como objetivo final del mismo y meta de la empresa LS
Innovaciones C.A. Por lo tanto, recomendamos:
• Incorporar soporte en software para el protocolo OPC UA, considerando que es ampliamente
utilizado en la industria para aplicaciones de IoT, y posee además características de
encriptación y seguridad relevantes [30]. Adicionalmente, se debe incluir el soporte en la App
de escritorio.
• Implementar “Google Maps” (mapas de Google) en la App de escritorio, para que así el
usuario localice y ubique los diferentes dispositivos (PCBs) distribuidos en planta o en un área
geográfica específica.
• Mostrar en la App de escritorio la potencia de las señales entre cada conexión de RF, es decir,
la conexión Nodo – Gateway.
• Implementar un “Data logger” (Registro de datos) en la App de escritorio para facilitar la
solución de problemas de funcionamiento del PCB.
• Mejorar la capacidad del hardware para obtener un mejor rendimiento del PCB en el modo
distribuido con RF. Por ejemplo, se puede implementar un procesador Linux conjuntamente
con el MCU Atmel SAMD21 utilizado en este proyecto, a fin de incrementar las velocidades
de conexión y transmisión de datos, y evitar limitaciones de memoria RAM que posee el MCU
SAMD21 que es de 32 KB, considerando que un procesador Linux, para esta aplicación,
generalmente ofrece una memoria RAM superior, en el orden de los Megabytes (MB).
• Desarrollar una Aplicación (App) móvil para expandir el acceso de los datos publicados en
Internet por el PCB.

Finalmente, se puede desarrollar un PCB cuyo hardware y firmware sea más robusto, lo que
permitiría una mayor utilidad y representaría una solución IoT potencial para su comercialización
y certificación.

 76

REFERENCIAS

[1] J. Balcell y J. Romeral. Autómatas Programables. Barcelona: Marcombo, 2000.

[2] H. Tschofenig et al., “Architectural Considerations in Smart Object Networking”. Tech. No

RFC 7452. Internet Architecture Board. Marzo 1, 2015. [Online]. Disponible en:
http://www.rfc-editor.org/rfc/rfc7452.txt. [Consultado Sep. 12, 2017].

[3] Modbus, “Modbus Application Protocol V1.1b3”. Modbus org. Abril 26, 2012. [Online].
Disponible en: http://www.modbus.org/docs/Modbus-Application Protocol V1.1b3.pdf.
[Consultado Sep. 10, 2017].

[4] Modicon, “Modbus Protocol Reference Guide PI-MBUS-300 Rev. J.” Modbus org. Junio 1,
1996. [Online]. Disponible en: http://modbus.org/docs/PI-MBUS-300.pdf. [Consultado en
Sep. 21, 2017].

[5] A. Banks and R. Gupta, “MQTT Version 3.3.1.” OASIS Estándar. Committee Specification
Draft 02/Public Review Draft 02. April 2014. [Online]. Disponible en: http://docs.oasis-
open.org/mqtt/mqtt/v3.1.1/csprd02/mqtt-v3.1.1-csprd02.pdf. [Consultado Oct. 4, 2017].

[6] LSI-Group, “IndConnect Description”. Enero 15, 2017. Disponible en: http://www.lsi-
group.net/indconnect/description/.

[7] LSI-Group, “IndConnect Link”. Enero 15, 2017. Disponible en: http://www.lsi-
group.net/indconnect-link/.

[8] Atmel “SAM D21E/SAM D21G/SAM D21J SMART ARM Based Microcontroller”
datasheet. Sept. 2015 . [Consultado Oct. 2017].

[9] WIZnet, “W5500 Datasheet Version 1.0.6”, W5500 datasheet, Dic. 2014 [Consultado Oct.
2017].

[10] Exar Corporation, “RS-232/RS-485/RS422 TRANSCEIVER WITH 1.65V-5.5V

INTERFACE”, SP330E datasheet, Nov. 2013 [Consultado Oct. 2017].

[11] Microchip Technology Inc., “1 MHz Bandwidth Low Power Op Amp”, MCP6001/2/4
datasheet, 2003 [Consultado Oct. 2017].

[12] Toshiba, “Toshiba Photocoupler In GaAsIred & Photo-Transistor”, TLP293-4 datasheet,

Oct. 2015 [Consultado Oct. 2017].

 77
[13] NXP Semiconductor, “Real-Time Clock (RTC) and calendar”, PCF8523 datasheet, Jul.
2012, [Consultado Oct. 2017].

[14] Microchip Technology Inc., “24AA02E48/24AA025E48” datasheet, 2010 [Consultado Oct.

2017].

[15] Microchip Technology Inc., “24AA64/24LC64” datasheet, 2010 [Consultado Oct. 2017].

[16] PHOENIX CONTAC, “Electronic housing - ME MAX 22,5 2-2 KMGY – 2713625”. Oct.
2017 [Online]. Disponible: http://www.phoenixcontac/us/product/2713625. [Consultado
Oct. 29, 2017].

[17] R. Guadrón y J. Guevara, “Implementación de Bootloaders en Microcontroladores PIC16 y

PIC18 de Microchip Inc.” Escuela Especializada en Ingeniería ITCA-FEPADE. El
Salvador. Revista Tecnológica, Vol. 7, No 1, 2014. [Online]. Disponible:
http://www.redicces.org.sv/jspui/bitstream/10972/2545/1/CAP%2010.pdf. [Consultado
Nov. 9, 2017].

[18] Arduino LLC., “Zero_V1.0. Diagrama”. 2017. [Online]. Disponible:

http://www.arduino.cc/en/uploads/Main/ZeroV1.0.pdf. [Consultado Nov. 2, 2017].

[19] GitHub, “adafruit/Ethernet2: WIZ5500 based Ethernet Shield library”. Copyright (c) 2009-
2016 Arduino LLC. [Online]. Disponible:
https://github.com/adafruit/Ethernet2 [Consultado Nov. 2, 2017].

[20] GitHub, “adafruit/RTClib: A fork of Jeelab’s fantastic RTC library”. [Online]. Disponible:
https://github.com/adafruit/RTClib. [Consultado Nov. 3, 2017].

[21] Jack Christensen, “JChristensen/exEEPROM: Arduino library to support external I2C

EEPROMs”. GitHub Jul. 2014. [Online]. Disponible:
https://github.com/JChristensen/extEEPROM. [Consultado Nov. 3, 2017].

[22] ModBus library. “Modbus TCP library for the Arduino”. ModBud org. 2013. [Online].
Disponible:
http://myarduinoprojects.com/modbus.html [Consultado Nov. 4, 2017].

[23] Doc Walker, “4-20 mA/ModBus Master: Enlighten your Arduino to be a ModBus Master”.
GitHub Copyright: 2009-2016. [Online]. Disponible:
https://github.com/4-20ma/ModbusMaster [Consultado Nov. 4, 2017].

[24] Nick O'Leary, “knollenary/pubsubclient: A client library for the Arduino Ethernet Shield
that provide support for MQTT”. GitHub. MIT License 2015. [Online]. Disponible:
https://github.com/knolleary/pubsubclient [Consultado Nov. 3, 2017].

[25] HiveMQ Public Broker, “Introducing HiveMQ, the enterprise MQTT broker”. 2012.
[Online]. Disponible:
https://www.hivemq.com/try-out/. [Consultado Nov. 4, 2017].

 78
[26] GitHub, “sandro-k/MQTTLens Chrome App: MQTT Lens Chrome App, a MQTT utility
build on Web Components and Package for the Chrome Platform”. [Online]. Disponible:
https://chrome.google.com/webstore/detail/mqttlens/hemojaaeigabkbcookmlgmdigohjobjm.
[Consultado Nov. 5, 2017].

[27] Adafruit, “Overview, RFM69HCW and RFM9X LoRa Packet Radio Breakouts”. Nov.
2016. [Online]. Disponible:
https://learn.adafruit.com/adafruit-rfm69hcw-and-rfm96-rfm95-rfm98-lora-packet-padio-
breakouts/overview. [Consultado Nov. 10, 2017].

[28] Mike McCauley, “RadioHead Packet Radio library for embedded microprocessors”. Apr.
2014. [Online]. Disponible:
http://www.airspayce.com/mikem/arduino/RadioHead/index.html. [Consultado Nov. 4,
2017].

[29] Adafruit, “RFM9X Test, RFM69HCW and RFM9X LoRa Packet Radio Breakouts”. Apr.
2016. [Online]. Disponible:
https://learn.adafruit.com/adafruit-rfm69hcw-and-rfm96-rfm95-rfm98-lora-packet-padio-
breakouts/rfm9x-test. [Consultado Nov. 10, 2017].

[30] Jonathan Wilkins, “OPC UA and the Industrial Internet of Things”. Jun. 2017. [Online]
Disponible:
https://www.automation.com/automation-news/article/opc-ua-and-the-industrial-internet-
of-things. [Consultado en Nov. 10, 2017]

 79

APÉNDICES

Apéndice A
En este apéndice se muestran tres vistas adicionales del PCB desarrollado, definidas como
Apéndice A1, correspondiente a la vista de la capa superior, Apéndice A2, para la vista de la capa
inferior y el Apéndice A3, correspondiente a la vista de las perforaciones.

Apéndice B
En este apéndice se muestra la carátula y el índice del manual de usuario del PCB realizado.

Apéndice C
En este apéndice se muestra un folleto ilustrativo del Proyecto y sus aplicaciones en la
industria, como elemento orientado a la comercialización del producto.

 80

APÉNDICE A

A1. Vista de la capa superior del PCB.

 81

A2. Vista de la capa inferior del PCB.

 82

A3. Vista de las perforaciones respectivas del PCB.

 83

APÉNDICE B

 84

 85

 86

APÉNDICE C

 87

 88

 89