control del proceso de fermentación de cerveza...

UNIVERSIDAD DE BUENOS AIRES

FACULTAD DE INGENIERÍA

CARRERA DE ESPECIALIZACIÓN EN SISTEMAS

EMBEBIDOS

MEMORIA DEL TRABAJO FINAL

Control del proceso de fermentación decerveza artesanal

Autor:Ing. Matías Alvarez

Director:Mg. Ing. Patricio Bos (FIUBA)

Codirector:Esp. Ing. Luis Chico (FIUBA)

Jurados:Esp. Ing. Ramiro Alonso (FIUBA)

Mg. Ing. Leonardo Carducci (FIUBA)Esp. Lic. Danilo Zecchin (FIUBA)

Este trabajo fue realizado en la Ciudad Autónoma de Buenos Aires, entre Abrilde 2018 y Diciembre de 2018.

III

Resumen

En la presente memoria se detalla el desarrollo de un prototipo de un sistema decontrol y alarmas del proceso de fermentación de cerveza artesanal,

implementado en la Cervecería Rieger de la Ciudad de La Plata.

El sistema consta de una interfaz de visualización, alarmas y panel de control enplanta junto a una interfaz web y un módulo de reportes vía GPRS que permite

el control en tiempo real, tanto local como remoto, de la temperatura de lostanques de fermentación, reduciendo costos y mejorando la calidad del producto

final.

Para asegurar la calidad del sistema, se realizaron etapas de elicitación yespecificación de requerimientos, diseño de arquitectura e implementación, se

emplearon técnicas de gestión de proyectos en ingeniería, conceptos de sistemasde tiempo real y protocolos de comunicación y se realizaron diseños y ejecuciónde tests y casos de prueba para validar y verificar el correcto funcionamiento del

mismo.

V

Agradecimientos

A mis padres, Noemí y Sergio, y a mi hermana, Milagros, que me han acompa-ñado durante estos últimos años, y en particular durante la realización de estetrabajo, por su comprensión, apoyo y cariño.

A mis compañeros y profesores de la Especialización por compartir sus conoci-mientos y por su acompañamiento a lo largo del año.

Al Ing. Patricio Bos, por su orientación, seguimiento, supervisión y aportes du-rante la realización del presente trabajo y al Ing. Luis Chico por sus valiosos apor-tes en la resolución de problemas con el módulo GPRS y la excelente predisposi-ción.

Al GRIDCOMD de la Facultad de Ingeniería de la Universidad de La Plata por elinstrumental prestado y la ayuda durante estos meses, y en especial al Ing. JoseJuarez, por haber sido quien me acercó por primera vez en los sistemas embebi-dos y por la ayuda ante problemas surgidos con el trabajo.

A todos ellos, muchas gracias.

VII

Índice general

Resumen III

1. Introducción General 11.1. Proceso de elaboración de cerveza artesanal . . . . . . . . . . . . . . 1

1.1.1. Temperatura de fermentación . . . . . . . . . . . . . . . . . . 21.2. Motivación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.3. El proyecto CIAA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

1.3.1. Plataforma CIAA-NXP . . . . . . . . . . . . . . . . . . . . . . 5

2. Introducción Específica 72.1. Definición del trabajo . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.1.1. Objetivos y alcance . . . . . . . . . . . . . . . . . . . . . . . . 7Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7Alcance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.1.2. Requerimientos . . . . . . . . . . . . . . . . . . . . . . . . . . 8Requisitos funcionales . . . . . . . . . . . . . . . . . . . . . . 8Requisitos no funcionales . . . . . . . . . . . . . . . . . . . . 9

2.1.3. Desglose de tareas . . . . . . . . . . . . . . . . . . . . . . . . 92.2. Planteo del problema . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

2.2.1. Entrada/Salida del sistema . . . . . . . . . . . . . . . . . . . 122.2.2. Alternativas tecnológicas . . . . . . . . . . . . . . . . . . . . 13

3. Diseño e Implementación 173.1. Diseño general del sistema . . . . . . . . . . . . . . . . . . . . . . . . 17

3.1.1. Arquitectura . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173.1.2. Principio de funcionamiento . . . . . . . . . . . . . . . . . . 19

3.2. Diseño e implementación del firmware y software de la web . . . . 203.2.1. Configuración de plataforma . . . . . . . . . . . . . . . . . . 213.2.2. Interfaz de visualización y panel de control . . . . . . . . . . 213.2.3. Reporte de alertas vía SMS . . . . . . . . . . . . . . . . . . . 233.2.4. Control del proceso de fermentación . . . . . . . . . . . . . . 253.2.5. Servidor web . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

Interfaz web embebida . . . . . . . . . . . . . . . . . . . . . . 293.3. Diseño e Implementación de prototipo de hardware y gabinete . . 33

3.3.1. Diseño de hardware . . . . . . . . . . . . . . . . . . . . . . . 333.3.2. Diseño de gabinete . . . . . . . . . . . . . . . . . . . . . . . . 37

4. Ensayos y Resultados 394.1. Pruebas funcionales del firmware . . . . . . . . . . . . . . . . . . . . 394.2. Ensayos de sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . . 424.3. Ensayos de estabilidad del servidor . . . . . . . . . . . . . . . . . . . 44

5. Conclusiones 45

VIII

5.1. Conclusiones generales . . . . . . . . . . . . . . . . . . . . . . . . . 455.2. Próximos pasos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

A. Manual de usuario 49

Bibliografía 67

IX

Índice de figuras

1.1. Proceso de elaboración de cerveza artesanal1 . . . . . . . . . . . . . 11.2. Mapa cervecero de la Ciudad de Buenos Aires y sus alrededores2 . 31.3. Plataforma CIAA-NXP . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2.1. Duración estimada de las tareas del proyecto . . . . . . . . . . . . . 102.2. Diagrama de Gantt de la planificación de tareas . . . . . . . . . . . 112.3. Termostato ETC-2003 . . . . . . . . . . . . . . . . . . . . . . . . . . . 142.4. Alternativas de módulos GPRS . . . . . . . . . . . . . . . . . . . . . 142.5. Alternativas de sensores de temperatura . . . . . . . . . . . . . . . . 152.6. Alternativas de displays LCD . . . . . . . . . . . . . . . . . . . . . . 15

3.1. Arquitectura específica del sistema de control del proceso de fer-mentación de cerveza artesanal . . . . . . . . . . . . . . . . . . . . . 18

3.2. Arquitectura en capas del firmware . . . . . . . . . . . . . . . . . . . 193.3. Estructura del patrón Hardware Proxy Pattern . . . . . . . . . . . . 193.4. Diagrama en bloques del funcionamiento del sistema . . . . . . . . 203.5. Distribucion de los archivos del proyecto . . . . . . . . . . . . . . . 213.6. Pantallas de la interfaz de visualización . . . . . . . . . . . . . . . . 223.7. Máquina de estados finitos de la interfaz de visualización . . . . . . 233.8. Máquina de estados finitos del panel de control . . . . . . . . . . . . 233.9. Diagrama de flujo de la tarea de reportes de alarmas vía SMS . . . . 243.10. Ejemplo de reporte recibido vía SMS . . . . . . . . . . . . . . . . . . 243.11. Diagrama de flujo de la tarea de control de fermentación . . . . . . 263.12. Diagrama de secuencia AJAX . . . . . . . . . . . . . . . . . . . . . . 283.13. Barra de navegacion de la interfaz web . . . . . . . . . . . . . . . . . 293.14. Página de monitoreo de los sensores . . . . . . . . . . . . . . . . . . 303.15. Página de monitoreo de las alarmas . . . . . . . . . . . . . . . . . . 303.16. Página de monitoreo de los actuadores . . . . . . . . . . . . . . . . . 313.17. Página de control de los sensores . . . . . . . . . . . . . . . . . . . . 313.18. Página de control de las alarmas . . . . . . . . . . . . . . . . . . . . 323.19. Página de control de la red del servidor web . . . . . . . . . . . . . 323.20. Página de control del módulo GPRS . . . . . . . . . . . . . . . . . . 333.21. Página 404 - Page not found . . . . . . . . . . . . . . . . . . . . . . . 333.22. Interacción del prototipo con la planta . . . . . . . . . . . . . . . . . 343.23. Conexión de la CIAA-NXP con las placas diseñadas . . . . . . . . . 343.24. Circuito esquemático de la placa del módulo GPRS . . . . . . . . . 353.25. Ruteo de la placa del módulo GPRS . . . . . . . . . . . . . . . . . . 353.26. Modelo 3D del diseño de PCB de la placa del módulo GPRS . . . . 363.27. Circuitos esquemáticos de la placa poncho . . . . . . . . . . . . . . 363.28. Ruteo de la placa estilo poncho . . . . . . . . . . . . . . . . . . . . . 363.29. Modelo 3D del diseño de PCB de la placa poncho . . . . . . . . . . 373.30. Modelo 3D del diseño de gabinete . . . . . . . . . . . . . . . . . . . 373.31. Gabinete terminado . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

X

4.1. Ejemplo I de ensayos de sistema . . . . . . . . . . . . . . . . . . . . 434.2. Ejemplo II de ensayos de sistema . . . . . . . . . . . . . . . . . . . . 434.3. Tabla del uso de stack por partes de las tareas del sistema . . . . . . 44

XI

Índice de Tablas

2.1. Tareas demoradas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92.2. Sensores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132.3. Actuadores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132.4. Alarmas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132.5. Información y estadísticas . . . . . . . . . . . . . . . . . . . . . . . . 13

3.1. Servidor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

4.1. Tests unitarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 414.2. Tests de cobertura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

1

Capítulo 1

Introducción General

En este capítulo se menciona el proceso de elaboración de la cerveza artesanal,los motivos por los cuales se llevó a cabo este proyecto y una introducción alproyecto CIAA y a la plataforma CIAA-NXP.

1.1. Proceso de elaboración de cerveza artesanal

El proceso de elaboración de cerveza artesanal se representa en la figura 1.1

FIGURA 1.1: Proceso de elaboración de cerveza artesanal1

Este proceso se divide en las etapas listadas a continuación:

1. Cosecha: Consiste en la recolección del grano de cebada, que suele ser lamateria prima principal de la cerveza artesanal, aunque en algunos casos seutilizan otros granos.

2. Malteado: Durante esta etapa los granos de cereal, previamente tamizadosy limpiados, se sumergen en agua para que comiencen a germinar. Pocodespués se secan con aire caliente, en lo que se denomina el tostado. De-pendiendo del grado de tostado se consiguen maltas más claras u oscuras,que aportarán el color de la cerveza.

3. Molienda y Maceración: El cereal se muele, dependiendo del volumen de pro-ducción, y se mezcla con agua a temperatura adecuada para convertir el al-midón del grano en azúcares fermentables y obtener así un líquido claro y

1https://actitudsaludable.net/beneficios-de-la-cerveza/

https://actitudsaludable.net/beneficios-de-la-cerveza/

2 Capítulo 1. Introducción General

azucarado que se conoce por el nombre de mosto. El agua es el ingredientemayoritario, por lo que la duración y temperatura durante el proceso influi-rá bastante en el tipo de cerveza final, sobre todo en el cuerpo y sabor de lamisma.

4. Cocción: El mosto, previamente filtrado, se pone a hervir con el objetivo deeliminar las bacterias que hayan podido aparecer durante el proceso, y esjusto en este momento cuando se añade el lúpulo, ingrediente que aportaráel aroma y amargor deseado. La duración del proceso de cocción dependede cada receta, pero se suele prolongar por algunas horas. El tiempo decocción influye en el amargor del producto final.

5. Enfriado: Durante esta etapa, se enfría el resultado de la cocción rápidamen-te hasta la temperatura de fermentación. En muchos casos, este proceso noes aplicado, y el resultado de la cocción se enfría directamente en el fermen-tador.

6. Fermentación: El resultado pasa al fermentador, donde se añade la levadu-ra. Sus enzimas transforman los azúcares del mosto en alcohol y marcanel perfil de la cerveza. El tiempo de fermentación dependera del estilo ygraduación alcohólica de la cerveza final. El proceso de fermentación esexotérmico, es decir que durante el mismo se liberan grandes cantidadesde calor, que hacen que los tanques de fermentación deban ser refrigeradosconstantemente para lograr una fermentación con temperatura estable.

7. Maduración: El líquido resultante se mantiene un tiempo en un tanque demaduración, donde reposa en frío para que el sabor y los aromas logradosdurante el proceso se estabilicen y el producto final mantenga el carácterdeseado. Este proceso se puede realizar en el mismo tanque que el procesode fermentación.

8. Embotellado o Embarrilado: La cerveza ya está lista. Se envasa en diferentesformatos para su consumo.

1.1.1. Temperatura de fermentación

La temperatura de fermentación es, quizás, el factor más importante del procesode elaboración de la cerveza artesanal y varía según el tipo de levadura empleadadurante el proceso:

