El presente informe describe el trabajo de pasantía para el diseño y desarrollo de una tarjeta de adquisición de datos para la interconexión de equipos industriales con la web a través del monitoreo de variables provenientes de sensores industriales y otros dispositivos mediante los protocolos de comunicación ModBus y MQTT. El Hardware está fundamentado en un microcontrolador Atmel SAMD21G, basado en arquitectura ARM, compatible con la plataforma de desarrollo Arduino IDE y IoT.

El proyecto incluye una Aplicación de escritorio, diseñada para ejecutarse desde cualquier computador, representando de este manera una interacción directa. La funcionabilidad del prototipo fue verificada al monitorear señales analógicas de 4-20 mA, señ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 verificó el consumo de potencia del dispositivo, obtenié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.

Excerpt

INDICE GENERAL

INDICE DE TABLAS

INDICE DE FIGURAS

LISTA DE SIMBOLOS

LISTA DE ABREVIATURAS

INTRODUCCION

Antecedentes

Justificacion e importancia del trabajo

Planteamiento del problema

Objetivo General

Objetivos Especificos

CAPITULO

DESCRIPCION DE LA EMPRESA LS INNOVACIONES C.A

Generalidades

Mision

Vision

Productos y soluciones

CAPITULO 2
FUNDAMENTOS TEORICOS
2.1 Internet de las cosas (IoT)
2.1.1 Descripcion General
2.1.2 Modelos de Comunicacion del IoT y sus Aplicaciones
2.1.3 Desafios y barreras para el IoT
2.2 Protocolo de Comunicacion Industrial ModBus
2.2.1 Las Transacciones en ModBus
2.2.2 Modos de Transmision en Serie
2.2.2.1 Modo de Transmision RTU
2.2.3 Modo de Transmision TCP/IP
2.2.4 El Ciclo Solicitud/Respuesta
2.2.4.1 Campo de Direccion
2.2.4.2 Campo de Codigos de Funcion
2.2.5 Funciones de Datos y Control ModBus

2.2.5.1 Codigos de Funcion de Acceso de Datos
2.2.5.2 Codigos de Funcion de Diagnostico
2.2.5.3 Otras Funciones
2.3 Protocolo de Comunicacion Web MQTT
2.4 Descripcion General del Sistema a Monitorear
2.4.1 Sensores
2.4.2 Red de Datos
2.5 Software SCADA
2.6 PLC
2.7 Microcontroladores Atmel
2.8 Programacion de MCU con Arduino IDE
2.9 Aplicacion (App) de escritorio en Windows
2.9.1 Visual Estudio IDE
2.9.2 Framework.NET

CAPITULO 3
DISENO, DESARROLLO E IMPLEMENTACION DEL PCB
3.1 El MCU Atmel SAMD21G
3.2 Pruebas experimentales
3.2.1 Modulo Ethernet (Circuito integrado WIZnet W5500)
3.2.2 Circuito para Comunicacion Serial (Transceptor EXAR SP330E)
3 2 3 Circuito de acondicionamiento para entradas Analogicas y Digitales
Industriales
3.2.3.1 El Amplificador Operacional MCP
3.2.3.2 El Optoacoplador TLP 293-
3.2.4 Modulo RTC PCF8523T
3.2.5 Memoria EEPROM 24AA025E48T
3.2.6 Memoria EEPROM 24AA
3.3 Diseno del PCB en Eagle CAD
3.3.1 Seleccion del encapsulado
3.3.2 Diagrama electronico del PCB
3.3.3 Layout del PCB
3.4 Ensamblaje del PCB
3.5 Firmware del PCB

CAPITULO 4
DESARROLLO E IMPLEMENTACION DE LA APLICACION DE ESCRITORIO
4.1 Descripcion del Funcionamiento de la App de escritorio

4.2 Programacion de la App de escritorio

CAPITULO 5
RESULTADOS Y ANALISIS
5.1 Bootloader del microcontrolador (MCU)
5.2 Modulo ETHERNET
5.3 Entradas Analogicas
5.4 Entradas Digitales
5.5 Modulo RTC
5.6 Memorias EEPROM
5.7 Modulo de Comunicacion Serial
5.8 Comunicacion App - PCB
5.9 Comunicacion ModBus
5.10 Comunicacion MQTT
5.11 Consumo de potencia del PCB
5.12 Modulo de Radio Frecuencia (RF) para futuras aplicaciones

CONCLUSIONES Y RECOMENDACIONES

REFERENCIAS

APENDICES

RESUMEN

El presente informe describe el trabajo de pasanda para el diseno y desarrollo de una tarjeta de adquisicion de datos para la interconexion de equipos industriales con la web a traves del monitoreo de variables provenientes de sensores industriales y otros dispositivos mediante los protocolos de comunicacion ModBus y MQTT. El Hardware esta fundamentado en un microcontrolador Atmel SAMD21G, basado en arquitectura ARM, compatible con la plataforma de desarrollo Arduino IDE y IoT. El proyecto incluye una Aplicacion de escritorio, disenada para ejecutarse desde cualquier computador, representando de este manera una interaccion directa. La funcionabilidad del prototipo fue verificada al monitorear senales analogicas de 4-20 mA, senales digitales de 0-24 V, datos obtenidos de esclavos ModBus en la misma red, los cuales fueron publicados posteriormente en la “Nube”. Finalmente, se verifico el consumo de potencia del dispositivo, obteniendose 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: Adquisicion de datos, PCB, Microcontrolador, ModBus, Sensores, Senales industriales, IoT, la Nube.

DEDICATORIA

A mis amados padres, Jose Jesus y Ana Elizabeth, por su invalorable amor y confianza durante todas las etapas de mi vida.

A mi hermana Keyla, a mi hermano Jose Jesus, 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 temia que no podia hacer”.

Henry Ford

ÍNDICE DE TABLAS

Tabla 2.1 Datos en un dispositivo de una red ModBus

Tabla 2.2 Referencia de los datos en los controladores ModBus

Tabla 2.3 Formato para cada Byte en el modo RTU

Tabla 2.4 Consulta del maestro con modo de transmision RTU

Tabla 2.5 Estructura de mensajes en ModBus TCP

Tabla 2.6 Definicion de Codigos de Funcion Publica disponibles en el Protocolo ModBus[4]

ÍNDICE DE FIGURAS

Figura 2.1 Diagrama del Modelo de Comunicacion Dispositivo - Dispositivo

Figura 2.2 Diagrama del Modelo de Comunicacion Dispositivo - Internet

Figura 2.3 Diagrama del Modelo de Comunicacion Dispositivo - Puerta de Enlace de Capa de Aplicacion ALG

Figura 2.4 Diagrama del Modelo de Intercambio de Datos a traves del Back End (Interfaz de programacion)

Figura 2.5 Marco General ModBus

Figura 2.6 Arquitectura de red ModBus

Figura 2.7 Trama en el modo de transmision RTU

Figura 2.8 Orden de bits en el modo de transmision RTU

Figura 2.9 Encabezado de una trama ModBus TCP/IP

Figura 2.10 El ciclo de Solicitud/Respuesta (Maestro - Esclavo)

Figura 2.11 Categorias Codigos de Funcion ModBus4

Figura 2.12 Plataforma indConnect6

Figura 2.13 Ejemplo de una aplicacion web concerniente a los datos de una Estacion de bombeo en la plataforma indConnect

Figura 2.14 Vista comercial del PCB (Modulo indConnect LINK)

Figura 2.15 Enfoque del PCB en la industria

Figura 2.16 Esquema general de la aplicacion del PCB en la industria

Figura 2.17 Estructura generica de un MCU

Figura 3.1 Pin Out del microcontrolador Atmel SAMD21G188

Figura 3.2 Asignacion de pines/Diagrama de bloques del WIZnet W55009

Figura 3.3 Diagrama de bloques de los modos RS-232 y RS-485 Half-Duplex del

Transceptor SP330E10

Figura 3.4 Aplicacion del Amplificador Operacional MCP6004 como No-Inversor [11]

Figura 3.5 Pin Out del Optoacoplador TLP293-412

Figura 3.6 Diagrama de bloque del Integrado PCF852313

Figura 3.7 Diagrama de bloques de la memoria EEPROM 24AA025E4814

Figura 3.8 Diagrama de bloque de la memoria EEPROM 24AA6415

Figura 3.9 Vistas tridimensionales del encapsulado Phoenix Contact MEMAX 22, 2-2 KMGY-2713625 utilizada en el proyecto

Figura 3.10 Muestra de una hoja del esquematico desarrollado en este proyecto

Figura 3.11 Layout (diseno) del PCB desarrollado en este proyecto

Figura 3.12 Vista de la capa superior del PCB

Figura 3.13 Vista de la capa inferior del PCB

Figura 3.14 Vista del PCB dentro del encapsulado seleccionado

Figura 3.15 Diagrama de flujo del firmware del PCB disenado

Figura 4.1 Diagrama general del funcionamiento de la aplicacion de escritorio

Figura 4.2 Ventana de inicio de la aplicacion de escritorio

Figura 4.3 Ventana principal de la aplicacion de escritorio (sin proyecto aun creado)

Figura 4.4 Ejemplo de la ventana principal, en este caso, mostrando la pestana para configurar las entradas (pestana “I/O”)

Figura 4.5 Ejemplo del comienzo de un archivo de configuracion .cfg creado por la aplicacion de escritorio

Figura 5.1 Resistencias [R104yR105] que deben ser removidas para utilizar el depurador de la tarjeta Arduino Zero de manera independiente

Figura 5.2 Conexion del PCB a un transmisor de 2 hilos (senal analogica]

Figura 5.3 Conexion de un suiche [entrada digital industrial) al PCB

Figura 5.4 Interfaz del programa RealTerm utilizado en este proyecto para las pruebas de la comunicacion serial

Figura 5.5 InterfazdelsimuladorModScan

Figura 5.6 InterfazdelsimuladorModSim

Figura 5.7 Mensajes JSON publicados en el servidor HiveMQ, observados en la App MQTTLens

Figura 5.8 Esquema de la aplicacion del PCB en modo distribuido en la Industria 72

LISTA DE SÍMBOLOS

Abbildung in dieser Leseprobe nicht enthalten

LISTA DE ABREVIATURAS

Abbildung in dieser Leseprobe nicht enthalten

INTRODUCTION

Antecedentes

Un sistema de adquisicion de datos es un conjunto de dispositivos, lineas e interfaces que realizan la conexion entre las senales provenientes de dispositivos de campo (ya sean transductores, interruptores, medidores y controladores que emiten senales electricas), y un computador para que este, mediante un software realice el procesamiento y almacenamiento de la informacion[1].

Las tarjetas de adquisicion de datos son dispositivos empleados ampliamente como herramientas para el monitoreo y control de los procesos industriales. Estas posibilitan la toma de senales provenientes de sensores que registran los cambios en las variables de interes, para posteriormente procesarlas o generar acciones de control.

Justificacion e importancia del trabajo

La existencia de sistemas de adquisicion de datos modernos, potentes y confiables ha permitido grandes avances en el campo de la instrumentacion de procesos industriales e incluso ha incentivado el desarrollo y crecimiento de la instrumentacion virtual de los ultimos anos sobremanera con el desarrollo reciente del Internet de las Cosas (IoT).

Se pretende ademas, fortalecer la generacion de ideas y propuestas desde las empresas y las universidades, capaces de competir en diseno, calidad y costos con productos existentes para los sectores productivos, considerando que aun existe la posibilidad de incursionar con nuevas tecnologias a pesar de la presencia de equipos de reconocidos fabricantes y de la competencia de toda indole.

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 adquisicion de datos para su comercializacion en un proyecto denominado IndConnect LINK, como solucion 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 ^Como llevar los datos de su planta a la Internet?

