UNIVERSIDAD DE BUENOS AIRES FACULTAD DE INGENIERÍA …laboratorios.fi.uba.ar/lse/tesis/LSE-FIUBA-Trabajo-Final-CESE-Mariano-Mondani-2016...En los últimos meses, la cuestión del

UNIVERSIDAD DE BUENOS AIRES

FACULTAD DE INGENIERÍA

CARRERA DE ESPECIALIZACIÓN EN SISTEMAS

EMBEBIDOS

MEMORIA DEL TRABAJO FINAL

Diseño y construcción de un Smart Plug

Autor:Ing. Mariano Mondani

Director:Ing. Juan Manuel Cruz (FIUBA, UTN-FRBA)

Jurados:Ing. Federico Giordano Zacchigna (FIUBA)

Ing. Gustavo Alessandrini (INTI)Esp. Ing. Ramiro Alonso (FIUBA)

Este trabajo fue realizado en las Ciudad Autónoma de Buenos Aires, entre enerode 2016 y diciembre de 2016.

III

Resumen

La presente memoria describe el diseño de un controlador inteligente dedispositivos eléctricos que puede ser conectado a cualquier tomacorriente, paracontrolar y conocer el consumo eléctrico desde su teléfono móvil. Se realizó conel objetivo de incorporar un innovador equipo de fabricación nacional a la línea

de productos de domótica ofrecidos por la empresa X-28 Alarmas.

La motivación para diseñar el producto surgió de la creciente preocupaciónrelacionada con el consumo eléctrico y sus costos en constante aumento.

El proyecto abarcó la planificación, el desarrollo del hardware encargado decontrolar y medir el consumo eléctrico y el diseño y la programación del

firmware embebido y de la aplicación para dispositivos móviles destinada a queuna persona pueda gestionar sus equipos eléctricos a través de la red WiFi

disponible en su hogar.

V

Agradecimientos

A Juan Manuel Cruz, director del trabajo, que dedicó su tiempo a ayudarme ya los profesores de la carrera de Especialización en Sistemas Embebidos que meacompañaron en esta formación profesional.

VII

Índice general

Resumen III

1. Introducción General 11.1. Motivación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2. Soluciones comerciales existentes . . . . . . . . . . . . . . . . . . . . 21.3. Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2. Introducción Específica 72.1. Esquema general del sistema . . . . . . . . . . . . . . . . . . . . . . 72.2. Requerimientos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92.3. Planificación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

3. Diseño e Implementación 133.1. Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

3.1.1. Esquemático general . . . . . . . . . . . . . . . . . . . . . . . 143.1.2. Descripción de los módulos de hardware . . . . . . . . . . . 15

3.1.2.1. Fuente de alimentación . . . . . . . . . . . . . . . . 163.1.2.2. Adaptación de las señales de tensión y corriente . 163.1.2.3. Front-end analógico . . . . . . . . . . . . . . . . . . 173.1.2.4. Control de la carga . . . . . . . . . . . . . . . . . . . 183.1.2.5. Módulo WiFi . . . . . . . . . . . . . . . . . . . . . . 19

3.2. Firmware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193.2.1. Arquitectura del firmware . . . . . . . . . . . . . . . . . . . . 193.2.2. Capas de abstracción . . . . . . . . . . . . . . . . . . . . . . . 223.2.3. Metodología orientada a objetos . . . . . . . . . . . . . . . . 233.2.4. Protocolo de comunicación . . . . . . . . . . . . . . . . . . . 273.2.5. Uso de los comandos . . . . . . . . . . . . . . . . . . . . . . . 28

3.3. Aplicación Android . . . . . . . . . . . . . . . . . . . . . . . . . . . . 313.3.1. Maqueta de la aplicación . . . . . . . . . . . . . . . . . . . . 313.3.2. Arquitectura de la aplicación . . . . . . . . . . . . . . . . . . 36

4. Ensayos y Resultados 434.1. Ensayos de caja negra . . . . . . . . . . . . . . . . . . . . . . . . . . . 434.2. Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 434.3. Firmware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 454.4. Aplicación móvil . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

5. Conclusiones 495.1. Conclusiones generales . . . . . . . . . . . . . . . . . . . . . . . . . . 495.2. Trabajo futuro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

Bibliografía 53

IX

Índice de figuras

1.1. Evolución del costo de la energía eléctrica en la Ciudad Autónomade Buenos Aires. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.2. Smart Plug DSP-W215 de la empresa D-LINK . . . . . . . . . . . . . 31.3. Smart Plug HS110 de la empresa TP-LINK . . . . . . . . . . . . . . 4

2.1. Esquema general del sistema propuesto en este proyecto, compues-to por un Smart Plug y la aplicación móvil. . . . . . . . . . . . . . . 7

2.2. Diagrama de Gantt de la planificación del proyecto. . . . . . . . . . 12

3.1. Prototipo funcional del Smart Plug. 1 - Fuente de alimentación. 2 -Adaptación de las señales de línea. 3 - Control de la carga. 4 - Mó-dulo WiFi. 5 - Microcontrolador, led bicolor, pulsador y memoriaEEPROM. 6 - Conexión a la línea eléctrica. 7 - Conexión a la carga. . 14

3.2. Diagrama en bloques del hardware del prototipo funcional. . . . . 153.3. Esquemático de la fuente de alimentación. . . . . . . . . . . . . . . . 163.4. Esquemático de la etapa de adaptación de las señales de tensión y

corriente de la línea eléctrica. . . . . . . . . . . . . . . . . . . . . . . 173.5. Esquemático del front-end analógico encargado de medir los pará-

metros eléctricos. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183.6. Esquemático del control de la carga eléctrica mediante un relay me-

cánico. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193.7. Esquema de las tareas y recursos utilizados en el firmware. . . . . . 203.8. Capas del firmware. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233.9. Diagrama de clases de los controladores desarrollados para el firm-

ware. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243.10. Creación de interfaces y objetos en C. . . . . . . . . . . . . . . . . . 243.11. Formato de la trama del protocolo desarrollado para comunicar la

aplicación móvil con los Smart Plugs. . . . . . . . . . . . . . . . . . 273.12. Diagrama de comunicación del comando GET. . . . . . . . . . . . . 283.13. Diagrama de comunicación del comando SET. . . . . . . . . . . . . 293.14. Diagrama de comunicación del comando RESET. . . . . . . . . . . . 303.15. Diagrama de comunicación de los comandos NODE ON y NODE

OFF. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 313.16. Maqueta de la aplicación móvil. . . . . . . . . . . . . . . . . . . . . . 323.17. Detalle de la maqueta, pantallas 1, 2 y 3. . . . . . . . . . . . . . . . . 333.18. Detalle de la maqueta, pantallas 5, 6 y 7. . . . . . . . . . . . . . . . . 343.19. Detalle de la maqueta, pantallas 8 y 9. . . . . . . . . . . . . . . . . . 353.20. Detalle de la maqueta, pantallas 10, 11 y 12. . . . . . . . . . . . . . . 363.21. Relación entre las clases desarrolladas para la aplicación móvil. . . 413.22. Tablas que componen la base de datos de la aplicación. . . . . . . . 42

4.1. Error relativo en el canal de tensión. . . . . . . . . . . . . . . . . . . 444.2. Error relativo en el canal de corriente. . . . . . . . . . . . . . . . . . 44

X

4.3. Mensajes UDP periódicos recibidos de un Smart Plug, utilizadospara identificarlo dentro de la red WiFi. . . . . . . . . . . . . . . . . 46

4.4. Captura del software desarrollado que permite generar todos loscomandos propuestos en el protocolo de comunicación. . . . . . . . 47

4.5. Capturas de la aplicación móvil resultantes de la prueba de funcio-namiento general del Smart Plug. . . . . . . . . . . . . . . . . . . . . 48

XI

Índice de Tablas

3.1. Señalizaciones del Smart Plug . . . . . . . . . . . . . . . . . . . . . . 223.2. Comandos disponibles en el protocolo . . . . . . . . . . . . . . . . . 283.3. Resumen de los registros disponibles en el protocolo . . . . . . . . . 29

1

Capítulo 1

Introducción General

En este capítulo se presenta la motivación que impulsó el desarrollo del equipoy una breve reseña de algunos productos comerciales similares al sistema imple-mentado.

1.1. Motivación

El proyecto surgió de la necesidad de desarrollar un producto que no solo permi-tiera automatizar el encendido y apagado de una carga eléctrica, sino que tambiénbrindara información acerca del consumo de la misma.

En los últimos años, uno de los principales intereses de los consumidores a nivelmundial es el de la domótica, entendiéndose por esta al conjunto de sistemas yequipos que permiten automatizar una casa, abarcando la seguridad, el confort yla gestión energética. Es en este último aspecto en el cual se encuadra el presentetrabajo.

Uno de las funcionalidades más básicas que se pretende esté presente en un siste-ma de domótica consiste en el control de un aparato eléctrico. Esto incluye tantoel encendido y apagado del mismo como la posibilidad de poder programar ho-rarios específicos de funcionamiento.

Sumado al mero deseo de poder controlar un dispositivo eléctrico de forma sen-cilla, se encuentra el hecho de que los usuarios tienen una mayor conscienciaacerca de la importancia de tener un consumo eléctrico responsable. En nuestropaís uno de los principales impulsores de esta concientización son los crecientescostos asociados a la energía eléctrica.

En los últimos meses, la cuestión del costo del servicio eléctrico ha sido uno de losprincipales temas de debate. En la Figura 1.1 puede verse la evolución del costodel kWh (kilowatt hora) en la Ciudad Autónoma de Buenos Aires, desde el año1993 hasta el presente.

La preocupación de los consumidores se ve justificada en el hecho de que durantelos primeros meses del año 2016 se produjo un aumento brusco en la tarifa, hechoque no ocurría desde hacía más de diez años. Y es en este contexto que se con-sideró importante desarrollar un producto que le permita al usuario conocer deuna forma práctica y fácil la información del consumo de los aparatos eléctricosque utiliza cotidianamente.

Es importante destacar, que en la mayoría de los casos, la única información queposee el consumidor acerca de su consumo es la cantidad de energía consumida

2 Capítulo 1. Introducción General

FIGURA 1.1: Evolución del costo de la energía eléctrica en la Ciu-dad Autónoma de Buenos Aires.

en un mes o en un bimestre por toda su instalación eléctrica. Contando con esteúnico dato, es difícil poder tomar decisiones que modifiquen la forma de consu-mir energía eléctrica de las personas. El equipo propuesto en este trabajo buscóofrecer una mayor información de cada dispositivo eléctrico al que se lo conecte.De esta forma, el usuario puede conocer en tiempo real las características de suconsumo.

Contando con información más detallada, el usuario puede:

Identificar consumos de energía desconocidos.

Ajustar los horarios de funcionamiento del aparato eléctrico, adecuándolosa los momentos del día en el que realmente son necesarios.

Estimar el costo de la energía consumida por cada aparato eléctrico.

Otro impulsor del proyecto fue que la disponibilidad local de equipos de auto-matización con estas características es extremadamente baja. Las soluciones quese comentan en la Sección 1.2 pueden ser compradas a través de Internet, pero node una forma sencilla en los comercios nacionales. Esta situación hace propicio elofrecer una alternativa de fabricación nacional que pueda ser adquirida junto conotros productos que conformen una solución más completa de domótica.

1.2. Soluciones comerciales existentes

Actualmente, varias empresas a nivel mundial ofrecen productos para la auto-matización de cargas eléctricas. Comúnmente se denomina a estos equipos SmartPlugs y consisten básicamente en un equipo que se conecta al tomacorriente y alcual se conecta el aparato eléctrico que se quiere controlar. De esta forma, el SmartPlug permite:

Encender y apagar la carga.

1.2. Soluciones comerciales existentes 3

Conocer los parámetros eléctricos de la carga: tensión, corriente, factor depotencia, potencia activa, etc.

Informar la energía consumida por el aparato.

Programar horarios de encendido y apagado.

Monitorear la temperatura del equipo.

No todos los equipos comerciales cumplen con todas estas funcionalidades simul-táneamente. Sin embargo, un punto común a todos los Smart Plugs comercialeses que ofrecen algún tipo de aplicación móvil para poder gestionar los Plugs. Esteaspecto es uno de los más importante en el diseño de un producto de estas carac-terísticas ya que la información que proveen los Smart Plugs debe ser mostradaal usuario de forma sencilla y útil para que pueda ser aprovechada.

Otra característica común es que muchos de los equipos son fabricados por em-presas dedicadas a comercializar productos para redes de computadoras. De estaforma, se tienen algunos ejemplos como WeMo de la empresa Belkin, DSP-W215de D-Link y HS110 de TP-Link. En esta sección se describirán brevemente estosdos últimos equipos.

D-Link - DSP-W21. Este dispositivo, desarrollado por D-Link, puede verseen la Figura 1.2. Las principales funciones que ofrece son: encendido/a-pagado de la carga tanto a través de la aplicación móvil como de un in-terruptor en el propio equipo, conexión a la red WiFi a través de WPS 1,programación horaria del encendido/apagado y registro del consumo.

FIGURA 1.2: Smart Plug DSP-W215 de la empresa D-LINK