Levaduras de alta fermentación: Son levaduras que se activan a temperaturasrelativamente altas, entre 18°C y 25°C, y que permanecen activas de 4 a6 días. Las cervezas elaboradas con estas levaduras se denominan Ale, ysuelen tener tonalidades más bien oscuras.

Levaduras de baja fermentación: Se activan a temperaturas más bajas, entre 6°Cy 10°C, y tienen un periodo de actividad mayor, entre 8 y 10 días. Las cer-vezas elaboradas con estas levaduras reciben el nombre de Lager y suelentener tonalidades claras.

Por tal motivo, es sumamente importante mantener la temperatura de fermenta-ción estable en el rango deseado para cada caso, con el objetivo de no degradar lacalidad del producto final.

1.2. Motivación 3

1.2. Motivación

En los últimos años, en Argentina, ha ocurrido una expansión de las cervezasartesanales como alternativa a cervezas industriales por sus características dife-renciadoras, como lo son el uso de ingredientes naturales, recetas personalizadas,procesos de elaboración y filtrados sin químicos ni conservantes, aromas y sa-bores distintivos, entre otros. Se trata de una industria que ha crecido a un tasacercana al 40 % anual, llegando a representar un 2 % del mercado cervecero [2].

En la figura 1.2 se visualiza el mapa cervecero de la Ciudad de Buenos Aires ysus alrededores, resaltando particularmente a Cervecería Rieger, en donde se im-plementó el primer prototipo del sistema de control que se detalla en la presentememoria.

FIGURA 1.2: Mapa cervecero de la Ciudad de Buenos Aires y susalrededores2

El plan de negocios y producción de estos pequeños emprendimientos suele tenergran crecimiento en el corto y mediano plazo, sin embargo, en muchos otros casosesto no sucede, en parte por limitaciones debido a la falta de automatización ycontrol de calidad en su proceso productivo. Teniendo en cuenta esta realidad,es que nace la idea de realizar un sistema de control del proceso de elaboraciónde la cerveza que permita controlar, monitorear y supervisar la producción delos distintos tipos de cervezas, reduciendo costos y maximizando la calidad delproducto final.

En particular, interesó poder controlar el proceso de fermentación y/o madura-ción de la producción de cerveza artesanal. Se buscó implementar una interfazque permitiera visualizar información relevante sobre el sistema bajo control ypermitiera actuar sobre la temperatura de los distintos tanques de fermentacióny/o maduración de modo tal de mantenerse estable en los rangos deseados comose mencionó en la subsección 1.1.1. Asimismo, se pretendió alertar a los operariosde posibles problemas en la planta, con el objetivo de minimizar pérdidas de lotesde producción.

2http://www.mapacervecero.com.ar/

http://www.mapacervecero.com.ar/


Debido a la poca o nula presencia de sistemas de elaboración de cerveza artesa-nal controlados remotamente en el mercado, es que se opta por desarrollar unainterfaz web embebida en el dispositivo de control, que será accesible mediante elprotocolo Ethernet a través de un equipo conectado a la misma red de área localo Local Area Network (LAN).

Por otra parte, el desarrollo de este sistema sirve como punto de partida para eldesarrollo de sistemas de control para otros procesos productivos, o incluso paraotras plantas de producción de cerveza artesanal que utilicen otros modulos deadquisicion de datos y/o actuadores. En este sentido, los mecanismos utilizadostanto en la interfaz en planta, como en la interfaz web, no se encuentran atados aninguna aplicación en particular, y por el contrario, permiten su reutilización endistintos proyectos.

Por último, el proyecto busca visibilizar las plataformas de hardware abiertas, ypor lo tanto el firmware de control es desarrollado sobre una de las plataformasdel Proyecto CIAA(Computadora Industrial Abierta Argentina), específicamente laversión CIAA-NXP.

1.3. El proyecto CIAA

El Proyecto CIAA(Computadora Industrial Abierta Argentina) nació en 2013 comouna iniciativa conjunta del sector académico y el industrial, representados por laACSE(Asociación Civil para la investigación, promoción y desarrollo de los Sistemas elec-trónicos Embebidos) y CADIEEL(Cámara Argentina de Industrias Electrónicas, Electro-mecánicas y Luminotécnicas), respectivamente [9].

Los objetivos del proyecto:

Impulsar el desarrollo tecnológico nacional, a partir de sumar valor agre-gado al trabajo y a los productos y servicios, mediante el uso de sistemaselectrónicos, en el marco de la vinculación de las instituciones educativas yel sistema científico-tecnológico con la industria.

Darle visibilidad positiva a la electrónica argentina.

Generar cambios estructurales en la forma en la que se desarrollan y utilizanen nuestro país los conocimientos en el ámbito de la electrónica y de lasinstituciones y empresas que hacen uso de ella.

Este proyecto se desarrolla en el marco de un trabajo libre, colaborativo y ar-ticulado entre industria y academia. Dentro de esta iniciativa se han elaboradodistintas plataformas de hardware, un firmware con drivers y ejemplos de apli-cación, una API(Application Programming Interface) simplificada y un entorno dedesarrollo basado en Eclipse. Dentro de las plataformas de hardware se encuen-tran versiones basadas en distintos microcontroladores de distintos fabricantesy versiones sobre FPGA (Field Programmable Gate Array). También hay versionespensadas para trabajar en ambientes industriales y versiones educativas que uti-lizan el mismo microcontrolador dentro de una placa de menores prestaciones y,por lo tanto, menor costo total que la versión industrial. A continuación se listanlas plataformas que se encuentran en fase de comercialización:

1.3. El proyecto CIAA 5

CIAA-NXP, primera plataforma industrial desarrollada por el proyecto. Sebasa en el microcontrolador NXP LPC4337.

EDU-CIAA-NXP, versión de bajo costo de la CIAA-NXP pensada para laenseñanza universitaria, terciaria y secundaria.

CIAA-Z3R0, versión de bajo costo y consumo, y reducido tamaño pensada,también para la enseñanza desde la educación primaria hasta la universita-ria, basada en un microcontrolador Silicon Labs EFM32HG322F64.

picoCIAA, versión de tamaño reducido, con formato de una placa mini PCIExpress, basada en el microcontrolador NXP LPC54102.

Asimismo, existen otras versiones en desarrollo, CIAA-FSL, EDU-CIAA-FSL, CIAA-Safety, CIAA-ACC, EDU-CIAA XILINX, EDU-CIAA-INTEL y CIAA-PIC. Infor-mación detallada respecto a cada plataforma y su grado de avance se puede en-contrar en [1].

Debido a que el trabajo requiere una plataforma totalmente desarrollada paraentornos industriales y capacidad de conexión Ethernet, se elige la plataformaindustrial CIAA-NXP.

1.3.1. Plataforma CIAA-NXP

La CIAA-NXP reúne dos cualidades:

Ser Industrial, ya que su diseño está preparado para las exigencias de con-fiabilidad, temperatura, vibraciones, ruido electromagnético, tensiones, cor-tocircuitos, etc., que demandan los productos y procesos industriales.

Ser Abierta, ya que toda la información sobre su diseño de hardware, firm-ware, software, etc. está libremente disponible en Internet bajo la LicenciaBSD(Berkely Software Distribution), para ser utilizada libremente.

FIGURA 1.3: Plataforma CIAA-NXP

Esta plataforma se compone de[4]:

CPU: Microcontrolador NXP LPC4337JBD1443(Dual-core Cortex-M4 + Cortex-M0 @ 204MHz).

Debugger: USB-to-JTAG FT2232H4. Soportado por OpenOCD.

3http://www.nxp.com/products/microcontrollers/cortex_m4/lpc4300/LPC4337JBD144.html4https://www.ftdichip.com/Support/Documents/DataSheets/ICs/DS_FT2232H.pdf

http://www.nxp.com/products/microcontrollers/cortex_m4/lpc4300/LPC4337JBD144.html

https://www.ftdichip.com/Support/Documents/DataSheets/ICs/DS_FT2232H.pdf


Memorias:

• Memorias internas del LPC4337.

• SDRAM 128 Mbit (IS42S16800F-7TL o compatible).

• Flash QSPI 32 Mbit (S25FL032P0XMFI011 o compatible).

• EEPROM I2C 1 Mbit y 2 Kbit.

Entradas y salidas:

• 8 entradas digitales opto-acopladas.

• 4 entradas analógicas 0-10V/4-20mA.

• 4 salidas Open-Drain.

• 4 salidas con Relay DPDT.

• 1 salida analógica 0-10V/4-20mA.

LV-GPIO:

• 14 GPIOs.

• I2C.

• SPI.

• 4 canales analógicos.

• Aux. USB.

Interfaces de comunicación:

• Ethernet.

• USB On-The-Go.

• RS232.

• RS485.

• CAN.

Fuente de alimentacion:

• Rango de tensión de entrada típico: 12VDC a 30VDC.

• Fuente de Switching para reducción a 5V-3A.

• Fuente lineal de 3.3V-1A a partir de los 5V.

• Fuente filtrada de 3.3V para conversores ADC.

7

Capítulo 2

Introducción Específica

En este capítulo se detallan los objetivos y alcances del proyecto, los requerimien-tos a cumplir, la división en tareas del mismo y se plantea el problema a resolver.

2.1. Definición del trabajo

Para la realización del sistema de control detallado en la presente memoria, seelaboró, en primera instancia, un plan de trabajo, donde se plantean los aspectosprincipales del proyecto que se incorporan en esta sección. Particularmente, enla subsección 2.1.1 se listan los objetivos y alcances del mismo, en la subsección2.1.2 se listan los principales requerimientos del sistema y por último, en la sub-sección 2.1.3 se muestran las tareas que se llevaron a cabo durante la realizacióndel sistema.

2.1.1. Objetivos y alcance

Objetivos

El propósito de este proyecto es desarrollar un prototipo operativo de un sistemade control que permita controlar, monitorear y supervisar el proceso de fermen-tación de cerveza artesanal con el objetivo de estandarizar la misma, de modotal de lograr una repetitividad de las características del producto en las sucesivaspartidas de producción, además de reducir costos operativos, la intervención deoperarios y las pérdidas de producción.

Alcance

El presente proyecto incluye los siguientes aspectos:

1. Control del proceso de fermentación de la cerveza.

2. Implementación de sistema de alarmas lumínicas y/o sonoras en el lugarpara informar distintos eventos de interés.

3. Confección de interfaz web que permita configuración de parámetros decada una de las etapas de acuerdo a la receta de la cerveza y visualizaciónde estados, alarmas, información y estadísticas.

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

4. Realización de interfaz GPRS(General Packet Radio Service) para envío deSMS(Short Message Service) con alarmas.

5. Implementación de interfaz de visualización en planta para mostrar las va-riables en tiempo real.

6. Realización de panel de control en planta para selección de parámetros.

7. Desarrollo de poncho/s para prototipado.

8. Construcción de gabinete prototipo.

Nota: En primera instancia se incluía el envío de mails diarios con reportes esta-dísticos de los procesos, pero debido a la complejidad y extensión en tiempo deldesarrollo de ese subsistema se dejó pendiente para más adelante.

El presente proyecto NO incluye los siguientes aspectos:

1. Automatización de los procesos de maceración de la malta, cocción del mos-to y envasado/embarrilado de la cerveza.

2.1.2. Requerimientos

Los requerimientos, en forma resumida, solicitados por el cliente y consensuadoscon el responsable de Cervecería Rieger, en una primera etapa, son listados acontinuación diferenciando entre funcionales y no funcionales:

Requisitos funcionales

1. El sistema debe medir la temperatura de hasta 4 tanques de fermentación/-maduración, en un rango de 0°C a 70°C con un error aceptable de +/-2°C.Generalmente el rango operativo va de 18°C a 25°C.

2. El sistema debe controlar la temperatura de hasta 4 tanques de fermenta-ción/maduración durante el tiempo indicado por el operario mediante elcomando de electroválvulas. Completado el tiempo, el sistema debe seguircontrolando la temperatura hasta que el usuario finalice el proceso median-te un comando vía web o pulsador.

3. El sistema debe comandar el llenado de tanque de fermentación/madura-ción.

4. El sistema debe visualizar información referida a los procesos de fermenta-ción/maduración y llenado de tanque.

5. El sistema debe permitir la configuración de parámetros referidos a los pro-cesos de fermentación/maduración y llenado de tanque.

6. El sistema debe encender/apagar las alarmas lumínicas cuando el eventode interes se dispare/termine.

7. El sistema debe enviar reportes diarios vía mail.

8. El sistema debe enviar alertas vía SMS ante eventos de interés.

9. El sistema debe permitir visualizar información, estadísticas, estados y alar-mas mediante interfaz web.

2.1. Definición del trabajo 9

10. El sistema debe permitir configurar los procesos de fermentación/madura-ción, llenado de tanque, red y módulo de envio de reportes vía SMS me-diante interfaz web.

Durante el transcurso del proyecto, como se mencionó previamente, el cumpli-miento del requerimiento 7 fue pospuesto debido a su complejidad y extensiónen tiempo.