La realizacion de este proyecto titulado “Diseno y desarrollo de modulos electronicos para la interconexion de equipos industriales con la Web” busca desarrollar un dispositivo electronico (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 informacion de sus equipos desde cualquier lugar del mundo y de ese modo, con la informacion publicada en Internet, los datos pueden ser accedidos a traves de servicios web haciendo uso de una pagina web personalizada, o de manera local a traves de un PLC en una region remota o un SCADA directamente en la sala de control.

Objetivo General

Desarrollar una PCB con interconexion de modulos electronicos para la comunicacion con equipos industriales y plataformas Web.

Objetivos Especificos

1. Disenar circuito electronico de acondicionamiento de entradas analogicas y digitales con estandar industrial, asi como tambien de modulos accesorios: Memoria EEPROM, RTC, USB, Ethernet.
2. Disenar circuito electronico con capacidad para comunicacion industrial (ModBus TCP/IP y ModBus 232/485).
3. Integrar el protocolo de comunicacion industrial ModBus y el protocolo de comunicacion a traves de Internet (MQTT) en el PCB a disenar.
4. Disenar, programar e integrar el firmware para el funcionamiento del PCB.
5. Disenar e integrar una aplicacion de escritorio de Windows con el proposito de configurar el PCB.
6. Elaborar un manual de usuario del producto como un todo.

CAPITULO 1

DESCRIPCION DE LA EMPRESA LS INNOVACIONES C.A.

1.1. Generalidades

LS Innovaciones C.A., es un empresa fundada en el ano 2006 con sede principal en la ciudad de Caracas, dedicada al desarrollo y puesta en marcha de sistemas de Automatizacion y Seguridad, Instrumentacion y Construccion, con alto grado de confiabilidad, seguridad, eficiencia y conocimiento en la busqueda de nuevas y mejores soluciones.

En el ano 2009 recibe su primera certificacion de la empresa Rockwell Automation como proveedor de soluciones (Solution Provider), lo cual la afianza como lider en automatizacion y control. Posteriormente esta certificacion es ratificada en el ano 2012 como Socio Proveedor de Soluciones del Programa de Rockwell Automation (Solution Provider Partner Network Program). Entre los anos 2013 y 2017, de forma consecutiva la empresa Rockwell Automation la certifica como Reconocido Integrador de Sistemas para Informacion (Recognize System Integrator for Information). Adicionalmente ha recibido otras certificaciones como: Analista de vibracion para el area de monitoreo de condiciones (Vibration Institute) en 2013, Soporte Tecnico Region 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, Petroleo y Gas, Metal urgia y Metalmecanica, Electronica, Electrica, 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 Panama, Panama.
- PFsolve ubicada en Houston, Texas, USA.

1.2. Mision

Brindar soluciones a sus clientes en cuanto a aplicaciones de sistemas de automatizacion y seguridad, instrumentacion y construccion, con especial atencion a la seguridad y ambiente en el entorno social que nos rodea.

1.3. Vision

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 mas sostenible. Estos productos, atienden las necesidades desde la perspectiva de las plantas de produccion, buscando conectarlas, desde el sensor o dispositivo de medicion 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 Fiscalizacion
-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 Deteccion de Fuego y Gas
-Sistemas SCADA
-Sistemas de Control Distribuidos
-Sistemas de Monitoreo de Vibraciones
-Centro de Control de Motores
-Coordinacion de Protecciones
-Transferencia Automatica
-Sistemas de control de energia
-Data Center

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

-Servicios de consultoria, para apoyo y coordinacion de proyectos
-Evaluacion presencial para la elaboracion de soluciones para su empresa
-Servicio de soporte tecnico y asistencia personalizada
-Servicios integrados de asistencia y mantenimiento, tanto preventivo como correctivo
-Proyectos de Ingenieria, Procura y Construccion (IPC) en la industria energetica
-Proyectos de calculo y revision de Sistemas Instrumentados de Seguridad
-Proyectos en diseno, construccion e implementacion de soluciones con sistemas PLCs, SCADA Y DCS
- Diseno e instalacion de RTUs (Remote Terminal Unit - Unidad Terminal Remota)
-Instalacion de Sistemas de Seguridad, Sistemas de Deteccion de Fuego y Gas

CAPITULO 2

FUNDAMENTOS TEORICOS

2.1. Internet de las cosas (IoT)

El termino “Internet de las Cosas” (IoT) fue empleado por primera vez en 1999 por el pionero britanico Kevin Ashton para describir un sistema en el cual los objetos del mundo flsico se podlan conectar a Internet por medio de sensores. Hoy en dla, el termino se ha popularizado para describir escenarios en los que la conectividad a Internet y la capacidad de computo se extienden a una variedad de objetos, dispositivos, sensores y artlculos de uso diario.

2.1.1. Description General

Por lo general, el termino IoT se refiere a escenarios en los que la conectividad de red y la capacidad de computo se extienden a objetos, sensores y artlculos de uso diario que habitualmente no se consideran computadoras, permitiendo que estos dispositivos generen, intercambien y consuman datos con una minima intervention humana.

El concepto de combinar computadoras, sensores y redes para monitorear y controlar diferentes dispositivos ha existido durante decadas. Sin embargo, la reciente confluencia de diferentes tendencias del mercado tecnologico esta permitiendo que la Internet de las Cosas este cada vez mas cerca de ser una realidad generalizada. Estas tendencias incluyen la conectividad omnipresente, la adoption generalizada de redes basadas en el protocolo IP, la economla en la capacidad de computo, la miniaturization, los avances en el analisis de datos y el surgimiento de la computation en la nube.

En este trabajo de investigation, consideramos la definition de la IAB (Internet Architecture Board - Consejo de Arquitectura de Internet), establecido en “Architectural Considerations in Smart Object Networking - Consideraciones Arquitectonicas en Redes de Objetos Inteligentes’’[2], donde definen a la IoT como: “El termino que denota una tendencia en que un gran numero de dispositivos embebidos utilizan los servicios de comunicacion 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 vehiculos o estan distribuidos en el entorno”.

2.1.2. Modelos de Comunicacion del IoT y sus aplicaciones

Desde el punto de vista operativo, debemos conocer como se conectan y comunican los dispositivos de la IoT en terminos de sus modelos de comunicacion. En marzo de 2015, la IAB dio a conocer un documento para guiar la creacion de redes de objetos inteligentes, que describe un marco de cuatro modelos de comunicacion comunes que utilizan los dispositivos de la IoT [2]. Los cuatro modelos basicos de comunicacion muestran las estrategias de diseno subyacentes utilizadas para permitir que los dispositivos de la I/O (Imput Output - Entrada Salida) se comuniquen, y cuyas caracteristicas principales se explican a continuacion.

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.

Abbildung in dieser Leseprobe nicht enthalten

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

El modelo de comunicacion dispositivo a dispositivo encaja bien en aplicaciones de domotica o telemetrla, en las que los dispositivos intercambian pequenos paquetes de datos a baja velocidad y cada cierto tiempo. Los dispositivos para la IoT residenciales (bombillas de luz, interruptores, termostatos y cerraduras) normalmente envlan pequenas cantidades de informacion (por ejemplo, un mensaje del estado de bloqueo de una puerta o un comando para encender una bombilla de luz) en un escenario de automatizacion del hogar.

2) Modelo de Comunicacion Dispositivo - Internet

Es un modelo de comunicacion donde el dispositivo de la IoT se conecta directamente a un servicio en la nube¹, como por ejemplo un proveedor de servicios de aplicaciones para intercambiar datos y controlar el trafico de mensajes. Este enfoque suele aprovechar los mecanismos de comunicacion existentes (por ejemplo, conexiones WiFi o Ethernet cableadas) para establecer conexion 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 algun 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.

Abbildung in dieser Leseprobe nicht enthalten

Figura 2.2. Diagrama de Modelo de Comunicacion Dispositivo - Internet.

Para que esto sea posible, el dispositivo debe contener el hardware especffico que permita conectarse via Ethernet o WiFi y tener recursos suficientes para albergar una pila TCP/IP. Ejemplos de este tipo de comunicacion la vemos en electrodomesticos de alta gama, como una Smart Tv (Tv inteligente).

3) Modelo de Comunicacion Dispositivo - ALG (Application Level Gateway - Puerta de Enlace de Capa de Aplicacion)

Para este modelo el dispositivo de la IoT se conecta a traves del servicio ALG a fin de llegar a un servicio en la nube. Lo que significa que hay un software de Aplicacion (App) corriendo en un dispositivo de puerta de enlace local, que actua como intermediario entre el dispositivo y el servicio en la nube y que provee seguridad y otras funcionalidades tales como traduccion de protocolos o datos.

Este es el modelo de comunicacion mas utilizado en IoT, hay varios dispositivos que se utilizan hoy en dia como ALG. Uno de los mas populares y flexibles son los smartphones (telefono inteligente), capaces de conectar dispositivos IoT e Internet a traves de alguna App, aprovechando la conexion a Internet que traen de serie. Este modelo se muestra en la Figura 2.3.

Abbildung in dieser Leseprobe nicht enthalten

Figura 2.3. Diagrama del Modelo de Comunicacion Dispositivo - Puerta de Enlace Capa de Aplicacion ALG.

4) Modelo de Intercambio de Datos a traves del Back End (Interfaz de programacion)

Este modelo es la arquitectura de comunicacion 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, esta 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 representacion de este diseno.

Abbildung in dieser Leseprobe nicht enthalten

Figura 2.4. Diagrama del Modelo de Intercambio de Datos a traves del Back End (Interfaz de programacion).

2.1.3. Desafios y barreras para el IoT

A pesar de las bondades ofrecidas por el IoT, existen desafios y barreras que podrian retrasar su desarrollo, entre estos resaltan la implementacion de IPv6, la energia para alimentar los sensores y el acuerdo sobre normas, lo cual detallamos a continuacion:

- Implementacion 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 necesitaran direcciones IP exclusivas. Considerando que IPv6 facilita la administracion de las redes por sus capacidades de autoconfiguracion y caracteristicas de seguridad mejoradas, su implementacion es impostergable.
-Energia para los sensores: Para que IoT alcance su maximo potencial, los sensores deberan ser autosustentables. Pues no se podran cambiar las baterias 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 aun mas, especialmente en areas de seguridad, privacidad, arquitectura y comunicaciones. IEEE (Institute of Electrical and Electronics Engineers - Instituto de Ingenierla Electrica y Electronica) 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 traves de tipos de red diferentes.

2.2. Protocolo de Comunicacion 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 comunicacion entre dispositivos de automatizacion. Fue implementado como un protocolo al nivel de la aplicacion con la finalidad de transferir datos utilizando:

-TCP/IP sobre Ethernet
-Transmision en serie asincrona en diferentes medios (cables, fibra optica, 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 comun utilizado por todos los controladores Modicon. Este define una estructura de mensajes que los controladores reconoceran y utilizaran, independientemente del tipo de redes sobre las que se comuniquen. Describe el proceso que un controlador utiliza para solicitar acceso a otro dispositivo, como respondera a las solicitudes de los otros dispositivos y como se detectaran y notificaran los errores. Establece un formato comun para el diseno 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 comunicacion subyacentes. El mapeo del protocolo ModBus en buses o redes especificos puede introducir algunos campos adicionales en la ADU (Aplication Data Unit - Unidad de Datos de Aplicacion) tal como se indica en la Figura 2.5.

Abbildung in dieser Leseprobe nicht enthalten

Figura 2.5. Marco General ModBus.

Su especificacion abierta permite la comunicacion entre todos los tipos de arquitectura de red. Dispositivos, como: PLC (Programmable Logic Controller - Controlador Logico Programable), HMI (Human Machine Interface - Interfaz Hombre Maquina), Panel de control, Driver (Controlador), Control de movimiento, I/O (Input/Output- Entrada/Salida), pueden utilizar el protocolo ModBus para iniciar una operacion remota. La misma comunicacion se puede realizar tanto en linea serial como en redes. Las entradas permiten una comunicacion entre varios tipos de buses o red usando el protocolo ModBus. Tal como se muestra en la Figura 2.6.

Abbildung in dieser Leseprobe nicht enthalten

Figura 2.6. Arquitectura de red ModBus [3].

ModBus proporciona el estandar interno que utilizan los controladores Modicon para analizar mensajes. Durante las comunicaciones en una red ModBus, el protocolo determina como cada controlador conocera su direccion de dispositivo, reconocera un mensaje dirigido a ella, determinara el tipo de accion que se tomara y extraera cualquier dato u otra informacion contenida en el mensaje. Si se requiere una respuesta, el controlador construira el mensaje de respuesta y lo enviara usando el protocolo.

2.2.1. Las transacciones en ModBus

ModBus es un protocolo de mensajeria de capa de aplicacion, situado en el nivel 7 del modelo OSI (Open System Interconnection - Modelo de interconexion de sistemas abiertos), que proporciona comunicacion entre dispositivos conectados en diferentes tipos de buses o redes enmarcada en el concepto de bus de Campo de Control y como tal, su topologia 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 mas dispositivos programables que actuan como esclavos que pueden ser hasta 247 y que responden y proceden segun lo requerido por el maestro. Los esclavos se limitan a retornar los datos solicitados o a ejecutar la accion indicada por el maestro. La comunicacion del maestro hacia los esclavos puede ser de dos tipos:

- Peer to Peer (Punto a Punto): en la que se establece la comunicacion “maestro - esclavo”, el maestro solicita informacion y el esclavo responde.
- Broadcast (Difusion amplia): en la que se establece comunicacion “maestro - todos los esclavos”, el maestro envia un comando a todos los esclavos de la red sin esperar respuesta.

La comunicacion se da en forma serial asincrona bajo los estandares RS-232 o RS-485 para enlace half duplex (semi-duplex)² y RS-422 para enlace full duplex (duplex)³, utiliza diferentes medios fisicos como son los de soporte metalico (cables), radio frecuencia (RF), fibra optica o infra rojo cuya velocidad de transmision oscila entre los 75 y 19200 Baudios.

Estos mensajes son conocidos como tramas y estan constituidos por un conjunto de caracteres que tienen una longitud de las tramas variables, pero acotadas a un maximo de 256 caracteres. Estas tramas contienen los datos necesarios para reconocer el origen y objetivo decada mensaje puesto en el bus por alguno de los dispositivos y que luego le servira a un dispositivo receptor para hacer la validacion y la posterior toma de decisiones.

El protocolo ModBus maneja basicamente 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 analogo. En la Tabla 2.1 se presentan estos tipos de datos.

Tabla 2.1. Datos en un dispositivo de una red ModBus

Abbildung in dieser Leseprobe nicht enthalten

Estos datos pueden ser modificados solo si son salidas del controlador programable. La entradas no tiene la posibilidad de ser cambiadas por un software de aplicacion 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

Abbildung in dieser Leseprobe nicht enthalten

En su definicion inicial el protocolo ModBus era una especificacion de tramas, mensajes y funciones utilizada para la comunicacion entre los PLCs de la empresa Modicon. En la actualidad este protocolo ha sido acogido y actualizado convirtiendose de hecho en un estandar para la automatizacion de la industria gracias a su particular estructura de mensajes que opera con direcciones de memoria y no variables concretas, haciendolo aceptable a diferentes dispositivos. Tambien debido a su especificacion realmente abierta que permite comprender en toda su extension la forma en que se lleva a cabo la transaccion de mensajes y el flujo de informacion con lo cual ha sido posible la programacion de equipos que lo ejecuten y puedan formar parte de una red ModBus.

2.2.2. Modos de transmision en Serie

El protocolo ModBus posee dos modos de comunicacion serial conocidas como ASCII (American Standard Code for Information Interchange - Codigo Estandar Americano para Intercambio de Informacion) 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 transmision: ASCII o RTU. Los usuarios seleccionan el modo deseado, junto con los parametros de comunicacion del puerto serie (velocidad en baudios, modo de paridad, etc.) durante la configuracion de cada controlador. Los parametros de modo y serie deben ser los mismos para todos los dispositivos de una red ModBus. La seleccion del modo ASCII o RTU pertenece unicamente a las redes ModBus estandar. Define el contenido de bits de los campos de mensaje transmitidos en serie en dichas redes. Determina como la informacion sera empaquetada en los campos de mensaje y decodificada. El modo y los parametros 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 continuacion desarrollamos el modo de transmision RTU por ser el modo de transmision en serie utilizado en el proyecto.

2.2.2.I. Modo de transmision RTU

Cuando los controladores se configuran para comunicarse en una red ModBus mediante el modo de transmision 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 caracter lo cual se indica como T1-T2-T3-T4. Despues de este silencio el primer campo transmitido es la direccion del esclavo, cuya longitud es de ocho bits.

Abbildung in dieser Leseprobe nicht enthalten

Figura 2.7. Trama en el modo de transmision RTU.

De igual modo se cuenta con ocho bits para enviar el codigo de funcion, multiplos enteros de ocho bits para los datos si son necesarios y dieciseis para el CRC (Cyclic Redundancy Check - Chequeo Ciclico Redundante). La trama terminara con un silencio de al menos 3,5 veces el tiempo necesario para enviar un caracter.

Ademas del tiempo que limita el inicio y el fin de una trama, en el modo de transmision RTU se debe considerar, el tiempo que transcurre entre la llegada de caracteres consecutivos. Este tiempo se ha definido para que sea maximo de 1,5 veces el Tiempo necesario para enviar un caracter (Tc). Si entre el fin de un caracter y el comienzo de otro, transcurre un tiempo mayor que 1,5Tc y menor que 3,5Tc se producira una situacion de error en la transmision y el dispositivo receptor debe ignorar la trama. Cuando se produce este error los esclavos no enviaran ningun 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

Abbildung in dieser Leseprobe nicht enthalten

De esto se deduce que los caracteres para el modo de transmision RTU tiene una longitud de once bits. En la Figura 2.4 se muestra graficamente el orden en el que se envia cada caracter de la trama en el modo de transmision RTU.

Abbildung in dieser Leseprobe nicht enthalten

Figura 2.8. Orden de bits en el modo de transmision RTU.

Un ejemplo de peticion 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 envie tres registros a partir del registro 006B (107d).

Tabla 2.4. Consulta del maestro con modo de transmision RTU

Abbildung in dieser Leseprobe nicht enthalten

2.2.3. Modo de transmision TCP/IP

ModBus TCP/IP es el Protocolo de Control de Transmision y Protocolo de Internet, que proporciona el medio de transmision para la mensajeria ModBus TCP/IP, es simplemente el protocolo ModBus RTU con una interfaz TCP que funciona en Ethernet.

La funcion 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 combinacion TCP/IP es simplemente un protocolo de transporte, y no define que significa el dato o como se interpretaran los datos, lo cual es el objetivo del protocolo de aplicacion ModBus. ModBus TCP/IP utiliza TCP/IP y Ethernet para transportar los datos de la estructura de mensajes entre dispositivos compatibles, combina una red fisica (Ethernet), un estandar de red (TCP/IP) y un metodo estandar de representacion de datos ModBus como protocolo de aplicacion.

El mensaje ModBus TCP/IP es simplemente una comunicacion ModBus encapsulada en una envoltura Ethernet TCP/IP. Asi, ModBus TCP incorpora una trama de datos ModBus estandar en una trama TCP, sin la suma de comprobacion ModBus, como se muestra en la Figura 2.9.

Abbildung in dieser Leseprobe nicht enthalten

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
- Longitud: 2 bytes que identifican el numero de bytes en el mensaje a seguir.
- Identificador de unidad: 1 byte establecido por el Cliente y repetido por el Servidor para la identificacion de un esclavo remoto conectado en una llnea 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

Abbildung in dieser Leseprobe nicht enthalten

Por ejemplo, una solicitud equivalente a esta trama de RTU de ModBus, serla:

11 03 006B 0003 7687

Y su equivalente en ModBus TCP, serla:

1 0000 0006 11 03 006B 0003

Donde:

0001: Identificador de transaccion

0000: Identificador de protocolo

0006: Longitud del mensaje (6 bytes a seguir)

11: El identificador de la unidad (17 = 11 Hex.)

03: El codigo de funcion (leer los registros de retencion de salida analogica)

006B: Direccion de datos del primer registro solicitado (40108 - 40001 = 107 = 6B Hex.) 0003: El numero total de registros solicitados. (Leer 3 registros 40108 a 40110)

La ADU ModBus TCP/IP completa, esta incrustada en el campo de datos de una trama TCP estandar y enviada a traves de TCP al Puerto de Sistema 502⁴, reservado para aplicaciones ModBus, mediante el cual los clientes y servidores ModBus TCP/IP escuchan y reciben datos ModBus. La union del protocolo de aplicacion ModBus con la transmision Ethernet forma un poderoso estandar de comunicacion 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 transmision. 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 Direccion
(2) Campo Codigo de Funcion
(3) Campo de Datos
(4) Campo de Chequeo de Errores.

Abbildung in dieser Leseprobe nicht enthalten

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

2.2.4.1. Campo de direccion

ModBus es un protocolo multipunto, el maestro puede comunicarse a multiples esclavos utilizando la misma linea de comunicacion. Cada esclavo debe tener una identificacion unica 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 direccion 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 aparicion de un elemento de datos se trata como el numero de item cero. Por ejemplo:

- La bobina (Coil) conocida como “Bobina 7” en un controlador programable se dirige como bobina 0000 en el campo de direccion de datos de un mensaje ModBus.
- La bobina 127 decimal se dirige como la bobina 007E Hex. (126 decimal).
- El registro de retencion 40001 se dirige como el registro 0000 en el campo de direccion de datos del mensaje. El campo de codigo de funcion ya especifica una operacion “Holding Register” (Registros de Lectura/Escritura). Asi, la referencia “4XXXX” esta implicita.
- El registro de retencion 40108 se dirige como el registro 006B Hex. (107 decimal).

El campo de direccion es utilizado por los esclavos para colocar en el su propia direccion y permitirle al maestro identificar que esclavo a puesto en el bus un mensaje de respuesta.

2.2.4.2. Campo de codigos de funcion

Cada funcion permite transmitir ordenes a un esclavo. Existen dos tipos basicos 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, verificacion de contadores, etc.)

Hay tres categorias de codigos de funciones ModBus, estas son:

- Codigos de Funcion Publica
- Estan bien definidos
- Garantizados para ser unicos
- Validado por Modbus.org
- Documentados publicamente
- Disponen de pruebas de conformidad
- Incluye tanto los codigos de funcion publicos asignados definidos, como la funcion no asignada
- Codigos reservados para uso futuro
- Codigos de Funcion Definidos por el Usuario
- Existen dos rangos de codigos definidos por el usuario, de 65 a 72 y de 100 a 110 decimal
- El Usuario puede implementar un codigo de funcion no soportado por la especificacion
- No hay garantla de que el uso del codigo de funcion seleccionado sea unico
- Si el usuario desea volver a colocar la funcionalidad como un codigo de funcion publica, debe iniciar una RFC (Request For Comments - Solicitud de Comentario) para introducir el cambio en la categorla publica y tener un nuevo codigo de funcion publico asignado
- La organizacion ModBus se reserva expresamente el derecho de desarrollar el RFC propuesto
- Codigos de Funcion Reservados
- Codigos utilizados por algunas empresas para productos y no disponibles para uso publico

El Campo de Codigo de Funcion de una trama cuando se utiliza el modo de transmision RTU contiene ocho bits. Los codigos validos estan en el rango decimal de 1 ...255. Cuando el maestro envla un mensaje de peticion a un dispositivo esclavo, el campo de codigo de funcion le dice al esclavo que tipo de accion 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 diagnostico del esclavo, etc. En la Figura 2.11. se muestran las categorlas de codigos de funcion ModBus.

Abbildung in dieser Leseprobe nicht enthalten

Figura 2.11. Categorlas Codigos de Funcion ModBus[4].

Cuando el esclavo responde usa el campo de codigo de funcion en el mensaje de respuesta para indicar si es una respuesta normal o si ha ocurrido alguna excepcion.

Un mensaje del maestro al esclavo para leer un grupo de registros de salida tendria el siguiente codigo de funcion en el modo de transmision RTU: 0000 0011 (Hex. 03). Si el dispositivo esclavo puede ejecutar la accion solicitada, el codigo de funcion en el mensaje de respuesta es igual al enviado en la solicitud.

En caso contrario, si hay una excepcion, el contenido del campo del codigo de funcion sera: 1000 0011 (Hex. 83). Ademas, el esclavo coloca un codigo en el campo de datos del mensaje de respuesta, que le informa al maestro que tipo de error se produjo o la razon de la excepcion. En la Tabla 2.6. se muestra la definicion de los codigos de funcion publica disponibles en el protocolo ModBus.

Tabla 2.6. Definicion de Codigos de Funcion Publica disponibles Protocolo ModBus[4]

Abbildung in dieser Leseprobe nicht enthalten

2.2.5. Funciones de datos y control ModBus

A continuacion se indican los codigos segun corresponde:

2.2.5.1 Codigos de funcion de acceso de datos

- Leer Bobina (Read Coil) [01 0X01]
- Leer Entradas Discretas (Read Multiple Coils) [02 (0X02)]
- Leer Registros de Retencion (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 Unico (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)]
- Mascara Escribir Registro [22 (0X16)]
- Leer/Escribir Multiples Registros [23 (0X17)]
- Leer la Cola “Primero entra, Primero sale” FIFO (First in, First out) [24 (0X18)]

2.2.5.2 Codigos de funcion de diagnostico