La aplicación (disponible para dispositivos con sistema operativo Androidy iOS) le permite al usuario controlar la carga desde la misma red WiFi enla que se encuentran los Smart Plugs y desde la red móvil. Esta aplicacióntambién permite controlar otros productos de la línea mydlink como puedenser cámaras y detectores de movimiento.

1WiFi Protected Setup. Es un conjunto de mecanismos que buscan facilitar la incorporación deun equipo a una red WiFi. Generalmente, para iniciar el proceso de WPS se debe presionar un botónen el producto que se desea incorporar a la red y se debe presionar el botón de WPS en el routerWiFi. Una vez hecho esto el dispositivo se incorporará a la red.

4 Capítulo 1. Introducción General

A diferencia de otros Smart Plugs, el gabinete es considerablemente grande(96 x 62 x 45 mm) lo cual es resaltado como un punto negativo en las reseñasde este producto.

Al momento de escribir esta memoria, el precio del producto era de 50 dó-lares en Estados Unidos y no estaba disponible para ser adquirido en loscomercios argentinos. Además, entre los tipos de enchufes disponibles paraconectar la carga no se encuentra el usado en Argentina.

TP-Link - HS110. Al igual que el anterior Smart Plug, el HS110 permitecontrolar una carga desde una aplicación móvil (disponible en Android y eniOS), pudiendo visualizar el tiempo total de encendido del dispositivo y laenergía consumida tanto actual como en las semanas previas. Este productoofrece un gabinete más reducido que el Smart Plug de D-Link (66 x 77 x 100mm). Puede verse una fotografía del mismo en la Figura 1.3.

FIGURA 1.3: Smart Plug HS110 de la empresa TP-LINK

Como diferencias con el producto de D-Link, se pueden mencionar que ca-da Smart Plug puede ser configurado para que se encienda y se apague deforma aleatoria para simular la presencia de una persona en el hogar. Tam-bién es compatible con Amazon Echo, un producto que permite controlardispositivos mediante comandos de voz.

El precio en Estados Unidos es cercano a los 40 dólares y al igual que elSmart Plug de D-Link no es vendido localmente.

1.3. Objetivos

Este proyecto se llevó a cabo con el objetivo de incorporar un nuevo producto a lalínea de domótica ofrecida por la empresa X-28 Alarmas. Actualmente la empre-sa ofrece una variedad de equipos que incluye: luces de emergencia, actuadoreseléctricos para la automatización de cargas, llaves táctiles que permiten coman-dar los actuadores, dimmers, etc.

Dentro de esta gama de productos se buscó agregar un equipo que le permitieraal usuario final poder utilizar su teléfono móvil para poder comandar un dispo-sitivo eléctrico. Y no solo eso, sino también que le brindara información acerca

1.3. Objetivos 5

del consumo de sus equipos y que esta información fuera presentada de formasencilla y útil.

Por otro lado, se buscó incorporar técnicas de ingeniería de software y de gestiónde proyectos en todas las etapas de desarrollo del producto. Se comenzó con laplanificación y la escritura de los requerimientos que debía cumplir tanto el hard-ware, el firmware y la aplicación móvil. Estos requerimientos fueron abordadostanto desde el punto de vista técnico como del punto de vista funcional y estético.

Una vez acordados los requerimientos, se continuó con el diseño y la implemen-tación de los distintos aspectos del producto. Finalmente se realizaron pruebas decaja negra para validar los requerimientos planteados.

El llevar a cabo estos procesos de forma ordenada y sistemática fue uno de losprincipales objetivos del trabajo, ya que esto representa una forma distinta detrabajar a la que se utilizó para el resto de los proyectos de la empresa.

7

Capítulo 2

Introducción Específica

En este capítulo se presenta una visión general del equipo desarrollado y se mues-tran algunos aspectos de la planificación del proyecto.

2.1. Esquema general del sistema

El producto básicamente debe permitir controlar una carga eléctrica a través decomandos que se le envían desde un teléfono móvil. Un esquema básico del siste-ma puede verse en la Figura 2.1. Dentro del contexto de este trabajo final, se desa-rrolló un prototipo funcional del equipo. Por lo tanto, es un producto que cumpletodas la funciones que va a tener el equipo final, pero que no busca cumplir concaracterísticas mecánicas y estéticas que si van a estar presentes en el productocomercial. Una descripción detallada del hardware desarrollado se encuentra enla Sección 3.1.

FIGURA 2.1: Esquema general del sistema propuesto en este pro-yecto, compuesto por un Smart Plug y la aplicación móvil.

Cuando se adquiere un Smart Plug, lo primero que debe hacerse es incorporarloa la red WiFi del hogar. Se eligió que la comunicación fuera a través de esta red,ya que con el paso de los años cada vez es más común que en las casas esté dispo-nible este servicio, debido a que muchos otros dispositivos electrónicos necesitande una conexión a Internet.

8 Capítulo 2. Introducción Específica

Para agregar el Smart Plug a la red, se puede proceder de dos formas: WPS oconfigurando la red en el Smart Plug. En el primer caso, el proceso es sumamentesencillo: simplemente se debe presionar el pulsador que se encuentra en la placadel Smart Plug (el led verde comenzará a destellar) y luego presionar el pulsadorde WPS que se encuentra en el router WiFi. Una vez hecho esto, el Smart Plug seincorpora a la red.