Requisitos no funcionales

1. El sistema debe ser de tiempo real, de modo tal de responder a los eventosdel entorno en tiempo y forma.

2. El sistema debe ser genérico de modo tal de ser implementado en cualquierplanta de producción de cerveza artesanal y eventualmente en otros proce-sos productivos.

3. El sistema debe ser implementado en CIAA-NXP.

4. El sistema debe ser de fácil uso y entendimiento para el operador.

5. El sistema debe ser programado minimizando el consumo.

6. La página web debe ser intuitiva, de fácil uso y estética a la vista.

7. La información provista en forma de mails o mensajes de texto debe serconcisa y fácil de interpretar.

Finalmente el requerimiento 4 fue desestimado.

2.1.3. Desglose de tareas

Para llevar a cabo el proyecto se realizó una planificación de tareas y se estimaronque tiempos debían emplearse para cada una de ellas. A su vez se analizaron quétareas debían realizarse primero y cuáles eran sus dependencias. En la figura 2.1se muestra el listado de tareas y el tiempo estimado para cada una, mientras que,en la figura 2.2 se muestra la información de la planificación de tareas en formade diagrama de Gantt.

Debido a la falta de experiencia en diseño y armado de gabinetes, y a proble-mas con el GPRS y la estabilidad del servidor web, se requirió más tiempo de loplanificado. En la tabla 2.1, se aprecia el tiempo estimado, el tiempo realmenteutilizado y cuáles fueron las tareas que requirieron más tiempo.

TABLA 2.1: Comparación de tiempo planificado vs tiempo reque-rido

Nro Tarea Tiempo estimado Tiempo real

20 Pruebas de funcionamiento (Firmware) 30hs 45hs29 Integración con el firmware (Web) 20hs 35hs37 Elaboración del PCB 35hs 40hs46 Montaje de prototipo experimental 15hs 45hs


FIGURA 2.1: Duración estimada de las tareas del proyecto

2.2. Planteo del problema 11

FIGURA 2.2: Diagrama de Gantt de la planificación de tareas

2.2. Planteo del problema

Como punto de partida, resulta imprescindible abordar el problema a resolver,comentando las suposiciones y restricciones con las que se trabajó. El proyectose limita a un sistema de control del proceso de fermentación y/o maduración,debido a los costos que significaría para Cervecería Rieger, realizar un sistema au-tomático de control que involucre todos los procesos de elaboración de la cervezaartesanal y a los tiempos a los que se acota este proyecto.

Las variables que se deben medir son de naturaleza analógica y están asociadas aprocesos físicos lentos. En este sentido, se adopta en principio una tasa de mues-treo menor a 1/5Hz para la adquisición de datos. Se definen valores umbralespara las variables medidas, tanto en el límite superior como inferior, y tiemposde finalización de los procesos.


En los lazos de control se aplican acciones binarias del tipo encender/apagar so-bre los actuadores del sistema en función del estado de la variable a controlarcon respecto a los umbrales. Las acciones de control se deben sostener en el tiem-po mientras el estado de la variable que las haya iniciado continúe sin cambios,incluso después de la finalización del proceso, en el caso del proceso de fermenta-ción/maduración, por una cuestión de aseguramiento de la calidad del producto.Distinto es el caso del llenado de tanque, donde por cuestiones de seguridad, elllenado corta al finalizar el tiempo indicado.

Se establecen condiciones de alarma para cada proceso de fermentación/madu-ración o llenado de tanque. Particularmente, se definen cuatro alarmas para elprimer proceso y dos para el segundo:

Alarma de temperatura fuera de rango: Alarma que se activa en caso de quela variable supere el valor maximo permitido(umbral superior más 10°C) ose encuentre por debajo del valor mínimo permitido(umbral mínimo menos10°C).

Alarma de error de adquisicion de datos.

Alarma de proceso en marcha.

Alarma de proceso finalizado.

Las últimas dos alarmas se ecuentran presentes en ambos tipos de proceso.

Se define que el envío de reportes vía SMS solo se realizará en el caso de la pri-mer alarma, por única vez al dispararse la alarma, y que la alarma de error en laadquisición de datos de los sensores no se mostrará en la web, ya que se mues-tra el estado del sensor, evitando así la visualización de la información de formarepetida.

Se definen los estados posibles de los procesos como encendido, finalizado, pau-sado o apagado. Particularmente, resulta importante diferenciar los estados fina-lizado y apagado, siendo el primero, el estado que el proceso alcanza cuando hasuperado el tiempo máximo de fermentación/maduración y el segundo el estadocuando el proceso no se encuentra adquiriendo datos.

Se precisa que la información a mostrar en la interfaz de visualización incluyevalores actuales y parámetros de configuración, mientras que en la interfaz web,incluye, además de lo mencionado, estadísticas, estados de sensores, actuadoresy alarmas, información relevante al envío de SMS y de la red.

2.2.1. Entrada/Salida del sistema

En esta subsección se definen con mayor detalle las variables a sensar, actuadoresy alarmas que serán parte del sistema de monitoreo y control. En la tabla 2.2se declaran los sensores con las características principales que deben tener. Sedeclaran las condiciones de alarma, asociadas a los procesos, en la tabla 2.4. En latabla 2.3 se declaran los actuadores del sistema con las características principalesque deben tener. Por último, en la tabla 2.5 se declaran los valores actuales yestadísticas del sistema a informar.


TABLA 2.2: Especificación de las variables a sensar

Sensor Rango Resolución

Temperatura 0∼99,9°C 0,1°C

TABLA 2.3: Especificación de los actuadores del sistema

Actuador Tensión de operación

Electroválvulas 24VDC

TABLA 2.4: Especificación de las alarmas del sistema

Alarma Condición

Alarma proceso encendido Proceso adquiriendo datos

Alarma proceso finalizadoProceso superó tiempo máximo de

fermentación/maduración

Alarma temperatura fuera de rangoTemperatura >Umbral máximo + 10°C o

Temperatura <Umbral mínimo - 10°C

Alarma error de sensorError en la adquisición de datos del

sensor

TABLA 2.5: Información y estadísticas a visualizar

Sensor Rango Resolución

Valor actual temperatura 0∼99,9°C 0,1°CUmbral máximo temperatura 0∼99,9°C 0,1°CUmbral máximo temperatura 0∼99,9°C 0,1°CValor máximo temperatura 0∼99,9°C 0,1°CValor mínimo temperatura 0∼99,9°C 0,1°CValor promedio temperatura 0∼99,9°C 0,1°CTiempo actual transcurrido 0∼99 días 1 segTiempo máximo de fermentación 0∼99 días 1 segEstado sensores - -Estado alarmas - -Estado actuadores - -Números de celular de reporte - -IP, Gateway y Máscara de red - -

2.2.2. Alternativas tecnológicas

En esta sección se presentan las alternativas tecnológicas que se evaluaron o con-sultaron para la realización del sistema en general, la elección de los sensores, delmódulo GPRS para el envío de reportes y del display para la interfaz de visua-lización, en base a los requerimientos, restricciones de hardware, disponibilidaden el mercado local y costos.

Para la realización del sistema general se consultó el termostato ETC-200[5], dedonde se obtuvieron las ideas de las alarmas, los rangos y resolución de tempera-tura típicos, la idea de funcionamiento de la interfaz de visualización y tipos de


sensores utilizados. En la figura 2.3 se visualiza el termostato mencionado.

FIGURA 2.3: Termostato ETC-2001

Existen múltiples módulos GPRS en el mercado de disponibilidad, prestaciones yprecios distintos. Particularmente se consultaron los visualizados en la figura 2.4.

(A) Módulo GPRS SIM8002 (B) Módulo GPRS SIM9003

FIGURA 2.4: Alternativas de módulos GPRS

Ambos presentan las siguientes características:

Cuatri-banda: 850/ 900/ 1800/ 1900 MHz

GPRS multi-slot clase 10/8

GPRS mobile station clase B

Control vía comandos AT

Comunicación 2G

La principal diferencia radica en la tensión de alimentación, mientras que el mó-dulo SIM800 tiene un rango de alimentación de 3,4V a 4,4V, el módulo SIM900 sepuede alimentar con tensiones típicas 5V y 9V.

En primera instancia se había escogido el módulo SIM800 pero debido a proble-mas con el mismo, se optó por utilizar el módulo SIM900. Los problemas encon-trados y las decisiones tomadas a partir de ello, se detallan en la sección 3.2.3.

1https://www.aliexpress.com/item/Thermostat-ETC-200-with-two-meters-NTC-sensor-heating-defrost-and-cooling-220-VAC-10A/1159811599.html

2https://sc02.alicdn.com/kf/HTB1MJRfXvfsK1RjSszgq6yXzpXae/Smallest-MicroSIM-Card-Core-Board-Quad-Band.jpg_350x350.jpg

3https://hetpro-store.com/images/detailed/2/3_grande.jpg

https://www.aliexpress.com/item/Thermostat-ETC-200-with-two-meters-NTC-sensor-heating-defrost-and-cooling-220-VAC-10A/1159811599.html

https://www.aliexpress.com/item/Thermostat-ETC-200-with-two-meters-NTC-sensor-heating-defrost-and-cooling-220-VAC-10A/1159811599.html

https://sc02.alicdn.com/kf/HTB1MJRfXvfsK1RjSszgq6yXzpXae/Smallest-MicroSIM-Card-Core-Board-Quad-Band.jpg_350x350.jpg

https://sc02.alicdn.com/kf/HTB1MJRfXvfsK1RjSszgq6yXzpXae/Smallest-MicroSIM-Card-Core-Board-Quad-Band.jpg_350x350.jpg

https://hetpro-store.com/images/detailed/2/3_grande.jpg


Para la medición de la temperatura de fermentación se encontraron principal-mente sensores de temperatura tipo termistor NTC (Negative Temperature Coeffi-cient). El principio de funcionamiento se basa en presentar un valor de resisti-vidad que disminuye con el incremento de la temperatura. En la figura 2.5a sepuede observar un sensor de este tipo de 10kΩ a 25°C en un encapsulado de ace-ro inoxidable sumergible con un cable de 30cm. Por otra parte, se encontró untermómetro digital basado en el integrado ds18b20 que proporciona lecturas dela temperatura de 9 a 12 bits en forma configurable, sobre una interfaz One-Wire,que requiere solo un cable de señal conectado al microcontrolador. En la figura2.5b se puede observar un sensor de este tipo que también cuenta con un encap-sulado de acero inoxidable apto para inmersión con un cable de 1m. Por último,se analizó la posibilidad de utilizar un sensor LM35, con etapa de amplificación yrealización de vainado sumergible. Este tipo de sensores tiene precisión calibradade 1°C y salida lineal, donde cada °C equivale a 10mV. La dificultad de realizarun vainado que fuera totalmente hermético, hizo desestimar su elección. En lafigura 2.5c se visualiza un sensor de este tipo.

(A) Termistor NTC4 (B) Sensor digital ds18b205 (C) Sensor LM356

FIGURA 2.5: Alternativas de sensores de temperatura

Finalmente, por una cuestión de costos y disponibilidad en el mercado se optópor la utilización de sensores ds18b20 [3].

Para la interfaz de visualización se consultaron displays LCD de distintos tama-ños y protocolos de comunicación. En particular, se analizaron los vistos en lafigura 2.6, que se comandan vía I2C, debido a la falta de GPIO de la CIAA-NXP.

(A) Display LCD 20*47 (B) Display LCD 16*28

FIGURA 2.6: Alternativas de displays LCD

4https://teslabem.com/tienda/sensor-temperatura-termistor-ntc-10k-3470-20-a-120c/5https://chips.mecatronium.com/product/sensor-de-temperatura-ds18b20-digital-tipo-sonda-sumergible-1m/6https://www.mikroe.com/lm35-sensor

https://teslabem.com/tienda/sensor-temperatura-termistor-ntc-10k-3470-20-a-120c/

https://chips.mecatronium.com/product/sensor-de-temperatura-ds18b20-digital-tipo-sonda-sumergible-1m/

https://www.mikroe.com/lm35-sensor


Se escogió el display LCD de 20 caracteres, debido a la cantidad de informaciónque se necesitaba informar simultáneamente.

7https://didacticaselectronicas.com/index.php/optoelectronica/displays-lcd/display-lcd-20x4-interfaz-i2c-detail

8https://articulo.mercadolibre.com.co/MCO-464853974-lcd-1602-16x2-back-light-azul-con-conversor-i2c-_JM

https://didacticaselectronicas.com/index.php/optoelectronica/displays-lcd/display-lcd-20x4-interfaz-i2c-detail

https://didacticaselectronicas.com/index.php/optoelectronica/displays-lcd/display-lcd-20x4-interfaz-i2c-detail

https://articulo.mercadolibre.com.co/MCO-464853974-lcd-1602-16x2-back-light-azul-con-conversor-i2c-_JM

https://articulo.mercadolibre.com.co/MCO-464853974-lcd-1602-16x2-back-light-azul-con-conversor-i2c-_JM