- Estado de Excepcion de Lectura (Solo linea serial) [07 (0X07)]
- Diagnostico (Solo linea serial) [08 (0X08)]
- Los Codigos de Sub-funcion Soportados por los Dispositivos de Linea Serial
- 00 Datos de Consulta de Devolucion
- 01 Opcion de Reinicio de Comunicaciones
- 02 Registro de Diagnostico de Devoluciones
- 03 Cambio del Delimitador de Entrada ASCII
- 04 Forzar el Modo de Solo Escuchar
- 10 Contadores Claros y Registro de Diagnostico [0A Hex.]
- 11 Recuento de Mensajes de bus de Retorno [0B Hex.]
- 12 Error de Comunicacion de Bus de Retorno [0C Hex.]
- 13 Retorno del Error de Excepcion de Bus de Retorno [0D Hex.]
- 14 Devolver el Numero de Mensajes del Servidor [0E Hex.]
- 15 Servidor de Devolucion 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 Comunicacion (Solo linea serial) [11 (0X0B)]
- Obtener Registro de Eventos de Comunicacion (Solo linea serial) [12 (0X0C)]
- ID de Servidor de Informes (Solo linea serial) [17 (0X11)]
- Leer la Identificacion 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 Comunicacion Web MQTT

MQTT (Message Queue Telemetry Transport - Transporte Telemetrico de Mensajes en Cola), es un protocolo usado para la comunicacion machine-to-machine (maquina a maquina) (M2M) en el Internet de las Cosas (IoT). Este protocolo esta orientado a la comunicacion 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 perdidas. En Octubre de 2014 se aprobo el MQTT Version 3.1.1. como una norma OASIS[5]. Sus caracteristicas incluyen:

- Uso del patron de mensaje de publicacion/suscripcion que proporciona una distribucion de mensajes de uno a varios y desacoplamiento de aplicaciones.
- Un transporte de mensajeria que es agnostico para el contenido de la carga util. Con tres cualidades de servicio para el envio 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 perdida de mensajes. Este nivel podria utilizarse, por ejemplo, con datos de sensores ambientales en los que no importa si se pierde una lectura individual, ya que la siguiente sera publicada poco despues.
- "Por lo menos una vez", donde los mensajes se aseguran para llegar pero los duplicados pueden ocurrir.
- "Exactamente una vez", donde el mensaje esta asegurado para llegar exactamente una vez. Este nivel podria utilizarse, por ejemplo, con sistemas de facturacion en los que los mensajes duplicados o perdidos podrian dar lugar a que se aplicaran cargos incorrectos.
- Se minimiza un pequeno gasto de transporte y se minimizan los intercambios de protocolos para reducir el trafico de red.
- Un mecanismo para notificar a las partes interesadas cuando se produce una desconexion anormal.

La arquitectura de MQTT sigue una topologia 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 periodicamente un paquete y esperan la respuesta del servidor. La comunicacion puede ser cifrada entre otras muchas opciones que aporta a la red una capa extra de seguridad. Este tipo de arquitectura, permite que la comunicacion puede ser de uno a uno o de uno a muchos. La comunicacion se basa en "topics" (topicos), que el cliente que publica el mensaje crea y los nodos que deseen recibirlo deben subscribirse a el.

2.4. Descripcion 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 presion, son variables comunes en los procesos industriales. Estas son monitoreadas y controladas por medio de la instrumentacion del proceso a fin de tener un mejor entendimiento de como las maquinas y/o equipos en la planta, se estan desempenando en tiempo real y poder tomar acciones sobre el comportamiento de las mismas. Los datos en vivo e historicos sobre el desempeno de estas variables ayudan a identificar problemas tecnicos 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 produccion, tiempo y dinero, haciendo onerosos los procesos de mantenimiento y recuperacion de maquinas y equipos danados. Como parte de sus objetivos comerciales y empresariales, surge como solucion a esta problematica IndConnect de la empresa LS Innovaciones C.A., cuya solucion se presenta como una combinacion de hardware y software, capaz de monitorear los distintos sistemas[6], los cuales en base a la data obtenida y recolectada, permiten al usuario visualizar y analizar toda la informacion con el fin de verificar y evaluar el desempeno requerido y necesario para las operaciones de una planta en espedfico 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.

Abbildung in dieser Leseprobe nicht enthalten

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 traves 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 ultimo es el caso que nos ocupa en este proyecto de pasanha.

En la Figura 2.13. se muestra un ejemplo de aplicacion 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.

Abbildung in dieser Leseprobe nicht enthalten

Figura 2.13. Ejemplo de una aplicacion web concerniente a los datos de una Estacion de Bombeo en la plataforma indConnect [6].

Los datos de campo (entradas digitales y analogicas) pueden ser cableados directamente al modulo indConnect Link (PCB) (Ver Figura 2.14.), el cual tiene la capacidad de procesar estas senales 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 variacion: las senales analogicas solo se enviaran cuando su variacion sea superior a un porcentaje configurado por el usuario.
- Cambio de estado: las senales digitales solo se enviaran cuando se produzca un cambio de estado en ellas.

Estos criterios garantizan que el consumo de datos de Internet sea el minimo posible o deseable haciendo al sistema mas eficiente y confiable en cuanto al uso de recursos[7].

Abbildung in dieser Leseprobe nicht enthalten

Figura 2.14. Vista comercial del PCB (Modulo indConnect Link).

En la Figura 2.15 se muestra un esquema del enfoque del PCB desarrollado para proposito de este informe (Modulo indConnect Link) en la industria. Como se puede observar, el PCB se puede conectar al sensor y a un PLC por protocolo ModBus. Ademas, el PCB puede estar conectado por USB a un computador para que asi el usuario pueda interactuar con el mismo a traves de la Aplicacion (App) de escritorio, tambien desarrollada y que se discutira en el Capitulo 4 con mas detalles.

Abbildung in dieser Leseprobe nicht enthalten

En la Figura 2.16, se puede observar la aplicacion general en la industria del PCB desarrollado. En esta figura se muestra un diagrama de bloques general con una cantidad “N” de modulos distribuidos por toda la planta. Cada modulo (representado como “nodo” en la Figura 2.16.) puede estar conectado directamente a varios sensores y ademas conectado por protocolo ModBus con otros dispositivos como PLCs; creando de esta manera toda una red de datos ModBus. Ademas, puede enviar los datos a la “Nube” por protocolo MQTT como se ha explicado anteriormente.

Abbildung in dieser Leseprobe nicht enthalten

Figura 2.16. Esquema general de la aplicacion del PCB en la industria.

2.4.1 Sensores

Los sensores son las piezas de hardware que hacen el trabajo crltico de los procesos de monitoreo, mediciones y recoleccion de datos. Un sensor convierte el parametro fisico (por ejemplo: temperatura, presion, humedad, velocidad, etc.) en una senal que puede ser medida electricamente.

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

- Precision
- Condiciones ambientales (existen llmites de temperatura/humedad)
- Alcance (llmite de medicion del sensor)
- Calibracion (esencial en los dispositivos de medicion, una vez que las lecturas cambien con el tiempo)
- Poder de decision (mayor incremento detectado por el sensor)
- Costo
- Repeticion (la lectura que varia es repetidamente medida dentro del mismo ambiente)

Segun el tipo de salida que se obtiene de los sensores, estos pueden ser:

- Analogicos: cuando entrega como senal 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 transmision de informacion a traves del intercambio de datos. Para propositos de este informe, se entendera como red de datos, a una red de datos ModBus donde se tiene un conjunto de dispositivos conectados entre si a traves de este protocolo de comunicacion industrial, tal como el que se muestra en la Figura 2.16.

2.5 Software SCADA

SCADA (Supervisory Control And Data Acquisition - Adquisicion de Datos y Supervision de Control) es una aplicacion software de control de produccion que se comunica con los dispositivos de campo (sensores y actuadores) y controla el proceso de forma automatica desde la pantalla del computador que es configurada por el usuario y puede ser modificada con facilidad. Proporciona toda la informacion que se genera en el proceso productivo (supervision, control de calidad, control de produccion, almacenamiento de datos, etc.) y permite su gestion e intervencion.

Entre los principales servicios que ofrece un Sistema SCADA tenemos:

- Posibilidad de crear paneles de alarma que permite al operador reconocer una parada o situacion de alarma, con registro de incidencias.
- Generacion de historicos de senal de planta que pueden ser tabulados para su proceso en una hoja de calculo.
- Ejecucion de programas que modifiquen o anulen las tareas asociadas al automata bajo ciertas condiciones.
- Posibilidad de programacion numerica para realizar calculos aritmeticos de elevada resolucion sobre la CPU del computador.

Los principales elementos en un Sistema SCADA son:

- Operador: Persona que monitorea de forma remota la operacion de una planta y ejecuta funciones de control supervisorio.
- Interfaz Hombre-Maquina (HMI): Software encargado de interactuar con el operador del sistema dandole informacion y variables de control mediante graficos, esquemas, pantallas y menus.
- Unidad Terminal Maestra (MTU): Presenta los datos al operador a traves del software HMI, reune informacion de las unidades remotas y trasmite las senales 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 metodos de control son de lazo abierto.
- Medios de comunicacion: Permite la comunicacion entre la MTU y los dispositivos remotos.
- Unidad Terminal Remota (RTU): Envia senales de control a los actuadores y recibe senales de los sensores. Recolecta la informacion de estos dispositivos y transmite los datos a la MTU. La velocidad de transmision entre la RTU y los sensores y actuadores es alta, esto posibilita la implementacion de metodos de control de lazo cerrado.
- Instrumentos de campo: Son dispositivos que permiten realizar la automatizacion o control del sistema (PLCs, controladores de procesos industriales y actuadores en general), captan la informacion de la planta (sensores y alarmas).

Cuando se decide implementar un sistema SCADA se deben considerar 5 fases basicas sobre

su instalacion:

- Fase 1: El diseno de la arquitectura del sistema. Incluye el sistema de comunicaciones (Tipo de bus de campo, distancias, numero de E/S, Protocolo del sistema y Drivers).
- Fase 2: Equipamiento de los RTUs, comunicaciones, Equipos HMI y Hardware en general. Adquisicion de un software SCADA adecuado a la arquitectura y sistemas de la planta.
- Fase 3: La instalacion del equipo de comunicacion y el sistema PC (Personal computer - Computador personal).
- Fase 4: Programacion de equipos de comunicaciones, HMI y software SCADA.
- Fase 5: Puesta a punto para corregir y solucionar problemas de programacion, comunicacion y software.

Algunos de los software SCADA, o que incluyen SCADA como parte de ellos, son:

- Aimax, de Design Instruments S.A.
- CUBE, Orsi Espana 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

Segun la NEMA (National Electrical Manufacturers Association - Asociacion Nacional de Fabricantes Electricos) un PLC (Programable Logic Controller - Controlador Logico Programable) es un dispositivo digital electronico con una memoria programable para el almacenamiento de instrucciones que permiten la implementacion de funciones especificas (logicas, secuenciales, temporizadas, de conteo y aritmeticas) con el objeto de controlar maquinas y procesos.

La plataforma IndConnect tiene en el PLC un importante elemento para el manejo de la informacion de los procesos que seran 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 informacion.

La estructura basica del PLC esta compuesta por:

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

Los PLC estan capacitados para almacenar y retirar informacion mediante dos tipos de memoria, Memoria de Datos y Memoria de Usuarios, capaces de almacenar:

- Datos del Proceso:
- Senales de entradas y salidas o Variables internas, de bit y de palabra o Datos alfanumericos y constantes
- Datos de Control:
- Instrucciones de usuario, programa o Configuracion del automata

Los dispositivos de entrada son aquellos que intercambian (o envian) senales con el PLC. Cada dispositivo de entrada sirve para conocer una condicion particular de su entorno, como temperatura, presion, posicion, entre otras.

Entre los dispositivos de entrada podemos encontrar: sensores inductivos, magneticos, opticos, pulsadores, termocuplas, termoresistencias, encoders, etc.

Las entradas se pueden clasificar en:

- Entradas Digitales: son las que pueden tomar solo dos estados: encendido o apagado, estado logico 1 o 0. Los modulos de entradas digitales trabajan con senales de voltaje por lo general de 0 y 24 V. Un voltaje de 24 V se interpreta como “7” y una de 0 V se interpreta como “0”.
- Entradas Analogicas: son las que admiten como senal de entrada valores de corriente intermedios dentro de un rango de 4-20 mA, convirtiendola en un numero que se guarda en una posicion de la memoria del PLC. Los modulos de entradas analogicas traducen una senal de corriente que proviene de un sensor de temperatura, velocidad, aceleracion, presion, posicion, o cualquier otra magnitud fisica medible, en un numero que el PLC interpreta mediante un conversor analogico digital.

Los dispositivos de salida son aquellos que responden a las senales que reciben del PLC, cambiando o modificando su entorno. Entre los dispositivos de salida podemos mencionar:

- Contactores de motor
- Electrovalvulas
- Indicadores luminosos o simples reles

Los modulos de salida digital permiten al PLC actuar sobre elementos que admitan ordenes de tipo encendido - apagado, todo o nada u “on - off".

Las empresas que piensan en el futuro se encuentran provistas de modernos dispositivos electronicos en sus maquinas y procesos de control. En la actualidad, las fabricas 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 ordenes grabadas en su memoria. Dispone de una unidad central de procesamiento, memoria y perifericos de entrada/salida.

En el desarrollo del PCB de este trabajo, se utilizo un MCU Atmel debido a sus caracteristicas y su compatibilidad con la plataforma de desarrollo Arduino IDE, la cual facilita el uso de la electronica y programacion de sistemas embebidos en proyectos multidisciplinarios. Los MCU Atmel ofrecen una mezcla de disenos integrados eficientes e innovadores que son ideales para los productos inteligentes de hoy en dia. En esta era de Internet de las Cosas (IoT), los MCU constituyen una tecnologia clave que alimenta las comunicaciones de maquina a maquina (M2M). En la Figura 2.17 se muestra un diagrama con la estructura generica de un MCU.

Abbildung in dieser Leseprobe nicht enthalten

Figura 2.17. Estructura generica de un MCU.

Los MCU Atmel ofrecen arquitecturas optimizadas para baja potencia, conectividad de alta velocidad, ancho de banda optimo de datos y un gran soporte de interfaz. Ofrece una amplia variedad de opciones de configuracion, los desarrolladores pueden disenar 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 combinacion unica de rendimiento, eficiencia de potencia y flexibilidad de diseno. Se basan en la arquitectura mas eficiente en codigo para la programacion de lenguaje “C” y ensamblaje. Son la eleccion ideal para disenos que requieren grandes cantidades de codigo, 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 minimo consumo de energia.

- MCU Atmel ARM

Es un MCU de 32 bits que puede satisfacer las necesidades de practicamente cualquier dispositivo. Flexible y altamente integrado, esta disenado para optimizar el control del sistema, conectividad cableada e inalambrica, gestion 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 tecnologia probada con las ultimas caracteristicas y funcionalidades. Los desarrolladores pueden elegir entre los microcontroladores de 8 bits de un solo ciclo de bajo consumo, asi como los dispositivos de socket estandar de la industria (MSC 51), todos ellos con avanzadas tecnologias de memoria Flash. Los MCU Atmel permiten una amplia gama de aplicaciones los cuales incluyen areas como Automatizacion de edificios, Electrodomesticos, Entretenimiento en el hogar, Automatizacion industrial, Iluminacion, Energia Inteligente, Electronica Movil, Perifericos para PC y el Internet de las Cosas.

2.8. Programacion de MCU con Arduino IDE

El Arduino Software IDE (Arduino Integrated Development Environment - Entorno de Desarrollo Integrado Arduino) es un entorno de programacion que ha sido empacado como un programa de aplicacion; es decir, consiste en un editor de codigo, un compilador, un depurador y un GUI (Graphical User Interface - Constructor De Interfaz Grafica). Ademas incorpora las herramientas para cargar el programa ya compilado en la memoria flash del hardware. Su principal caracteristica es su sencillez y facilidad de uso.

El codigo fuente del Arduino IDE esta disponible en https://github.com/arduino/Arduino/. Las instrucciones para construir el IDE desde el codigo fuente que implementa el lenguaje de programacion puede verse en: https://github.com/arduino/Arduino/wiki/Building-Arduino.

La direccion para descargar el Arduino IDE es: https://www.arduino.cc/en/Main/Software. Ademas 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 codigo, acceder a contenido, configurar tarjetas y compartir proyectos, muy enfocado al Internet de las Cosas (IoT).

2.9. Aplicacion (App) de escritorio en Windows

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

El desarrollo de App de escritorio es un termino amplio que se refiere al proceso de escribir un software que se ejecutara en equipos estandar, como los equipos de escritorio, portatiles o de uso general. El software en desarrollo puede ser un software de sistema o un software de aplicacion. El software de aplicacion esta disenado para realizar una tarea unica 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 programacion de aplicaciones de Windows), codigo administrado .NET con WPF (Windows Presentation Foundation - Fundacion de Presentacion de Windows) y codigo administrado .NET con Silverlight para el desarrollo rapido de App.

Puede escribirse para cada uno de estos entornos de programacion y otros mas 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 multiples lenguajes de programacion, como: C++, C#, C, JavaScript, F# y Visual Basic .NET, asi como entornos de desarrollo web, como ASP.NET, etc.

Visual Studio permite crear sitios y aplicaciones web, asi como servicios web en cualquier entorno que soporte la plataforma .NET. Asi, se pueden crear aplicaciones que se comuniquen entre estaciones de trabajo, paginas web, dispositivos moviles, dispositivos embebidos y consolas, entre otros. Estas herramientas estan disenadas para trabajar juntas de la forma mas eficiente posible y todas se exponen a traves del entorno del IDE de Visual Studio.

Visual Studio funciona y se integra bien con App de terceros como Unity a traves de la extension Visual Studio Tools para Unity, y Apache Cordova a traves 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 tambien 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 graficos 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 Ejecucion de Lenguaje Comun) que es la rutina universal
- 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 comun para que dichas App puedan ejecutarse. Para los desarrolladores de App, .NET Framework facilita un modelo de programacion coherente y completo para crear aplicaciones que ofrezcan experiencias de usuario visualmente interesantes y una comunicacion segura y sin problemas.

CAPITULO 3

DISENO, DESARROLLO E IMPLEMENTACION DEL PCB

En este capitulo, se discute sobre los componentes que conforman el diseno, asi como el desarrollo del esquematico de los circuitos y el ensamblaje e implementacion del PCB. La empresa LS Innovaciones C.A., preselecciono componentes para el diseno, entre estos el microcontrolador (MCU) utilizado. Ademas, por razones de confidencialidad, no se mostrara con detalle el esquematico de los circuitos disenados, ni la programacion 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 Estatica de Acceso Aleatorio). Funcionan a una frecuencia maxima de 48 MHz. Estan disenados para la migracion simple e intuitiva con modulos perifericos identicos, codigo hexadecimal compatible, mapa de direcciones lineal identico y rutas de migracion compatibles con pin entre todos los dispositivos de la serie del producto.

En el proyecto realizado se utilizo el MCU Atmel SAMD21G18 de alto rendimiento que lo hace ideal para una amplia gama de aplicaciones domoticas, de consumo, de medicion e industriales. Cuenta con 256 KB de memoria flash y 32 KB de SRAM, con una frecuencia de funcionamiento de hasta 48 MHz, seis modulos de comunicacion 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 Analogico a Digital) de 14 canales y 12 bits, uno DAC (Digital to Analog Converter - Convertidor Digital a Analogico) de 10 bit. Fuente de alimentacion 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 evaluacion.

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

Abbildung in dieser Leseprobe nicht enthalten

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

3.2 Pruebas experimentales

Se procedio como primer paso a realizar ciertas pruebas experimentales. Una vez adquirido el MCU SAMD21G18, seleccionado a priori por la empresa, se procedio a probar y disenar los modulos que conformarian el diseno completo del PCB. Como se tenia disposicion de una tarjeta Arduino Zero, la cual esta basada en este MCU, se decidio en primera instancia probarla con el Ethernet Shield Wiz550io (Modulo Ethernet para tarjetas Arduinos desarrollado por empresa Wiznet) que ademas se tenia a disposicion. De igual forma, se procedieron a realizar pruebas experimentales en un protoboard de los modulos 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 comunicacion serial (basado para las pruebas en el integrado MAX232) conectados a la tarjeta Arduino Zero. Esto se realizo con el fin de verificar el funcionamiento de estos distintos modulos con un MCU basado en la arquitectura ARM, a diferencia de la comunmente 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 tenia a disposicion para usos en el protoboard. Sin embargo, para el caso de diseno se decidio usar el circuito integrado TLP293-4 por sus caracteristicas muy particulares, ademas de permitir la conexion de hasta 4 entradas. En el caso del circuito de acondicionamiento para las entradas analogicas, no se realizaron pruebas experimentales previo al diseno del PCB ya que no se disponian de los componentes electronicos 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 conexion al Internet sencilla para sistemas integrados que utilizan SPI (Serial Peripheral Interface - Interfaz de perifericos en serie) de alta velocidad. Los perifericos 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 energia del sistema, el controlador WIZnet W5500 hace uso de WOL (Wake on LAN - Encender Remotamente un Computador) y un modo de apagado.

Adicionalmente presenta caracteristicas de interes para el proyecto, tales como:

- Admite 8 sockets independientes simultaneamente
- Memoria interna de 32 KB para el Buffer Tx/Rx
- Soporte de Negociacion Automatica (Full y Half duplex, 10 y 100-based)
- Operacion de 3,3 V con tolerancia de senal E/S de 5 V
- Salidas LED (Full/Half duplex, Link, Speed, Active)

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

Abbildung in dieser Leseprobe nicht enthalten

Figura 3.2. Asignacion de pines/Diagrama de bloques del WIZnet W5500[9].

3.2.2 Circuito para Comunicacion Serial (Transceptor EXAR SP330E)

La comunicacion serial es una de las herramientas mas 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 tambien soporte una comunicacion serial: tales como ordenadores, equipos controlados por MIDI, sensores con conexion serial, camaras, smartphones, tablets, servidores u otro MCU.

La comunicacion 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 logica de bajo voltaje variable de hasta 1,65 V. Opera desde una sola fuente de alimentacion, 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 kQ), lo que permite hasta 256 dispositivos en un solo bus de comunicacion (1/8 de unidad de carga).

Adicionalmente presenta las siguientes caracteristicas que lo hacen ideal para este proyecto:

- Velocidades de datos de 20 Mbps para RS-485 y 1 Mbps para RS-232
- Operacion de suministro unico de + 3 V a + 5,5 V
- 2 Transmisores, 2 Receptores RS-232
- 1 Transmisor, 1 Receptor RS-485/422
- Configuracion completa o half-duplex (semi-duplex)
- 1/8 unidad de carga, hasta 256 receptores en el bus
- VL Pin (Logic supply - Suministro de entradas logicas) de la interfaz logica de 1,65 V a 5,5 V
- Proteccion robusta de ESD (Electrostatic Discharge - Descarga Electroestatica)
- Diseno pequeno con encapsulado 24-TSSOP (Thin Shrink Small Outline Package - Paquete de contorno pequeno y contraccion delgada)
- Pin de seleccion 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.

Abbildung in dieser Leseprobe nicht enthalten

Figura 3.3. Diagrama de bloques de los modos RS-232 y RS-485 Half-Duplex del Transceptor SP330E [10].

3.2.3 Circuito de acondicionamiento para entradas Analogicas y Digitales Industriales

En algunos casos, la senal puede ser demasiado pequena, y seria necesario amplificarla; o podria contener interferencias que eliminar; ser no lineal y requerir su linealizacion; ser analogica y requerir su digitalizacion; ser digital y convertirla en analogica, etc. Todas estas modificaciones necesarias segun corresponda en el dispositivo que se disena o maneja, se le denomina con el termino acondicionamiento de senal. De tal modo que para acondicionar la senal, es decir, hacerla adecuada al requerimiento tecnico durante el desarrollo de un dispositivo electronico, se requiere de elementos capaces de hacer estos acondicionamientos.

En este proyecto hemos requerido acondicionar ciertas senales necesarias para la operabilidad del dispositivo en desarrollo. Estas son senales analogicas y digitales industriales. Una senal analogica industrial es una senal de corriente que se encuentra entre el rango de 4 a 20 mA, mientras que una senal digital industrial es una senal de voltaje entre el rango de 0 a 24 V. Ambas senales, necesitan ser convertidas a senales 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 senales analogicas y el Opto- acoplador TLP293-4 para las senales digitales.

3.2.3.1 El Amplificador Operacional MCP6004

El Amplificador Operacional MCP6004, esta disenado para aplicaciones de uso general. Posee un ancho de banda de ganancia 1 MHz y un margen de fase de 90° (tipico). Tambien mantiene un margen de fase de 45° (tipico) 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 pA (tipico). Ademas, el MCP6004 admite oscilaciones de entradas y salidas rail to rail (riel a riel), con un rango de entrada de voltaje en modo comun de: VDD + 300 mV a VSS - 300 mV.