Sin embargo, muchos routers hogareños no cuentan con la funcionalidad de WPS,por lo que existe otra forma de configurar la red WiFi. Esta consiste en estableceral Smart Plug como un punto de acceso temporario. Para esto se debe mantenerpresionado el pulsador en la placa del Smart Plug durante 5 segundos. Cuandoel led verde comienza a destellar, indica que el punto de acceso fue creado. Luegode esto se debe conectar un dispositivo móvil a la red WiFi creada por el SmartPlug. Una vez conectado, mediante un browser se debe entrar a la página de con-figuración de la red WiFi (http://config) y cargar los parámetros de la red a la quese desea conectar el Smart Plug: SSID de la red, tipo de seguridad y clave.

Cuando el Smart Plug se encuentra conectado a la red WiFi ya puede comenzara ser comandado mediante la aplicación móvil. El único requerimiento para queel sistema funcione es que tanto los Smart Plugs como el teléfono en el que estála aplicación se encuentren en la misma red WiFi. En el alcance de este trabajo noestaba contemplado el desarrollo de la infraestructura para poder comandar losPlugs desde fuera del hogar.

La aplicación lista todos los Plugs que encuentra en la red WiFi y permite: encen-der/apagar la carga, conocer algunos parámetros eléctricos (tensión corriente,potencia y energía), configurar horarios de encendido y apagado, visualizar me-diciones históricas de potencia y energía. La cantidad de Smart Plugs que puedegestionar la aplicación no está limitada, por lo que se pueden controlar numero-sos dispositivos eléctricos dentro de una casa.

Además de poder enviar comandos a los Smart Plugs cuando el usuario lo requie-re, la aplicación inicia un servicio en Android que se encarga de realizar consul-tas periódicamente a todos los Smart Plugs que tiene registrados, aun cuando laaplicación se encuentre cerrada. Mediante estas consultas, la aplicación va a po-der conocer: si la carga está encendida o no, las últimas mediciones, los cambiosen las configuraciones del equipo, etc. De esta forma se logra que una aplicaciónmóvil puedan comandar y configurar un Smart Plug y todas las demás que ten-gan registrado a ese mismo Plug se mantengan actualizadas con estos cambios.Una explicación más detallada del funcionamiento y del diseño de la aplicaciónmóvil se encuentra en la Sección 3.3.

Finalmente, la comunicación entre los Smart Plugs y la aplicación móvil se basaen conexiones TCP iniciadas por la aplicación. Sobre TCP se desarrolló un pro-tocolo propio que permite enviar comandos a los Plugs tanto para que realicenacciones como para leer/escribir valores de ciertos registros también definidospor el protocolo diseñado. Este protocolo es explicado en mayor profundidad enla Subsección 3.2.4.

2.2. Requerimientos 9

2.2. Requerimientos

A continuación se enumeran los requerimientos de hardware, firmware y de laaplicación móvil. Inicialmente se habían planteado un número mucho más redu-cido de requerimientos. Así también eran requerimientos que debían ser dividi-dos en otros más acotados para facilitar su validación. Antes de comenzar con eldesarrollo del producto, se establecieron claramente estos requerimientos, para locual fueron importantes los aportes realizados desde las áreas de marketing (encuanto al aspecto estético y funcionalidades deseadas) y de atención al cliente (enbase a comentarios de los clientes referidos a un producto de estas características).

Requerimientos de Hardware

• Req #1.1: El Smart Plug debe poder operar con cargas de 220VAC yhasta 5A.

• Req #1.2: La fuente de alimentación debe generar 5V y 3,3V

• Req #1.3: La fuente de alimentación debe entregar 350mA.

• Req #1.4: El encendido y apagado de la carga se realizará con un relaymecánico de 5V. Se deben usar los contactos común y normal cerrado.

• Req #1.5: La interfaz de programación debe ser accesible mediante unheader de pines.

• Req #1.6: Utilizar un front-end analógico monolítico para realizar elanálisis de los parámetros eléctricos.

• Req #1.7: Conectarse a la red hogareña mediante un módulo WiFi.

• Req #1.8: Debe poseer un pulsador de tipo tact switch. El presionarlopone un nivel lógico alto.

• Req #1.9: Debe poseer un led bicolor verde y rojo. Se encienden inde-pendientemente con un nivel lógico alto.

• Req #1.10: Deberá tener una memoria EEPROM SPI de la línea 25LCde Microchip.

Requerimientos de Firmware

• Req #2.1: Cuando se inicia el modo WPS, el led verde debe destellar auna frecuencia aproximada de 1Hz.

• Req #2.2: Cuando se inicia el modo Soft-AP, el led verde debe destellara una frecuencia aproximada de 2Hz.

• Req #2.3: Cuando se une a una red WiFi, si logra sincronizar la horacon el servidor NTP, el led verde se debe encender.

• Req #2.4: Cuando se une a una red WiFi, si no logra sincronizar la horacon el servidor NTP, el led verde y el rojo deben destellar.

• Req #2.5: Si no se puede unir a una red WiFi, el led rojo debe destellara una frecuencia aproximada de 1Hz.

• Req #2.6: Al presionar el botón de la placa se debe iniciar el proceso deWPS.


• Req #2.7: Al mantener presionado por 5 segundos el botón de la placase debe iniciar el Soft-AP.

• Req #2.8: Si se desconecta el Smart Plug, cuando se lo vuelve a conectarse debe intentar unir a la última red WiFi a la que estuvo unido.

• Req #2.9: Al conectarse a una red WiFi, se debe conectar a un servidorNTP y obtener la fecha y la hora.

• Req #2.10: La fecha y la hora deben ser llevadas por un RTC en el mi-crocontrolador.

• Req #2.11: Debe existir un módulo encargado de registrar la actividaden el equipo. Su salida va a ser una UART configurada a 115200 baud- 8N1.

• Req #2.12: Se deben obtener las siguientes mediciones de la línea: ten-sión eficaz, corriente eficaz, potencia activa, frecuencia, factor de po-tencia y energía.

• Req #2.13: El intervalo entre una muestra y la siguiente de cada medi-ción no debe superar los 10 segundos.

• Req #2.14: Cada hora el Smart Plug debe obtener la potencia activapromedio de esa hora y la energía de esa hora.

• Req #2.15: Cada hora se deben guardar de forma no volátil las medi-ciones de potencia activa y energía correspondientes a esa hora.

• Req #2.16: Se deben guardar de forma no volátil las mediciones de po-tencia activa y energía correspondiente a las 24 horas de los últimos 7días.

• Req #2.17: Cada dispositivo debe tener un ID único de 6 dígitos hexa-decimales cargado durante la prueba de fábrica.

• Req #2.18: Cada dispositivo debe guardar de forma no volátil un nom-bre de hasta 32 caracteres.

• Req #2.19: Debe guardar de forma no volátil los parámetros de calibra-ción del front-end analógico.

• Req #2.20: Debe permitir configurar una hora de encendido y apagadode la carga para cada día de la semana.

• Req #2.21: Cuando llega la hora de encendido configurada para el díacorrespondiente, la carga se debe encender.

• Req #2.22: Cuando llega la hora de apagado configurada para el díacorrespondiente, la carga se debe apagar.

• Req #2.23: Cuando el dispositivo se inicia debe chequear que la EE-PROM esté inicializada. Debe haber un valor “bandera” en la EEPROMque indique si está inicializada.

• Req #2.24: Si la memoria EEPROM no está inicializada se deben cargarlos siguientes valores: nombre - Smart Plug; horarios de encendido yapagado - 0:0.

2.2. Requerimientos 11

• Req #2.25: El Smart Plug debe generar un mensaje UDP periódicamen-te para darse a conocer en la red WiFi. Lo debe enviar a la direcciónbroadcast.

• Req #2.26: En el mensaje periódico se debe indicar número de ID.

• Req #2.27: La comunicación con la App móvil va a ser a través de men-sajes sobre TCP. Se debe respetar el formato de la trama definido en[1].

Requerimientos App móvil

• Req #3.1: Debe identificar los Smart Plugs presenten en la red.

• Req #3.2: Debe permitir encender y apagar cada Smart Plug.

• Req #3.3: Debe mostrar el estado actual de la carga: encendida o apa-gada.

• Req #3.4: Debe mostrar el estado de la comunicación con cada SmartPlug: comunicación OK o con errores.

• Req #3.5: Debe mostrar la hora y la fecha de la última comunicaciónexitosa con cada Smart Plug.

• Req #3.6: Debe permitir configurar el nombre de cada Smart Plug en-contrado.

• Req #3.7: Debe permitir configurar el horario de encendido y apagadode la carga para cada día de la semana.

• Req #3.8: Debe permitir deshabilitar la programación horaria para cadadía de la semana.

• Req #3.9: Debe permitir asignar un ícono a cada Smart Plug.

• Req #3.10: Debe permitir visualizar las mediciones de: tensión eficaz,corriente eficaz, potencia activa y energía acumulada. Para cada SmartPlug.

• Req #3.11: Debe permitir visualizar las mediciones históricas de poten-cia activa y energía de los últimos 20 días mediantes gráficos del tipo“Magnitud vs. hora del día”.

• Req #3.12: Debe permitir borrar las mediciones históricas y la energíaacumulada en los Smart Plugs.

• Req #3.13: Debe permitir volver a valores de fábrica a los Smart Plugs.

• Req #3.14: Debe actualizar de forma periódica (cada 10 minutos) lainformación de cada Smart Plug. La información incluye: nombre deldispositivo, estado de la carga, tensión eficaz, corriente eficaz, potenciaactiva y energía acumulada.

• Req #3.15: Debe actualizar de forma periódica (cada 1 hora) las medi-ciones por hora de la potencia activa y energía de cada Smart Plug.

• Req #3.16: La actualización periódica debe continuar aún cuando laaplicación esté cerrada.


2.3. Planificación

La realización de este proyecto supuso la utilización de herramientas de gestiónde proyectos para organizar su desarrollo. Una de estas herramientas fue la de-finición de las tareas a realizar y el armado de un cronograma. En la Figura 2.2puede observarse el diagrama de Gantt con la tareas llevadas a cabo.

FIGURA 2.2: Diagrama de Gantt de la planificación del proyecto.

Para mayor información acerca de la planificación se puede recurrir al documen-to Planificación del Trabajo Final de Carrera - Mondani Mariano en [9], en donde sepuede encontrar la planificación detallada, incluyendo las tareas y los riesgos quese contemplaron al iniciar el proyecto.

13

Capítulo 3

Diseño e Implementación

En este capítulo se explican los criterios utilizados en el desarrollo del prototipo yse justifican las decisiones de diseño, así como también se describe la implemen-tación.

3.1. Hardware

En el contexto del presente trabajo, se desarrolló un prototipo funcional del pro-ducto final. Este prototipo presenta las mismas funciones que el equipo final perono se ajusta a los lineamientos estéticos y mecánicos que si deberá cumplir en unfuturo. Es por esto que el prototipo diseñado tiene dimensiones mucho más gran-des que las que tendrá, lo cual facilitó las mediciones y pruebas que se debieronrealizar para comprobar el correcto funcionamiento tanto del hardware como delfirmware.

En la Figura 3.1 puede verse una fotografía del prototipo. En la misma se puedeapreciar el PCB diseñado y las dos conexiones principales: a la izquierda del gabi-nete la conexión a la línea eléctrica y a la derecha la conexión a la carga eléctrica.La placa fue colocada dentro de un gabinete que no tiene relación alguna con elgabinete que finalmente se utilizará. Simplemente cumple la función de facilitarla manipulación del prototipo.

Los bloques mencionados en la Figura 3.1 son explicados en las Subsecciones 3.1.1y 3.1.2.

A pesar de ser un prototipo funcional, el hardware se diseño pensando en lascaracterísticas finales que tendrá el producto. Por lo tanto se debieron definir lasespecificaciones deseadas para el equipo:

Tensión máxima de operación: 240VAC

Corriente máxima de operación: 5A

Para una tensión de operación de 220VAC, la máxima potencia que se puede co-nectar es de 1100W. Para un primer producto se buscó cubrir la automatización deaparatos eléctricos de baja potencia como lámparas, ventiladores, electrodomés-ticos pequeños, televisores, etc. El manejo de equipos de mayor potencia comoaires acondicionados, estufas eléctricas, hornos eléctricos, etc, será cubierto en unfuturo cuando se modifique el hardware para soportar una mayor corriente, ge-nerando así un nuevo producto.

14 Capítulo 3. Diseño e Implementación

FIGURA 3.1: Prototipo funcional del Smart Plug. 1 - Fuente de ali-mentación. 2 - Adaptación de las señales de línea. 3 - Control de lacarga. 4 - Módulo WiFi. 5 - Microcontrolador, led bicolor, pulsadory memoria EEPROM. 6 - Conexión a la línea eléctrica. 7 - Conexión

a la carga.

3.1.1. Esquemático general

En la Figura 3.2 pueden verse los principales bloques funcionales del prototipo.

A continuación se describe brévemente cada uno de los módulos. Una explicaciónmás detallada de cada uno se encuentra en la Subsección 3.1.2:

Fuente de alimentación. La alimentación del equipo es obtenida de la mis-ma línea eléctrica a la que está conectado el dispositivo. Debe generar dosniveles de tensión, 5V y 3,3V y debe ser capaz de soportar el consumo espe-cialmente del módulo WiFi.

Adaptación de las señales de corriente y tensión. Este bloque se encarga deadaptar la señal de tensión de la línea y la señal de la corriente consumidapor el aparato eléctrico a los niveles que requiere el front-end analógicoCS5490. La adaptación se realiza mediante transformadores para lograr unacompleta aislación de la línea.

Front-end analógico CS5490. Es el circuito integrado encargado de tomar

3.1. Hardware 15

FIGURA 3.2: Diagrama en bloques del hardware del prototipo fun-cional.

las señales de la línea y generar las mediciones eléctricas de interés: ten-sión eficaz, corriente eficaz, frecuencia de línea, factor de potencia, energíaconsumida, etc.

Control de la carga. La conmutación de la carga se realiza mediante un relaymecánico.

Módulo WiFi RN1723. Es el módulo encargado de la comunicación entre elSmart Plug y la aplicación móvil. Básicamente se encarga de esperar cone-xiones TCP y enviar las respuestas requeridas al socket del que provino elcomando.

Microcontrolador LPC1763. Es el encargado de implementar la lógica delSmart Plug.

Memoria EEPROM. Es la encargada de retener información de configura-ción del Smart Plug y las mediciones diarias de potencia y energía.

Led bicolor. Es un led rojo y verde encargado de realizar las señalizacionesacerca del funcionamiento del equipo. En la Subsección 3.2.1 se describe elsignificado de las distintas señalizaciones.

Pulsador. Mediante el pulsador se inician los procesos destinados a incor-porar el Smart Plug a la red WiFi de la casa.

3.1.2. Descripción de los módulos de hardware

En este apartado de la memoria se describen las decisiones de diseño asociadas alos módulos de hardware. Los fragmentos de esquemático que a continuación semuestran surgen del archivo SmartPlug_v1.0 en [7].


3.1.2.1. Fuente de alimentación

El esquemático de la fuente del Smart Plug puede verse en la Figura 3.3. Estafuente de alimentación se conecta a la misma línea eléctrica que es medida por elfront-end analógico. A partir de la tensión de 220VAC genera una tensión de 5Vy 3,3V. Para lograr los 5V se utiliza una fuente switching con montaje para PCBVSK-S2-5U la cual puede entregar hasta 400mA. Esta fuente permite generar unatensión estable manteniendo un empaquetado de reducido tamaño (34 x 22 x 18mm).

FIGURA 3.3: Esquemático de la fuente de alimentación.

Se debe aclarar que esta fuente switching fue elegida para el prototipo funcional.En la versión final del equipo se utilizará una fuente switching AC-DC de simi-lares características diseñada dentro de la empresa X-28 Alarmas, debido a quetanto el tamaño del empaquetado de la fuente como su costo (U$s 13,25 por uni-dad al momento de escribir la memoria) son prohibitivos para incluir esta fuenteen el diseño final.

En cuanto al regulador de 3,3V se eligió un componente que puede entregar has-ta 500mA. El requerimiento de corriente tanto de la fuente switching como delregulador de 3,3V surge del consumo especialmente del módulo WiFi RN1723, elcual puede requerir hasta 250mA.

3.1.2.2. Adaptación de las señales de tensión y corriente

En la Figura 3.4 puede verse la sección del esquemático relacionada con la adap-tación de las señales de tensión y de corriente del dispositivo. Para poder obtenerlas mediciones eléctricas y el consumo de la carga conectada al Smart Plug es ne-cesario adaptar las señales de tensión de línea y de la corriente consumida por lacarga a los niveles soportados por el front-end analógico.

De acuerdo a la hoja de datos del front-end elegido para este proyecto (CS5490)tanto la señal de corriente como la de tensión no deben superar los 250mV de picoen las entradas diferenciales del circuito integrado. Para lograr esto, primero sedebe definir la tensión y la corriente máxima que debe medir el Smart Plug. Enel caso concreto de este proyecto, y como ya fue mencionado, estos valores son:tensión máxima - 240VAC, corriente máxima - 5A.

Definidos estos valores, se eligió aislar el resto del circuito de la línea eléctricatomando las señales de tensión y corriente mediante transformadores. Al igualque sucedió con la elección de la fuente switching, esta decisión fue exclusiva-mente para el desarrollo del prototipo funcional, ya que en la versión final será

3.1. Hardware 17

FIGURA 3.4: Esquemático de la etapa de adaptación de las señalesde tensión y corriente de la línea eléctrica.

conveniente reemplazar el transformador de tensión por divisores resistivos y eltransformador de corriente por un shunt. Ambos cambios van a permitir reducirel tamaño del producto final y su costo.

Luego de los transformadores hay divisores resistivos dispuestos en forma dife-rencial para reducir la tensión a los valores tolerados por el CS5409. Finalmentehay filtros pasa-bajo con un a frecuencia de corte de 3,3kHz.

Con los valores elegidos de relación de transformación y divisores resistivos, losvalores máximos soportados por el equipo resultan:

Tensión máxima soportada por el hardware: 320VAC.

Corriente máxima soportada por el hardware: 6,5A.

Ambos valores se encuentran por encima de los valores máximos informados alusuario.

3.1.2.3. Front-end analógico

Luego de adaptar las señales de tensión y de corriente, las mismas deben ser me-didas por un front-end analógico que se encargará de generar los parámetros deinterés para la aplicación: tensión y corriente eficaz, frecuencia de línea, potenciaactiva, factor de potencia, energía consumida, etc. En la Figura 3.5 puede verse elcircuito asociado al front-end elegido, el CS5490.

A parte de los componentes relacionados con la adaptación de las señales de lí-nea, este circuito integrado no necesita de una gran cantidad de componentesadicionales, salvo algunos capacitores y un cristal de 4,096Mhz con el cual vagenerar la base de tiempo interna para realizar las mediciones y cálculos.


FIGURA 3.5: Esquemático del front-end analógico encargado demedir los parámetros eléctricos.

La comunicación es sencilla, a través de comandos enviados por una UART. Conestos comandos se van poder conocer casi todas las mediciones que calcula elCS5490. La única medición que no puede ser conocida a través de la lectura deun registro es la energía consumida. Esta es informada mediante pulsos a travésdel pin DO. Para esto se debe configurar la constante del medidor en el CS5490,es decir la cantidad de pulsos a los que equivale un kilowatt-hora.

3.1.2.4. Control de la carga

La conmutación de la carga está a cargo de un relay mecánico. En la Figura 3.6puede verse que la fase de la línea eléctrica se conecta entre los contactos común ynormal cerrado del relay para que, en caso de ocurrir un desperfecto con el SmartPlug, la carga pueda seguir funcionando.

La elección de un relay de este tipo por sobre los de estado sólido, radicó en elmenor costo de los primeros. Por otro lado, la gran mayoría de los smart plugsdisponibles actualmente utilizan relays mecánicos.

Para funcionar, la bobina del relay requiere de una tensión de 5V y los contactossoportan una corriente máxima de 8A con 250VAC, valor que satisface sobrada-mente las especificaciones propuestas para el Smart Plug.

3.2. Firmware 19

FIGURA 3.6: Esquemático del control de la carga eléctrica median-te un relay mecánico.

3.1.2.5. Módulo WiFi

El módulo elegido es el RN1723, el cual prácticamente no requiere de componen-tes adicionales y se comunica con el microcontrolador mediante una UART.

Para la antena del módulo se eligió una antena impresa en el PCB de acuerdo alas especificaciones de la hoja de datos del módulo.

Al momento de comenzar con el proyecto y elegir los componentes, este móduloresultaba una opción atractiva, que proveía las funcionalidades especificadas enlos requerimientos del producto a un precio aceptable. Además se decidió elegireste módulo ya que es comercializado por Microchip, marca que es ampliamenteusada por los productos de X-28 Alarmas, lo cual lleva a la posibilidad de obtenerprecios muy competitivos con los distribuidores.

3.2. Firmware

3.2.1. Arquitectura del firmware

El firmware embebido en el Smart Plug se escribió utilizando FreeOSEK comosistema operativo de tiempo real. De esta forma, en la Figura 3.7 pueden verse lastareas que se crearon y la interacción que hay entre estas.

Básicamente, las características del firmware surgen de los requerimientos enu-merados en la Sección 2.2 y son:

Iniciar el proceso de WPS o configurarse en modo punto de acceso (AP)cuando se presiona el pulsador presente en la placa.

Mostrar el estado del dispositivo a través del led bicolor.

Escuchar las conexiones TCP que provengan de las aplicaciones móviles ygenerar las respuestas adecuadas.

Guardar de forma no volátil (en la memoria EEPROM) la potencia activapromedio y energía consumida de cada hora del día. En la EEPROM seguarda la información de los últimos 7 días.


Sincronizar la hora del Smart Plug con un servidor NTP y gestionar el en-cendido y apagado de la carga de acuerdo a la programación horaria confi-gurada.

MÓDULO WIFI

RELAY

PULSADOR

LEDS

CS5490

EEPROM

RTC

UART DEBUG

taskRTC

taskWiFi

ISR UART2

taskSwitch

taskLeds

taskMeter

ISR UART3

ISR EINT3

moduleLogtaskSmartPlug

20 ms

1,5 s

200 ms

taskTimer

1 ms

10 ms

10 ms

ISR UART1

FIGURA 3.7: Esquema de las tareas y recursos utilizados en el firm-ware.

A continuación se describe cada una de las tareas:

taskSmartPlug. Es la tarea principal del Smart Plug. Implementa la lógicadel dispositivo. Se encarga de recibir los eventos generados por el resto delas tareas y realizar acciones en base a los mismos. Se bloquea esperandoque ocurra alguno de los eventos.

De taskWiFi obtiene los eventos relacionados con la conexión a la red WiFiy las conexiones TCP. Además le indica cuando tiene que iniciar un procesode WPS o configurarse como punto de acceso.

A taskLeds le indica la señalización que debe realizar de acuerdo al even-to recibido. En la Tabla 3.1 puede verse un resumen de todas las posiblesseñalizaciones.

De taskMeter obtiene las últimas mediciones para guardarlas de forma novolátil en la memoria EEPROM e ir generando un registro de potencia activay energía consumida por hora de los últimos 7 días.

Además se encarga de manejar el relay que conmuta la carga eléctrica. Elencendido o apagado de la misma se va a determinar a partir de la pro-gramación horaria (si está configurada) y de los comandos de encendido yapagado que envíe la aplicación móvil.

taskSwitch. Gestiona el pulsador de tipo tact switch que se encuentra en elPCB. Realiza el anti-rebote y genera los eventos cuando es presionado. Va agenerar un evento cuando se suelte el pulsador (lo cual inicia el proceso de

3.2. Firmware 21

WPS en el módulo WiFi) y otro cuando se mantenga presionado por más de5 segundos (lo cual configura al módulo WiFi como un punto de acceso).

Es una tarea que se ejecuta cada 20ms mediante una alarma de FreeOSEK.

taskLeds. Se encarga de realizar las señalizaciones indicadas por otras ta-reas. Las señalizaciones se forman a partir de un led bicolor (rojo y verde),tanto encendiéndolos, apagándolos o haciéndolos destellar a distintas fre-cuencias. Es una tarea periódica que se ejecuta cada 10ms, mediante unaalarma de FreeOSEK, para actualizar los leds.

taskRTC. Se encarga de configurar y acceder al RTC interno del microcon-trolador. Es la tarea que genera los eventos para indicar el paso de un mi-nuto, una hora o un día, los cuales son utilizados por taskSmartPlug pararegistrar las mediciones de potencia activa y energía consumida en cadahora del día.

taskWiFi. Se encarga de recibir las conexiones desde la aplicación móvil.Interacciona con taskMeter para requerir las últimas mediciones de acuerdoa lo solicitado por la aplicación móvil.

También consulta la memoria EEPROM para leer o modificar los paráme-tros de configuración del Smart Plug y para enviarle a la aplicación móvillas mediciones históricas de potencia activa y energía consumida.

Cuando se inicia la tarea, se conecta con un servidor NTP para obtener lafecha y hora. Estos parámetros son enviados a la tarea taskRTC para queconfigure el RTC interno del microcontrolador. En caso de no poder concre-tar la conexión con el servidor NTP, la aplicación móvil le informará la horaactual.

La comunicación con el módulo es a través de una UART y tanto la re-cepción como la transmisión se realizan a través de la interrupción de esteperiférico. La tarea es periódica, cada 10ms, para procesar los mensajes quellegan desde el módulo RN1723 de forma asincrónica.

taskMeter. Se encarga de obtener periódicamente las mediciones del front-end analógico CS5490. Además acumula los pulsos generados por el mismointegrado para llevar un registro de la energía consumida por la carga.

Al iniciar la tarea, se encarga de configurar el CS5490 para que funcione deacuerdo a lo especificado. Este proceso incluye:

• Configurar la constante del medidor. Es la cantidad de pulsos a los queequivale un kilowatt-hora. Para este proyecto se eligió una constantede 5000 pulsos/kWh. Esta constante no es configurada directamenteen el CS5490, sino que se deben escribir algunos registros del integradopara lograr que genere 5000 pulsos por kWh. El proceso para lograresto se explica en la Sección 5.5 de [1].

• Configurar la tensión y corriente máxima de operación, ya que algunasmediciones van a ser calculadas a partir de estos parámetros.

• Cargar los valores de calibración. Para lograr los valores de error rela-tivo en el canal de tensión y de corriente que informa la hoja de datoses necesario realizar un proceso de calibración del equipo. Básicamen-te este proceso consta de dos etapas: calibración de offset de continua


y calibración de ganancia. Para el primero se deben cortocircuitar lasentradas diferenciales del canal de tensión y de corriente y comenzarel proceso. Para la calibración de ganancia, en el caso de la tensión, sedebe generar la tensión máxima que puede medir el Smart Plug y co-menzar el proceso de calibración. Para el caso de la corriente, se puedeusar una corriente menor a la máxima del Smar Plug que debe ser in-dicada al CS5490 antes de comenzar con la calibración. Este proceso seencuentra detalladamente explicado en la Sección 7.1 de [1].

En el contexto del presente trabajo el proceso de calibración no se in-cluyó. Los valores de calibración se calcularon y luego se ajustaronmanualmente para cada equipo. En la Sección 5.2 se propondrá unaposible forma de implementar la etapa de calibración en el proceso defabricación del producto final.

La comunicación con el CS5490 se realiza a través de una UART y tantola recepción como la transmisión se realizan a través de la interrupción deeste periférico. Además se utiliza otra interrupción, encargada de detectarlos pulsos generados por el CS5490 para indicar la energía consumida.

Es una tarea periódica que se ejecuta cada 1,5 segundos mediante una alar-ma de FreeOSEK.

moduleLog. Es la tarea encargada de enviar información de la actividad dela aplicación a través de mensajes por una UART. Otras tareas le envíanmensajes que debe sacar por la UART, incluyendo la fecha y la hora en laque se produjo el mensaje. Esto tuvo una especial importancia al momentode desarrollar el firmware para conocer los eventos que se estaban produ-ciendo. Los mensajes son enviados a una velocidad de 115200 baudios y sedebe conectar un adaptador TTL-USB en la tira de pines destina a la UARTen el PCB (llamada DEBUG en el esquemático).

TABLA 3.1: Señalizaciones del Smart Plug a través del led bicolor.

Señalización Modo AP Modo WPS Autenticado RTC Sincronizado

Verde destella a 2Hz 1 X X XVerde destella a 1Hz 0 1 X XRojo destella a 1Hz 0 0 0 X

Verde y rojo destellan 0 0 1 0Verde encendido 0 0 1 1

3.2.2. Capas de abstracción

Para lograr una mayor abstracción del hardware, se decidió implementar el firm-ware dividiéndolo en capas como se muestra en la Figura 3.8.

A continuación se realiza una breve descripción de cada una de las capas:

Aplicación. Consiste en el firmware propio del equipo, que utiliza al sistemaoperativo para implementar la lógica del Smart Plug.

3.2. Firmware 23

FIGURA 3.8: Capas del firmware.

Sistema operativo. Consiste en las librerías de FreeOSEK. Como se utilizóun microcontrolador LPC1763 se utilizó la implementación de FreeOSEKpara el LPC1769 realizada por Pablo Ridolfi en [11].

Drivers. Dentro de los drivers se encuentran las bibliotecas particulares paracontrolar tanto los periféricos internos del microcontrolador como los dis-positivos externos. La capa de abstracción de hardware, también conocidacomo HAL (por sus siglas en inglés, Hardware Abstraction Layer), buscagenerar un nivel más de abstracción entre los drivers de alto nivel y las bi-bliotecas del fabricante del microcontrolador, lo cual permite, que ante uncambio en el microcontrolador, solamente se deba cambiar la capa HAL.

Para implementar los controladores se utilizó un enfoque orientado a ob-jetos para ordenar las distintas çlases". Una explicación detallada de esteproceso se encuentra en la Subsección 3.2.3.

Bibliotecas del fabricante. Son las bibliotecas provistas por NXP para acce-der a los periféricos internos del microcontrolador.

Hardware. Componentes del Smart Plug.

3.2.3. Metodología orientada a objetos

Para implementar los drivers, tanto de los periféricos internos del microcontrola-dor como de los módulos externos, se decidió utilizar una metodología orientadaa objetos, a pesar de estar programando en C. La forma de estructurar el códi-go surgió a partir de lo explicado por Alex Schreiner en su libro Object-OrientedProgramming With ANSI-C [12].

Mediante esta forma de programar los drivers se lograron implementar los con-ceptos de encapsulamiento, polimorfismo y herencia propios de un lenguaje orien-tado a objetos.

Las clases que se implementaron para este proyecto se pueden ver en el diagramade clases de la Figura 3.9.

La idea general detrás de esta forma para programar módulos de firmware sepuede ver en la Figura 3.10. Todas las clases implementadas en este trabajo parten


cObject

ioDebounce cTimerio25LCxxxioCS5490

cBuffer

cStaticBuffer

cQueue

ioObject

ioGPIO ioRTC

ioInternalRTCioDigital

ioComm

ioUARTioSPIioRN1723

FIGURA 3.9: Diagrama de clases de los controladores desarrolla-dos para el firmware.

de la interfaz cObject. Se la llama interfaz y no clase, ya que su comportamiento essimilar a las interfaces de Java: cObject no implementa la lógica de sus métodos,sino que simplemente declara los prototipos de las funciones (esto se implementamediante punteros a funciones). Las clases que implementen la interfaz cObjectdeberán establecer la algoritmia para cada uno de los métodos contenidos en lainterfaz cObject.

FIGURA 3.10: Creación de interfaces y objetos en C.

Este comportamiento puede verse en la parte superior de la Figura 3.10: objeto1es una clase que implementa la interfaz cObject. Esta interfaz contiene los mé-todos básicos necesarios para cualquier otra clase: un constructor, un destructor,una función para crear una copia de un objeto, una función para determinar si dosobjetos son iguales y una para mostrar el contenido del objeto de forma compren-sible para un humano. Además contiene un campo size el cual indica la cantidadde bytes que ocupa una instancia de la clase en memoria RAM.

Por lo tanto objeto1 debe implementar la lógica de todos los métodos incluidos encObject. Además de implementar la algoritmia, objeto1 puede contener variablesque van a ser propias de cada instancia. En la Figura 3.10, estas variables son

3.2. Firmware 25

var1, var2 y var3. Por otro lado, objeto1 puede declarar funciones que solamentepuedan ser utilizadas sobre instancias de la clase objeto1.

Finalmente ptr1 es un puntero a la instancia de objeto1. El tipo de variable de ptr1es void*, es decir que la implementación de la clase queda totalmente encapsulada,ya que la aplicación que instancie a objeto1 no conocerá su estructura interna.

Con esta metodología también es posible implementar la herencia tanto de in-terfaces como de clases. En la parte inferior de la Figura 3.10 puede verse unejemplo de herencia de interfaces. En este caso, la interfazB hereda a la interfazcObject, agregando 3 métodos a los ya definidos por cObject. Por lo tanto, la claseque implementa la interfazB debe implementar todos los métodos, tanto los defi-nidos por cObject como los de interfazB. En el ejemplo, esta clase es objeto2, la cualademás define 3 variables. Nuevamente ptr2 es un puntero a void el cual apuntaal área de memoria donde fue creada la instancia de objeto2.

Como puede suponerse esta metodología de trabajo requiere además implemen-tar alguna forma de asignación dinámica de memoria. Para este trabajo se decidióimplementar un pool de memoria, el cual contiene una sencilla lógica que permi-te asignar, liberar y unir segmentos continuos (para reducir la fragmentación) delpool de memoria.

Esta librería es una modificación de la descripta en [2], en la que delante de cadasegmento de memoria se coloca un encabezado de dos bytes que indica si estáasignado el bloque de memoria o no y la longitud del bloque. El código fuentede la librería de asignación de memoria puede encontrarse dentro de la carpetamemAlloc en [8].

Se debe aclarar que esta forma de trabajo no contradice la naturaleza estática delRTOS FreeOSEK. Como condición en la implementación del firmware se estable-ció que la creación y destrucción de los objetos únicamente se pudiera hacer enel comienzo de la aplicación. De esta forma, cuando el RTOS se encuentra funcio-nando no se producen más asignaciones dinámicas de memoria y el sistema secomporta como si fuera estático.

En cuanto a las clases desarrolladas se puede mencionar lo siguiente:

ioObject es una interfaz que hereda a cObject y agrega los métodos básicosnecesarios para cualquier periférico de entrada/salida: inicialización, habi-litación/deshabilitación y escritura/lectura.

ioGPIO es una clase que implementa a la interfaz ioObject y que sirve comobase para las clases que describen tipos más específicos de GPIOs, como porejemplo pines digitales a través de la clase ioDigital.

ioDigital es una clase que herada a ioGPIO e implementa la lógica para ma-nejar los GPIO del microcontrolador LPC176x como pines digitales, tantoentradas como salidas.

ioRTC es una interfaz que hereda a ioObject y los métodos básicos necesa-rios para manejar relojes de tiempo real, tanto internos al microcontrolador,como externos: reset del reloj, lectura y escritura de la hora y fecha.

ioInternalRTC es una clase que implementa la interfaz ioRTC y permite con-figurar y consultar el RTC interno del microcontrolador LPC176x.


ioComm es una interfaz que hereda a ioObject y agrega los métodos básicospara las clases que modelen periféricos de comunicación: lectura y escri-tura de cadenas de bytes, determinación de espacio disponible en buffers,habilitación/deshabilitación/consulta de interrupciones.

ioUART es una clase que implementa la interfaz ioComm y que permite ma-nejar las UARTs del microcontrolador LPC176x y las interrupciones relacio-nadas con estos periféricos. Además agrega el manejo de buffers de recep-ción y transmisión. La comunicación se puede implementar tanto de formabloqueante como mediante interrupciones.

ioSPI es una clase que implementa la interfaz ioComm y que permite ma-nejar los SPI del microcontrolador LPC176x. La comunicación es siemprebloqueante.

ioRN1723 es una clase que implementa la interfaz ioComm y que permitemanejar el módulo WiFi RN1723. Implementa la lógica para poder confi-gurar el módulo, iniciar el modo WPS y AP y manejar las conexiones TCP.Esta clase requiere de otras clases para poder funcionar: ioUART para im-plementar la comunicación con el módulo, ioDigital para manejar los pinesde reset y GPIO del módulo, cQueue para implementar los buffers de recep-ción y transmisión, cTimer para determinar eventos de timeout del móduloy de las conexiones TCP.

cBuffer es una interfaz que herada a cObject y agrega los métodos necesariospara las clases que modelen contenedores de datos: agregado y borrado deelementos, consulta de elementos, consulta de espacio libre, limpieza delcontenedor, etc.

cStaticBuffer es una clase que implementa la interfaz cBuffer y que sirve comobase para todas las clases que implementen contenedores de tamaño fijo.

cQueue es una clase que hereda a cStaticBuffer e implementa la lógica de unacola, es decir un contenedor de tipo FIFO (First In First Out, primero entraprimero sale). Puede contener objetos de cualquier cantidad de bytes perodeben ser todos del mismo tipo.

ioCS5490 es una clase que implementa la interfaz cObject que permite mane-jar el front-end analógico CS5490. Implementa la lógica para poder leer/es-cribir registros y contiene las variables necesarias para obtener las medicio-nes eléctricas. Esta clase depende de otras para poder funcionar: ioUARTpara implementar la comunicación con el módulo y ioDigital para los pinesde reset y de pulsos de energía consumida.

io25LCxxx es una clase que implementa la interfaz cObject que permite ma-nejar memorias EEPROM de la línea 25LC fabricadas por Microchip. Unainstancia de esta clase puede ser configurada para escribir/leer/borrar da-tos de memorias de distintas capacidades, desde 32kbit hasta 1Mbit. Estaclase depende de ioSPI para implementar la comunicación con la memoriaexterna.

ioDebounce es una clase que implementa la interfaz cObject y permite ejecu-tar la lógica de un anti-rebote sobre una instancia de la clase ioDigital.

3.2. Firmware 27

ioTimer es una clase que implementa la interfaz cObject y permite implemen-tar timers sencillos y detectar cuando vencen mediante polling. La base detiempo debe ser establecida por el usuario de la clase ioTimer.

El código fuente de todas las interfaces y clases puede encontrarse en la carpetacObject en [8]. Dentro de esta carpeta también puede encontrarse un diagramade clases completo (class_diag_cObject.dia) con los métodos y variables que definecada clase e interfaz.

3.2.4. Protocolo de comunicación

Para poder intercambiar comandos y respuestas entre la aplicación móvil y losSmart Plugs fue necesario implementar un protocolo de comunicación. Este pro-tocolo está por encima de TCP, el cual se usa para establecer la conexión y proveerla de retransmisiones y corrección de errores. La trama del protocolo desarrolladopuede verse en la Figura 3.11.

FIGURA 3.11: Formato de la trama del protocolo desarrollado paracomunicar la aplicación móvil con los Smart Plugs.

Cada trama va a comenzar y a terminar con los caracteres #!, lo cual facilita larecepción. Además están los siguientes campos:

LEN: indica la cantidad de bytes de la trama desde el campo COMANDOhasta los caracteres #! finales incluidos.

COMANDO: es un byte que indica el código del comando que se está en-viando. En la Tabla 3.2 pueden verse todos los posibles valores para estecampo.

REGISTRO: indica el registro que se quiere leer, escribir o reiniciar. Es uncampo opcional, de acuerdo al comando. En la Tabla 3.3 puede verse unresumen de los registros disponibles.

VALOR: indica el valor que se leyó o se quiere escribir en un registro. Estecampo va a variar de acuerdo al registro manipulado. En algunos registros,el campo valor será los 4 bytes de un float, en otros registros será los bytesde una cadena de caracteres, etc. Es responsabilidad del receptor interpretarlos bytes de este campo de acuerdo al registro.

Una característica a destacar es que este protocolo es de lazo cerrado. Para cual-quier comando hay una respuesta que indica que ese comando fue recibido por elSmart Plug. Esta característica es usada por la aplicación móvil, en la cual cuan-do el usuario cambia un valor de configuración del Smart Plug, el cambio no semuestra en la pantalla de la aplicación hasta haber recibido la respuesta del co-mando enviado. De esta forma se asegura que el comando se haya recibido.

La forma en que se implementó el protocolo permite en un futuro agregar nuevoscomandos y registros. Solamente será necesario agregar estos nuevos campos enel firmware del Smart Plug y en la aplicación móvil.


TABLA 3.2: Comandos disponibles en el protocolo.

Comando Descipción Notas

0x01 GET(registro) Pide el valor de un registro0x02 SET(registro, valor) Escribe el valor de un registro0x10 NODE_ON() Enciende la carga manejada por el

Smart Plug0x11 NODE_OFF() Apaga la carga manejada por el

Smart Plug0x20 RESET(registro) Reinicia el valor del registro0x30 RESP_GET(registro, valor) Informa el valor del registro pedido0x31 RESP_SET(registro, valor) Confirma el valor escrito en el re-

gistro0x32 RESP_RESET(registro) Confirma que el valor del registro

fue reiniciado0x33 RESP_NODE_ON() Confirma que la carga fue encendi-

da0x34 RESP_NODE_OFF() Confirma que la carga fue apagada

3.2.5. Uso de los comandos

A continuación se muestran los distintos escenarios que se pueden dar utilizandoel protocolo desarrollado.

En el caso de leer un registro se tiene la secuencia mostrada en la Figura 3.12.En este ejemplo, se quiere obtener el valor (campo COMANDO = 0x01 - GET)del registro de la potencia activa (campo REGISTRO = 0x05). Cuando la tareataskWiFi en el Smart Plug recibe esta petición le pide el valor actual de la potenciaactiva a la tarea taskMeter y devuelve el valor con el comando 0x30 (RESP_GET).

# ! 4 0x01 0x05 # !

APLICACIÓN MÓVIL SMART PLUG

# ! 8 0x30 0x05 # !VALOR

FIGURA 3.12: Diagrama de comunicación del comando GET.

Como se mencionó anteriormente, el campo valor se debe interpretar de distin-ta forma de acuerdo al registro que se quiera leer. En el caso del registro ACTI-VE_POWER (0x05) el campo valor va a contener los 4 bytes del float de la potenciaactiva ordenados en formato Big Endian.

3.2. Firmware 29

TABLA 3.3: Resumen de los registros disponibles en el protocolo.

Comando Descripción Notas

0x01 a 0x08 Registros de mediciones eléc-tricas

Incluye: tensión eficaz, corrienteeficaz, factor de potencia, frecuen-cia, potencia activa, energía totalconsumida, etc.

0x10 DEVICE_ID Nombre del dispositivo. Es el nom-bre que identifica al Smart Plug enla aplicación móvil.

0x15 LOAD_STATE Indica si la carga está encendida oapagada.

0x20 a 022F Registros de programaciónhoraria

Es un conjunto de registros quecontiene la hora de encendido y lade apagado de la carga para cadadía de la semana.

0x30 PER_HOUR_ENERGY Contiene las 24 mediciones de ener-gía consumida por hora de una de-terminada fecha.

0x31 PER_HOUR_ACTIVE_POWER Contiene las 24 mediciones de po-tencia activa promedio por hora deuna determinada fecha.

Cuando se quiere escribir un registro en el Smart Plug, se debe enviar un coman-do SET y el nuevo valor del registro. En la Figura 3.13 puede verse la secuencia.En este ejemplo, la aplicación móvil quiere cambiar el registro de la hora de en-cendido de la carga para los días lunes (REGISTRO = 0x20), con la hora 12:10.


# ! 6 0x02 0x20 # !0x12 0x10

# ! 6 0x31 0x20 # !0x12 0x10

FIGURA 3.13: Diagrama de comunicación del comando SET.

Cuando taskWiFi recibe este comando, escribe el nuevo valor para el registro enla EEPROM, genera la trama de respuesta con el comando RESP_SET (0x31) ydevuelve el valor que fue cargado en el registro. El hecho de devolver el mismovalor que recibió ayuda a la aplicación móvil a actualizar los datos en sus registrosinternos.


En este caso se puede ver que el campo valor se debe interpretar como dos bytes,en el cual el primero indica la hora y el segundo los minutos del encendido de lacarga.

Además de escribir un valor determinado en un registro, el protocolo permiteindicar que se debe reiniciar el valor de un registro. Para lograr esto se debe uti-lizar el comando RESET (0x20) y el registro que se quiere reiniciar. En el ejemplode la Figura 3.14 se puede ver cómo se quiere reiniciar el nombre del dispositivo(campo REGISTRO = 0x10).


# ! 6 0x20 0x10 # !

# ! 6 0x32 0x10 # !

FIGURA 3.14: Diagrama de comunicación del comando RESET.

Cuando la tarea taskWiFi recibe este comando escribe el valor de fábrica asociadoal registro en la EEPROM. Por ejemplo, para el caso del nombre de dispositivo,el valor de fábrica es Smart Plug. Sin embargo, cada registro tiene un valor de fá-brica distinto. Una vez reiniciado el registro, el Smart Plug genera una trama derespuesta con el comando RESP_RESET (0x32) acompañado del registro modifi-cado.

Finalmente existen dos comandos dedicados al control de la carga conectada alSmart Plug. Estos son NODE_ON (0x10) y NODE_OFF (0x11). Mediante estoscomandos, se le indica al Smart Pug que encienda o apague la carga. En la Figura3.15 puede verse la secuencia cuando se envían estos comandos.

La tarea taskWiFi al recibir estos comandos genera un evento y la tarea taskSmart-Plug enciende o apaga la carga a partir del evento recibido. Hecho esto, se de-vuelve una trama con el comando RESP_NODE_ON (0x33) o RESP_NODE_OFF(0x34) para que la aplicación móvil tenga la confirmación de que la carga fueconmutada.

3.3. Aplicación Android 31


# ! 3 0x10 # !

# ! 3 0x33 # !

# ! 3 0x11 # !

# ! 3 0x34 # !

FIGURA 3.15: Diagrama de comunicación de los comandos NODEON y NODE OFF.

3.3. Aplicación Android

3.3.1. Maqueta de la aplicación

Antes de comenzar con el diseño de la lógica de la aplicación, fue necesario de-terminar la forma en la que se iban a presentar los datos al usuario. Para esto serecurrió al uso de una maqueta, en la cual se muestran las pantallas de las queestará compuesta la aplicación y la interacción que hay entre ellas. Cada una delas pantallas presenta el aspecto que realmente debe tener en la aplicación perono describe la forma en que se debe implementar la lógica.

En la Figura 3.16 puede verse la maqueta completa de la aplicación. La líneasrojas muestran la interacción entre las pantallas y las violetas son comentariosque clarifican el funcionamiento de la pantalla.

A continuación se describe brevemente el funcionamiento de la aplicación desdeel punto de vista del usuario:

Pantalla 1 (parte izquierda de la Figura 3.17): la aplicación comienza con unsplash screen, es decir, una pantalla que muestra el logo y el nombre de laaplicación durante unos segundos y luego da paso a la siguiente pantalla.

Pantalla 2 (parte central de la Figura 3.17): luego del splash screen se muestrauna lista con todos los Smart Plugs que se encontraron en la red WiFi. Comose explicará en la Subsección 3.3.2, cada Smart Plug se identifica periódica-mente dentro de la red WiFi. Estos mensajes periódicos son capturados porla aplicación y en el caso de detectar un Smart Plug que no conocía, lo agre-gará en la lista. La forma de identificar unívocamente a cada Smart Plug


FIGURA 3.16: Maqueta de la aplicación móvil.

es mediante un número único que se graba en la EEPROM del equipo du-rante el proceso de fabricación. Este es un número de seis dígitos que esinformado en los mensajes UDP periódicos.

Cada uno de los elementos de la lista representa a un Smart Plug. Se va amostrar el nombre del dispositivo, el estado de la comunicación medianteun tilde verde o una cruz roja y la fecha y hora de la última comunica-ción exitosa que hubo con ese Smart Plug. Además se muestra un íconoque permite identificar de forma sencilla el dispositivo que realmente estácontrolando el Smart Plug.


Sin embargo, el ícono no cumple únicamente una función pictórica: si selo presiona se puede conmutar el estado de la carga. Más aún, la opacidaddel ícono indica el estado actual de la misma: cuando se lo muestra semi-transparente la carga está apagada y cuando se lo muestra sin transparencia,está encendida.

Pantalla 3 (parte derecha de la Figura 3.17): cuando en la pantalla 2 se pre-siona alguno de los Smart Plugs de la lista, la aplicación muestra una vistade detalle del mismo. En esta se volverá a mostrar el ícono asociado al SmartPlug, su nombre, el estado de la comunicación y la fecha y hora de la últimacomunicación exitosa. Pero además de estos datos se indicarán las últimasmediciones recibidas desde el equipo. Estas mediciones incluyen: tensióneficaz, corriente eficaz, potencia activa y energía total consumida. Estos da-tos son actualizados periódicamente, aún cuando la aplicación se encuentrecerrada.

Por otro lado, en esta vista de detalle se encuentra presente, en la esquinainferior derecha de la pantalla, un botón de acción flotante (floating actionbutton) el cual permite acceder a más opciones para gestionar el Smart Plugseleccionado.

FIGURA 3.17: Detalle de la maqueta, pantallas 1, 2 y 3.

Pantalla 4: cuando se presiona el botón de acción flotante se despliega unmenú el cual incluye la siguiente opciones: Configuración, Historial, Actua-lizar, Reiniciar mediciones y Volver a valores de fábrica.

Pantalla 5 (parte izquierda de la Figura 3.18): si se presiona la opción de Vol-ver a valores de fábrica, se le preguntará al usuario si confirma que quiererealizar esta acción. En caso afirmativo se le enviará al Smart Plug el co-mando correspondiente el cual volverá a sus valores de fábrica, los cualesconsisten en:

• Nombre del dispositivo: Smart Plug.

• Programación horaria de encendido/apagado deshabilitada.


• Se reinicia el registro la energía consumida.

• Se eliminan las mediciones históricas de potencia activa y energía con-sumida por hora, tanto en el Smart Plug como en la aplicación.

Pantalla 6 (parte central de la Figura 3.18): si se presiona la opción Reiniciarmediciones, se le preguntará al usuario si confirma que quiere realizar laacción. En caso afirmativo, se enviarán los comandos correspondientes alSmart Plug. Cuando se realiza esta acción se reiniciará el registro de la ener-gía consumida y se eliminarán las mediciones históricas de potencia activay energía consumida por hora.

Se decidió incorporar esta opción para ayudar en los casos en los que, porejemplo, se cambia la carga que está controlando el Smart Plug, por lo quese desea eliminar los registros de la anterior carga ya que podrían llevar aconfusiones en la interpretación de los datos.

Pantalla 7 (parte derecha de la Figura 3.18): cuando se presiona la opciónActualizar, una caja de diálogo le preguntará al usuario si confirma la ac-ción. En caso afirmativo, se forzará el proceso de actualización de los datosdel Smart Plug, es decir, se le pedirán las últimas mediciones, sus paráme-tros de configuración y sus mediciones históricas para actualizar la infor-mación en la aplicación. Este comando es útil cuando se necesita conocerla información actual, por ejemplo, de una medición y no se puede esperarhasta la próxima consulta periódica que realiza la aplicación.


Pantalla 8 (parte izquierda de la Figura 3.19): al presionar la opción Historialse accede a todas las mediciones históricas que se recibieron desde el SmartPlug. Este historial consiste en las mediciones que realizó en cada hora deldía, tanto de la potencia activa promedio como de la energía consumida. Enesta pantalla se podrá elegir el día que se quiere ver y el parámetro que sedesea consultar mediante dos listas de fechas. Se debe aclarar que aunque elSmart Plug retenga las mediciones de los últimos 7 días, la aplicación puederetener hasta 20 días.


Pantalla 9 (parte derecha de la Figura 3.19): cuando se elije una fecha, lapantalla gira para mejorar la visualización de los datos en forma de gráfico.En este gráfico se va a representar la potencia activa por hora (en Watt) vsla hora del día o la energía consumida por hora (en kWh) vs la hora del día.Se puede realizar zoom y desplazarse por el gráfico arrastrando el dedo.

Estos gráficos representan una de las características distintivas de este pro-ducto, ya que permite visualizar de forma sencilla mediciones que puedenser aprovechadas para conocer el consumo de un determinado aparato eléc-trico.

FIGURA 3.19: Detalle de la maqueta, pantallas 8 y 9.

Pantalla 10 (parte izquierda de la Figura 3.20): contiene los parámetros con-figurables del Smart Plug seleccionado. Se accede a esta pantalla presionan-do la opción Configuración en el menú del botón de acción flotante. Losparámetros que se pueden configurar son básicamente tres: el nombre deldispositivo, el ícono del Smart Plug y la programación horaria para cadadía de la semana.

En cuanto al nombre del dispositivo, se puede configurar un nombre dehasta 32 caracteres. Una vez ingresado se debe presionar la flecha que seencuentra a la derecha del control para ingresar el texto. Este nombre que-dará configurado en el Smart Plug, por lo que todas las aplicaciones quetengan registrado a este Plug, verán el nuevo nombre.

Al presionar el ícono del Smart Plug se mostrará la pantalla 11 (parte centralde la Figura 3.20), permitiendo elegir una imagen de una lista de íconos.Una vez que se selecciona uno de estos se vuelve a la pantalla 10. El íconoes una información propia de la aplicación móvil y no queda guardado enel Smart Plug. Por lo tanto, distintas aplicaciones móviles pueden asignaríconos diferentes a un mismo Plug.


Finalmente, la programación horaria puede ser habilitada y deshabilitadapara cada día de la semana individualmente. La transparencia del recuadroque contiene la información de cada día indica si la programación horariaestá habilitada: si el recuadro es semi-transparente, está deshabilitada, perosi no es transparente, está habilitada.

Si se presiona cualquiera de los días se mostrará la pantalla 12 (parte de-recha de la Figura 3.20) invitando a ingresar la hora de encendido de lacarga. Se puede elegir cambiar esta hora o dejar la que estaba ya configu-rada. Una vez configurada la hora de encendido se volverá a mostrar lapantalla 12 para ingresar la hora de apagado; se procede de igual forma queantes. Cuando se ingresan ambas horas se configura el Smart Plug con estosnuevos valores.

Si en cambio de desea deshabilitar esta opción para un día de la semana, sedebe mantener presionado el recuadro del día elegido. Cuando se deshabi-lite la opción, el recuadro se mostrará semi-transparente.


3.3.2. Arquitectura de la aplicación

La estructura general de la aplicación móvil puede verse en la Figura 3.21. Acontinuación se describirán los elementos principales que la componen y la inter-acción que existe entre ellos.

EventBus. La forma que se eligió para comunicar todos los elementos de laaplicación es un bus de eventos. Para esto se utilizó una librería llamadaEventBus, desarrollada por la empresa Green Robot [3]. Esta librería consis-te en un esquema de suscripción a un bus en el que cualquier clase puedepublicar un evento, el cual va a ser recibido por todas las clases que se ha-yan suscrito al mismo. Además, esta librería se encarga de la comunicaciónentre clases que se encuentran en distintos threads.


Los eventos no son más que objetos de java que contienen información deinterés para la clase que los recibe. En el caso concreto de la aplicación, secrearon varios eventos, los cuales pueden verse en la Figura 3.21 represen-tados mediante un número al lado de las flechas que unen las clases al busde eventos común. Estos eventos son:

1. HeartbeatEvent: este evento se genera cada vez que el servidor UDPrecibe un mensaje periódico de uno de los Smart Plugs. Con este men-saje se logra mantener actualizada la información del Smart Plug, es-pecialmente la IP que le fue asignada por el DHCP dentro de la redWiFi.

2. ResponseEvent: contiene la respuesta recibida por el cliente TCP de laaplicación a un comando enviado a un Smart Plug.

3. CommandEvent: contiene los elementos de una trama que se tiene queenviar a un determinado Smart Plug. Cualquier componente de la apli-cación que quiera enviar un mensaje a un Smart Plug debe enviar unainstancia de este evento al EventBus.

4. UpdateSmartPlugEvent: este evento se genera cada vez que se recibenueva información de un Smart Plug. De esta forma, los fragmentosque están suscritos a este evento actualizarán la información mostradasi el Smart Plug que se actualizó coincide con el que se está mostrando.

Por ejemplo cuando se enciende la carga de un Smart Plug desde lalista de Plugs, este evento permite que la transparencia del ícono delPlug cambie al recibir la confirmación de que la carga fue encendida. Sino estuviera este evento el ícono se actualizaría cuando se regenerarala vista del fragmento.

5. AllmessagesSent: se genera cuando el cliente TCP de la aplicación notiene más mensajes que enviar. Se utiliza para que la aplicación libereciertos recursos que retiene mientras se están enviando los mensajes.

6. TcpTimeout: se genera cuando se produce un timeout esperando la res-puesta a un comando, o cuando se produce otro error en la comunica-ción. Cada uno de estos errores y timeouts se van sumando en un con-tador asociado a cada Smart Plug y cuando se superan los 5 eventos,se indica que existe un problema en la comunicación con el Plug.

7. WiFiStateEvent: se genera cada vez que cambia el estado de la cone-xión del teléfono a la red WiFi. Esto le sirve a la aplicación para co-nocer si está conectado a la red WiFi o no. En caso de no estarlo, nose intentan enviar mensajes a los Plugs ya que no se los va a poderalcanzar.

Servicio. Cuando se inicia la aplicación por primera vez, esta inicia una ins-tancia de la clase SmartPlugService que hereda a la clase Service de An-droid. Un servicio permite implementar una parte de la lógica que se debeejecutar por un tiempo prolongado en un thread distinto del thread prin-cipal de la aplicación. Además, como fue configurado en el caso de estaaplicación, este servicio se mantiene ejecutándose aún cuando la aplicaciónse encuentra cerrada.


Dentro del servicio se implementa la lógica para la consulta periódica delos Smart Plugs que identificó la aplicación. Cada 10 minutos, el servicio seejecutará y realizará una serie de consultas a todos los Smart Plugs que co-nozca, preguntando el último valor de las mediciones, algunos parámetrosde configuración para ver si fueron cambiados por otra aplicación y el es-tado de la carga, para ver si fue conmutada por otra aplicación. Además lepreguntará al Smart Plug si pudo obtener la hora para sincronizar su relojinterno; en caso de no estar sincronizado, la aplicación le enviará la horaactual.

Además, cada 1 hora aproximadamente, el servicio le pedirá a todos losSmart Plugs las mediciones históricas del día para conocer los valores depotencia activa y energía consumida de la última hora.

Toda la información que es recibida desde los Smart Plugs es volcada a unabase de datos propia de la aplicación (smartPlug.db) la cual va a ser consul-tada por todos los otros elementos de la aplicación cuando necesiten cono-cer la última información de un Smart Plug. El acceso a la base de datos serealiza a través de la clase SmartPlugProvider.

La ejecución periódica de este servicio se logra configurando una alarmamediante el AlarmManager de Android. Esta alarma se dispara cada 10 mi-nutos. A las 6 veces que se ejecute esta alarma, se considerará que pasó unahora y se harán las consultas correspondientes a los Plugs.

TcpWatcher y TcpClient. Estas clases se ocupan de establecer la comunica-ción TCP con los distintos Smart Plugs. La clase TcpWatcher se suscribe a loseventos de tipo CommandEvent y cada vez que recibe uno lo coloca dentrode una lista, la cual va a ir siendo leída para determinar las tramas que debeenviar. La comunicación propiamente dicha está implementada en la claseTcpClient, la cual gestiona la conexión y los posibles errores que se puedenproducir.

Para armar las tramas de acuerdo a lo establecido por el protocolo desa-rrollado en este trabajo, la clase TcpWatcher utiliza los métodos de la claseSmartPlugCommHelper que se encarga de encapsular los formatos de lastramas de acuerdo al comando y registro que se está manipulando.

Si se recibe una respuesta del Smart Plug, la clase TcpWatcher generará unevento del tipo ResponseEvent. En caso de que se produzca un error, ge-nerará un evento del tipo TcpTimeout. Cuando termine de enviar todos losmensajes que tenía pendientes generará el mensaje AllmessagesSent.

UdpWatcher y UdpServer. Este par de clases se ocupa de escuchar los men-sajes periódicos que son enviados a la dirección de broadcast de la red porparte de los Smart Plugs. Los mensajes periódicos son enviados al puer-to UDP 55555. Cada vez que UdpServer (que es la clase que implementaconcretamente el servidor UDP) recibe un nuevo datagrama UDP, se lo co-munica a la clase UdpWatcher.

La clase UdpWatcher parsea el datagrama con la ayuda de la clase Smart-PlugCommHelper y determina de qué Smart Plug provino. Con esta infor-mación genera un evento del tipo HeartbeatEvent. Dentro del datagramaUDP se encuentra el ID único que identifica a cada Smart Plug, el cual se vaa utilizar dentro de la aplicación para identificar unívocamente a un Plug.


SmartPlugProvider. Es la clase encargada de acceder a la base de datos dela aplicación (smartPlug.db) en donde está contenida la información de losSmart Plugs encontrados. Esta base de datos está compuesta por 4 tablas,las cuales pueden verse en la Figura 3.22. A continuación se da una brevedescripción de cada tabla:

• StaticInfo. Contiene la información básica del Smart Plug: su nombre yel ícono que tiene asociado. Todas las entradas de las tablas van a estarasociadas al número de ID único del Smart Plug el cual es recibido encada mensaje UDP que envía el Plug.

• OnOffTimes. Contiene los horarios de encendido y apagado para cadadía de la semana así como también una variable que indica qué díasestán habilitados.

• Measurements. Contiene las mediciones históricas recibidas desde ca-da Smart Plug. En cada entrada de la tabla se guarda la fecha a la quecorresponden las mediciones y las 24 mediciones de ese día, al igualque el tipo de medición (potencia activa o energía consumida).

• InstantaneousInfo. Contiene información variable de cada Smart Plug.Es información incluye: la última IP en la que se encontró al SmartPlug, la última fecha y hora de comunicación, el estado de la carga,las últimas mediciones instantáneas, la cantidad de timeouts que seprodujeron en la comunicación y el estado de la comunicación.

Toda clase que desee acceder a la base de datos, debe hacerlo a través de laclase SmartPlugProvider ya que implementa toda la lógica relacionada conla manipulación de la base de datos.

WiFiStateChangeReceiver. Es una clase que extiende a BroadcastReceiver yse encarga de recibir los intents de Android relacionados con los cambiosen la conectividad. De esta forma determina si el teléfono se encuentra co-nectado a la red WiFi o no. En caso de no estar conectado los mensajes a losSmart Plugs no se envían.

La lógica asociada a cada una de las pantallas mostradas en la maqueta en la Sub-sección 3.3.1 se implementaron mediante fragments, para flexibilizar el diseño dela interfaz gráfica. La relación entre las pantallas de la Figura 3.16 y los nombresde los fragmentos es la siguiente:

1. Pantalla 1: SplashScreenFragment.

2. Pantalla 2: SmartPlugListFragment.

3. Pantalla 3: SmartPlugDetailsFragment.

4. Pantalla 4: SmartPlugDetailsFragment.

5. Pantalla 5: AskingDialog.



8. Pantalla 8: HistorySelectionFragment.

9. Pantalla 9: HistoryPlotFragment.


10. Pantalla 10: ConfigurationFragment.

11. Pantalla 11: IconPickerFragment.

12. Pantalla 12: TimePickerDialog.

La lógica de alto nivel que implementa cada fragment fue explicada en la Subsec-ción 3.3.1. El código fuente de la aplicación puede encontrarse en [4].


SmartPlugListFragment

Fragment

SmartPlugDetailsFragment

Fragment

AskingDialog

DialogFragment

HistorySelectionFragment

Fragment

ConfigurationFragment

Fragment

SmartPlugProvider

Singleton

SmartPlugService

Service

UdpServer

Class

TcpClient

Class

SmartPlugCommHelper

Class

SmartPlugDb

SQLite

EventBus

(1) HeartbeatEvent

(3) CommandEvent(7)

(2) ResponseEvent(5) AllmessagesSent(6) TcpTimeout

(1)(2)(5)(6)(7)

(4) UpdateSmartPlugEvent

(3)

(3) (3)

Service

SmartPlugCommHelper

Class

TcpWatcher

Class

UdpWatcher

Class

(4)

(4)

TimePickerDialog

DialogFragment

IconPickerFragment

Fragment

HistoryPlotFragment

Fragment

WifiStateChangeReceiver

BroadcastReceiver

(7) WiFiStateEvent

FIGURA 3.21: Relación entre las clases desarrolladas para la apli-cación móvil.


FIGURA 3.22: Tablas que componen la base de datos de la aplica-ción.

43

Capítulo 4

Ensayos y Resultados

En este capítulo se describen las pruebas realizadas sobre el prototipo y se expli-can los resultados obtenidos.

4.1. Ensayos de caja negra

Al finalizar la implementación de cada uno de los aspectos del producto, hard-ware, firmware y aplicación móvil, se procedió a validar los requerimientos esta-blecidos durante la planificación. Para esto se escribió una serie de pruebas quebuscaron cubrir todos los requerimientos y se las llevó a cabo, registrando el pro-cedimiento y los resultados. Las pruebas se realizaron al terminar cada una de lasetapas.

Todas las pruebas que se llevaron a cabo, especialmente las aplicadas al firmwarey a la aplicación móvil, fueron del tipo ”caja negra”, es decir, fueron pruebas quebuscaban comprobar que ante ciertas entradas las salidas fueran las esperadas,dejando de lado la implementación interna.

El realizar pruebas sistemáticas para comprobar los requerimientos de un pro-ducto desarrollado, representó una nueva forma de trabajo dentro de la empresa.Esto fue la causa de que se eligieran implementar pruebas de caja negra, comoun primer paso en el proceso de incorporar pruebas unitarias, de integración, desistema, etc, en los próximos proyectos que se lleven a cabo.

4.2. Hardware

El registro completo de pruebas puede encontrarse en el documento Smart PlugHardware - Documento de pruebas en [7]. A continuación se describen algunas prue-bas significativas y se muestran sus resultados.

Al diseñar el Smart Plug se debió establecer la tensión y la corriente máxima demedición para el medidor eléctrico. Como fue explicado, estos valores se fijaronen 240VAC y 5A. por lo tanto, fue necesario validar que el hardware diseñadofuera capaz de medir estos valores.

El límite en la medición tanto de la corriente como de la tensión está impuestopor la tensión máxima de pico que soporta el front-end analógico en sus entra-das diferenciales. Esta tensión no puede superar los 250mV de pico. Por lo tanto,

44 Capítulo 4. Ensayos y Resultados

cuando se aplicaran los valores máximos para los que fue diseñado el Smart Plug,la tensión pico en las entradas diferenciales debía estar por debajo de los 250mV.

En el caso de la tensión, se utilizó un autotransformador variable de de 0 a 250V,el cual permitió generar una tensión de 240VAC. Aplicando esta tensión, se midióla señal en la entrada diferencial del CS5490 mediante un osciloscopio, compro-bándose que su tensión de pico era de 203mV, valor que se encuentra por debajodel máximo permitido por el CS5490.

En el caso de la corriente, y debido a que los canales de tensión y corriente sonindependientes, para producir una corriente de 5A de forma sencilla se eligióreducir la tensión con que se alimenta al Smart Plug. Para esto se utilizó el auto-transformador, generando una tensión de 5VAC. Como carga se utilizó una resis-tencia de potencia de 1Ω. Se ajustó la salida del autotransformador hasta mediruna corriente de 5A sobre la carga. La tensión pico medida mediante un osci-loscopio en la entrada diferencial del canal de corriente fue de 192mV, valor quecomprueba que el equipo puede medir la corriente especificada.

Un aspecto que debió ser medido, aunque no estuviera relacionado con un reque-rimiento, fue el error relativo en las mediciones de tensión y de corriente. En lasFiguras 4.1 y 4.2 pueden verse los resultados de las mediciones para el canal detensión y el de corriente respectivamente.

FIGURA 4.1: Error relativo en el canal de tensión.

FIGURA 4.2: Error relativo en el canal de corriente.

4.3. Firmware 45

En el caso de la tensión, se utilizó el autotransformador variable para generardistintas tensiones de entrada y se comparó la tensión medida por el Smart Plugcontra un voltímetro usado para el contraste. Como puede verse, el error relativose encuentra por debajo del 1 % en todo el rango de tensión desde los 200VAChasta los 240VAC.

En el caso de la corriente, se ajustó la tensión de línea sobre el Smart Plug en10VAC utilizando el autotransformador, y se usaron distintas combinaciones deresistencias de potencia para generar diferentes corrientes. Para contrastar las me-diciones se empleó un amperímetro. Los resultados se encuentran por debajo del2 % en el rango de 0,02A hasta 4A. Los puntos en los que el error relativo estápor arriba del 1 % en realidad representan una variación de una centésima en lamedición respecto del amperímetro.

Para validar el resto de los requerimientos de hardware se realizaron firmwaresespeciales que tenían por objetivo validar un aspecto particular del equipo. Es-tos firmwares se pueden encontrar en [8] dentro de la carpeta Tests. Los tests dehardware son aquellos cuyo nombre comienza con SmartPlug_hw_test.

4.3. Firmware

En el caso de la validación de los requerimientos del firmware, la totalidad de laspruebas se encuentran descritas en el documento Smart Plug Firmware - Documen-to de Pruebas v1.0 en [6].

Uno de los aspectos que se debió validar en el caso del firmware fueron las se-ñalizaciones del led bicolor. Este led es el único medio que tiene el usuario paraconocer cómo está funcionando su Smart Plug, por lo que su funcionamientodebe ser confiable. Para generar todas las señalizaciones implementadas se im-plementaron distintos casos de prueba en los que se simulaba la condición defuncionamiento o de falla y se observaba el resultado en el led.

A continuación se resumen las pruebas para las distintas señalizaciones:

Led verde destellante a 2Hz: esta señalización se produce al iniciar el SmartPlug como un punto de acceso. Para esto, se mantuvo presionado el pulsa-dor en la placa del Smart Plug durante 5 segundos y se comprobó que elPlug creara una red WiFi. El led comenzó a destellar con una frecuencia de2Hz (medido con un osciloscopio) cuando se creó la red WiFi. El led dejó dedestellar cuando se configuró una red WiFi a la que se tenía que conectar elSmart Plug.

Led verde destellante a 1Hz: esta señalización se produce mientras dura elproceso de WPS. Para producirla, se presionó el pulsador en la placa delSmart Plug. Luego de hacer esto, el led comenzó a destellar con una fre-cuencia de 1Hz. Se presionó el botón de WPS en un router WiFi y cuando elSmart Plug se unió a la red, el led verde dejó de destellar.

Led rojo destellante a 1Hz: se produce cuando el Smart Plug no puede re-gistrarse en una red WiFi. Para producir esta situación se enciende el SmartPlug con el router WiFi desenergizado. Luego de unos segundos, al no po-der conectarse a la red WiFi, el led rojo comenzó a destellar a una frecuenciade 1Hz.


Led verde y rojo destellan: se produce cuando el Smart Plug no puede sin-cronizar la su fecha y hora con un servidor NTP. Para producir esta falla,se configuró el router WiFi para que impidiera las conexiones a la direcciónIP del servidor NTP usado por el Plug. Cuando se encendió el Smart Plug,luego de unos segundos el led verde y el rojo comenzaron a destellar.

Led verde encendido: esta señalización indica el correcto funcionamientodel Smart Plug. Para producir esta situación se eliminaron las condicionesde falla antes simuladas y el led verde se encidió luego de unos segundos.

Otro aspecto importante que debió validarse es que el Smart Plug generara unmensaje UDP periódico cada 2 segundos a la dirección de broadcast de la red Wi-Fi. Es importante que estos mensajes existan ya que la aplicación móvil dependede estos para identificar a los Plugs existentes en la red. Además, dentro de estosmensajes periódicos debe informarse el número de ID único del dispositivo.

Para realizar la prueba se utilizó una computadora, dentro de la misma red que elSmart Plug, ejecutando un capturador de paquetes (Wireshark). En la Figura 4.3puede verse una porción de la captura, en la que se aprecia que el tiempo entremensajes UDP dirigidos a la dirección broadcast de la red es de aproximadamente2 segundos. Además, en la misma figura se puede ver el contenido de uno de losmensajes, en donde se resaltan los seis dígitos del ID del Smart Plug (en este caso123456) expresado en caracteres ASCII.

FIGURA 4.3: Mensajes UDP periódicos recibidos de un SmartPlug, utilizados para identificarlo dentro de la red WiFi.

El protocolo desarrollado para comunicar los Smart Plugs con la aplicación móvilrequirió ser validado completamente, probando todos los comandos y registros,para determinar si se producían las acciones esperadas y se devolvían las res-puestas debidas.

Para poder conducir las pruebas sin la necesidad de desarrollar la aplicación mó-vil (la cual no estaba implementada al momentos de llevar a cabo la validacióndel firmware), se diseño e implementó una aplicación para PC que permitieragenerar las tramas de acuerdo a la especificación del protocolo.

En la Figura 4.4 puede verse una captura del software desarrollado utilizandoQT.

4.3. Firmware 47

FIGURA 4.4: Captura del software desarrollado que permite gene-rar todos los comandos propuestos en el protocolo de comunica-

ción.

La interfaz gráfica del software consta de cuatro secciones principales:

1. Permite elegir el puerto UDP en el que escuchar los mensajes periódicosenviados por los Smart Plugs y el puerto TCP al que mandar las tramas.Los Smart Plugs envían sus mensajes periódicos al puerto UDP 55555 yescuchan las conexiones TCP en el puerto 2000.

2. Cuando se abre el puerto UDP, se empiezan a recibir mensajes periódicosde los Smart Plugs que estén conectados en la misma red a la que pertenecela computadora que está corriendo esta aplicación. Cuando llega un men-saje periódico se agrega el ID único del Plug que lo envió en la lista de laderecha, como puede verse con el Plug de ID 123456. Al seleccionar uno delos Smart Plugs de la lista, en los controles de la izquierda de esta secciónse visualizarán algunos parámetros del Plug: dirección MAC, IP, RSSI de laseñal WiFi, hora de llegada del mensajes, etc.

3. Esta sección permite elegir el comando que se va a enviar al Smart Plug se-leccionado en la sección 2. Se debe elegir tanto el comando como el registroafectado (en caso de que corresponda). Además, si el comando requiere unparámetro adicional, como puede ser el en el caso del comando SET, en elcampo Payload se pueden ingresar los datos que debe llevar la trama.

4. Muestra la trama enviada y la trama recibida como respuesta. En el casode la respuesta. se muestra la misma parseada de acuerdo al comando yal registro manipulado. De esta forma, por ejemplo, si se está enviando elcomando GET de un registro de tipo float (como puede ser la tensión eficazmedida), la aplicación mostrará el contenido de la respuesta como un float.

Utilizando esta aplicación se llevaron a cabo numerosos casos de prueba paracomprobar la correcta implementación del protocolo en el firmware del SmartPlug. Tanto las pruebas como los resultados obtenidos pueden verse en el docu-mento Smart Plug Firmware - Documento de Pruebas v1.0 en [6].


Por otro lado, el código fuente de esta aplicación de PC se encuentra en [10].

4.4. Aplicación móvil

En el caso de la aplicación móvil, además de las pruebas de caja negra para va-lidar sus requerimientos (las cuales pueden encontrarse en el documento SmartPlug App - Documento de Pruebas v1.0 en [5]) se llevó a cabo una prueba generaldel sistema completo para comprobar su funcionamiento.

Básicamente la prueba general consistió en dejar conectado el Smart Plug durante5 días con una lámpara de 60W conectada realizando distintas configuracionespara comprobar su funcionamiento.

Las acciones que se realizaron dentro de la prueba fueron:

Configuración de la programación horaria para algunos días de la semana.

Encendido y apagado de la carga mediante la aplicación.

Comprobación de las mediciones eléctricas.

Visualización de los gráficos de potencia y energía consumida por hora.

Mediante la programación horaria se pudo comprobar que la carga se encendía yapagaba de acuerdo al día de la semana y a las horas configuradas para ese día.

Presionando el ícono asociado al Smart Plug en la lista de Plugs encontrados sepudo encender y apagar la carga.

Luego de pasados los 5 días se tenían 5 gráficos históricos de potencia y de energíaconsumida como se ve en la Figura 4.5. En la parte derecha de la figura, puedeverse uno de los gráficos de potencia promedio por hora.

FIGURA 4.5: Capturas de la aplicación móvil resultantes de laprueba de funcionamiento general del Smart Plug.

49

Capítulo 5

Conclusiones

En este capítulo se presentan las principales conclusiones del trabajo, así comotambién las futuras mejoras que se pueden realizar sobre el equipo.

5.1. Conclusiones generales

En la presente memoria se documentó el diseño e implementación de un SmartPlug. Se logró construir un prototipo funcional que permitió evaluar las pres-taciones del equipo y desarrollar una aplicación para dispositivos móviles consistema Android para poder interactuar con los Smart Plugs.

La información provista por cada uno de los Plugs le permitirá al usuario cono-cer el consumo de los dispositivos eléctricos, ayudándolo a tomar decisiones conel objetivo de cambiar la forma en que los utiliza. Se tomó como principal obje-tivo en el diseño de la aplicación, que la misma fuera sencilla de utilizar y quepresentara los datos de una forma útil.

El dispositivo desarrollado será uno de los primeros equipos de fabricación nacio-nal con estas características, complementando la línea de productos de domóticaya existente en la empresa X-28 Alarmas.

Para la realización de este proyecto se aplicaron los conocimientos aprendidosen la carrera de especialización en sistemas embebidos, principalmente de lassiguientes asignaturas:

Arquitectura de microprocesadores: en la misma se aprendió la arquitec-tura del microcontrolador utilizado en el Smart Plug y técnicas básicas deprogramación. Fue la base para empezar a usar dichos microcontroladores.

Programación de microprocesadores: se aplicaron las metodologías apren-didas, el uso de capas para generar abstracción con el hardware y la teoríade programación orientada a objetos.

Ingeniería de software en sistemas embebidos: se aplicaron los conocimien-tos adquiridos para diseñar, implementar y probar tanto el firmware co-mo la aplicación móvil. Esto constituyó uno de los principales aportes delproyecto a la metodología habitual de trabajo, ya que permitirá utilizar lastécnicas y herramientas aprendidas a otros desarrollos.

Gestión de Proyectos en Ingeniería: lo aprendido en esta asignatura per-mitió abordar el proyecto de forma ordenada, previendo las tareas que se

50 Capítulo 5. Conclusiones

debían realizar y el tiempo que se le debía dedicar a cada una de estas. Tan-to las herramientas como la forma de trabajo aprendidas en la materia sonotro de los aportes del proyecto a la forma de trabajo habitual.

Sistemas Operativos de Tiempo Real: a pesar de que cuando se cursó estamateria, se enseñaba únicamente el uso de FreeRTOS, los conocimientosaprendidos permitieron entender, sin mayores dificultades, el uso de otroRTOS como es FreeOSEK.

Protocolos de comunicación en sistemas embebidos: se utilizó la comunica-ción SPI aprendida en la asignatura.

Diseño para manufacturabilidad: se discutieron los diseños y se realizaronrevisiones y modificaciones para mejorar el funcionamiento del equipo.

Por otro lado, durante el desarrollo de este proyecto, se adquirieron conocimien-tos en las áreas de:

Diseño de aplicaciones móviles: se aprendió la importancia del uso de ma-quetas al momento de diseñar una aplicación, lo cual facilita la articulaciónentre la estética buscada y la funcionalidad de la aplicación.

Programación de aplicación para el sistema Android: a pesar de que quese contaba con alguna experiencia en programación de aplicaciones bajoAndroid, la aplicación desarrollada introdujo el uso de nuevas clases, espe-cialmente relacionadas con el manejo de servicios.

5.2. Trabajo futuro

Para continuar con el desarrollo del equipo, con el objetivo de obtener un produc-to comercial, se plantearon las siguientes mejoras y modificaciones sobre las quese debe trabajar:

Rediseñar la adaptación de las señales de tensión y corriente para reducir eltamaño del PCB. Evaluar la posibilidad de utilizar divisores resistivos parael canal de tensión y un shunt para la corriente. Implementar un diseñopropio de fuente switching la cual se integre en el PCB del producto.

Agregar la lógica del proceso de prueba en fábrica. La comunicación entreel probador del equipo y el equipo se realizará a través de la UART de de-bug, por lo que se debe modificar la tarea moduleLog para permitir recibircomandos durante la prueba. La prueba de fábrica incluirá: grabación delID único, calibración de continua y de ganancia del canal de corriente y detensión del front-end analógico.

En la aplicación móvil, el agregado de un nuevo Smart Plug se realizará in-troduciendo el ID único del producto. En la versión descrita en este trabajo,la aplicación muestra todos los Smart Plugs que encuentra.

En la aplicación móvil, se agregará información acerca del costo de la ener-gía consumida y se introducirá la posibilidad de configurar un nivel deenergía o de dinero, superado el cual se generarán notificaciones en el celu-lar.

5.2. Trabajo futuro 51

Desarrollar la infraestructura necesaria para permitir comandar los SmartPlugs tanto desde la misma red WiFi en la que se encuentran como desdecualquier otra red.

53

Bibliografía

[1] Cirrus Logic. Hoja de datos del front-end analógico CS5490. Marzo 2013.Disponible: 2016-10-22. URL:https://www.cirrus.com/jp/pubs/proDatasheet/CS5490_F3.pdf.

[2] Ross M. Fosler. AN914 - Dynamic Memory Allocation for the MPLAB R© C18 CCompiler. 2004. URL:http://ww1.microchip.com/downloads/en/AppNotes/00914a.pdf.

[3] Green Robot. Librería EventBus. Disponible: 2016-10-22. URL:http://greenrobot.org/eventbus/.

[4] Mariano Mondani. Aplicación móvil del Smart Plug. Disponible: 2016-10-22.URL:https://github.com/mmondani/SmartPlug/tree/master/Android_App.

[5] Mariano Mondani. Documentación de la aplicación móvil del Smart Plug engithub. Disponible: 2016-10-22. URL: https://github.com/mmondani/SmartPlug/tree/master/Documentacion_proyecto/App.

[6] Mariano Mondani. Documentación del firmware del Smart Plug en github.Disponible: 2016-10-22. URL: https://github.com/mmondani/SmartPlug/tree/master/Documentacion_proyecto/Firmware.

[7] Mariano Mondani. Documentación del hardware del Smart Plug en github.Disponible: 2016-10-22. URL: https://github.com/mmondani/SmartPlug/tree/master/Documentacion_proyecto/Hardware.

[8] Mariano Mondani. Firmware del Smart Plug. Disponible: 2016-10-22. URL:https://github.com/mmondani/SmartPlug/tree/master/LPCXpresso/Firmware.

[9] Mariano Mondani. Planificación del proyecto Smart Plug en github.Disponible: 2016-10-22. URL: https://github.com/mmondani/SmartPlug/tree/master/Documentacion_proyecto/Planificaci%C3%B3n.

[10] Mariano Mondani. Simulador TCP del Smart Plug. Disponible: 2016-10-22.URL: https://github.com/mmondani/SmartPlug/tree/master/LPCXpresso/Simulador_TCP.

[11] Pablo Ridolfi. Repositorio de la implementación de FreeOSEK para LPC1769.Disponible: 2016-10-22. URL:https://github.com/ciaa/FreeOSEK_LPC1769.

[12] Axel Tobias Schreiner. Object-Oriented Programming With ANSI-C. 1993.URL: https://www.cs.rit.edu/~ats/books/ooc.pdf.

https://www.cirrus.com/jp/pubs/proDatasheet/CS5490_F3.pdf

http://ww1.microchip.com/downloads/en/AppNotes/00914a.pdf

http://greenrobot.org/eventbus/

https://github.com/mmondani/SmartPlug/tree/master/Android_App

https://github.com/mmondani/SmartPlug/tree/master/Documentacion_proyecto/App

https://github.com/mmondani/SmartPlug/tree/master/Documentacion_proyecto/App

https://github.com/mmondani/SmartPlug/tree/master/Documentacion_proyecto/Firmware

https://github.com/mmondani/SmartPlug/tree/master/Documentacion_proyecto/Firmware

https://github.com/mmondani/SmartPlug/tree/master/Documentacion_proyecto/Hardware

https://github.com/mmondani/SmartPlug/tree/master/Documentacion_proyecto/Hardware

https://github.com/mmondani/SmartPlug/tree/master/LPCXpresso/Firmware

https://github.com/mmondani/SmartPlug/tree/master/LPCXpresso/Firmware

https://github.com/mmondani/SmartPlug/tree/master/Documentacion_proyecto/Planificaci%C3%B3n

https://github.com/mmondani/SmartPlug/tree/master/Documentacion_proyecto/Planificaci%C3%B3n

https://github.com/mmondani/SmartPlug/tree/master/LPCXpresso/Simulador_TCP

https://github.com/mmondani/SmartPlug/tree/master/LPCXpresso/Simulador_TCP

https://github.com/ciaa/FreeOSEK_LPC1769

https://www.cs.rit.edu/~ats/books/ooc.pdf

Documents

UNIVERSIDAD DE BUENOS AIRES FACULTAD DE INGENIERÍA …laboratorios.fi.uba.ar/lse/tesis/LSE-FIUBA-Trabajo-Final-CESE-Mariano-Mondani-2016...En los últimos meses, la cuestión del