17

Capítulo 3

Diseño e Implementación

En este capítulo se detallan las consideraciones de diseño que se tuvieron en cuen-ta para realizar el sistema y se describe el desarrollo y funcionamiento del hard-ware y firmware implementado en el proyecto.

3.1. Diseño general del sistema

3.1.1. Arquitectura

La arquitectura del sistema se diseñó teniendo en cuenta tres patrones de diseñode arquitectura:

1. Observar y reaccionar: se recopilan y analizan los valores de entrada de unconjunto de sensores de los mismos tipos. Dichos valores se despliegan dealguna forma. Si los valores de los sensores indican que surgió alguna con-dición excepcional, entonces se inician acciones para llamar la atención deloperador hacia dicho valor y se realizan acciones en respuesta al mismo.

2. Capas: su principal objetivo es el desacople de las partes que componen elsistema, trayendo como principal ventaja la reducción de complejidad delas capas y la portabilidad del sistema.

3. Hardware Proxy Pattern: este patrón crea un elemento de software respon-sable del acceso a un elemento de hardware y del encapsulamiento de laimplementacion del codigo de dicho elemento. El proxy permite el accesoa servicios de lectura, escritura, inicialización, y configuración del elementode hardware. De esta forma permite el cambio del hardware subyacente deforma sencilla y transparente para el resto del sistema.

En la figura 3.1 se visualiza la arquitectura del sistema siguiendo el patrón obser-var y reaccionar, que incluye tres secciones bien diferenciadas:

Comunicación con usuario: incluye los procesos de la interfaz web, panelde control para configuración, reportes SMS y alarmas en planta.

Proceso de fermentación: es el proceso de control.

Comunicación con planta: incluye los sensores y actuadores.

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

FIGURA 3.1: Arquitectura específica del sistema de control delproceso de fermentación de cerveza artesanal

En la figura 3.2 se visualiza la arquitectura del firmware siguiendo el patrón dearquitectura en capas, donde, agrupados por color se pueden apreciar los distin-tos niveles de abstracción y, dentro de cada capa, los bloques funcionales que laintegran:

Hardware: representa el hardware de la CIAA, los sensores, actuadores, dis-play, alarmas y panel de control.

HAL(Hardware Abstraction Layer): permite el desacople de las capas supe-riores del hardware. Aquí se encuentran los drivers del fabricante del mi-crocontrolador, en el bloque funcional LPCOPEN, los desarrollados para laplataforma CIAA en el bloque BOARD, y los drivers propios que fuerondiseñados para el sistema.

HIL(Hardware Independent Layer): incluye los módulos del RTOS y el stackTCP/IP.

App Layer: incluye dos aplicaciones, la del servidor web y la del controldel proceso de fermentación con todas sus partes componentes(interfaz devisualización, panel de control, envío de reportes SMS y control de tempe-ratura).

3.1. Diseño general del sistema 19

FIGURA 3.2: Arquitectura en capas del firmware

En la figura 3.3 se visualiza la estructura del patrón Hardware Proxy Pattern. Es-te patrón fue elegido para poder cumplir con el requerimiento 2 de la subsección2.1.2. De este modo es posible aplicar el sistema en otras plantas de producciónde cerveza artesanal, o incluso, en otros procesos productivos con cambios rela-tivamente sencillos al mismo. Además, facilita la implementación de las demásetapas del proceso productivo de la cerveza artesanal, como lo son la maceraciónde la malta, cocción del mosto y el embotellado o embarrilado. Más allá de esto, elsistema fue diseñado teniendo en cuenta las alternativas tecnológicas escogidascomo se mencionó en la subsección 2.2.2.

FIGURA 3.3: Estructura del patrón Hardware Proxy Pattern

3.1.2. Principio de funcionamiento

En la figura 3.4 se visualiza la distribución de las tareas y el principio de funcio-namiento del sistema. Todas las tareas acceden a los datos del sistema de formaconcurrente, medio utilizado para la comunicación entre las mismas. Es impor-tante destacar que se utilizan mecanismos de exclusión mutua para mantener laintegridad de los datos. Los datos del sistema están representados por los sen-sores, alarmas, actuadores y comandos. En la figura 3.4 resaltan las siguientestareas, que serán explicadas con mayor detalle en la sección 3.2:


Servidor web: en términos generales, un servidor web es un programa quepermite publicar información en la World Wide Web (WWW) o una red deárea local (LAN). Esta información puede ser consultada desde cualquiernavegador web estándar en computadoras, celulares o tablets. El servidorestablece un canal de comunicación entre un servidor y un cliente, donde,básicamente, ejecuta las peticiones del cliente. En el presente trabajo, el ser-vidor web se encuentra embebido en la plataforma CIAA y proporciona alusuario una interfaz para monitorear, configurar y controlar el sistema.

Control: es la tarea encargada de leer los sensores, analizar los valores yactuar en consecuencia, mediante el control de los actuadores y el seteo delas alarmas.

GPRS: es la tarea encargada de obtener la señal del módulo GPRS y enviarlos reportes vía SMS.

Panel de control: es la tarea encargada de relevar el estado de los botones delpanel de control.

Interfaz de visualización: es la tarea encargada de visualizar los distintos datosy parámetros de configuración en el LCD, así como las alarmas.

FIGURA 3.4: Diagrama en bloques del funcionamiento del sistema

3.2. Diseño e implementación del firmware y software dela web

Durante esta sección se mencionan las herramientas utilizadas en el desarrollodel firmware del proyecto, como así también se explica el funcionamiento de ca-da módulo. Para un mejor entendimiento del funcionamiento del sistema ver elmanual de uso en el apéndice A.

3.2. Diseño e implementación del firmware y software de la web 21

3.2.1. Configuración de plataforma

Antes de comenzar con la implementación del firmware, se continuó con la elec-ción y configuración de la plataforma y las herramientas de desarrollo. Particu-larmente, se hizo uso del firmware versión 2 del Proyecto CIAA [8], con cambiosen la distribución de los archivos, lo que implicó una modificación al makefileque trae por defecto. La distribución de los archivos se visualiza en la figura 3.5.

FIGURA 3.5: Distribucion de los archivos del proyecto

Una vez configurada la plataforma, se procedió a configurar las herramientas quese iban a utilizar durante la realización del proyecto:

Doxygen: es una herramienta para generar documentación directamente apartir del código fuente.

CCCC y Cppcheck: herramientas para análisis de código estático.

Ceedling: es un framework que trabaja con otras dos herramientas, unity ycmock, que permite la generación de mocks automáticamente y la ejecuciónde tests.

Gcov: es una herramienta de análisis de cobertura del código fuente. Utili-zado en conjunto con ceedling.

Git y Gitlab: Git es un sistema de control de versiones libre y gratuito, mien-tras que Gitlab es un servicio web de control de versiones y desarrollo desoftware colaborativo basado en Git. Se utilizo Gitlab en particular, porquepermite llevar un sistema de versionado sin hacer público el código en laweb.

3.2.2. Interfaz de visualización y panel de control

La interfaz de visualización y el panel de control están compuestos de la siguientemanera:

Display LCD: para visualizar la información y parámetros de configuraciónde los distintos procesos del sistema. Se puede recorrer de forma manualo automática por las distintas pantallas de los procesos. Las dos pantallasmás importantes se visualizan en la figura 3.6


Botones UP/DOWN: permiten la modificación de los parámetros de los pro-cesos.

Botón SET: para iniciar la configuración de los parámetros de los procesos.

Botón MODE: para modificar el modo de recorrer la interfaz visual.

Botón ON/OFF: para iniciar, pausar y finalizar los procesos.

(A) Pantalla de visualización (B) Pantalla de configuración

FIGURA 3.6: Pantallas de la interfaz de visualización

Para la implementación de la interfaz de visualización se utilizó una Máquina deEstados Finitos (MEF) con los siguientes estados:

Estado inicial: estado que muestra un mensaje de bienvenida, la primera vezque se enciende el sistema.

Estado de visualización: estado que visualiza los valores de los procesos deforma automática o manual de forma circular. Su principal pantalla es la quese muestra en la figura 3.6a. Además es el estado encargado de visualizarlas alarmas.

Estado de configuración de tiempo: estado que permite la modificación del pa-rámetro de tiempo máximo de proceso. Su pantalla principal es la que semuestra en la figura 3.6b.

Estado de configuración de temperatura mínima: estado que permite la modi-ficación del parámetro de temperatura mínima de control del proceso. Supantalla principal es la que se muestra en la figura 3.6b.

Estado de configuración de temperatura máxima: estado que permite la modi-ficación del parámetro de temperatura máxima de control del proceso. Supantalla principal es la que se muestra en la figura 3.6b.

Los últimos tres estados consultan el estado de los botones UP y DOWN al panelde control para decidir si aumentar o decrementar el dígito actual del paráme-tro que se está configurando. Además consultan el estado de los botones SET yMODE para pasar al siguiente dígito o cambiar de estado. Es en el cambio deestado cuando efectivamente se guarda el valor del parámetro. En el caso de latemperatura máxima de control esta es guardada solo si su valor es mayor al de latemperatura mínima, caso contrario, se pide volver a configurar dicho parámetro.

El diagrama de estados de la MEF se muestra en la figura 3.7.


FIGURA 3.7: Máquina de estados finitos de la interfaz de visuali-zación

En el caso del panel de control, se utilizó una MEF antirebote para los botonescon los siguientes estados:

Estado arriba: estado cuando el botón no se encuentra pulsado.

Estado bajando: estado cuando el botón está siendo presionado.

Estado abajo: estado cuando el botón está pulsado.

Estado subiendo: estado cuando el botón está siendo soltado. Es aquí cuandose computa el botón como presionado.

El diagrama de estados de la MEF se visualiza en la figura 3.8.

FIGURA 3.8: Máquina de estados finitos del panel de control

3.2.3. Reporte de alertas vía SMS

La tarea de reporte de alertas es la encargada de configurar el módulo GPRS pa-ra su uso. Particularmente, se requiere que esté configurado en modo texto parapoder transmitir mensajes SMS. A su vez, es la encargada de interactuar con elmódulo GPRS realizando consultas del nivel de señal del módem y de enviar losmensajes de alarmas si éstas están activadas y los numeros de telefono habilita-dos. El funcionamiento detallado de esta tarea se muestra en el diagrama de flujode la figura 3.9.


FIGURA 3.9: Diagrama de flujo de la tarea de reportes de alarmasvía SMS

En la figura 3.10 se visualiza un ejemplo de reporte enviado por la tarea de reportede alertas.

FIGURA 3.10: Ejemplo de reporte recibido vía SMS

En primera instancia se había escogido el módulo SIM800 como parte del sistema,pero problemas con la alimentación del módulo, que ocasionaban que nunca sepudiera conectar a la red telefónica del proveedor y por tanto no pudiera enviarSMS, se optó por la elección del módulo SIM900.


3.2.4. Control del proceso de fermentación

La tarea de control del proceso de fermentación es la que lleva el tiempo de losprocesos productivos, controla la inicialización, pausado y finalización de los mis-mos, lee, analiza y controla el valor de temperatura de los tanques de fermenta-ción, controla el llenado de tanque, y establece si las alarmas se deben disparar ono.

Como se mencionó en la subsección 2.2, las variables a medir están asociadasa procesos físicos lentos y se adopta un principio de muestreo menor a 1/5Hzporque el muestreo de un sensor ds18b20 a 12 bits, máxima resolución, lleva untiempo de 750ms.

Por otro lado, los lazos de control funcionan de modo tal que si la temperaturadel tanque bajo control supera la máxima temperatura configurada, el sistemaacciona la electroválvula correspondiente para permitir que circule líquido porun encamisado que posee el tanque. La acción de control permanece, entonces,sin cambios, mientras que la variable que la disparó permanezca por encima delvalor mínimo configurado, momento en el que se desactiva la electroválvula yfinaliza el circulado de agua por el encamisado del tanque. Este proceso continúa,aún finalizado el tiempo máximo de fermentación.

El funcionamiento de esta tarea se explica en el diagrama de flujo de la figura 3.11


FIGURA 3.11: Diagrama de flujo de la tarea de control de fermen-tación

3.2.5. Servidor web

Como se mencionó en la sección 3.1.2 el servidor web se encuentra embebido enla plataforma CIAA y es capaz de soportar los siguientes servicios:

HTTP 2.0: HyperText Transfer Protocol [1] es un protocolo sin estado orien-tado a transacciones y que sigue el esquema petición/respuesta entre uncliente y un servidor. Permite conexiones persistentes que permiten reducirel tráfico de red y mejorar el desempeño en cuanto al tiempo de respuestadel servidor web. Resulta necesario para implementar métodos AJAX.

SSI: Server Side Includes es un lenguaje interpretado sencillo que consisteen un conjunto de directivas que se incluyen dentro de la codificación deuna página HTML y que se evalúan en el servidor web cuando la páginaHTML es solicitada. Permite incluir contenido generado en forma dinámi-ca en tiempo de ejecución, sin tener que programar toda la pagina en PHP,ruby on rails, ASP o alguna tecnología similar, lo que resulta sumamente