Esta ultima caracteristica fue determinante al momento de seleccionar este amplificador operacional debido a que el voltaje de salida no estaria limitado a gran escala, obteniendo un maximo 3 V en lugar de 3,3 V, lo cual para la aplicacion deseada es aceptable. En la Figura 3.4 se muestra una aplicacion tipica del Amplificador Operacional MCP6004. Sin embargo, para el proyecto se uso en modo seguidor de voltaje, donde el voltaje de salida es igual al voltaje de 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: Vout = Vin.

Abbildung in dieser Leseprobe nicht enthalten

Figura 3.4. Aplicacion 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 opticamente 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 (Ta = — 55°Cal25°C), y por lo tanto es adecuado para aplicaciones como controladores programables, conmutacion de fuentes de alimentacion y transmisiones de datos simplex/multiplex.

En la Figura 3.5 se muestra la configuracion de pin de un optoacoplador TLP293-4 utilizado en el proyecto.

Abbildung in dieser Leseprobe nicht enthalten

3.2.4 Modulo RTC PCF8523

El circuito integrado PCF8523 es un RTC (Real Time Clock - Reloj en tiempo Real) CMOS (Complementary metal oxide semiconductor - Semiconductor complementario de oxido metalico) y un calendario optimizado para bajo consumo de potencia. Los datos se transfieren en serie a traves de un bus I² C con una velocidad de datos maxima de 1000 kbps. Las funciones de alarma y temporizador estan disponibles con la posibilidad de generar una senal de despertador en un pin de interrupcion. Un registro de desplazamiento permite un ajuste fino del reloj. El RTC PCF8523 tiene un circuito de conmutacion de baterla de respaldo, que detecta fallas de energla y cambia automaticamente su voltaje de alimentacion por el voltaje que suministra la baterla cuando se produce un corte de energla.

Otras caracterlsticas importante de este dispositivo, son las siguientes:

- Proporciona ano, mes, dla, dla de la semana, horas, minutos y segundos en funcion 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 interrupcion

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

Abbildung in dieser Leseprobe nicht enthalten

3.2.5 Memoria EEPROM 24AA025E48

La EEPROM 24AA025E48, es una memoria PROM electricamente borrable de 2 Kbit. El dispositivo esta organizado como dos bloques de memoria de 128 x 8 bits con una interfaz serial de 2 cables. Tiene una capacidad de escritura de pagina de 16 bytes. Ademas, se puede alimentar con un voltaje entre 1,7 V y 5 V. Otras caracteristicas adicionales y relevantes de este componente para la aplicacion, son:

- Tecnologia 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 pagina 3 ms, tipico
- Ciclo de borrado/escritura auto-programado
- Buffer de escritura de pagina de 16 bytes
- Proteccion de ESD > 4000 V
- Mas de 1 millon de ciclos de borrado/escritura
- Posee pin para proteccion de escritura por hardware
- Programacion de fabrica 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.

Abbildung in dieser Leseprobe nicht enthalten

3.2.6 Memoria EEPROM 24AA64

La EEPROM 24AA64, es una memoria PROM electricamente borrable de 64 Kbit. El dispositivo esta organizado como ocho bloques de memoria de 1 K x 8 bits con una interfaz en serie de 2 cables. El diseno 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 adquisicion de datos. La memoria EEPROM 24AA64 ademas tiene una capacidad de escritura de pagina de hasta 32 bytes de datos y esta disponible en los encapsulados PDIP (Plastic Dual In-Line Package - Encapsulado Doble en Linea de Plastico) estandar de 8 pines, SOIC (Small Outline Integrated Circuit - Circuito Integrado de Esquema Pequeno) de montaje superficial, TSSOP (Thin Shrink Small Outline Package - Encapsulado de Contorno Pequeno y Delgado) y MSOP (Mini Small Outline Plastic - Mini Pequeno Esquema de Plastico) lo cual la hace ideal para este proyecto.

Otras caracteristicas relevantes de este dispositivo, son las siguientes:

- Tecnologia 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 pagina de hasta 32 bytes
- Tiempo de ciclo de escritura tipico de 2 ms para escritura de pagina
- Proteccion de ESD > 4000 V
- 1 millon de ciclos de borrado/escritura
- Posee pin para proteccion de escritura por hardware
- Retencion de data > 200 anos
- 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.

Abbildung in dieser Leseprobe nicht enthalten

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

3.3 Diseno del PCB en Eagle CAD

El diseno de PCB se realizo con el software EAGLE CAD. El diseno es un proceso de dos pasos donde primero se trabaja el esquematico de los circuitos electronicos, y luego se disena el PCB conformada por los componentes electronicos utilizados en el esquematico. Un esquema bien disenado es fundamental para el proceso general de diseno de un PCB, pues ayuda a detectar errores antes de que se fabrique la tarjeta, e incluso despues de la fabricacion en caso de que algo no funcione.

3.3.1 Seleccion del encapsulado

Antes de realizar el Layout (diseno) del PCB, se hizo la seleccion del encapsulado que alojaria y por lo tanto protegeria al mismo. Conjuntamente con la empresa LS Innovaciones C.A., se selecciono el encapsulado MEMAX 22,5 2-2 KMGY-2713625, fabricado por la empresa Phoenix Contact. Este es un encapsulado completo con orificios de ventilacion, conectores de 5 posiciones y posee un conector para montaje sobre riel tipo DIN.

Sus especificaciones tecnicas principales son las siguientes:

1. Material del encapsulado: Poliamida
2. Temperatura de Operacion: - 40 °C a + 105 °C
3. Longitud: 99 mm
4. Altura: 114,5 mm
5. Ancho: 22,5 mm

Asi, el diseno del PCB se realizo siguiendo estas caracteristicas dimensionales. En la Figura 3.9 se muestran dos vistas tridimensionales del encapsulado utilizado en este proyecto.

Abbildung in dieser Leseprobe nicht enthalten

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 electronico del PCB

El diagrama electronico corresponde al esquematico de los circuitos del PCB. Este esquematico incluye todos los modulos implementados, asi como tambien el circuito de la fuente de alimentacion, el circuito de acondicionamiento del MCU (conformados por capacitores, cristales y resistencias), entre otros. Como se menciono al principio de este capitulo, por motivos de confidencialidad exigidos por la empresa LS Innovaciones C.A. no se mostrara con detalle el esquematico. Sin embargo, como muestra, en la Figura 3.10 se puede observar una hoja del esquematico desarrollado. En este caso, el correspondiente a los circuitos para el MCU y la fuente de alimentacion.

Abbildung in dieser Leseprobe nicht enthalten

Figura 3.10. Muestra de una hoja del esquematico desarrollado en este proyecto.

3.3.3 Layout del PCB

Un Layout de un PCB corresponde a su diseno, incluyendo las pistas de cobre, la distribucion de los componentes, la ubicacion ideal de cada circuito integrado, entre otros. Ademas, al realizar el diseno se deben considerar ciertos casos especiales, como por ejemplo, aislar las pistas de cobre de GND (tierra) de circuitos como el del modulo de ethernet para evitar de esta manera interferencia de ruido proveniente de tierra. Otro ejemplo importante lo representa el circuito de la fuente de alimentacion. En este proyecto, el circuito de la fuente de alimentacion esta basado en un circuito integrado. Este circuito integrado generara cierta cantidad de calor. Por lo tanto, al ubicar el circuito de alimentacion se debe considerar, adicionalmente disenar un disipador de calor, por ejemplo, usando un area de cobre dentro del PCB. En consecuencia, estos ejemplos representan algunos casos que se deben evaluar al disenar, los cuales evitarian errores de funcionamiento posteriores.

Como se menciono anteriormente, el Layout (diseno) del PCB se realizo siguiendo las caracterlsticas dimensionales del encapsulado previamente seleccionado. En la Figura 3.11 se muestra el diseno realizado en EAGLE CAD.

Abbildung in dieser Leseprobe nicht enthalten

Figura 3.11. Layout (diseno) del PCB desarrollado en este proyecto.

3.4 Ensamblaje del PCB

Una vez disenado el PCB, se procedio a fabricarlo con la empresa Seeed Studios, ubicada en China. Esta empresa, en su pagina web (https://www.seeedstudio.com/fusion pcb.html), exige el cumplimiento de ciertas exigencias mlnimas de diseno, 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: mlnimo 0,152 mm
- Tamano de las perforaciones metalizadas: mlnimo 0,3 mm de diametro
- Espacio entre pads (superficie de cobre): mlnimo 0,4 mm

Posterior a la fabricacion del PCB y recepcion del mismo, se procedio a realizar la soldadura de los componentes que conforman el diseno y previamente adquiridos.

El proceso de soldadura de componentes se realizo manual y cuidadosamente mediante el uso de cautin y en algunos casos, se utilizo 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.

Abbildung in dieser Leseprobe nicht enthalten

Figura 3.12. Vista de la capa superior del PCB.

Abbildung in dieser Leseprobe nicht enthalten

Figura 3.13. Vista de la capa inferior del PCB.

Abbildung in dieser Leseprobe nicht enthalten

Figura 3.14. Vista del PCB dentro del encapsulado seleccionado.

3.5 Firmware del PCB

El firmware es un bloque de instrucciones de programa (software programado) para propositos espedficos, grabado en una memoria de tipo no volatil (por ejemplo, ROM, EEPROM), y que contiene la informacion, configuracion y el sistema basico para controlar los circuitos electronicos de un dispositivo. Estas instrucciones fijan la logica primaria que ejerce el control de los circuitos de alguna clase de artefacto. En concreto podemos establecer que el firmware de cualquier dispositivo tecnologico cumple basicamente 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 comoda interfaz para que, de esta manera, se pueda acometer rapida y facilmente la configuracion del sistema mediante el uso de una serie determinada de parametros.
3. Controlar y gestionar tanto lo que es el arranque del sistema del dispositivo como la correspondiente iniciacion.

El firmware del PCB disenado y construido en este proyecto consistio de la programacion realizada en lenguaje C en Arduino IDE, el cual define su funcionamiento. Este se diseno y desarrollo bajo la siguientes premisas:

- El PCB debe tener la capacidad de procesar las senales analogicas 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:
- Porcentaje de variacion: las senales analogicas solo se enviaran cuando su variacion sea superior a un porcentaje configurado por el usuario. o Cambio de estado: las senales digitales solo se enviaran cuando haya un cambio de estado en ellas.

En la Figura 3.14 se muestra el diagrama de flujo bajo el cual se diseno el firmware del PCB construido, el cual cumple con las premisas propuestas anteriormente. Por razones de confidencialidad, mencionada a comienzo de este capbulo, los codigos del firmware no podran mostrarse.

Abbildung in dieser Leseprobe nicht enthalten

Figura 3.15. Diagrama de flujo del firmware del PCB disenado.

CAPITULO 4

DESARROLLO E IMPLEMENTACION DE LA APLICACION DE ESCRITOTIO

En este capitulo, se discute el desarrollo de la Aplicacion (App) de escritorio para Windows, haciendo uso de Visual Studio IDE. Al igual que en el Capitulo 3, por razones de confidencialidad, no se mostrara con detalle la programacion que conforma el desarrollo y puesta en marcha de la App.

4.1 Descripcion del Funcionamiento de la App de escritorio

La App de escritorio se diseno y desarrollo con la finalidad de poder interactuar con el PCB y ademas poder configurarlo. Para ello, la idea principal se basa en editar los diferentes comando del maestro ModBus, configurar las respectivas entradas y demas parametros a fin de crear un archivo de texto .cfg (extension para archivos de configuracion). Este archivo de texto basicamente es descargado, desde la App de escritorio, en el PCB via puerto serial a traves del conector USB. Ademas, con la App de escritorio el usuario puede tener acceso a una ventana de diagnostico donde puede observar la memoria interna del PCB, los errores de los comandos ModBus (si existen), el numero de publicaciones exitosas y fallidas en el broker message (servidor de mensajeria) 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 util y representa el vinculo 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 aplicacion, esto vendria 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 modulo, el numero de entradas, se introduce el nombre deseado por el usuario y posteriormente se puede agregar y editar los comandos del maestro ModBus, asi como tambien los parametros del cliente MQTT o del servidor ModBus (si es el caso). Por ultimo, la etapa final consiste en descargar el archivo de configuracion .cfg, que es creado por la App, via USB al PCB. Si el usuario lo desea, puede volver a editar el proyecto actual o crear uno nuevo. Ademas, el usuario puede diagnosticar, como se menciono anteriormente, sobre el PCB o tambien puede actualizar el firmware del mismo. En consecuencia, la App provee al usuario diferentes opciones de interaccion con el PCB. En la Figura 4.1 se muestra un diagrama general de la App de escritorio.

Abbildung in dieser Leseprobe nicht enthalten

Figura 4.1. Diagrama general del funcionamiento de la aplicacion de escritorio.

4.2 Programacion de la App de escritorio

La programacion de la App de escritorio se realizo haciendo uso de la plataforma de desarrollo Visual Studio IDE, mediante el lenguaje VB.NET. Esta programacion se desarrollo con el objetivo de lograr el funcionamiento mencionado en el subcapltulo anterior. Para ello, Visual Studio IDE proporciona varias herramientas para el manejo de botones, pestanas, 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 propositos de este informe. La App cuenta con varias ventanas, cada una para el cumpliendo de cierto proposito: comandos maestro ModBus, parametros del cliente MQTT, parametros del broker message (servidor de mensaje) MQTT, descarga de archivo, actualizacion de firmware, configuracion de los parametros de cada una de las entradas analogicas/digitales, entre otras. Por motivos de solo muestra, solo se proporcionaran algunas App.

Abbildung in dieser Leseprobe nicht enthalten

Figura 4.2. Ventana de inicio de la aplicacion de escritorio.

Abbildung in dieser Leseprobe nicht enthalten

Figura 4.3. Ventana principal de la aplicacion de escritorio (sinproyecto aun creado).

Abbildung in dieser Leseprobe nicht enthalten

Figura 4.4. Ejemplo de la ventana principal, en este caso, mostrando la pestana para configurar las entradas (pestana “I/O”).

En la Figura 4.5 se muestra un ejemplo del inicio de un archivo de configuracion .cfg. Como se menciono anteriormente, es el objetivo principal de la App de escritorio. Sin el archivo de configuracion, no se puede configurar el PCB de la manera deseada.

Abbildung in dieser Leseprobe nicht enthalten

Figura 4.5. Ejemplo del comienzo de un archivo de configuracion .cfg creado por la aplicacion de escritorio.

CAPITULO 5

RESULTADOS Y ANALISIS

En este capitulo, 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 continuacion.

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 diseno 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 traves de un software o por medio de una combinacion de teclas, lo cual depende del tipo de bootloader que se esta utilizando. Si se recibe la orden de ingresar al modo bootloader el programa entra en un bucle que le permite recibir ordenes de lectura, escritura y eliminacion 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 aplicacion (App) o programa principal, el cual toma el control del MCU hasta que se vuelva a producir una inicializacion del sistema[17].

Por ejemplo, en el caso de la tarjeta Arduino Zero utilizada para las pruebas experimentales (ver el subcapitulo 3.2), el MCU SAMD21 posee el bootloader pre-instalado o pre-cargado en su memoria y en consecuencia la tarjeta, una vez descargado algun programa desde el Arduino IDE, 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 fabrica. 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 ultima fue la utilizada para el proposito de este proyecto. Para poder utilizar el depurador de manera independiente, se procedio de desoldar dos resistencias de 0 Q que conectan al depurador con el MCU de la tarjeta (ver Figura 5.1).

Abbildung in dieser Leseprobe nicht enthalten

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 traves de la plataforma Arduino IDE, conectando la tarjeta Arduino Zero con el PCB a traves de la interfaz JTAG (Joint Test Action Group - Grupo de Accion de Prueba Conjunta). Esta conexion 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 “quemaf el bootloader al MCU. Este procedimiento se utilizo durante el desarrollo del proyecto, siendo exitoso al descargar el cargador de arranque en varios MCUs.

Ademas, como se menciono anteriormente, el MCU debe entrar en modo bootloader para que el usuario pueda descargarle algun programa (Arduino IDE realiza esta tarea por el usuario). En base a esta idea, se diseno y programo la opcion de actualizacion del firmware del PCB en la aplicacion de escritorio. El MCU SAMD21 puede entrar en modo bootloader de dos maneras: presionando el boton de RESET dos veces seguidas o abriendo y cerrando su puerto serial con una velocidad de 1200 Bd. Por lo tanto, la aplicacion de escritorio envla 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, tambien se hicieron varias pruebas resultando todas exitosas, agregando esta opcion de gran utilidad a la App de escritorio.

5.2 Modulo Ethernet

Para las pruebas del modulo de Ethernet se utilizo la librerla de programacion “Ethernet 2” desarrollada por la empresa Adafruit[19]. En este caso, las pruebas fueron sencillas y basicas. En primer lugar se verifico la asignacion dinamica de direcciones IP por DHCP (Dynamic Host Configuration Protocol - Protocolo de Configuracion Dinamica de Host). Luego, se procedio a probar la asignacion estatica de direcciones IP, y finalmente se verifico la asignacion de direcciones IP con diferentes direcciones MAC (Media Access Control - Control de Acceso al Medio). Todas las pruebas resultaron exitosas.

5.3. Entradas Analogicas

Las entradas analogicas, como se ha mencionado, consisten en senales de corriente entre 4 mA y 20 mA. Para las pruebas, se hizo uso de un multimetro capaz de suministrar corriente y por lo tanto simular un sensor o transmisor. Debemos resaltar que el multimetro posee dos modalidades para este proposito: la modalidad “source” fuente) y “simulate” (simulado). En la modalidad “source”, el multimetro posee su propia fuente de alimentacion, es decir, que equivale a que el sensor posea una fuente de alimentacion externa. En la modalidad “simulate”, el PCB suministra la alimentacion al multimetro (sensor o transmisor). Como se trata de una senal 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 multimetro. Entonces, con lo antes descrito, se tienen dos casos:

- Caso 1: Modalidad “source”, donde el transmisor posee su fuente de alimentacion externa y por ende el lazo de corriente tiene su retorno en GND.
- 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.

Abbildung in dieser Leseprobe nicht enthalten

Figura 5.2. Conexion del PCB a un transmisor de 2 hilos (senal analogica).

Una vez definidas estas dos modalidades, se procedio a verificar con corrientes entre 4 mA y 20 mA, obteniendose voltajes entre 600 mV y 3 V a la entrada del ADC implementado en el PCB. El voltaje maximo de 3 V se debe a la caracterlstica del rail to rail (riel a riel) del amplificador operacional utilizado, el cual es VDD - 300 mV. Por lo tanto, para una alimentacion de 3,3 V, como en este caso, el maximo voltaje en la salida es de 3 V. Asl, 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 implemento un termistor para corrientes maximas de 35 mA, como medida de proteccion contra corriente mayores. Sin embargo, para aplicaciones industriales, los sensores o transmisores proporcionan senales de corriente de 4-20 mA.

5.4 Entradas Digitales

Las entradas digitales industriales consisten de senales de voltajes de 0 V (OFF) y 24 V (ON). En la industria, estas senales generalmente provienen de un switch (suiche). Para las pruebas, se disponla 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” logico y 0 V por un “0” logico. En la Figura 5.3 se puede observar la manera de conectar un suiche de 0-24 V al PCB.

Abbildung in dieser Leseprobe nicht enthalten

Figura 5.3. Conexion de un suiche (entrada digital industrial) al PCB.

5.5 Modulo RTC

Para las pruebas del modulo RTC PCF8523, se hizo uso de la libreria de programacion “RTC Lib", desarrollada por la empresa Adafruit[20]. Una vez verificada su compatibilidad con MCUs de la arquitectura ARM, como en este caso, se procedio a realizar pruebas de funcionalidad, como por ejemplo: asignacion y actualizacion de fecha y hora. Ademas, se verifico la funcionabilidad del circuito integrado RTC PCF8523 para el modo “back-up" (respaldo), es decir, haciendo uso de una bateria de respaldo de 3 V y desconectando la alimentacion del PCB. De esta manera, se observo que con una bateria de respaldo, el RTC PCF8523 no desactualiza la fecha y hora previamente ajustado en su memoria. Esta modalidad es util 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 bateria, 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 libreria de programacion “ExtEEPROM", disenada y desarrollada por Jack Christensen[21]. Las pruebas se realizaron con el fin de evaluar la funcionalidad de escritura y lectura de ambas memorias EEPROM, y ambas resultaron exitosas. Ademas, como la memoria EEPROM 24AA025E48T posee una direccion MAC unica integrada en su memoria, se procedio a leer la data de las respectivas direcciones de la memoria donde se ubicaba esta direccion MAC; desde la direccion 0x80 a la direccion 0xFF.

5.7 Modulo de Comunicacion Serial

Para las pruebas del modulo de comunicacion serial, se trabajo en los dos enfoques: el protocolo RS-232 y el protocolo RS-485, debido a que ambos son de uso comun en la industria. Como se menciono en el subcapitulo 3.2.2, el circuito integrado Transceptor EXAR SP330E posee un pin de seleccion para ambos protocolos. El hardware se diseno de manera que con un “0” logico el integrado funcionara en modo RS-232, y con un “7” logico 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.

Abbildung in dieser Leseprobe nicht enthalten

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

5.8 Comunicacion App - PCB

La comunicacion App - PCB se realiza por medio de un cable micro USB. El usuario puede realizar tres importantes tareas a traves de esta comunicacion: (1) Descargar un archivo de configuracion, (2) Obtener informacion de diagnostico concerniente al PCB, y (3) Realizar actualizacion del firmware.

Como se explico en el capitulo 4, la App de escritorio es una herramienta util para proveer interaccion 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 procedio a probar descargando varios archivos de configuracion (.cfg), observando que el PCB respondiera de manera correcta al leer cada una de las lineas de este archivo y que realizara la configuracion 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 evaluo el comportamiento de la ventana de diagnostico de la App al recibir informacion del PCB via serial. Se observo que la frecuencia de actualizacion de los datos reflejados en esta ventana es relativamente lenta, con un tiempo de actualizacion minimo de 1.5 s. Sin embargo, debemos resaltar que esta frecuencia se debe a la comunicacion serial, ya que no permite tener una actualizacion en tiempo real, a diferencia de otros modos de transmision de datos, como por ejemplo TCP/IP, que si lo permite. Esta comparacion se realizo evaluando el rendimiento de ciertos equipos disponibles en la empresa, como por ejemplo, equipos Prosoft Technology⁵, donde la transmision de datos entre el equipo y la App de escritorio de Prosoft Technology se lleva a cabo a traves del protocolo TCP/IP, resultando en una velocidad de transmision relativamente mayor y por ende un tiempo de actualizacion de datos mayor.

Finalmente, como se menciono en el subcapitulo 5.1, las pruebas de actualizacion de firmware resultaron exitosas, al lograrse descargar varios archivos de programas y concretando de esta manera otra herramienta util de la App de escritorio.

5.9 Comunicacion ModBus

Para las pruebas de comunicacion ModBus, se utilizo como base la libreria “MsgModBus” orientada al protocolo ModBus Ethernet TCP/IP[22], y la libreria “ModbusMastef” orientada al protocolo ModBus RTU desarrollada por Doc Walker[23]. Ambas librerias fueron editadas para poder adaptarlas al MCU SAMD21, debido a que el mismo esta 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 utilizo el programa para Windows ModScan y como simulador esclavo/servidor se utilizo el tambien programa para Windows ModSim. Basicamente, se realizaron programas en Arduino IDE con el objetivo de probar que todas las funciones ModBus estuvieran implementadas. Para ambos modos de transmision ModBus (RTU y TCP/IP), se probo la funcionabilidad del PCB como maestro/cliente y como esclavo/servidor. Se obtuvieron resultados satisfactorios, logrando una completa funcionabilidad ModBus del PCB, incluyendo deteccion de errores en los comandos maestros. Cabe destacar que ademas de estos simuladores, tambien se realizaron pruebas con equipos industriales, como por ejemplo el modulo PLX31-EIP-MBS4 de la empresa Prosoft Technology, el cual tiene la opcion de ser un cliente y servidor ModBus TCP/IP simultaneamente, asi como tambien, ser un maestro o esclavo ModBus RTU. En este caso, las pruebas fueron igual de exitosas, logrando un desempeno satisfactorio con equipos industriales. Las Figuras 5.5 y 5.6 muestran la interfaz de los simuladores ModScan y ModSim utilizados.

Abbildung in dieser Leseprobe nicht enthalten

Figura 5.5. Interfaz del simulador ModScan.

Abbildung in dieser Leseprobe nicht enthalten

Figura 5.6. Interfaz del simulador ModSim.

5.10 Comunicacion MQTT

La comunicacion con el servidor MQTT se realizo utilizando la libreria de programacion “PubSubClient" desarrollada por Nick O’Leary[24]. Las pruebas se hicieron usando el servidor publico de la empresa LS Innovaciones C.A., HiveMQ[25] el cual posee los siguientes parametros:

- Broker: broker.hivemq.com
- Puerto: 1883