importante tratándose de un servidor web embebido. Al no estar estandari-zado, cada desarrollador de servidores web es libre de incluir e interpretarestas directivas de la forma en que desee.

AJAX: Asynchonous JavaScript And XML es un conjunto de técnicas utiliza-das desde el lado del cliente para enviar y recibir información de un servi-dor en forma asincrónica para desarrollar aplicaciones interactivas. Es unaforma de desacoplar el intercambio de información y la visualización de lapágina web. De esta forma es posible realizar cambios sobre las páginas sinnecesidad de recargarlas, mejorando la interactividad, velocidad y usabili-dad en las aplicaciones. Para implementar AJAX, el servidor debe soportardirectivas SSI. El cliente debe soportar JavaScript para peticionar informa-ción en segundo plano y es responsable de realizar dichas peticiones a in-tervalos regulares. En la figura 3.12 se visualiza un ejemplo de secuenciaAJAX.

Formularios web (peticiones GET): permiten al usuario introducir datos, loscuales son enviados a un servidor para ser procesados. GET es un métododel protocolo HTTP que se utiliza para solicitar información de un servi-dor. Durante una petición GET se produce un request HTTP por parte delcliente y un response del servidor. La solicitud de información se transmi-te a través de la Uniform Resource Identifier (URI) agregando parámetros ala Uniform Resource Locator (URL). En la presente implementación, el méto-do GET se utiliza para enviar información al servidor en lugar de utilizar loque sería más correcto, el método POST, debido a la mayor sencillez del pri-mero por sobre el segundo. Esto obliga a tener ciertos cuidados, puesto quelos parámetros quedan persistentes en la URL, pudiendo ocasionar envíosconsecutivos de información al servidor si el usuario no tiene los recaudossuficientes. Esto se soluciona manejando el historial de la aplicación webmediante JavaScript.

CGI (peticiones GET): Common Gateway Interface [10] es un estándar queprovee una interfaz sencilla a un cliente para solicitar datos de un progra-ma ejecutado en un servidor HTTP. En esta implementación se utiliza CGIpara ejecutar rutinas específicas dentro del microcontrolador y generar unanueva página web como respuesta. Las funciones asociadas a un CGI seejecutan cuando se envía un formulario web con el método GET al servidorpara su procesamiento.


FIGURA 3.12: Diagrama de secuencia AJAX

Para la implementación del servidor web embebido se tomaron como guía unport de LPCOPEN v2.16 [6], provisto por NXP para la familia de microcontrola-dores LPC43XX, que contiene un ejemplo de aplicación sencillo que integra freeR-TOS y lwIP, un ejemplo de los desarrolladores del stack TCP/IP lwIP [12]y unanota de aplicación de NXP sobre el uso de servidores web embebidos en micro-controladores de la familia MCF51CN [7].

El servidor web es implementado utilizando el stack TCP/IP de lwIP [11]. Pa-ra acceder a los sockets, el servidor web utiliza la RAW API de lwIP, cercana ala capa TCP, que emplea una serie de callbacks para manejar los eventos de lacomunicación. El servidor inicia con la configuración detallada en la tabla 3.1.

TABLA 3.1: Parámetros iniciales del servidor

Parámetro Valor

Dirección IP 192.168.200.99Máscara de red 255.255.255.0Puerta de enlace 192.68.200.1DHCP DeshabilitadoPuerto 80

Por otro lado el diseño e implementación de la página web se realizó mediantelas siguientes herramientas:

HTML: HyperText Markup Language es el lenguaje de marcado para la elabo-ración de páginas web. Es un estándar que define una estructura básica yun código para la definición de contenido de una página web, como texto,imágenes, gráficos, entre otros.

CSS: Cascading Style Sheets es un lenguaje de diseño gráfico para definir ycrear la presentación de un documento estructurado escrito en un lenguajede marcado. Es muy usado para establecer el diseño visual de los documen-tos web.

JavaScript: es un lenguaje de programación interpretado, que se define comoorientado a objetos, basado en prototipos, imperativo, débilmente tipado y


dinámico. Se utiliza principalmente en su forma del lado del cliente, im-plementado como parte de un navegador web permitiendo mejoras en lainterfaz de usuario y páginas web dinámicas

Bootstrap: es un conjunto de herramientas de código abierto para diseño deaplicaciones web. Contiene plantillas de diseño con tipografías, formula-rios, botones, cuadros, menús de navegación y otros elementos de diseñobasado en HTML y CSS, así como extensiones de JavaScript adicionales.Como su utilización es en un entorno embebido, se requiere una compi-lación de las herramientas más reducida que solo abarque los elementosutilizados.

La interfaz web fue implementada utilizando técnicas de Responsive Web Design(RWD) para que permita su correcta visualización en distintos dispositivos, na-vegadores y resoluciones de pantalla.

Interfaz web embebida

A continuación se presenta la interfaz web embebida diseñada e implementadapara el monitoreo, configuración y control del proceso de fermentación de cer-veza artesanal. Consta de una barra de navegación en la parte superior, que sevisualiza en la figura 3.13, donde a izquierda se visualiza el nombre de la cer-vecería que permite el acceso a la página principal, mientras que a derecha sevisualiza una pestaña de monitoreo y otra de control, que permiten el acceso acuatro pantallas distintas:

Monitoreo de fermentación: muestra el estado de sensores, alarmas y actuado-res, los valores actuales de los procesos y las estadísticas. Observable en lasfiguras 3.14, 3.15 y 3.16.

Control de fermentación: muestra los controles de los procesos y las alarmas.Permite la iniciación, pausado, finalización y configuración de los procesosy la activacion y desactivacion de las alarmas. Observable en las figuras 3.17y 3.18.

Control de red: muestra la configuración actual de la red del servidor. Permiterealizar cambios en ella. Observable en la figura 3.19.

Control de GPRS: muestra la señal del módulo GPRS y la configuración delos números de celular a los cuales se envían reportes. Permite la activacióny desactivación de los mismos, y modificarlos. Observable en la figura 3.20.

FIGURA 3.13: Barra de navegacion de la interfaz web

En la página monitoreo de fermentación, que se visualiza en las figuras 3.14, 3.15y 3.16, se pueden observar tres grandes bloques de información, referidos a lossensores, alarmas y actuadores, respectivamente.

Dentro del bloque de los sensores se visualizan los cinco procesos disponibles,cuatro procesos de fermentación y uno de llenado de tanque junto al tiempo ac-tual de proceso, el valor actual, las estadísticas, el estado del proceso y del sensor.


El tiempo actual del proceso, el valor actual y los estados son resaltados en dis-tintos colores dependiendo del estado del sistema en cada momento.

En el bloque de alarmas se visualizan todas las alarmas activas, que cuando noestán disparadas no se resaltan en color, y cuando están activas se resaltan enverde para la alarma de proceso en marcha y en rojo para las alarmas de procesofinalizado y temperatura fuera de rango.

Por último, el apartado de actuadores, muestra los actuadores correspondientesa las cuatro electroválvulas, resaltándolos con color verde en caso de estar encen-didos.

FIGURA 3.14: Página de monitoreo de los sensores

FIGURA 3.15: Página de monitoreo de las alarmas


FIGURA 3.16: Página de monitoreo de los actuadores

En la página control de fermentación, que se visualiza en la figura 3.17, se puedenobservar distintos formularios para la configuración de cada proceso visualizadoen la página monitoreo de fermentación. Se visualizan los valores tiempo de con-trol, temperatura máxima y mínima de control, junto a un botón que es verdecuando se desea iniciar el proceso o rojo cuando se desea finalizar o pausar. Asi-mismo, en la figura 3.18 se visualizan las alarmas junto a un botón de activar enverde o desactivar en rojo, dependiendo de si estaban desactivadas o activadas,respectivamente.

FIGURA 3.17: Página de control de los sensores

En la página control de red, visible en la figura 3.19, se visualiza un formulariocon la dirección IP, máscara de red y puerta de enlace de la red.


FIGURA 3.18: Página de control de las alarmas

FIGURA 3.19: Página de control de la red del servidor web

En la página de control de GPRS, que se muestra en la figura 3.20, se visualizala señal del módulo GPRS junto a un formulario de modificación, activación ydesactivación de los números de celular. Particularmente, cada numero de celulartiene a su derecha un boton de activación en verde o uno de desactivación en rojo,dependiendo de si se encuentra desactivado o activado, respectivamente.

Toda la información de la página se actualiza periódicamente cada un segundo ymedio mediante el método AJAX.

Por último, si el usuario intenta acceder a alguna página que no se encuentradentro del servidor, se desplegará la vista que se muestra en la figura 3.21.

3.3. Diseño e Implementación de prototipo de hardware y gabinete 33

FIGURA 3.20: Página de control del módulo GPRS

FIGURA 3.21: Página 404 - Page not found

3.3. Diseño e Implementación de prototipo de hardware ygabinete

En este capítulo se detallan las consideraciones de diseño que se tuvieron en cuen-ta para realizar un primer prototipo del hardware del sistema.

3.3.1. Diseño de hardware

Una vez diseñado el firmware y software de la web embebida, se procedió aldiseño e implementación de un circuito electrónico y gabinete que permitieranrealizar ensayos de este primer prototipo en planta. En la figura 3.22 se visualizala interacción del prototipo con el entorno en la planta. El mismo interactúa conlas electroválvulas que comandan la refrigeración de cada tanque, los sensoresdentro de los tanques y un equipo conectado mediante red LAN.


FIGURA 3.22: Interacción del prototipo con la planta

Se diseñaron dos placas a modo de prototipo, una conteniendo el módulo GPRSque se conecta vía RS232 con la plataforma CIAA-NXP y otra estilo poncho, queva directamente conectada a la plataforma, que posee la interfaz de visualizacióny panel de control, las entradas de los sensores y las entradas de alimentación. Enla figura 3.23 se muestra la interconexión de la plataforma CIAA-NXP con ambasplacas diseñadas.

FIGURA 3.23: Conexión de la CIAA-NXP con las placas diseñadas

Para el diseño de la placa del módulo GPRS, se requirió de adaptación de nivelesde tensión para poder interactuar con la CIAA-NXP. Para ello se utilizó el inte-grado MAX3232 y el circuito esquemático es el que se muestra en la figura 3.24.


FIGURA 3.24: Circuito esquemático de la placa del módulo GPRS

Con el esquemático diseñado, se continuó con la elaboración del circuito impresode las placas. El ruteo de la placa del módulo GPRS es visible en la figura 3.25,mientras que el modelo 3D resultante se muestra en la figura 3.26.

(A) Ruteo frontal de la placa del móduloGPRS

(B) Ruteo trasero de la placa del móduloGPRS

FIGURA 3.25: Ruteo de la placa del módulo GPRS


FIGURA 3.26: Modelo 3D del diseño de PCB de la placa del mó-dulo GPRS

Para el diseño de la placa estilo poncho se utilizaron circuitos básicos para leds,botones y entradas de los sensores que se pueden visualizar en la figura 3.27.

(A) Circuito esquemáticode los LEDS de la placa

poncho(B) Circuito esquemáticode los botones de la placa

poncho

(C) Circuito esquemáticode las entradas de los sen-sores de la placa poncho

FIGURA 3.27: Circuitos esquemáticos de la placa poncho

El ruteo y modelo 3D final se pueden visualizar en las figuras 3.28 y 3.29, respec-tivamente.

(A) Ruteo frontal de la placa estilo poncho (B) Ruteo trasero de la placa estilo poncho

FIGURA 3.28: Ruteo de la placa estilo poncho


FIGURA 3.29: Modelo 3D del diseño de PCB de la placa poncho

Por una cuestión de costos, tiempos y de que se trata de un primer prototipo,ambas placas fueron realizadas y soldadas de forma casera.

3.3.2. Diseño de gabinete

Una vez que las placas se soldaron y verificaron, se continuó con el diseño yrealización de un gabinete de prototipado experimental que permitiera realizaralgunos ensayos en planta. El diseño del mismo se muestra en la figura 3.30.

FIGURA 3.30: Modelo 3D del diseño de gabinete

El gabinete fue diseñado mediante un software online, y luego realizado a partirde una caja estanca perforada y cortada, con frente, soportes internos y cartelesrealizados mediante impresión 3D. Se realizaron once orificios para los cables delos sensores, actuadores y red y se situaron sujeta cables a modo de seguridadpara evitar arrancamientos de cables de las borneras de las placas. El frente pre-senta los orificios para los botones, leds de alarmas y el LCD. Nuevamente, todoel armado y montaje del gabinete fue realizado de forma casera.


En la figura 3.31 se muestra el gabinete terminado.

FIGURA 3.31: Gabinete terminado

39

Capítulo 4

Ensayos y Resultados

En este capítulo se detallan los ensayos realizados para comprobar el correctofuncionamiento del firmware y del sistema en general.