Los mensajes enviados por protocolo MQTT se realizaron en base al formato JSON (JavaScript Object Notation - Notacion de objeto JavaScript). Para observar la correcta recepcion 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 topicos y publicar mensajes[26]. El mensaje enviado por MQTT posee tres parametros:

(1) Numero de identificacion (Id) de la variable
(2) Valor
(3) Timestamp (marca temporal)

Estos parametros estan reducidos en caracteres para as! ahorrar en consumo de bytes. Dependiendo del numero de variables que se esta monitoreando, as! como tambien el numero de cambios en dichas variables, el mensaje JSON puede variar en longitud. La longitud maxima establecida para propositos de programacion es de 1500 caracteres. En las pruebas realizadas, la maxima longitud obtenida fue alrededor de 350 caracteres, equivalente a 11 cambios aproximadamente.

Adicionalmente, la libreria cuenta con la posibilidad de detectar fallas a la hora de publicar un mensaje, lo cual es de gran utilidad para hacer diagnosticos con la App de escritorio respecto al numero de mensajes publicados exitosamente y el numero de intentos fallidos. En la Figura 5.7 se muestran algunos ejemplos de mensajes JSON enviados por el PCB al servidor.

Abbildung in dieser Leseprobe nicht enthalten

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 alimentacion del PCB se diseno para regular voltajes entre 9-35 V a 3,3 V. De este modo, mediante el uso de un multimetro se midio el consumo de corriente para un voltaje de alimentacion de 24 V, obteniendose un consumo de potencia de aproximadamente 30 mA @ 24V.

5.12 Modulo de Radio Frecuencia (RF) para futuras aplicaciones

En el PCB, tambien se integro un modulo de RF. Esto, como una solicitud de la empresa LS Innovaciones C.A. de explorar la posibilidad de contar con una aplicacion en modo distribuido en planta, es decir, con varios puntos de recoleccion de datos. En este tipo de aplicacion un grupo de varios PCB se encargan de tomar la informacion de dispositivos remotos, distribuidos en una misma area geografica y enviar la informacion obtenida hacia un unico equipo en la red (Gateway - Via) que se encarga de transmitir esa informacion al Internet mediante el protocolo MQTT. Cada PCB en modo nodo, posee las funcionalidades descritas en este informe a excepcion del protocolo MQTT (solo caracteristico del gateway o via). El protocolo inalambrico utilizado es el Lo-Ra (Long Range - Largo Alcance), permitiendo enlaces de 2 a 20 Km (con una antena direccional), dependiendo de las condiciones geograficas del lugar[27]. De este modo, para la prueba con el modulo de RF se utilizo la librerla “RadioHead" desarrollada por la empresa Airspayce[28]. Se procedio a verificar la comunicacion entre dos PCB, uno actuando como nodo y otro como gateway, obteniendose resultados moderadamente satisfactorios, al tener senales con un RSSI (Received Signal Strength Indicator - Indicador de Fuerza de la Sehal Recibida) entre -15 y -100. Mientras mas cercano a -15, la potencia de la senal recibida es mayor[29]. Se observo que a mayor distancia, el RSSI disminula hasta valores alrededor de los - 49 (para las distancias de prueba), lo cual es entendible considerando que a mayor distancia entre los dispositivos, menor sera la potencia de la senal RF recibida. En la Figura 5.8 se muestra el esquema de la aplicacion del PCB en un modo distribuido.

Abbildung in dieser Leseprobe nicht enthalten

Figura 5.8. Esquema de la aplicacion del PCB en modo distribuido en la Industria.

Finalmente, el alcance maximo probado fue de aproximadamente 1,5 Km, en lugares cercanos a las oficinas de la empresa LS Innovaciones en Caracas. Durante las pruebas de transmision y recepcion de los mensajes por RF, se presentaron varias fallas de recepcion, lo cual nos indica que se debe trabajar en disenar y desarrollar un protocolo de comunicacion capaz de adaptarse a estas fallas. Una posible solucion 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.

CONCLUSIONES Y RECOMENDACIONES

El PCB desarrollado cumple con los objetivos trazados en el plan de trabajo, en consideracion de las pruebas realizadas, creando as! un puente entre los datos de planta e Internet, permitiendo de forma segura la transmision de informacion de las variables seleccionadas de equipos en operacion desde cualquier lugar del mundo. Con esta informacion publicada en Internet, se puede acceder a los datos a traves de servicios web mediante el uso de una pagina web personalizada. Estos datos tambien pueden ser accedidos de manera local a traves de un PLC en una ubicacion remota, o un SCADA, mediante el protocolo ModBus.

Una de las caracterlsticas resaltantes del PCB y del proyecto en general, es haber logrado la interaccion PCB-USUARIO, a traves de un cable USB y la interfaz desarrollada con la Aplicacion (App) de escritorio. Con esta interfaz, como se indica en los capltulos 4 y 5 del informe, el usuario puede descargar un archivo de configuracion .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), numero de mensajes MQTT publicados de manera exitosa, entre otros. Por ello, esta interaccion PCB-USUARIO resulta ser una herramienta muy eficaz. Adicionalmente, de acuerdo a los resultados senalados en el capltulo 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 caracterlstica importante y elemental para un dispositivo de este tipo.

Se demostro a su vez la versatilidad del firmware del PCB. Su programacion en la plataforma de desarrollo Arduino IDE, posibilita su constante modificacion con el objetivo de satisfacer los requerimientos del cliente. De igual modo, el diseno del hardware tambien es versatil, puesto que es susceptible de cambios para su continua mejora y desarrollo.

En general, el desarrollo de esta solucion (PCB) como dispositivo aplicable al Internet de las cosas (IoT) debe continuar con miras a fortalecer su firmware y hardware, y en consecuencia el enfoque, como por ejemplo, en un modo distribuido. Esto se menciono en el subcapitulo 5.12, y consiste basicamente en tener varios puntos de recoleccion de informacion y algunos puntos de acceso al Internet, para ahorro en consumo de datos, comunicandose entre ellos (PCBs) via radio frecuencia (RF). Para lograrlo, se plantean algunas recomendaciones para futuros desarrollos que a continuacion se mencionan, esperando que su incorporacion fortalezca el rendimiento de este proyecto y facilite su comercializacion, 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 ademas caracterlsticas de encriptacion 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 area geografica especifica.
- Mostrar en la App de escritorio la potencia de las senales entre cada conexion de RF, es decir, la conexion Nodo - Gateway.
- Implementar un “Data logger” (Registro de datos) en la App de escritorio para facilitar la solucion 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 conexion y transmision 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 aplicacion, generalmente ofrece una memoria RAM superior, en el orden de los Megabytes (MB).
- Desarrollar una Aplicacion (App) movil para expandir el acceso de los datos publicados en Internet por el PCB.

Finalmente, se puede desarrollar un PCB cuyo hardware y firmware sea mas robusto, lo que permitirla una mayor utilidad y representarla una solucion IoT potencial para su comercializacion y certificacion.

REFERENCIAS

[1] J. Balcell y J. Romeral. Automatas 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 Estandar. 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 D21 E/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] .

[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. Guadron y J. Guevara, “Implementacion de Bootloaders en Microcontroladores PIC16 y PIC 18 de Microchip Inc.” Escuela Especializada en Ingenieria ITCA-FEPADE. El Salvador. Revista Tecnologica, Vol. 7, No 1, 2014. [Online] . Disponible: http://www.redicces.org.sv/ispui/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) 20092016 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://myarduinoproiects.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] .

[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/hemoiaaeigabkbcookmlgmdigohiobim. [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]

APENDICES

Apendice A

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

Apendice B

En este apendice se muestra la caratula y el indice del manual de usuario del PCB realizado.

Apendice C

En este apendice se muestra un folleto ilustrativo del Proyecto y sus aplicaciones en la industria, como elemento orientado a la comercializacion del producto.

APENDICE A

Abbildung in dieser Leseprobe nicht enthalten

A1. Vista de la capa superior del PCB.

Abbildung in dieser Leseprobe nicht enthalten

A2. Vista de la capa inferior del PCB.

Abbildung in dieser Leseprobe nicht enthalten

A3. Vista de las perforaciones respectivas del PCB.

APENDICE B

Abbildung in dieser Leseprobe nicht enthalten

APENDICE C

Abbildung in dieser Leseprobe nicht enthalten

¹ La nube de Internet es un nuevo modelo de uso de los equipos informaticos. Traslada y almacena parte de archivos y programas a un conjunto de servidores a los que puedes acceder a traves de Internet.

² Half-duplex (Semi-duplex): transmision en ambas direcciones, solo una direccion a la vez. Transmisor y receptor comparten una sola frecuencia.

³ Full duplex (Duplex): transmision en ambas direcciones, simultaneamente por el mismo canal. Dos frecuencias una para transmitir y otra para recibir.

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

⁵ Prosoft Technology 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.

Excerpt out of 103 pages - scroll top

Details

Title: 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
College: Simon Bolivar University
Author: Pablo Velasquez (Author)
Publication Year: 2018
Pages: 103
Catalog Number: V418755
ISBN (eBook): 9783668685659
ISBN (Book): 9783668685666
Language: Spanish; Castilian
Tags: Adquisición de datos PCB Microcontrolador ModBus Sensores Señales industriales IoT la Nube

Quote paper: Pablo Velasquez (Author), 2018, 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, Munich, GRIN Verlag, https://www.grin.com/document/418755

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

Excerpt

INDICE GENERAL

RESUMEN

DEDICATORIA

ÍNDICE DE TABLAS

ÍNDICE DE FIGURAS

LISTA DE SÍMBOLOS

LISTA DE ABREVIATURAS

INTRODUCTION

CAPITULO 1

1.1. Generalidades

1.2. Mision

1.3. Vision

1.4. Productos, Soluciones, Proyectos y Servicios

CAPITULO 2

2.1. Internet de las cosas (IoT)

2.1.1. Description General

2.1.2. Modelos de Comunicacion del IoT y sus aplicaciones

2.1.3. Desafios y barreras para el IoT

2.2. Protocolo de Comunicacion Industrial ModBus

2.2.1. Las transacciones en ModBus

2.2.2. Modos de transmision en Serie

2.2.2.I. Modo de transmision RTU

2.2.3. Modo de transmision TCP/IP

2.2.4. El ciclo Solicitud/Respuesta

2.2.4.1. Campo de direccion

2.2.4.2. Campo de codigos de funcion

2.2.5. Funciones de datos y control ModBus

2.2.5.1 Codigos de funcion de acceso de datos

2.2.5.2 Codigos de funcion de diagnostico

2.2.5.3 Otras Funciones

2.3. Protocolo de Comunicacion Web MQTT

2.4. Descripcion General del Sistema a Monitorear

2.4.1 Sensores

2.4.2 Red de Datos

2.5 Software SCADA

2.6. PLC

2.7. Microcontroladores Atmel

2.8. Programacion de MCU con Arduino IDE

2.9. Aplicacion (App) de escritorio en Windows

2.9.1. Visual Studio IDE

2.9.2. Framework.NET

CAPITULO 3

3.1 El MCU Atmel SAMD21G18

3.2 Pruebas experimentales

3.2.1 Modulo Ethernet (Circuito integrado WIZnet W5500)

3.2.2 Circuito para Comunicacion Serial (Transceptor EXAR SP330E)

3.2.3 Circuito de acondicionamiento para entradas Analogicas y Digitales Industriales

3.2.3.1 El Amplificador Operacional MCP6004

3.2.3.2 El Optoacoplador TLP293-4

3.2.4 Modulo RTC PCF8523

3.2.5 Memoria EEPROM 24AA025E48

3.2.6 Memoria EEPROM 24AA64

3.3 Diseno del PCB en Eagle CAD

3.3.1 Seleccion del encapsulado

3.3.2 Diagrama electronico del PCB

3.3.3 Layout del PCB

3.4 Ensamblaje del PCB

3.5 Firmware del PCB

CAPITULO 4

4.1 Descripcion del Funcionamiento de la App de escritorio

4.2 Programacion de la App de escritorio

CAPITULO 5

5.1 Bootloader del microcontrolador (MCU)

5.2 Modulo Ethernet

5.3. Entradas Analogicas

5.4 Entradas Digitales

5.5 Modulo RTC

5.6 Memorias EEPROM

5.7 Modulo de Comunicacion Serial

5.8 Comunicacion App - PCB

5.9 Comunicacion ModBus

5.10 Comunicacion MQTT

5.11 Consumo de potencia del PCB

5.12 Modulo de Radio Frecuencia (RF) para futuras aplicaciones

REFERENCIAS

Details