4.1. Pruebas funcionales del firmware

Se realizó un test unitario para cada una de las librerías implementadas para elsistema. De esta forma se realizaron tests para las librerías de manejo de LCD,del sensor y del GPRS, no solo buscando verificar el correcto funcionamiento delas librerías, sino también lograr una alta cobertura del código. Las herramientasutilizadas fueron ceedling y gcov, detalladas en la subseccion 3.2.1. Los códigosfuente de los tests más importantes realizados se muestran a continuación:

1 extern l c d _ t lcd ;2 u i n t 8 _ t dataNibble [ 6 ] [ 4 ] ;3

4 void t e s t L c d I n i t ( ) {5 i2cConfig_Expect ( I2C0 , I2C_CLOCK_RATE_10KHZ) ;6

7 setExpectedDataToi2cWrite ( dataNibble [ 0 ] , 0x02 , LCD_COMMAND_TYPE) ;8 setExpectedDataToi2cWrite ( dataNibble [ 1 ] , 0x20 , LCD_COMMAND_TYPE) ;9 setExpectedDataToi2cWrite ( dataNibble [ 2 ] , 0x28 , LCD_COMMAND_TYPE) ;

10 setExpectedDataToi2cWrite ( dataNibble [ 3 ] , 0x0C , LCD_COMMAND_TYPE) ;11 setExpectedDataToi2cWrite ( dataNibble [ 4 ] , 0x06 , LCD_COMMAND_TYPE) ;12 setExpectedDataToi2cWrite ( dataNibble [ 5 ] , 0x80 , LCD_COMMAND_TYPE) ;13

14 l c d I n i t (0 x3f ) ;15

16 TEST_ASSERT_EQUAL_UINT8_MESSAGE( lcd . i2cAddress , 0 x3f , " address " ) ;17 TEST_ASSERT_EQUAL_INT32_MESSAGE( lcd . cursorMode , LCD_CURSOR_OFF, "

cursor " ) ;18 TEST_ASSERT_EQUAL_INT32_MESSAGE( lcd . displayMode , LCD_DISPLAY_ON, "

displayMode " ) ;19 TEST_ASSERT_EQUAL_INT32_MESSAGE( lcd . backlightMode , LCD_BACKLIGHT_ON, "

backlightMode " ) ;20 TEST_ASSERT_EQUAL_INT32_MESSAGE( lcd . s ize , LCD_SIZE_8X5 , " s i z e " ) ;21 }22

23

24 void t e s t L c d W r i t e S t r i n g ( ) {25 char s t r i n g [ ] = " Hola " ;26 setExpectedDataToi2cWrite ( dataNibble [ 0 ] , ’H’ , LCD_DATA_TYPE) ;27 setExpectedDataToi2cWrite ( dataNibble [ 1 ] , ’ o ’ , LCD_DATA_TYPE) ;28 setExpectedDataToi2cWrite ( dataNibble [ 2 ] , ’ l ’ , LCD_DATA_TYPE) ;29 setExpectedDataToi2cWrite ( dataNibble [ 3 ] , ’ a ’ , LCD_DATA_TYPE) ;

40 Capítulo 4. Ensayos y Resultados

30 l c d Wr i t e S t r in g ( " Hola " ) ;31 }

ALGORITMO 4.1: Codigo fuente de los tests del módulo LCD.

1 oneWireSensor_t me;2

3 void t e s t F i l l S e n s o r S c r a t c h p a d ( ) {4 u i n t 8 _ t i ;5 u i n t 8 _ t scratchpad [ ] = { 8 5 , 1 , 75 , 70 , 127 , 255 , 12 , 16 , 1 9 0 } ;6

7 /* Primer caso : Primer RESET f a l l a */8 setExpectedDataToResetFunction ( t rue ) ;9 TEST_ASSERT_EQUAL( f a l s e , oneWireSensorFi l lScratchpad (&me) ) ;

10 r e s e t T e s t ( ) ;11

12 /* Segundo caso : Segundo RESET f a l l a */13 setExpectedDataToResetFunction ( f a l s e ) ;14 setExpectedDataToWriteOneByteFunction (SKIP_ROM) ;15 setExpectedDataToWriteOneByteFunction (CONVERT_T) ;16 delay_Expect (me . operat ion . delay ) ;17 setExpectedDataToResetFunction ( t rue ) ;18 TEST_ASSERT_EQUAL( f a l s e , oneWireSensorFi l lScratchpad (&me) ) ;19 r e s e t T e s t ( ) ;20

21 /* Tercer caso : CRC l e i d o i n c o r r e c t o */22 setExpectedDataToResetFunction ( f a l s e ) ;23 setExpectedDataToWriteOneByteFunction (SKIP_ROM) ;24 setExpectedDataToWriteOneByteFunction (CONVERT_T) ;25 delay_Expect (me . operat ion . delay ) ;26 setExpectedDataToResetFunction ( f a l s e ) ;27 setExpectedDataToWriteOneByteFunction (SKIP_ROM) ;28 setExpectedDataToWriteOneByteFunction (READ_SCRATCHPAD) ;29

30 f o r ( i =0 ; i <SCRATCHPAD_LENGTH; i ++) {31 setExpectedDataToReadOneByteFunction (0xAA) ;32 }33

34 TEST_ASSERT_EQUAL( f a l s e , oneWireSensorFi l lScratchpad (&me) ) ;35 r e s e t T e s t ( ) ;36

37 /* Cuarto caso : Todo funciona + CRC l e i d o correctamente */38 setExpectedDataToResetFunction ( f a l s e ) ;39 setExpectedDataToWriteOneByteFunction (SKIP_ROM) ;40 setExpectedDataToWriteOneByteFunction (CONVERT_T) ;41 delay_Expect (me . operat ion . delay ) ;42 setExpectedDataToResetFunction ( f a l s e ) ;43 setExpectedDataToWriteOneByteFunction (SKIP_ROM) ;44 setExpectedDataToWriteOneByteFunction (READ_SCRATCHPAD) ;45

46 f o r ( i =0 ; i <SCRATCHPAD_LENGTH; i ++) {47 setExpectedDataToReadOneByteFunction ( scratchpad [ i ] ) ;48 }49

50 TEST_ASSERT_EQUAL( true , oneWireSensorFi l lScratchpad (&me) ) ;51

52 }

ALGORITMO 4.2: Codigo fuente de los tests del modulo GPRS.

1 char answerOK [ ] = "OK" ;2 char answerMayor [ ] = ">" ;3 char answerDosPuntos [ ] = " : " ;

4.1. Pruebas funcionales del firmware 41

4 char s i g n a l [ ] = "AT+CSQ: 22 , " ;5

6 void testgprsSendSMS ( ) {7 uartWri teStr ing_Expect ( UART_RS232 , ATCMGF) ;8 setGetResponseExpectedData ( answerOK , 2 ) ;9 inaccurateDelayMS_Expect ( 2 0 0 ) ;

10 uartWri teStr ing_Expect (GPRS_UART, ATCMGS) ;11 uartWri teStr ing_Expect (GPRS_UART, " 2396484848 " ) ;12 uartWri teStr ing_Expect (GPRS_UART, " \"\ r\n" ) ;13 setGetResponseExpectedData ( answerMayor , 1 ) ;14 uartWri teStr ing_Expect ( UART_RS232 , " Hola " ) ;15 uartWriteByte_Expect ( UART_RS232 , 0x1A ) ;16 inaccurateDelayMS_Expect ( 3 0 0 ) ;17 setGetResponseExpectedData ( answerOK , 2 ) ;18

19 gprsSendSMS ( " Hola " , 0 ) ;20 }21

22 void t e s t g p r s G e t S i g n a l ( ) {23 u i n t 8 _ t i , byteReceived ;24 /* Primer Caso − Timeout */25 uartWri teStr ing_Expect (GPRS_UART, ATCSQ) ;26 setGetResponseExpectedData ( answerOK , 2 ) ;27 delayConfig_Ignore ( ) ;28 delayRead_IgnoreAndReturn ( t rue ) ;29 TEST_ASSERT_EQUAL( gprsGetSignal ( ) , GPRS_NOT_WORKING) ;30 r e s e t T e s t ( ) ;31 /* Segundo Caso − Todo c o r r e c t o */32 uartWri teStr ing_Expect (GPRS_UART, ATCSQ) ;33 setGetResponseExpectedData ( answerOK , 2 ) ;34 delayConfig_Ignore ( ) ;35 delayRead_IgnoreAndReturn ( f a l s e ) ;36 f o r ( i =0 ; i <11; i ++) {37 uartReadByte_ExpectAndReturn ( UART_RS232 , &byteReceived , UART_OK) ;38 uartReadByte_IgnoreArg_data ( ) ;39 uartReadByte_ReturnThruPtr_data (& s i g n a l [ i ] ) ;40 }41 TEST_ASSERT_EQUAL( gprsGetSignal ( ) , GPRS_WORKING) ;42 }

ALGORITMO 4.3: Codigo fuente de los tests del modulo GPRS.

Los resultados de los tests se visualizan en la tabla 4.1, mientras que los resultadosde la cobertura de visualizan en la figura 4.2.

TABLA 4.1: Resultados de los tests unitarios

Test Aprobado Fallado

LCD 5 0Sensor OneWire 5 0GPRS 6 0


TABLA 4.2: Resultados de los tests de cobertura

Sensor Líneas ejecutadas Saltos ejecutados Llamadas ejecutadas

LCD 76.81 % 100 % 73.68 %Sensor OneWire 100 % 100 % 100 %GPRS 100 % 100 % 100 %

4.2. Ensayos de sistema

Se realizaron pruebas de sistema que permitieron verificar el correcto funciona-miento del firmware y hardware en conjunto, y a su vez permitieran validar losrequerimientos. Para tal fin, se utilizó una plantilla de casos de prueba de la pá-gina web Software Testing Help [13], que permite indicar el test a realizar, quien lodiseñó, las pre y post-condiciones, los pasos a seguir, los requerimientos para loscuales fue diseñado dicho test, entre otras cosas. Los tests a realizar se dividieronen tres módulos:

IPCF: incluye tests que apuntan a verificar y validar los requerimientos dela interfaz de visualización, panel de control y control del proceso de fer-mentación.

W: incluye tests que buscan verificar y validar los requerimientos de la in-terfaz web y el control del proceso de fermentación.

GPRS: incluye tests que buscan verificar y validar los requerimientos delmódulo GPRS.

En el diseño de los tests se utilizó la técnica de inyección de fallas para evaluarla respuesta del sistema frente a las distintas condiciones de alarma posibles. Elensayo consiste en forzar las entradas de los sensores a valores que disparen lascondiciones de alarma y contrastar las acciones de control del sistema con lasesperadas y el envío de reportes vía SMS en los casos esperados, o incluso desco-nectar los sensores para corroborar que las alarmas correspondientes se muestran.También se utilizaron valores de configuración en los extremos, o que no fueranválidos o esperados para verificar que el sistema funciona de forma adecuada.Asimismo, se realizaron ensayos sobre cada posible comando e interacción con lainterfaz web, interfaz de visualización y panel de control. Todos los tests fueronrealizados de forma manual mediante la interacción con el prototipo. Los testsdiseñados se muestran de forma resumida y a modo de ejemplo en las figuras 4.1y 4.2.

Los documentos de los tests realizados son enviados a los jurados junto con lapresente memoria, en conjunto con un documento de elicitacion de requerimien-tos, para poder constatar que requerimientos verifica cada test.

4.2. Ensayos de sistema 43

FIGURA 4.1: Ejemplo I de ensayos de sistema

FIGURA 4.2: Ejemplo II de ensayos de sistema


4.3. Ensayos de estabilidad del servidor

Durante los ensayos de sistema se detectó que el servidor web no presentaba laestabilidad esperada, entonces se procedió a realizar ajustes en el uso de stack delas distintas tareas del sistema, ajustes en la heap y a realizar ensayos de estabili-dad.

Luego de dos series de ajustes se obtuvo una estabilidad mejor, permitiendo quela página web pasara de actualizarse cada cinco segundos a un segundo y mediosin caídas durante pruebas de más de una hora de duración. Incluso cuando elsistema es actualizado a una tasa mayor a un segundo, la caída detectada no duramás de diez segundos, logrando una alta disponibilidad del servidor.

Para la medición del uso de stack y heap se utilizó el software FreeRTOS TAD(TaskAware Debugger), que es un plugin para Eclipse. En la figura 4.3 se visualiza el usode stack de las tareas a lo largo de los ajustes.

FIGURA 4.3: Tabla del uso de stack por partes de las tareas delsistema

45

Capítulo 5

Conclusiones

En este capítulo se realiza una conclusión sobre el trabajo realizado hasta el mo-mento y se detallan los pasos a seguir próximamente.

5.1. Conclusiones generales

En la presente memoria se documentó la implementación de un prototipo de sis-tema de monitoreo, control y alarmas del proceso de fermentación de la cervezaartesanal.

Se desarrolló e implementó un prototipo de hardware y firmware que permite mo-nitorear y controlar hasta cuatro tanques de fermentación/maduración en formaremota, mediante el uso de una interfaz web embebida en la plataforma CIAA-NXP y directamente en planta mediante una interfaz de visualización y panelde control, con su correspondiente manual de uso. Asimismo, permite al usuariomodificar los parametros de configuración y comandar los distintos procesos.

Se cumplieron los requisitos en su gran mayoría, salvo aquellos que fueron pos-puestos para una segunda etapa, como el caso de los requerimientos 7 y 4, deta-llados en la subsección 2.1.2.

Se realizó una extensa documentación del plan de trabajo, diseño e implementa-ción de hardware y firmware y tests realizados.

Durante el desarrollo de este Trabajo Final se aplicaron conocimientos adquiri-dos a lo largo de la Carrera de Especialización en Sistemas Embebidos. Más alláde que todas las asignaturas cursadas aportaron conocimientos necesarios y ex-periencia para la práctica profesional en el área de los Sistemas Embebidos, seresaltan a continuación aquellas materias de mayor relevancia para este trabajo:

Arquitectura de microprocesadores: resultó necesario tener conocimientossobre la Arquitectura ARM Cortex M para la programación de la plataformaCIAA-NXP y el uso de los periféricos.

Programación de microprocesadores: se utilizaron buenas prácticas de pro-gramación de Lenguaje C para microcontroladores y periféricos.se empleóun formato de código consistente: comentarios en las declaraciones de fun-ciones y partes importantes del código, constantes en mayúsculas, camel-Case para poner nombres significativos a funciones y variables y se obtuvoun código más modular, legible y reutilizable.

46 Capítulo 5. Conclusiones

Ingeniería de Software en Sistemas Embebidos: se utilizaron técnicas de eli-citación y especificación de requerimientos, patrones de diseño de arqui-tectura, documentación de código fuente y arquitectura, documentación detests, análisis de código estático y se utilizó Git como sistema de control deversiones.

Gestión de Proyectos en Ingeniería: la elaboración de un Plan de Proyec-to para organizar el Trabajo Final, facilitó la realización del mismo y evitódemoras innecesarias.

Sistemas Operativos de Tiempo Real (I y II): se utilizaron los conocimien-tos adquiridos aplicando FreeRTOS como sistema operativo para el sistemadesarrollado.

Protocolos de Comunicación: se aplicaron los conocimientos obtenidos, es-pecíficamente en los protocolos UART e I2C. Asimismo, para la aprobaciónde dicha materia, se presentó un driver OneWire, que permitió avanzar so-bre la lectura de los sensores de este proyecto, y permitió una mejor y másfácil comprensión sobre la información recolectada acerca de ethernet y elstack TCP/IP lwIP.

Testing de Software Embebido: se aplicaron los conocimientos adquiridosdurante la materia, sobre todo en las áreas de testing unitarios y ensayos desistema y de aceptación.

Diseño de PCB: se aplicaron los conocimientos adquiridos en el diseño deesquemáticos y PCB del sistema.

Por lo tanto, se concluye que los objetivos planteados al comienzo del trabajohan sido alcanzados satisfactoriamente, habiéndose cumplido con los criteriosde aceptación del sistema final y se han obtenido conocimientos valiosos para laformación profesional del autor.

5.2. Próximos pasos

Resulta imprescindible identificar el trabajo futuro, para dar continuidad al es-fuerzo realizado hasta el momento y poder realizar un producto comercialmenteatractivo. A continuación se listan las líneas de trabajo más trascendentes:

Analizar estadísticamente el uso del sistema desarrollado, especialmente enla adquisición de la temperatura de los tanques de fermentación y, eventual-mente, realizar una etapa de calibración del sistema.

Analizar el comportamiento del sistema actual en el entorno de la planta,y comprobar su correcto funcionamiento en tiempo extendido con respectoa ruido electromagnético, humedad, vibraciones, temperaturas, entre otrasvariables del entorno.

Realizar un hardware de forma más modular que permita el desarrollo eimplementación de un gabinete final de forma más sencilla y que permitael mantenimiento y reparación del equipo.

Realizar un gabinete definitivo que permita ser fácilmente replicado.

Implementar un hardware con fuente incluida.

5.2. Próximos pasos 47

Extender el control remoto más allá de una red LAN y mejorar la interfazweb.

Extender el sistema a las demás etapas del proceso productivo de la cervezaartesanal, e incluso extenderlo más allá de este proceso productivo.

Implementar el envío de reportes diarios por mail.

49

Apéndice A

Manual de usuario

SECASistema de Elaboracion de Cerveza Artesanal

Manual de Usuario

17 de noviembre de 2018

Ing. Matias Alvarez

¡Advertencia!:

¡Cualquier cambio en este equipo sin autorizacion expresa de la empresa, puede causar danos ensu equipamiento! Este equipo cuenta con el sello de seguridad electrica que garantiza su uso seguro encondiciones normales de operacion en interiores.

Nota importante:

La empresa no se hace responsable por posibles danos causado por el uso impropio de este equipoy por el funcionamiento anormal de los dispositivos que se le conecten.

La tension de alimentacion debe estar conforme con lo especificado en la siguiente seccion y debeser estable.

No se debe usar SECA en entornos sujetos a fuertes vibraciones o solicitaciones mecanicas,ambientes con altas temperaturas o corrosivos, ni sumergido bajo agua.

La/s sonda/s del sistema esta/n integrada/s con un sensor Maxim ds28b20. Atengase de formarigurosa a las instrucciones para conectar el cable debido a que cualquier error podrıa danar elsensor y el equipo.

Por favor contacte a su distribuidor si el equipo SECA funciona incorrectamente.

El contenido de este manual puede ser sujeto a modificaciones sin previo aviso. Asegurese decontar con la ultima version del documento disponible en https://github.com/alvmatias/SECA.

Version 05-09-2018 Firmware 1.0.0

Indice

1 Introduccion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . IV

1.1 Caracterısticas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . v1.2 Especificaciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . v1.3 Requerimientos mınimos del sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . . vi

2 Gabinete . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . VII

2.1 Panel frontal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vii2.2 Panel lateral izquierdo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . viii2.3 Panel lateral derecho . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ix2.4 Panel inferior . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ix

3 Interfaz de visualizacion y panel de control . . . . . . . . . . . . . . . . . . . . . . . . X

3.1 Indicadores de estado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . x3.2 Interfaz de visualizacion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . x3.3 Panel de control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . x3.4 Instrucciones de uso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xi

4 Interfaz web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . XII

Indice de figuras

1 Diagrama de conexion del sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . iv2 Panel Frontal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vii3 Panel lateral izquierdo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . viii4 Panel Inferior . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ix5 Panel Inferior . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ix6 Monitoreo de los sensores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xii7 Monitoreo de las sensores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiii8 Monitoreo de los actuadores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiii9 Campos de control de los sensores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiv10 Botones de control de las alarmas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xv11 Campos de control de la red . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xvi12 Campos de control del GPRS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xvi

iii

1. Introduccion

SECA es un equipo de medicion y control de la etapa de fermentacion/maduracion del procesode elaboracion de cerveza artesanal. Permite el llenado, medicion y control de temperatura de hasta4 tanques de fermentacion/maduracion, con configuracion y visualizacion de parametros medianteinterfaz de visualizacion y panel de control en planta y de forma remota vıa web, y el reporte dealarmas vıa SMS.

Con la tecnologıa de control y visualizacion remota, el usuario podra controlar el comienzo,pausado y finalizacion del proceso de fermentacion/maduracion de cualquiera de los tanques desdecualquier navegador en cualquier computadora o dispositivo movil conectado a la red LAN. Tambienpodra visualizar el estado de los sensores, actuadores, alarmas y estadısticas de los distintos procesos.Por otra parte, podra configurar la red y los numeros de celular a cuales enviar alertas. No es necesarioningun software especial ni es necesario introducir hardware adicional en la computadora desde dondese va a operar.

Con la tecnologıa de interfaz de visualizacion y panel de control, podra controlar y configurar elproceso de fermentacion/maduracion de cualquiera de los 4 tanques y visualizar sus parametros enplanta.

Un posible diagrama de conexion se muestra en la figura 1 donde se pueden ver multiples tanquesconectados al equipo SECA, junto con una conexion vıa ETHERNET a una computadora.

Figura 1: Diagrama de conexion del sistema

iv

1.1. Caracterısticas

Alimentacion con 24V y 5V separada.

Web server incorporado que puede ser accedido desde la interfaz ethernet con conector RJ45.

Soporta multiples navegadores: IE, Chrome, Firefox, etc.

Soporta HTTP.

Interfaz de visualizacion de 4 lıneas x 20 caracteres con fondo retroiluminado.

Panel de control con hasta 5 teclas(ON/OFF, MODE, SET, UP, DOWN).

Envıo de SMS vıa GPRS.

Leds de alarma.

Led testigo de alimentacion de 24V.

Led testigo de alimentacion de 5V.

4 conexiones para sensores Maxim ds18b20.

1 conexion para motor de llenado.

4 conexiones para electrovalvulas.

Funciones principales:

1. Control y medicion de temperatura de hasta 4 tanques de fermentacion/maduracion.

2. Control de llenado de tanque de fermentacion/maduracion.

3. Alarma de valor de sensor fuera de lımite(Tanto superior como inferior)

4. Alarma de proceso en marcha.

5. Alarma de proceso finalizado.

6. Alarma de error de sensor.

7. Ajuste de parametros de control(Cotas maximas, mınimas y tiempo de control)

8. Visualizacion de parametros de control, valores actuales, maximos y mınimos.

9. Ajuste de parametros de red.

10. Seleccion y activacion/desactivacion de hasta 2 numeros de celular a los cuales enviar aler-tas.

11. Seleccion de alarmas a mostrar en la web.

1.2. Especificaciones

Medida del panel: 20cmx25cm.

Temperatura ambiente: -5∼55 ◦C.

Tension de alimentacion: 5VDC y 24VDC por separado.

Rango medicion: -55∼125 ◦C.

Precision: +/- 0,5 ◦C en el rango -10∼85 ◦C.

Resolucion: 12 bits o 0,0625 ◦C.

Tiempo conversion temperatura : 750ms.

v

1.3. Requerimientos mınimos del sistema

Sistema operativo Windows o Linux con navegador IE, Google Chrome, Firefox o cualquier otro.

Placa de red con conector RJ45

Red LAN configurada

vi

2. Gabinete

2.1. Panel frontal

Figura 2: Panel Frontal

En el panel frontal se puede observar de arriba hacia abajo y de izquierda a derecha:

Led Verde de proceso encendido.

Led Rojo de proceso finalizado.

Led Rojo de temperatura fuera de rango.

Led Amarillo de error de sensor.

Display LCD.

Panel de control de 5 teclas: UP, MODE, ON/OFF, SET, DOWN.

vii

2.2. Panel lateral izquierdo

Figura 3: Panel lateral izquierdo

En el panel lateral izquierdo se puede observar de arriba hacia abajo:

Led testigo alimentacion 5VDC.

Entradas: Entrada de alimentacion externa 5VDC.

Entradas: Entrada de alimentacion externa 24VDC.

Led testigo Alimentacion 24VDC.

viii

2.3. Panel lateral derecho

Figura 4: Panel Inferior

En el panel inferior se puede observar de izquierda a derecha:

Salidas: Entradas 1 a 4 para electrovalvulas.

Salidas: Entrada 5 para motor de llenado.

2.4. Panel inferior

Figura 5: Panel Inferior

En el panel inferior se puede observar de izquierda a derecha:

Entradas: Entradas 1 a 4 para sensor Maxim ds18b20.

Entradas: Entrada para conexion ETHERNET.

ix

3. Interfaz de visualizacion y panel de control

La interfaz de visualizacion y panel de control del sistema se visualizan en el panel frontal delgabinete, figura 2, y se detallan sus partes componentes en las proximas subsecciones.

3.1. Indicadores de estado

Posee un total de 4 leds de estado:

Led proceso encendido: Si el proceso de medicion y control del sensor respectivo esta encendido,este led se encontrara encendido.

Led proceso finalizado: Si el proceso de medicion y control del sensor respectivo fue encendido yse ha alcanzado el tiempo maximo de control, este led estara encendido.

Led valor de sensor fuera de lımite: Si el proceso de medicion y control del sensor respectivo estaencendido, y el valor del sensor esta fuera de los lımites configurados, este led estara encendido.

Led error de sensor : Si el proceso de medicion y control del sensor respectivo esta encendido, yel sensor no funciona, este led estara encendido.

3.2. Interfaz de visualizacion

La interfaz de visualizacion posee dos modos de funcionamiento:

Modo de visualizacion automatica de informacion: Durante este modo, el cual es el modo pordefecto, todos los sensores, junto a su estado y valores, son mostrados a intervalos de 1 segundoentre sı.

Modo de visualizacion manual de informacion: Durante este modo, para cambiar de sensor

visualizado se deben presionar las teclas UP y DOWN. Importante: Para especificarparametros de los sensores se debe haber ingresado en este modo previamente. Si no se presionanbotones durante 30 segundos, se vuelve automaticamente al estado de visualizacion automaticade informacion.

Ademas de los modos de funcionamiento, posee distintas visualizaciones de informacion:

Inicio del sistema: Al iniciar el sistema es posible visualizar en la interfaz un mensaje de bien-venida en conjunto con un mensaje indicando el inicio del sistema.

Visualizacion de informacion: Tanto en modo automatico como manual, es posible visualizaren la interfaz, el numero de etapa, el id unıvoco del sensor, su estado(apagado o pausado) osu valor actual, maximo y mınimo(en formato TT.T ◦C ) o su tiempo de control(en formatoDD:HH:MM:SS ), si el sensor se encuentra en funcionamiento, dependiendo del tipo de sensor.

Especificacion de parametros: Al especificar los parametros de control de un sensor, es posiblevisualizar en la interfaz, el numero de etapa, el id unıvoco del sensor, el tiempo de control enformato DD:HH:MM:SS y los valores maximo y mınimo en formato TT.T ◦C.

3.3. Panel de control

El panel de control posee 5 botones:

ON/OFF : Boton de encendido/pausa/finalizacion de la medicion y control del sensor especifi-cado.

x

MODE : Boton de cambio de modo de funcionamiento de la interfaz de visualizacion. Por otrolado, tambien permite pasar al siguiente parametro a especificar cuando el usuario se encuentraespecificando los parametros de control del sensor.

SET : Boton de inicio de especificacion de parametros y de confirmacion de dıgito ingresado.

UP : Boton de avance de sensor en modo manual, y de dıgito siguiente en especificacion deparametros.

DOWN : Boton de retroceso de sensor en modo manual, y de dıgito anterior en especificacion deparametros.

3.4. Instrucciones de uso

Cambiar modo de funcionamiento de interfaz de visualizacion;

1. Presionar el boton MODE. Importante:: La interfaz de visualizacion debe encon-trarse visualizando informacion respectiva a los sensores.

Especificar parametros de control de un determinado sensor :

1. Presionar el boton MODE para cambiar a modo de visualizacion manual de informacion.

2. Buscar el sensor requerido mediante el uso de los botones UP y/o DOWN.

3. Presionar el boton SET para especificar los parametros.

4. Presionar el boton SET para pasar al siguiente dıgito del parametro a especificar o el

boton MODE para pasar al siguiente parametro a especificar. Importante:: La cotamaxima de control debe ser mayor o igual a la cota mınima. Los cambios de cada parametrose guardan al finalizar el ingreso del ultimo dıgito.

Iniciar medicion y control del sensor respectivo:



3. Presionar el boton ON/OFF para iniciar el proceso.

Pausar medicion y control del sensor respectivo:



3. Presionar el boton ON/OFF para finalizar el proceso.

Finalizar medicion y control del sensor respectivo:



3. Presionar el boton SET para especificar los parametros.

4. Setear el tiempo de control a 0.

5. Presionar el boton MODE para saltear los demas parametros a especificar y guardar loscambios.

6. Presionar el boton ON/OFF para finalizar el proceso.

xi

4. Interfaz web

La interfaz web cuenta con dos secciones. Una seccion para el monitoreo del estado de sensores,alarmas y actuadores de las etapas del proceso y otra para el control de sensores y alarmas de lasetapas del proceso, red y GPRS. Ambas secciones son accesibles desde la barra de navegacion en laparte superior de la pagina web. La seccion de monitoreo se puede observar en las figuras 6, 7 y 8 yla seccion de control en las figuras 9, 10, 11 y 12.

Figura 6: Monitoreo de los sensores

Descripcion de los campos de izquierda a derecha:

#: Descripcion del sensor y su id unıvoco.

Tiempo Transcurrido: Tiempo en formato DD:HH:MM:SS que lleva el proceso encendido, sincontar los tiempos de pausa. Si este tiempo es menor que el tiempo maximo de control, sevisualiza en verde.

Valor Actual : Ultimo valor leıdo por el sensor en formato TT.T ◦C. Este valor estara en verdesi se encuentra dentro del rango de temperatura y el actuador esta apagado, en amarillo si seencuentra dentro del rango de temperatura y el actuador esta encendido o en rojo si se encuentrafuera del rango de temperatura.

Promedio: Valor promedio de las mediciones del sensor en formato TT.T ◦C.

Maximo: Valor maximo leıdo por el sensor en formato TT.T ◦C.

Mınimo: Valor mınimo leıdo por el sensor en formato TT.T ◦C.

Estado: Indica el estado del proceso:

1. ON: Proceso encendido.

2. PAUSED: Proceso pausado.

3. OFF: Proceso finalizado.

¿Funcionando? : Indica el estado de funcionamiento del sensor:

1. SI: Sensor funcionando correctamente, no hay error en la sonda.

2. NO: Sensor no esta funcionando, error en la sonda.

xii

Figura 7: Monitoreo de las sensores


#: Descripcion de la alarma y su id unıvoco.

Estado: Indica el estado de la alarma:

1. ON: Alarma activada.

2. OFF: Alarma desactivada.

Importante: Las alarmas de proceso finalizado y temperatura fuera de rango se resaltanen rojo cuando estan encendidas, mientras que la alarmas de proceso en marcha se resalta en verde.

Importante: Solo apareceran en esta tabla aquellas alarmas que se encuentren activas enla seccion de control. Por defecto todas estan activadas.

Figura 8: Monitoreo de los actuadores


xiii

#: Descripcion del actuador y su id unıvoco.

Estado: Indica el estado del actuador:

1. ON: Actuador encendido.

2. OFF: Actuador apagado.

Importante: Los actuadores que estan encendidos se resaltan en verde.

Figura 9: Campos de control de los sensores


#: Descripcion del sensor y su id unıvoco.

Tiempo de Control : Tiempo en formato DD:HH:MM que el usuario desea que dure el proceso.

Importante: Para el caso del motor de llenado el formato es MM:SS.

Importante: Completar este campo antes de presionar Iniciar.

Cota Mınima: Temperatura de control inferior con formato TT.T ◦C del proceso.

Importante: Completar este campo antes de presionar Iniciar.

Tiempo de Control : Temperatura de control superior con formato TT.T ◦C del proceso.

Importante: Completar este campo antes de presionar Iniciar o Finalizar si desea finalizarel proceso y no pausarlo.

Control : Boton de control del proceso:

1. Iniciar: Aparecera cuando el proceso esta apagado y se lo quiere iniciar.

2. Reiniciar: Aparecera cuando el proceso esta pausado y se lo quiere retomar.

3. Finalizar: Aparecer cuando el proceso esta encendido y se lo quiere pausar/finalizar.

Importante: Para iniciar el proceso, complete todos los campos anteriores y presione elboton Iniciar. Para pausar, simplemente presione el boton Finalizar. Para finalizar el proceso, modi-fique el campo Tiempo de Control para que tenga un tiempo menor al campo Tiempo Transcurridode la seccion de monitoreo y presione el boton Finalizar.

xiv

Figura 10: Botones de control de las alarmas


#: Descripcion de la alarma y su id unıvoco.

Control : Boton de control del proceso:

1. Activar: Aparecera cuando la alarma este desactivada.

2. Desactivar: Aparecera cuando la alarma este activada.

Importante: Para desactivar una alarma y que no aparezca en la seccion de monitoreo, presionarel boton Desactivar. Para activar una alarma y que aparezca en la seccion de monitoreo, presionar elboton Activar.

xv

Figura 11: Campos de control de la red

Descripcion de los campos de arriba hacia abajo:

IP : IP de la red.

Mask : Mascara de red.

Gateway : Puerta de enlace de la red.

Importante: Tener en cuenta que una vez aplicados los cambios, luego de presionado el botonIngresar, la pagina web no sera mas accesible con esa direccion IP, sino con la nueva ingresada.

Importante: Tener en cuenta que una vez aplicados los cambios, luego de presionado el botonIngresar, los cambios deben ser tambien configurados en la red LAN.

Figura 12: Campos de control del GPRS

Descripcion de los campos de izquierda a derecha y de arriba hacia abajo:

xvi

Senal : Intensidad de la senal mostrado en barras, donde:

• Cero barras gris oscuro: Intensidad de senal desconocida.

• Una barra gris oscuro: Intensidad de senal Marginal.

• Dos barras gris oscuro: Intensidad de senal Regular.

• Tres barras gris oscuro: Intensidad de senal Buena.

• Cuatro barras gris oscuro: Intensidad de senal excelente.

Numero de Celular - Opcion 1 : Primer numero de celular al cual se enviaran los reportes.

Numero de Celular - Opcion 2 : Segundo numero de celular al cual se enviaran los reportes.

Importante: Para ingresar nuevos numeros de celular, completar los campos y presionarel boton Ingresar.

Importante: Para activar un numero de celular presionar el boton Activar a su izquierda.Para desactivar un numero de celular presionar el boton Desactivar a su izquierda.

xvii

67

Bibliografía

[1] Mike Belshe, Roberto Peon y Martin Thomson. Hypertext Transfer ProtocolVersion 2 (HTTP/2). RFC 7540. Nov. de 2015. DOI: 10.17487/rfc7540. URL:https://rfc-editor.org/rfc/rfc7540.txt.

[2] Sebastian Catalano. ¿Te tentaste con el boom de la cerveza artesanal u otroemprendimiento? 11 consejos para no fundirte. Disponible: 2018-11-04. 2018.URL: https://www.infobae.com/economia/finanzas-y-negocios/2018/02/11/te-tentaste-con-el-boom-de-la-cerveza-artesanal-u-otro-emprendimiento-11-consejos-para-no-fundirte/.

[3] DS18B20 Programmable Resolution 1-Wire Digital Thermometer. 197487. Rev.4. Dallas Semiconductor. 2015.

[4] EXO S.A. CIAA: Placa lógica de automatización y control industrial.Disponible: 2018-11-04. 2018. URL: http://www.exo.com.ar/ciaa.

[5] Micro-computer Temperature Controller (ETC-200+) Operating instructions.Rev. 1.2. Elitech. 2018.

[6] NXP Semiconductors. LPCOPEN v2.16 Drivers, Middleware and Examples.Disponible: 2018-11-04. URL:http://www.nxp.com/products/microcontrollers-and-processors/arm-processors/lpc-cortex-m-mcus/software-tools/lpcopen-libraries-and-examples:LPC-OPEN-LIBRARIES.

[7] NXP Semiconductors. Web Server Using the MCF51CN Family andFreeRTOS. Disponible: 2018-11-04. URL:https://www.nxp.com/docs/en/application-note/AN3928.pdf.

[8] Proyecto CIAA. CIAA Firmware Project. Disponible: 2018-11-04. 2018. URL:https://github.com/ciaa/firmware_v2.

[9] Proyecto CIAA. Computadora Industrial Abierta Argentina. Disponible:2018-11-04. 2018. URL:http://proyecto-ciaa.com.ar/devwiki/doku.php?id=start.

[10] David Robinson. The Common Gateway Interface (CGI) Version 1.1. RFC3875. Mar. de 2013. DOI: 10.17487/rfc3875. URL:https://rfc-editor.org/rfc/rfc3875.txt.

[11] Savannah. lwIP - A Lightweight TCP/IP stack. Disponible: 2018-11-04. URL:http://git.savannah.gnu.org/cgit/lwip/lwip-contrib.git.

[12] Savannah. lwIP - Wiki - Sample Web Server. Disponible: 2018-11-04. URL:http://lwip.wikia.com/wiki/Sample_Web_Server.

[13] Software Testing Help. Sample Test Case Template with Test Case Examples.Disponible: 2018-11-04. 2018. URL:https://www.softwaretestinghelp.com/test-case-template-examples/.

http://dx.doi.org/10.17487/rfc7540

https://rfc-editor.org/rfc/rfc7540.txt

https://www.infobae.com/economia/finanzas-y-negocios/2018/02/11/te-tentaste-con-el-boom-de-la-cerveza-artesanal-u-otro-emprendimiento-11-consejos-para-no-fundirte/



http://www.exo.com.ar/ciaa

http://www.nxp.com/products/microcontrollers-and-processors/arm-processors/lpc-cortex-m-mcus/software-tools/lpcopen-libraries-and-examples:LPC-OPEN-LIBRARIES



https://www.nxp.com/docs/en/application-note/AN3928.pdf

https://github.com/ciaa/firmware_v2

http://proyecto-ciaa.com.ar/devwiki/doku.php?id=start

http://dx.doi.org/10.17487/rfc3875

https://rfc-editor.org/rfc/rfc3875.txt

http://git.savannah.gnu.org/cgit/lwip/lwip-contrib.git

http://lwip.wikia.com/wiki/Sample_Web_Server

https://www.softwaretestinghelp.com/test-case-template-examples/