Control de termotanque basado en el sistema “Heat...

UNIVERSIDAD DE BUENOS AIRES

FACULTAD DE INGENIERÍA

CARRERA DE ESPECIALIZACIÓN EN SISTEMAS

EMBEBIDOS

MEMORIA DEL TRABAJO FINAL

Control de termotanque basado en elsistema “Heat Pump”

Autor:Ing. Nelson Ariel Fortunatti

Director:Dr. Alejandro Ghersin (FIUBA, ITBA)

Jurados:Mg. Ing. Facundo Larosa (UTN-FRH, FIUBA)

Ing. Nicolás Alvarez (FIUBA, UNSAM)Esp. Ing. Ernesto Gigliotti (UTN-FRA, FIUBA)

Este trabajo fue realizado en las Ciudad Autónoma de Buenos Aires, entrediciembre de 2018 y agosto de 2019.

III

Resumen

En la presente memoria se describe el diseño, desarrollo e implementación de unsistema de control de un termo-tanque eléctrico. El trabajo surgió de la necesi-dad de la empresa Rheem S.A. de implementar una interfaz gráfica y el controlasociado, para la realización de un nuevo producto.

Para la confección del presente proyecto se utilizó una Single Board Computer(SBC), bajo el sistema operativo Linux para desarrollar tanto la interfaz gráficacomo la lógica del sistema. La comunicación entre programas se realizó medianteuna conexión TCP/IP. Para la interfaz gráfica se utilizó Qt Quick y para la lógicadel sistema se utilizaron varias funcionalidades de sistemas operativos de propó-sito general. También se desarrollaron tanto test unitarios automatizados comotesteo exploratorio y pruebas de campo para verificar el correcto funcionamientodel sistema.

V

Índice general

Resumen III

1. Introducción General 11.1. Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2. Propósito . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.3. Alcance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2. Introducción Específica 52.1. Requerimientos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52.2. Consideraciones de diseño de la plataforma de desarrollo . . . . . . 62.3. Modos de operación del sistema de control . . . . . . . . . . . . . . 72.4. Planificación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

3. Diseño e Implementación 133.1. Elección de la plataforma de desarrollo . . . . . . . . . . . . . . . . 133.2. Master test plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

3.2.1. Estrategias generales: Características de calidad del software 193.2.2. Estrategias por nivel de prueba . . . . . . . . . . . . . . . . . 19

3.3. Estructura de programas asociados . . . . . . . . . . . . . . . . . . . 243.4. Diagrama de estados del sistema . . . . . . . . . . . . . . . . . . . . 263.5. Puesta en marcha del software de interfaz gráfica . . . . . . . . . . 263.6. Montaje del controlador en el termo-tanque . . . . . . . . . . . . . . 313.7. Interfaz gráfica desarrollada . . . . . . . . . . . . . . . . . . . . . . . 313.8. Gestión de la calidad . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

4. Ensayos y Resultados 394.1. Test unitarios automatizados . . . . . . . . . . . . . . . . . . . . . . 394.2. Revisiones eléctricas y funcionales del PCB . . . . . . . . . . . . . . 444.3. Testeo a nivel exploratorio y funcional . . . . . . . . . . . . . . . . . 444.4. Prueba de campo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

4.4.1. Consideraciones previas a la realización del ensayo . . . . . 454.4.2. Descripción del ensayo . . . . . . . . . . . . . . . . . . . . . . 454.4.3. Análisis de los datos . . . . . . . . . . . . . . . . . . . . . . . 484.4.4. Resultados obtenidos . . . . . . . . . . . . . . . . . . . . . . . 50

5. Conclusiones 515.1. Conclusiones generales . . . . . . . . . . . . . . . . . . . . . . . . . 515.2. Próximos pasos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

A. Configuración de Qt 5.10.1 para compilación cruzada 53

VII

Índice de figuras

1.1. Circuito del líquido refrigerante en la bomba de calor para el ca-lentamiento del agua. . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.2. Interfaz del controlador que se utiliza actualmente para comandarun termo-tanque con BC. Las dimensiones se expresan en mm (pul-gadas). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2.1. Diagrama Activity On Node . . . . . . . . . . . . . . . . . . . . . . . 8

3.1. SBCs populares de la marca Raspberry . . . . . . . . . . . . . . . . . 163.2. SBCs populares de la marca Beaglebone . . . . . . . . . . . . . . . . 163.3. Kit de desarrollo SoM de Raspberry . . . . . . . . . . . . . . . . . . 173.4. Versiones de Qt disponibles para el desarrollo de interfaces gráficas 183.5. Subetapas que componen el sistema del controlador . . . . . . . . . 223.6. Diagrama de bloques de la estructura del software . . . . . . . . . . 263.7. Diagrama de estados del sistema . . . . . . . . . . . . . . . . . . . . 273.8. Arbol de transiciones de estados . . . . . . . . . . . . . . . . . . . . 293.9. Prototipo del sistema de control desarrollado . . . . . . . . . . . . . 323.10. Interfaz gráfica desarrollada. . . . . . . . . . . . . . . . . . . . . . . 343.11. Interfaz gráfica montada en el panel frontal, diseño de la nueva

interfaz gráfica montada en el panel frontal. . . . . . . . . . . . . . . 35

4.1. Resultados obtenidos del ensayo realizado . . . . . . . . . . . . . . 464.2. Resultados obtenidos del ensayo realizado subsección 1-4 . . . . . . 464.3. Resultados obtenidos del ensayo realizado subsección 2-4 . . . . . . 474.4. Resultados obtenidos del ensayo realizado subsección 3-4 . . . . . . 474.5. Resultados obtenidos del ensayo realizado subsección 4-4 . . . . . . 48

IX

Índice de Tablas

2.1. Planificación 1-4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92.2. Planificación 2-4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102.3. Planificación 3-4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112.4. Planificación 4-4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

3.1. Memoria utilizada por pantallas de diferente resolución . . . . . . . 143.2. Análisis de características de calidad del software . . . . . . . . . . 203.3. Importancia relativa de las características de calidad . . . . . . . . . 213.4. Cobertura de las características de calidad con respecto a los nive-

les de prueba . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213.5. Relación entre cada subetapa con respecto a las características de

calidad y su importancia relativa . . . . . . . . . . . . . . . . . . . . 233.6. Técnicas de test utilizadas para cada subetapa del sistema . . . . . 243.7. Tabla de transición de estados con respecto a distintos eventos aso-

ciados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

4.1. Tabla de casos de prueba legales 1-2 . . . . . . . . . . . . . . . . . . 404.2. Tabla de casos de prueba legales 2-2 . . . . . . . . . . . . . . . . . . 414.3. Performance del termo-tanque durante el Calentamiento y Reposo 49

1

Capítulo 1

Introducción General

Se presenta el contexto y justificación de este trabajo, introduce por un lado qué esun sistema de bomba de calor y en qué se basa un controlador para este sistema.También se explica cuál es el propósito y el alcance del trabajo.

1.1. Introducción

A fines del año 2018 la empresa Rheem S.A. que fabrica y comercializa termo-tanques, se acercó al ITBA (Instituto Tecnológico Buenos Aires) con la finalidadde determinar si era factible efectuar el desarrollo del control de un sistema debomba de calor para un termo-tanque eléctrico que implemente una interfaz táctilpara su utilización.

Una bomba de calor (BC, Heat Pump en inglés) es una máquina térmica capaz decalentar una cierta sustancia o elemento mediante un trabajo aportado desde elexterior. Su principio de funcionamiento se basa en comprimir y dilatar un gas olíquido refrigerante a diferentes temperaturas para poder en este caso, absorbercalor del ambiente y poder utilizarlo para calentar el agua que se encuentra den-tro del termo-tanque [1]. La BC tiene la capacidad de capturar energía de fuentesexternas y gratuitas, la energía eléctrica suministrada se utiliza principalmentecomo complemento para realizar el ciclo que efectúa el líquido refrigerante den-tro de la BC transfiriendo calor útil de forma altamente eficiente. Esto permite quese pueda obtener una eficiencia eléctrica del orden del 70-75 % con respecto a unsistema que utilice solo una resistencia eléctrica para el calentamiento.

En la figura 1.1 se detalla el principio de funcionamiento de una BC donde sepuede notar el recorrido que realiza el líquido refrigerante en el circuito térmico.Su funcionamiento se puede explicar en cuatro etapas:

Etapa 1: el fluido refrigerante se encuentra a baja temperatura, baja presióny en estado líquido. El evaporador tiene un ventilador para forzar el flujode aire a través del mismo. El líquido refrigerante, al circular a través delevaporador, absorbe el calor del aire ambiente y cambia al estado gaseoso.

Etapa 2: el líquido refrigerante pasa por el compresor aumentando su pre-sión y por consiguiente la temperatura.

Etapa 3: este fluido a alta presión y temperatura pasa por el condensadorque se encuentra en el interior del tanque y le transfiere calor al agua por locual el fluido cambia al estado líquido y reduce levemente su temperatura.

Etapa 4: por último, el fluido reduce su presión mediante la válvula de ex-pansión y produce como consecuencia una disminución de la temperatura.

2 Capítulo 1. Introducción General

En este momento el fluido se encuentra en las mismas condiciones inicialesde temperatura, presión y fase que en la Etapa 1 por lo cual puede realizarseeste procedimiento de forma cíclica.

FIGURA 1.1: Circuito del líquido refrigerante en la bomba de calorpara el calentamiento del agua.

El desarrollo del trabajo consistió en realizar un prototipo funcional para coman-dar al termo-tanque en diferentes modos de operación mediante la utilización deuna pantalla táctil.

Teniendo en cuenta la lógica del sistema desde el punto de vista electrónico, comoentrada se tienen los valores de temperatura dados por tres resistencias PT100situados en tres regiones diferentes:

Región superior del tanque de agua: analiza la temperatura en la regiónque se mantiene con mayor temperatura cuando el sistema se encuentra enreposo.

Región inferior del tanque de agua: analiza la temperatura en la región decalentamiento del termo-tanque por parte de la BC.

Circuito de entrada del evaporador: se analiza la temperatura para evitarque el sistema caliente cuando el evaporador se encuentra a una tempera-tura muy baja.

Como salidas, para el accionamiento de la BC, se tienen tres relés:

Relé 1: para activar la resistencia calefactora, como el proceso de calenta-miento mediante la bomba de calor es un proceso lento, en algunas circuns-tancias donde se requiera calentar el agua rápidamente, se utiliza una resis-tencia eléctrica dejando de lado el ahorro de energía.

Relé 2: para activar el compresor encargado de establecer una diferencia depresión entre la región de baja y de alta presión (derecha y izquierda segúnla figura 1.1) y a su vez desplazar el flujo refrigerante a través del circuitodescrito anteriormente.

1.2. Propósito 3

Relé 3: para activar el ventilador del evaporador, el cual tiene dos funciones,primero mejorar el intercambio de aire con el entorno y también desconge-lar el evaporador en situaciones de baja temperatura.

Teniendo en cuenta el estado previo del sistema, las temperaturas medidas y losvalores seleccionados por el usuario (modo deseado, temperatura deseada), elsistema analiza cuál será el próximo estado y activa o desactiva los relés paracomandar el calentamiento del agua.

1.2. Propósito

El propósito de este trabajo fue realizar la primera iteración para la confección deun producto que contemple la incorporación de las siguientes características:

Sistema basado en una bomba de calor (BC) para obtener mayor eficienciaenergética que los productos convencionales.

Que sea muy intuitivo en su manipulación y provea gran variedad de fun-cionalidades para administrar el comportamiento del termo-tanque segúnel deseo del usuario, comúnmente denominado UX (user experience, expe-riencia de usuario).

Que utilice una interfaz táctil robusta y de rápida respuesta.

Mediante el sistema desarrollado, se pudieron determinar posibles mejoras quedeberán llevarse a cabo en el diseño final para su comercialización.

Los termo-tanques eléctricos que funcionan con BC actualmente utilizan un con-trolador que si bien es muy compacto, robusto y realiza las funciones de formaadecuada, es poco intuitivo y la configuración se hace bastante engorrosa ya quese utilizan cuatro botones fijos con múltiples funcionalidades cada uno, comopuede verse en la figura 1.2. Además, está compuesto por un display con cua-tro leds de 7-segmentos para informar al usuario de los cambios en las variablesdel sistema de control siendo limitada la información que se puede extraer deltermo-tanque.

El trabajo buscó solucionar esta limitación, mediante el desarrollo un sistema conbuena estética que mejore principalmente la experiencia del usuario. A su vez,en un futuro se incorporarán nuevas funcionalidades para que el sistema tengamayor versatilidad según los deseos particulares de cada usuario.

1.3. Alcance

Tareas comprendidas en la realización del trabajo:

Diseño e implementación del sistema de control del termo-tanque.

Diseño de la interfaz gráfica.

Diseño del circuito impreso, montaje de componentes y prueba funcionaldel hardware implementado.

Pruebas del sistema incluida una prueba de campo del mismo.

El trabajo realizado no incluye:

4 Capítulo 1. Introducción General

FIGURA 1.2: Interfaz del controlador que se utiliza actualmentepara comandar un termo-tanque con BC. Las dimensiones se ex-

presan en mm (pulgadas).

Implementación de un producto final comerciable.

Ajustes finos al diseño de la interfaz gráfica.

5

Capítulo 2

Introducción Específica

Se detallan los requerimientos, selección del hardware del controlador y softwareasociado a la interfaz gráfica. Se exponen los modos de operación y la planifica-ción del trabajo desarrollado.

2.1. Requerimientos

Los requerimientos se obtuvieron de cuatro fuentes:

Consensuados con el cliente durante varias reuniones previas al desarrollodel trabajo.

De consultas internas a profesionales dentro del ITBA.

Del análisis del comportamiento del controlador que actualmente utilizanlos termo-tanques con bomba de calor.

La experiencia del autor respecto a buenas prácticas para el desarrollo delsistema.

Los requerimientos son los siguientes:

1. El sistema debe accionar tres relés para activar el compresor, el ventiladordel evaporador y la resistencia según corresponda en base al modo elegidoy la temperatura obtenida de los sensores.

2. El sistema debe sensar la temperatura en la parte inferior, superior del tan-que de agua y en el evaporador. En el caso de que la temperatura en elevaporador sea menor a 0°C debe encenderse el ventilador del evaporadorhasta que el mismo se descongele.

3. El sistema debe proveer de una interfaz gráfica fácil de utilizar e intuitivapara uso hogareño. Debe tener la capacidad de configuración de modos deoperación y temperaturas deseadas.

4. El sistema debe funcionar mediante una pantalla táctil para la operación deltermotanque.

5. Se debe diseñar el circuito impreso siguiendo las dimensiones provistas porel cliente para obtener un diseño compacto y de fácil montaje.

6. El sistema debe contener un RTC (Real Time Clock) que pueda dar noción detiempo para analizar su desempeño durante los ensayos.

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

7. El sistema debe guardar en un archivo el estado actual del mismo, entradas,salidas, modos de operación y tiempo, con una frecuencia no mayor a 5segundos.

8. El sistema debe ser robusto, no debe presentar fallas o comportamientosindeseables durante la utilización del mismo en un periodo de tiempo dedos semanas ininterrumpidas de trabajo.

9. Realizar entregas parciales al cliente mostrando las nuevas funcionalidadesimplementadas.

10. La aplicación que corresponde a la interfaz gráfica del sistema debe inicia-lizarse automáticamente cuando el sistema se enciende.

11. Se debe restringir el acceso al usuario a áreas que no correspondan a laoperación del sistema de control.

12. La interfaz gráfica debe mostrar información importante al usuario comoel modo en el que se encuentra el termotanque y la temperatura actual delagua.

13. Debe poder seleccionarse el modo de operación y la temperatura.

2.2. Consideraciones de diseño de la plataforma de desa-rrollo

Para analizar qué plataforma de desarrollo era la más adecuada, se tuvieron encuenta varios aspectos, como por ejemplo:

1. Tiempo de desarrollo: en el momento que el cliente presentó el desarrollode este trabajo se disponía de dos meses para presentar un primer prototipobasado en el sistema elegido basado en una simulación de la interfaz gráficadel controlador.

2. Robustez del sistema desarrollado: el sistema debe estar diseñado de ma-nera tal que pueda operar de forma correcta durante dos semanas de usocontínuo, para considerarlo apropiado en la realización de los ensayos sobrelos prototipos que se puedan implementar en el futuro.

3. Estética del producto final: el cliente nos informó que el diseño debía con-templar una interfaz que sea similar a la que se encuentra en teléfonos ce-lulares modernos para dar mayor experiencia al usuario (UX)

4. Portabilidad del software implementado: Para mayor versatilidad en la elec-ción del hardware tanto para el prototipo implementado como a posiblesvariaciones en el futuro, es deseable que el software desarrollado sea com-pletamente compatible y portar el código sea una tarea sencilla.

5. Posibilidad de adicionar gran cantidad de funcionalidades: en tiempo rela-tivamente bajos sin preocuparnos por pérdida en la performance o espaciode almacenamiento disponible.

Además de los aspectos anteriores, el tamaño, tipo de pantalla a utilizar y co-nexionado de la misma a la placa de desarrollo, son características que debieronanalizarse en conjunto con la selección de la placa de desarrollo y el softwareasociado para la confección de la interfaz gráfica.

2.3. Modos de operación del sistema de control 7

2.3. Modos de operación del sistema de control

Como punto de partida para el desarrollo del sistema de control se tuvieron encuenta los modos de operación que poseía el controlador que actualmente operaen los termo-tanques bomba de calor sin interfaz gráfica. Estos modos son:

"Modo Económico": sólo se encuentra presente la BC operando. El consumoeléctrico es de aproximadamente una cuarta parte con respecto al de unaresistencia de 2000W de potencia. Por lo cual, el tiempo de recuperación eneste modo es lento pero posee una alta eficiencia energética.

"Modo Potencia": se mantiene encendido tanto la BC como la resistenciaeléctrica calefactora. Posee un tiempo de recuperación rápido en el caso derequerir agua caliente en el corto plazo. Sin embargo el consumo de energíaeléctrica aumenta en gran medida.

"Modo Confort": se enciende sólo la bomba de calor en un rango de tem-peraturas y se enciende sólo la resistencia en el rango complementario almencionado. De este modo se tiene para temperaturas de set point bajaseficiencia energética, y para temperaturas de set point altas tiempo de recu-peración reducido.

"Modo Antibacterial": se basa en sobrecalentar el agua cada seis meses deforma tal de eliminar cualquier microorganismo presente en el agua.

"Modo Descongelar": evita que el evaporador se congele durante períodosde baja temperatura o por condiciones de operación del sistema. Este mo-do de operación es automático, es decir, no puede ser seleccionado por elusuario, y posee mayor nivel de jerarquía con respecto a los demás. Cual-quier situación que se presente que produzca una baja temperatura en elevaporador debe activar este modo.

Los sensores colocados en el tanque de agua son utilizados para evaluar la tempe-ratura en el agua y encender o detener el calentamiento según el set point impues-to por el usuario. El sensor colocado en el evaporador se utiliza para la activacióndel "Modo Descongelar".

2.4. Planificación

El trabajo se planificó según la figura 2.1, donde puede verse cada una de las eta-pas con su duración estipulada. Los bloques sombreados representan el caminocrítico del proyecto.

Las tablas 2.1, 2.2, 2.3 y 2.4 muestran la planificación del proyecto, se mencionapara cada subetapa, duración, fecha de inicio/fin y dependencias.


1. Dimensionamiento del proyecto en base a requerimientos del cliente t = 10 días

Inicio 27/11/2018

1.1 Selección del hardware (placa de desarrollo basada en microcontrolador o SBC) t = 3 días

1.2 Selección de pantalla táctil compatible con el hardware elegido t = 6 días

2 Configuración del software, diseño de aplicación gráfica y prueba

funcional t = 30 días

3 Programación de la lógica del sistema, incorporación de periféricos y

prueba funcional. t = 19 días

4. Interconexión de la interfaz gráfica junto con el programa encargado del control del sistema t = 10 días

5 Selección del hardware definitivo.

Compra de placas para pruebas

t = 20 días

6 Diseño de esquemático, circuito impreso y fabricación

del mismo t = 35 días

7 Testeo funcional de programas (control e interfaz

gráfica) operando conjuntamente

t = 5 días

8. Corrección de errores. Optimización del código. t = 10 días

9. Prueba de campo del sistema t = 12.5 días

10. Etapa ajustes finales y confección de documentos t = 17.5 días

Fin 16/08/2019

FIGURA 2.1: Diagrama Activity On Node

2.4. Planificación 9

TABLA 2.1: Planificación 1-4

Índice Nombre de tarea Duración Comienzo FinTareasprevias

11. Dimensionamiento del pro-yecto y definición de compo-nentes claves

19 díasmar27/11/18

vie21/12/18

21.1. Dimensionamiento del pro-yecto en base a requerimientosdel cliente

80 horasmar27/11/18

lun10/12/18

31.2. Selección del hardware(placa de desarrollo basada enmicrocontrolador o SBC)

32 horasmar11/12/18

vie14/12/18

2

51.3. Selección de pantalla táctilcompatible con el hardware ele-gido.

40 horaslun17/12/18

vie21/12/18

3

5 Fin Etapa 1 0 díasvie21/12/18

vie21/12/18

4

62. Configuración del software,diseño de aplicación gráfica yprueba funcional

30 díaslun24/12/18

lun 4/2/19 5

7

2.1. Configuración buildeo einstalación del software parauso en el hardware selecciona-do

120 horaslun24/12/18

vie11/1/19

5

82.2. Desarrollo de aplicacionessimples

20 horaslun14/1/19

mié16/1/19

7

92.3. Desarrollo de la aplicacióngráfica del proyecto

60 horasmié16/1/19

vie25/1/19

8

10 2.4. Pruebas funcionales 20 horaslun28/1/19

mié30/1/19

9

112.5 Corrección de posibles dis-crepancias. Mejora del softwaredesarrollado.

20 horasmié30/1/19

vie 1/2/19 10

12 2.6. Fin Etapa 2 0 días lun 4/2/19 lun 4/2/19 11

133. Programación de la lógicadel sistema, incorporación deperiféricos y prueba funcional

19 días lun 4/2/19 vie 1/3/19 12

143.1 Diseño de la estructura delprograma

16 horas lun 4/2/19mié6/2/19

12

153.2 Selección del protocolo decomunicación con la interfázgráfica.

8 horasmié6/2/19

jue 7/2/19 14

163.3 Diseño de la estructura delos paquetes enviados y trasmi-tidos

16 horas jue 7/2/19lun11/2/19

15

173.4 Diseño de la lógica del siste-ma

32 horaslun11/2/19

vie15/2/19

16




183.5 Diseño del sensado de tem-peratura (en software y hard-ware)

32 horasvie15/2/19

jue21/2/19

17

193.6 Verificar la funcionalidad decada subetapa anterior

4 horasjue21/2/19

jue21/2/19

18

203.7 Corrección de errores ensubetapas

20 horasjue21/2/19

mar26/2/19

19

21

3.8 Verificar funcionalidad detodo el programa implementa-do en la presente etapa operan-do conjuntamente

4 horasmar26/2/19

mar26/2/19

20

223.9 Corrección de posibles erro-res

20 horasmar26/2/19

vie 1/3/19 21

23 Fin Etapa 3 0 días vie 1/3/19 vie 1/3/19 22

24

4. Interconección de la interfazgráfica junto con el programaencargado del control del siste-ma

10 días vie 1/3/19 vie 15/3/19 12;23

254.1. Desarrollo del protocolo decomunicación seleccionado enla interfaz gráfica

40 horas vie 1/3/19 vie 8/3/19 12;23

264.2 Verificar comunicación entreprogramas.

40 horas vie 8/3/19vie15/3/19

25


vie15/3/19

26

285. Selección del hardware de-finitivo, compra de placas deprueba

20 días vie 15/3/19 vie 12/4/19 27

295.1 Análisis de placas de desa-rrollo orientada a ambientes in-dustriales

40 horasvie15/3/19

vie22/3/19

27

305.2 Selección de placa de desa-rrollo, búsqueda de provedoresy realización de la compra

40 horasvie22/3/19

vie29/3/19

29

315.3 Envío de placas de desarro-llo.

40 horasvie29/3/19

vie 5/4/19 30

325.4 Configuración de las placaspara utilizar el software desa-rrollado

40 horas vie 5/4/19vie12/4/19

31


vie12/4/19

32

2.4. Planificación 11



346. Diseño de esquemático, cir-cuito impreso y fabricación delmismo

35 días vie 12/4/19 vie 31/5/19 33

35 6.1. Diseño esquemático 40 horasvie12/4/19

vie19/4/19

33

36 6.2. Diseño circuito impreso 80 horasvie19/4/19

vie 3/5/19 35

376.3. Verificación del esquemáti-co y circuito impreso

80 horas vie 3/5/19vie17/5/19

36

386.4. Fabricación del circuito im-preso

80 horasvie17/5/19

vie31/5/19

37


vie31/5/19

38

40

7. Testeo funcional de am-bos programas (control e inter-faz gráfica) operando conjunta-mente.

10 días vie 31/5/19 vie 14/6/19 39

417.1. Verificar correcto envío depaquetes (bidireccional)

20 horasvie31/5/19

mar4/6/19

39

427.2. Corrección de posibles erro-res

20 horasmar4/6/19

vie 7/6/19 41

43

7.3. Verificar el comportamien-to de la interfaz gráfica frente acambios en las condiciones deentrada y/o modos de opera-ción

20 horas vie 7/6/19mar11/6/19

42


20 horasmar11/6/19

vie14/6/19

43


vie14/6/19

44

468. Corrección de errores. Opti-mización del código.

20 días vie 14/6/19 vie 12/7/19 45;33;39

478.1. Verificar el comportamientode todo el sistema utilizando elPCB desarrollado.

40 horasvie14/6/19

vie21/6/19

45;33;39


40 horasvie21/6/19

vie28/6/19

47

498.3. Agregado de nuevas fun-cionalidades deseadas por elcliente.

40 horasvie28/6/19

vie 5/7/19 48

508.4. Optimización del código.Mejorar la estructura y docu-mentación.

40 horas vie 5/7/19vie12/7/19

49

51 Fin Etapa 8 0 horasvie12/7/19

vie12/7/19

50




52 9. Prueba de campo del sistema 12,5 días vie 12/7/19mar30/7/19

51

539.1 Montaje del sistema dentrodel termotanque.

40 horasvie12/7/19

vie19/7/19

51

54

9.2 Dejar el termotanque funcio-nando unos días cambiando pa-rámetros de configuración y ve-rificando su respuesta.

40 horasvie19/7/19

vie26/7/19

53

559.3 Corrección de posibles erro-res.

20 horasvie26/7/19

mar30/7/19

54

56 Fin Etapa 9 0 horasmar30/7/19

mar30/7/19

55

5710. Etapa ajustes finales y con-fección de documentos

17,5 díasmar30/7/19

vie 23/8/19 56

5810.1. Redacción memoria delproyecto

80 horasmar30/7/19

mar13/8/19

56

5910.2. Confección de documenta-ción asociada

40 horasmar13/8/19

mar20/8/19

58

6010.3. Confección de diapositivaspara la presentación del trabajo

20 horasmar20/8/19

vie23/8/19

59

61 Proyecto finalizado 0 horasvie23/8/19

vie23/8/19

60

13

Capítulo 3

Diseño e Implementación

En el presente capítulo se analiza la elección de la plataforma de desarrollo, seexplica la estructura que adopta el sistema, se detalla cómo fue implementado eldiagrama de estados y la comunicación entre programas. Por último, se realizaun análisis de gestión de calidad para evaluar el correcto cumplimiento de losrequerimientos.

3.1. Elección de la plataforma de desarrollo

Existen diferentes protocolos de comunicación entre pantallas táctiles, éstos pue-den realizarse mediante transmisión de bits en serie o en paralelo. En algunoscasos, el microcontrolador puede ser el encargado del refresco de la imagen deldisplay, ésto provoca que el microcontrolador se dedique principalmente a la rea-lización de esta tarea y reduzca su capacidad para atender tareas adicionales.

Para reducir el uso del microcontrolador administrando pantallas, existen dossoluciones:

Se dispone de un periférico interno dedicado al control de pantallas gráfi-cas.

El módulo de la pantalla táctil posee un controlador de pantalla interno jun-to con una memoria RAM gráfica para poder almacenar en un frame buffer[2] la imagen que es presentada en pantalla [3].

En base a una pantalla de una determinada resolución y densidad de colores, esposible guardar toda la información dentro de la memoria de un microcontro-lador, o utilizar una memoria externa para almacenar todo el frame buffer en lamisma.

En la tabla 3.1 se pueden ver diferentes resoluciones de pantallas, cada una condistinta densidad de colores, combinando ambas características se obtiene el ta-maño de memoria requerido para poder almacenar una imagen que se presentaen la pantalla.

Se determinó utilizar una pantalla táctil de 5 pulgadas con una resolución de800x480 pixeles y una densidad de colores de 24 bits (región en negrita de la tabla),para así poder obtener una buena calidad en la imagen presentada. En base aestos requerimientos, es necesaria una memoria de 1125 KB por cada imagen quese presenta en pantalla.

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

TABLA 3.1: Memoria RAM utilizada para almacenar una imagenen base a diferentes resoluciones de pantalla y densidad de colores

Frame buffer size (Kbyte)Screen resolution Number of pixels

8bpp 16bpp 24bpp 32bpp

QVGA (320x240) 76800 75 150 225 300VGA (640x480) 307200 300 600 900 1200

WVGA (800x480) 384000 375 750 1125 1500XGA (1024x768) 786432 768 1536 2304 3072

Previamente a la transmisión de la imagen al frame buffer, es necesario realizar elprocesamiento gráfico. Esta etapa requiere tiempo de procesamiento y un incre-mento del uso del CPU a medida que aumenta la densidad de píxeles y la den-sidad de colores. Todo este proceso debe realizarse en un tiempo acotado pararespetar la velocidad de refresco de la pantalla.

Si bien existen diferentes técnicas donde se puede dibujar en un sólo frame buffer,ésto reduce la calidad de la imagen obtenida, ya que se pueden percibir los cam-bios durante la transición de una pantalla a otra. Ésto se puede resolver haciendouso de dos frame buffers, el primero sólo se utiliza para el refresco de la pantallay el segundo se utiliza para cambiar lo que se muestra actualmente. Cuando seterminan de realizar los cambios en el segundo frame buffer, se intercambian éstospara presentar en pantalla el contenido de este último, y no percibir los cam-bios debidos a trabajar sobre la imagen que se muestra actualmente. Al utilizardos frame buffers es necesario el doble de memoria que el mencionado en la tabla3.1, es decir 2MB de memoria RAM sólo para contener ambos frame buffers. Estoúltimo es un requerimiento bastante restrictivo tanto en capacidad de memorianecesaria, como una alta tasa de transmisión y procesamiento de datos, inclusopara microcontroladores de altas prestaciones.

Si se desean realizar animaciones en pantalla empieza a tomar importancia latasa de refresco de las imágenes presentadas, siendo una frecuencia de refrescoaceptable 60 Hz. Es decir, se requiere una transferencia de datos de 1125 KB x 60Hz dando como resultado una tasa de transferencia de datos de 65,92 MBps quees un ancho de banda considerable para un microcontrolador.

Otro aspecto a tener en cuenta es cómo llevar a cabo el desarrollo de interfa-ces gráficas, mediante microcontroladores en el control de pantallas de alta re-solución. Si bien existen diversas bibliotecas para el desarrollo de interfaces deusuario, como por ejemplo STemWin [4], éstas son para realizar un diseño muy amedida y a bajo nivel.

Como el tiempo de desarrollo del trabajo era crucial, ya que el cliente requeríaun prototipo de la interfaz gráfica al finalizar el primer bimestre de desarrollo,debido a las características presentadas anteriormente, un microcontrolador de 32bits como lo son los ARM Cortex M4 o M7 [5] requerirían un tiempo considerablede desarrollo para obtener una buena interfaz gráfica. Por lo tanto, se evaluó lautilización de una SBC (Single Board Computer) [6].

Estas plataformas no son tan robustas como un buen diseño basado en un mi-crocontrolador, ya que utilizan un sistema operativo de propósito general (nor-malmente una distribución GNU/Linux). Por ejemplo, es posible que se generen

3.1. Elección de la plataforma de desarrollo 15

archivos corruptos en caso de producirse una interrupción en la alimentación.Ésta característica se puede mitigar tomando una serie de recaudos para poderser utilizados en ambientes donde se requiere un mayor nivel de robustez. Comopor ejemplo al detectarse una falla en la alimentación, si se almacena energía su-ficiente en la fuente encargada de alimentar la SBC se puede apagar la misma deforma ordenada evitando corrupción de archivos.

Por tratarse de una placa con núcleos ARM Cortex A, similar al presente en loscelulares actuales, la capacidad de cómputo, procesamiento gráfico y memoriadisponible superan ampliamente a cualquier microcontrolador de altas presta-ciones como los ARM Cortex M7. Incluso algunos núcleos ARM Cortex A tienenasociado un GPU(Graphical Processor Unit, unidad de procesamiento gráfico).

Toda la performance obtenida por el cambio en el hardware puede ser utilizadopara desarrollar una interfaz gráfica más orientada a la que se encuentra en cual-quier aplicación de celulares, dejando de lado la apariencia que comúnmente esvista en HMIs de PLCs o la típica interfaz que tenía el sistema operativo Windows98. Adoptar este enfoque produce sólo por apariencia y fluidez, un mayor valoragregado al producto desarrollado, ya que los usuarios van a percibir un diseñomás moderno y más orientado a lo que comúnmente utilizan a diario.

Actualmente, en el mercado existe gran variedad de SBCs debido a la populari-dad obtenida en los últimos años por la relativa facilidad de uso y a obtenerlas aprecios cada vez más accesibles.

Para poder determinar cuál sería la más apropiada para el trabajo se tomaron encuenta los siguientes aspectos:

Es recomendable que tenga disponibilidad dentro del país para reposiciónrápida en caso de falla y/o para desarrollar varios prototipos.

Debe seleccionarse una pantalla que sea compatible con la SBC a utilizar. Serequiere que disponga de una interfaz táctil capacitiva para mejorar expe-riencia del usuario. En las interfaces táctiles resistivas debe realizarse unapresión considerablemente mayor en la pantalla para detectar una peticióndel usuario.

La pantalla, a su vez, debe ser totalmente compatible con el software dedesarrollo de la interfaz gráfica, ya que se requiere presentar correctamentela aplicación en pantalla y poder detectar cuando el usuario presiona unadeterminada región de la misma.

Es ampliamente recomendable seleccionar una plataforma que sea bastantepopular en el mercado, donde se haya utilizado el software para el desarro-llo gráfico con anterioridad, ésto facilita en gran medida la documentación,el aprendizaje y la búsqueda de las soluciones a posibles problemas que sepueden encontrar durante el desarrollo.

Teniendo en cuenta los parámetros constructivos del producto final, se debeevitar la utilización de memorias SD como memoria principal de la SBC, yaque podrían producirse falsos contactos por vibraciones durante el trans-porte o la operación del sistema. Es preferible la utilización de una memo-ria EMMC por tratarse de circuitos integrados que se encuentran soldadosdirectamente al PCB (circuito impreso).


Se debe realizar una conexión entre el módulo de la pantalla táctil y la SBCde manera tal que no pueda producirse una desconexión por vibracionesdurante el transporte o la operación del sistema.

Pensando en el diseño del producto final, es deseable desarrollar un sistemacompacto mediante la implementación de un PCB a medida y la utilizaciónun SoM (System On Module, sistema en un módulo [7]) en reemplazo de unaSBC.

Dentro de Argentina, es posible obtener una Raspberry Pi modelo 3B+ o Zeroque pueden verse en la figura 3.1, siendo este última menos apropiada ya que nodispone de puertos USB sin la utilización de un HUB USB [8]. Es necesario dis-poner de puertos USB para poder alimentar a la pantalla táctil y eventualmenteconectar un teclado para realizar configuraciones.

(A) Raspberry Pi 3B+ (B) Raspberry Pi Zero

FIGURA 3.1: SBCs populares de la marca Raspberry

Existen otras SBCs disponibles también en Argentina, que son las BeagleboneBlack y Green las cuales se muestran en la figura 3.2, que tienen la ventaja deutilizar una memoria EMMC mientras que las Raspberry utilizan una tarjeta SDcomo memoria principal.

(A) Beaglebone Black (B) Beaglebone Green

FIGURA 3.2: SBCs populares de la marca Beaglebone

También pueden encontrarse otros modelos de SBCs disponibles como BananaPi o Orange Pi. Éstas fueron descartadas por presentar una robustez menor a lasanteriores.

Si bien la Raspberry Pi 3B+ no soporta EMMC mientras que la Beaglebone sí,pensando en el desarrollo del producto final, sólo Raspberry dispone de placasSoM que tienen integradas una memoria EMMC.

3.1. Elección de la plataforma de desarrollo 17

El último modelo disponible Compute Module 3+ puede verse en la figura 3.3a,posee circuitos integrados de EMMC con capacidad de almacenamiento de 8 GB,16 GB y 32 GB. Para poder utilizar el SoM durante la fase de desarrollo se utilizóla placa base Compute Module IO Board V3 que se muestra en la figura 3.3b. Porlo cual, aunque no se utilice una EMMC en el desarrollo del prototipo se sabeque el sistema final va a poder utilizar dicho circuito integrado como memoriaprincipal.

(A) SoM: Compute Module 3+

(B) Base board: Compute Module IO Board V3

FIGURA 3.3: Kit de desarrollo SoM de Raspberry

En la búsqueda de un IDE para la confección de la interfaz gráfica, fue necesa-rio obtener un framework que permita desarrollar un diseño moderno, portabley multiplataforma que aporte versatilidad en el caso de migrar de hardware enfuturas versiones del producto final. Otras características importantes a las de-talladas anteriormente son la documentación que ofrece el framework junto conla existencia de comunidades facilitan la utilización de la herramienta de formacorrecta, que como consecuencia optimizan el tiempo de desarrollo.

Las características mencionadas anteriormente pueden encontrarse en el softwa-re denominado Qt, que es un framework multiplataforma orientado a objetos am-pliamente utilizado para desarrollar programas que utilicen interfaz gráfica deusuario. Qt es desarrollada como un software libre y de código abierto a travésde Qt Project, donde participa tanto la comunidad, como desarrolladores de di-versas empresas. Se basa en el lenguaje de programación C++ de forma nativa, yes utilizado en sistemas embebidos para automoción, aeronavegación y aparatosdomésticos.

Realizando un análisis en las versiones disponibles de Qt se tiene por un ladoQt Widgets y por otro Qt Quick. En la figura 3.4a se puede notar que la aparien-cia en un desarrollo con Qt Widgets se basa en un diseño clásico. En la figura3.4b se muestra una aplicación diseñada para un vehículo desarrollada con Qt


Quick obteniendo como resultado, un diseño más elegante y moderno. Se pudodeterminar que para obtener una interfaz moderna y animada se debía utilizar QtQuick (Qt User Interface Creation Kit) que provee las herramientas para desarrollarprogramas similares a los encontrados en dispositivos móviles.

(A) Aplicación basada en Qt Widgets

(B) Aplicación basada en Qt Quick

FIGURA 3.4: Versiones de Qt disponibles para el desarrollo de in-terfaces gráficas

Si bien Qt está disponible para ser utilizado tanto en la Raspberry Pi como enla BeagleBone Black, la etapa de configurar el software para ser utilizado no estan sencilla. Sólo las últimas versiones de Qt soportan Qt Quick. Por otro lado,para facilitar el desarrollo del programa es muy recomendable realizar lo quecomúnmente se denomina compilación cruzada, utilizar una PC (Host) para lautilización del IDE de Qt y realizar compilación del programa desarrollado direc-tamente sobre la plataforma utilizada (Target).

Para hacer uso de Qt Quick mediante la compilación cruzada y que el programa seejecute en pantalla completa, es necesario realizar la descarga y configuración depaquetes tanto en la Raspberry como en la PC. En esta última, para poder hacer

3.2. Master test plan 19

uso de todas estas características, es necesario descargar el código fuente de Qt,realizar una configuración previa y volver a compilar el código fuente.

Existe notoriamente más información en internet para efectuar este procedimien-to para Raspberry Pi que para Beaglebone. Como fue la primera vez en la utiliza-ción de Linux para compilar el código fuente de un programa junto con el tiempoacotado que se disponía para la presentación del prototipo, la decisión final fueutilizar la Raspberry Pi 3b+ para el prototipo funcional del sistema y el ComputeModule 3+ para el diseño del producto final.

3.2. Master test plan

El master test plan describe en detalle cómo fue planeado el testeo del softwareimplementado y cómo se administraron diferentes niveles de testeo antes de quesea implementado el software [9]. Ofrece una vista panorámica de las decisionesclave que debieron ser tomadas, las estrategias a implementar y el esfuerzo deprueba involucrado en el proyecto.

3.2.1. Estrategias generales: Características de calidad del software

En la tabla 3.2 se muestran las características que tiene el software desarrollado,se indica en qué se basa cada una de ellas y se realiza un análisis para determinarla relevancia que tienen con respecto a la totalidad del software.

En base a la tabla 3.2 es posible ponderar la importancia relativa de cada una delas características como muestra la tabla 3.3.

Las características de calidad fueron analizadas en base a los niveles de pruebadonde la tabla 3.4 detalla en qué nivel de prueba fue analizada cada característicapresentada.

3.2.2. Estrategias por nivel de prueba

En base a cada nivel de prueba mencionado en la tabla 3.4 se analizaron las ca-racterísticas de calidad enumeradas a continuación, seleccionadas a partir de losrequerimientos y características específicas del trabajo realizado.

Por ser un producto de uso hogareño debe ser fácil e intuitivo de utilizar(Usability).

Debe funcionar de acuerdo a lo esperado y debe contener todas las caracte-rísticas funcionales especificadas (Functionality).

Como el desarrollo del sistema va a estar en constante actualización, agre-gado de nuevas características, mejoras en las características existentes, elcódigo debe ser entendible y bien documentado (Maintainability).

El sistema debe monitorear temperatura y calentar agua, este procedimien-to debe realizarse de forma segura para evitar problemas tanto del termo-tanque como del entorno del mismo (Reliability).

La importancia relativa de cada una de las características detalladas por nivel deprueba son equivalentes en este caso a las vistas en la tabla 3.3 donde las carac-terísticas que tomaron mayor importancia son la funcionalidad, la robustez y lausabilidad en el sistema implementado.


TABLA 3.2: Análisis de características de calidad del software

Característica Descripción Propósito de utilización

Functionality

Capacidad del software deproveer las funcionalidadesrequeridas y las necesida-des de los usuarios bajocondiciones de uso especi-ficadas.

Es de vital importancia determi-nar si el software cumple conlas tareas requeridas. El compor-tamiento del software frente acada requerimiento especificadodebe ser el esperado.

Reliability

La capacidad de un pro-ducto de software de man-tener un nivel dado de per-formance bajo ciertas con-diciones en un cierto perío-do de tiempo.

El producto desarrollado debetener una confiabilidad alta, lamisma no debe ser crítica, pe-ro debe ser capaz de contem-plar ciertos recaudos para evi-tar fallas que pongan en funcio-namiento errático al sistema decontrol o incluso produzca unriesgo al entorno.

Usability

La capacidad de un pro-ducto de software para serentendido, aprendido y uti-lizado.

Como el software está orientadoa ser utilizado por personas quepueden no tener experiencia enel uso de dispositivos digitales,el sistema debe ser intuitivo, ydebe contener una breve explica-ción de cómo utilizar la interfazgráfica.

Efficiency

La capacidad de un pro-ducto software para pro-veer una performancedeseada, en base a losrecursos utilizados.

Si bien la performance es muyimportante en el producto desa-rrollado, el hardware utilizadotiene una performance notable-mente superior a la requeridapara un buen funcionamientodel sistema de control por lo cuálno será necesario el análisis deesta característica.

Maintainability

La capacidad de un pro-ducto de software de sermodificado que puede in-cluir correcciones, mejoraso adaptación del software acambios del entorno.

Se analiza la modularización delsoftware y la explicación correc-ta y completa mediante comple-mentarios de cada una de las ta-reas desarrolladas.

Portability

La capacidad de un pro-ducto de software a sertransferido de un entorno aotro.

No será analizado este aspectoya que no se encuentra dentrodel alcance del proyecto. Aún asítanto el desarrollo de la inter-faz gráfica como la medición detemperatura puede ser amplia-mente utilizado para otros pro-yectos.


TABLA 3.3: Importancia relativa de las características de calidad

CaracterísticaImportanciarelativa ( %)

Functionality 30Reliability 35Usability 25Efficiency 0Maintainability 10Portability 0TOTAL 100

TABLA 3.4: Cobertura de las características de calidad con respec-to a los niveles de prueba

Functionality Reliability Usability MaintainabilityImportancia relativa 30 % 35 % 25 % 10 %

Test unitarios ++ +Test de integración ++ +Hardware/Softwaretest de integración

++ + +

Test de sistema ++ +Test de aceptación + +Test de campo + ++

++ La característica de calidad es cubierta completamente en el test indicado.+ En el test indicado se contempla la característica de calidad.(nada) No se analiza la característica de calidad correspondiente.


Dividiendo el sistema implementado en subsistemas como se muestra en la figura3.5, se pudo determinar la importancia relativa de cada una de las subetapas quecompone cada subsistema. El sistema de control del termotanque se divide en dossubsistemas, por un lado la aplicación orientada a la interfaz gráfica (subsistemaB) y por otro la aplicación orientada al monitoreo y control del termotanque (sub-sistema C). Cada uno de los subsistemas contemplan las siguientes subetapas:

b1. Estructura de componentes gráficos.

b2. Comunicación con el sistema de monitoreo y control

b3. Estructura de eventos del sistema

b4. Procesamiento de frames enviados y recibidos

c1. Lectura de temperaturas

c2. Comunicación con el sistema dedicado a la interfaz gráfica

c3. Procesamiento de frames enviados y recibidos

c4. Control del estado del sistema

c5. Monitoreo del sistema para verificar que los demás procesos operen co-rrectamente

c6. Proceso de monitoreo de sobretemperatura

c7. Accionamiento de bomba de calor y resistencia

c8. Guardar estado del sistema y eventuales errores en archivos log.txt

FIGURA 3.5: Subetapas que componen el sistema del controlador

En base a cada una de las subetapas descriptas fue necesario conocer la impor-tancia de cada una de las mismas con respecto a las características de calidad. Latabla 3.5 detalla la importancia relativa de cada una de las subetapas y a su vezcorresponde cada una de las mismas a una característica de calidad.

Por último, se establecieron las técnicas de test utilizadas para cada una de lassubetapas. Éstas técnicas de test son detalladas a continuación:


TABLA 3.5: Relación entre cada subetapa con respecto a las carac-terísticas de calidad y su importancia relativa

Subetapas b1 b2 b3 b4 c1 c2Característicade calidad

Importanciarelativa ( %)

20 % 10 % 15 % 5 % 5 % 5 %

Functionality 30 + + + + + +Reliability 35 +Usability 25 ++Maintainability 10 + + + + + +

Subetapas c3 c4 c5 c6 c7 c8Característicade calidad

Importanciarelativa ( %)

5 % 15 % 5 % 5 % 5 % 5 %

Functionality 30 + + ++ + + +Reliability 35 + ++ ++Usability 25Maintainability 10 + + + + + +

STT (State Transition Testing, prueba de transición de estado): se define comola técnica de prueba de software en la que los cambios en las condicionesde entrada provocan cambios de estado en la aplicación bajo prueba (AUT,Application Under Test). Es una técnica de prueba de caja negra en la queel probador analiza el comportamiento de una aplicación bajo prueba paradiferentes condiciones de entrada en una secuencia.

CFT (Control Flow Test, prueba de flujo de control ): es un tipo de prueba desoftware que utiliza el flujo de control del programa como modelo. La prue-ba de control de flujo es una estrategia de prueba estructural. Esta técnicade prueba viene bajo prueba de caja blanca. Para el tipo de prueba de flujode control, el sistema de control de prueba debe conocer toda la estructura,diseño, código e implementación del software. Los desarrolladores suelenutilizar éste tipo de método de prueba para probar su propio código y supropia implementación, ya que los desarrolladores conocen mejor el dise-ño, el código y la implementación. Este método de prueba se implementacon la intención de probar la lógica del código para que se puedan cumplirlos requisitos del usuario. Su aplicación principal es relacionar los pequeñosprogramas y segmentos de los programas más grandes.

ECT (Elementary Comparison Test, prueba de comparación elemental): es unmétodo formal de diseño de test de caja blanca. Su propósito es implemen-tar las pruebas detalladas de software complejo e importante. El código delprograma se prueba para evaluar el manejo adecuado de todos los resulta-dos del comportamiento de la máquina de estados. Las condiciones aisladasse agregan en situaciones conectadas creando casos de prueba. La indepen-dencia de una condición se muestra cambiando el valor de la condición deforma aislada. Cada valor de condición relevante está cubierto por casosde prueba. Con esto se planea cubrir todo el comportamiento del códigoanalizado.


En base a las técnicas de test explicadas se abordó la prueba de cada una de lassubetapas como muestra la tabla 3.6.

TABLA 3.6: Técnicas de test utilizadas para cada subetapa del sis-tema

Subetapas b1 b2 b3 b4 c1 c2

State transition testing(STT) + +

Control flow test (CFT) + + + +Elementary comparisontest (ECT)

Subetapas c3 c4 c5 c6 c7 c8

State transition testing(STT) ++

Control flow test (CFT) + + + +Elementary comparisontest (ECT) ++

3.3. Estructura de programas asociados

El sistema de control del termo-tanque se compone de dos grandes bloques, unoes el encargado del control de la interfaz gráfica y el segundo es encargado delcontrol del estado del termo-tanque. Estos bloques deben estar permanentementecomunicados entre sí con transmisión de paquetes de forma bidireccional, ya quepor un lado, el usuario debe tener noción del estado del sistema y por otro lainterfaz gráfica es el punto de entrada, por ejemplo, para la selección de modosde operación, temperatura deseada, que van a ser utilizados en la máquina deestados del sistema para actuar sobre las salidas.

Esta comunicación entre programas se realiza mediante una conexión TCP-IP co-mo se muestra en la figura 3.6. El protocolo al realizar una comunicación basadaen handshake, nos asegura que los paquetes enviados desde el cliente o servidorson recibidos correctamente por el remitente, ya que este último envía un mensajede confirmación de recepción comúnmente denominado ACK (Acknowledge) [10].

El software desarrollado en Qt se divide en dos subetapas:

1. Qt Quick Application Frontend: es donde se diseña la interfaz gráfica, es de-cir donde se desarrolla la apariencia del sistema, funcionalidad de botones,menús, presentación de datos, etc.

2. Qt C++ Backend: se encarga de interconectar la interfaz gráfica desarrolla-da, al sistema de control que se encuentra en otro programa que se ejecutasimultáneamente.

Para vincular ambas subetapas, Qt posee un sistema de comunicación entre obje-tos denominado Signals & Slots que consiste en emitir señales en un determinadoobjeto y recibirlas en otro. Esto da la posibilidad de comunicación bidireccionalentre el frontend y el backend [11].

3.3. Estructura de programas asociados 25

El programa en C contempla la lectura de entradas, implementación de la máqui-na de estados, manipulación de salidas, tratamiento de datos para la transmisiónde mensajes, etc. Fue desarrollado utilizando diferentes hilos de ejecución (threads[12]) que pueden ejecutarse en paralelo si el hardware es apropiado. Como se uti-lizó una Raspberry Pi 3b+ que posee 4 núcleos, es altamente probable que estosthreads se ejecuten en paralelo junto con la aplicación gráfica.

Tanto HP Processor, ADC Read, GPIO Write,TCP Read, TCP Write como Log Writerson implementados mediante threads que se comunican entre sí mediante regis-tros de variables compartidas, arbitrando la lectura y escritura en los mismosmediante Mutexes [12].

El sistema posee varios registros para realizar la comunicación entre los diferen-tes threads. Si se posee un sólo registro de variables compartidas con una cantidadconsiderable de campos, el sistema se encontraría bloqueado constantemente ca-da vez que se requiera manipular una variable interna al mismo. Agrupando lasvariables en diferentes registros donde cada uno de ellos sea comandado por unmutex distinto, es posible acceder a distintas variables de forma simultánea.

Para poder tener una lectura y escritura de datos a través de la comunicación TC-P/IP de forma asincrónica se tienen dos threads, uno encargado de la lectura y otroa la escritura de datos sobre el canal de transmisión. La estructura de los paquetesa transmitir consiste en un string que posee el nombre al que representa la varia-ble y el valor de la misma. Por ejemplo para el caso de un mensaje provenientede la interfaz gráfica al sistema de control cuyo contenido es “modoDeseado:1”,el sistema de control lo procesa y detecta que el usuario desea cambiar el mo-do actual a Económico. El cambio real del modo dependerá del estado actual delsistema en base a la tabla de estados detallada en la sección 3.4.

Las subetapas que contemplan el tratamiento de datos para transmisión que seencuentra en ambos bloques consiste en el traspaso de información de una varia-ble al mensaje a transmitir, o al traspaso de un mensaje recibido a una determina-da variable, como se detalló en el ejemplo anterior.

HP Processor es la etapa más importante del sistema que implementa la toma dedecisiones del sistema en base a su estado actual y variables de entrada.

Con respecto a la subetapa ADC Read, ésta realiza una conexión I2C con un con-versor analógico digital ADS1115 [13]. Este conversor tiene la particularidad detener un amplificador de ganancia programable (PGA) que lo hace muy apro-piado para la lectura de señales de amplitud relativamente pequeña. Como lalectura de tensión sobre los sensores PT100 son del orden de los 80 mV a 150 mVy el conversor posee para la mayor ganancia un rango de lectura de -256 mV a256 mV con una resolución de 16 bits, se pueden detectar las variaciones en latemperatura con muy buena resolución.

GPIO Write recibe los resultados dados por HP Processor y activa los relés delcompresor, ventilador del evaporador o resistencia según se requiera.

Log Writer se encarga de guardar en un archivo de texto todas las variables repre-sentativas del sistema como modos de operación actual y deseado, temperaturasde entrada, estado de relés, etcétera, para poder ser analizadas durante los ensa-yos del sistema. Existe otro bloque encargado de escribir en un archivo de textotodas las irregularidades del sistema o errores producidos, para poder determi-nar, en el caso de producirse una falla, dónde fue originada.


FIGURA 3.6: Diagrama de bloques de la estructura del software

3.4. Diagrama de estados del sistema

En base a las características obtenidas del controlador visto en la figura 1.2 y alagregado de funcionalidad tanto por aportes del cliente y consideraciones en eldiseño del sistema, se confeccionó el diagrama de estados de la figura 3.7. Ésterepresenta la lógica de control del termo-tanque junto con los eventos que debensuceder para efectuar un cambio de estado. Los modos de operación que inter-vienen en el diagrama son los presentados en la sección 2.3.

Por ser un sistema complejo, para analizar qué eventos producirían un cambio deestado y no otro, para luego poder validar el correcto funcionamiento, se utilizó latécnica STT (State Transition Testing) que es una técnica desarrollada para analizaretapas de software que pueden ser modeladas con una máquina de estados.

Para determinar inequívocamente el funcionamiento del sistema, se confeccionóla tabla 3.7. Esta representa para cada estado actual, qué eventos deben produ-cirse para que surja un cambio de estado. El número indicado previo al cambiode modo representa que se produjo el cambio de modo desde un modo particu-lar y una serie de condiciones de entrada particulares, por lo cual se distingueinequívocamente cómo se produjo dicho cambio de modo. Los colores en los mo-dos de operación sirven para corresponder los diferentes estados entre las tablase imágenes de la presente sección.

Para poder analizar de forma gráfica el comportamiento del sistema se realizóel árbol de transiciones de estados que se muestra en la figura 3.8. En la mismapueden verse las transiciones que se pueden realizar desde un determinado modoa otro. El número indica que condiciones debieron ser cumplidas para producirsedicho cambio en base a la tabla 3.7.

3.5. Puesta en marcha del software de interfaz gráfica

Es necesario utilizar un método que ejecute la aplicación desarrollada en panta-lla completa para proveer al sistema un diseño integrado. El usuario sólo debepoder ver y operar la aplicación, no puede acceder a regiones del sistema sin lospermisos pertinentes.

3.5. Puesta en marcha del software de interfaz gráfica 27

FIGURA 3.7: Diagrama de estados del sistema


TABLA 3.7: Tabla de transición de estados con respecto a distintoseventos asociados

Eventos Económico Potencia Confort Antibacterial Standby Descongelar

temperaturaEvaporador>0ModoDeseadoEconomico

*6-Económico

11-Económico

* * *

temperaturaEvaporador>0ModoDeseadoConfort

1-Confort 7-Confort * * * *

temperaturaEvaporador>0ModoDeseadoPotencia

2-Potencia *12-Potencia

* * *

temperaturaEvaporador<03-Descongelar

8-Descongelar

13-Descongelar

16-Descongelar

* *

temperaturaEvaporador>0ModoDeseadoEconomicoStandbyDesactivado

* * * *22-Económico

*

temperaturaEvaporador>0ModoDeseadoConfortStandbyDesactivado

* * * * 23-Confort *

temperaturaEvaporador>0ModoDeseadoPotenciaStandbyDesactivado

* * * *24-Potencia

*

temperaturaEvaporador<0StandbyDesactivado

* * * *25-Descongelar

*

StandbyButtonPressed 4-Standby 9-Standby 14-Standby 17-Standby * 27-Standby

tiempoTranscurrido6meses5-Antibacterial

10-Antibacterial

15-Antibacterial

* * *

temperaturaAlcanzo70°CtemperaturaEvaporador<0

* * *18-Descongelar

* *

temperaturaAlcanzo70°CtemperaturaEvaporador>0ModoDeseadoEconomico

* * *19-Económico

* *

temperaturaAlcanzo70°CtemperaturaEvaporador>0ModoDeseadoConfort

* * * 20-Confort * *

temperaturaAlcanzo70°CtemperaturaEvaporador>0ModoDeseadoPotencia

* * * 21-Potencia * *

temperaturaEvaporador>3ModoDeseadoEconomico

* * * * *28-Económico

temperaturaEvaporador>3ModoDeseadoConfort

* * * * * 29-Confort

temperaturaEvaporador>3ModoDeseadoPotencia

* * * * *30-Potencia

tiempoTranscurrido6mesesStandbyDesactivado

* * * *26-Antibacterial

*

tiempoTranscurrido6mesestemperaturaEvaporador<0

* * * * *31-Antibacterial

3.5. Puesta en marcha del software de interfaz gráfica 29

FIGURA 3.8: Arbol de transiciones de estados


Para satisfacer dicho requerimiento se utilizó el plugin EGLFS [14], que es uncomplemento de plataforma para ejecutar aplicaciones Qt5 sobre EGL y OpenGLES 2.0.

Éste es el complemento recomendado para los dispositivos Linux embebidos mo-dernos que incluyen una GPU. Ya que se utiliza la GPU para realizar el renderi-zado de las animaciones presentes en la aplicación.

EGLFS obliga a que la primera ventana de nivel superior (ya sea QWidget o QQuick-View) se convierta en pantalla completa. Esta ventana también se elige para ser laventana del widget raíz en la que se componen todos los demás widgets de nivelsuperior (por ejemplo, cuadros de diálogo, menús emergentes o menús desplega-bles de cuadros combinados). Ésto es necesario porque con EGLFS siempre hayexactamente una ventana nativa y una superficie de ventana EGL, y éstas perte-necen al widget o ventana que se crea primero.

Este enfoque funciona bien cuando existe una ventana principal para toda la vi-da útil de la aplicación y todos los demás widgets no son de nivel superior o secrean después, una vez que se muestra la ventana principal. En base a todas lascaracterísticas presentadas, EGLFS sirvió obtener un diseño integrado mediantela ejecución de la aplicación en pantalla completa.

Antes de poder desarrollar la aplicación en Qt, fue necesario realizar una serie depasos en la instalación, configuración y descarga de paquetes para poder realizarla compilación cruzada sobre la plataforma Raspberry Pi 3 utilizando Qt Quick.

Basándose en la información obtenida de una serie de páginas web [15] [16] [17]se realizó la descarga del código fuente junto con la dependencia de paquetes ybibliotecas.

La versión utilizada de Qt fue la 5.10.1 ya que era una versión reciente y ya poseíalas características de Qt-Quick que se esperaba obtener al implementar la aplica-ción gráfica.

Cuando se descargaron todos los archivos requeridos fue necesario hacer la con-figuración del código fuente para poder incluir las funcionalidades deseadas yquitar las que se reconoce que no van a ser utilizadas o que provocan problemasal realizar la compilación del código fuente. La configuración del código fuentesuele tardar unos 30 minutos en una PC de gama media, mientras que la construc-ción del código fuente suele tardar unas 7 u 8 horas. Este procedimiento requirió3 semanas de trabajo para poder lograr una versión estable del software que noarroje errores durante la compilación del código fuente. Buscando diferentes al-ternativas en internet, cambiando tanto de versiones de Qt como de parámetrosde configuración se logró obtener una versión funcional utilizando los siguientesparámetros de configuración:

1 ./ conf igure −skip qtwayland −skip q t l o c a t i o n −opengl es2 −device rasp−pi3−g++ −device−option CROSS_COMPILE=~/ r a s p i / t o o l s /arm−bcm2708/gcc−l inaro−arm−l inux−gnueabihf−raspbian−x64/bin/arm−l inux−gnueabihf− −sysroot ~/ r a s p i /sysroot −opensource −confirm−l i c e n s e −optimized−qmake −reduce−exports −r e l e a s e −make l i b s −p r e f i x /usr/ l o c a l /qt5pi −e x t p r e f i x ~/ r a s p i /qt5pi −h o s t p r e f i x ~/ r a s p i /qt5 −v −no−use−gold−l i n k e r −nomake examples −no−compile−examples −nomake t e s t s \

2 −skip q t s e r i a l b u s −skip qtscxml −skip q t s c r i p t −skip q t c h a r t s −skip qt3d\

3 −skip qtdatavis3d −skip qtcanvas3d −skip qtgamepad −skipqtv i r tua lkeyboard \

3.6. Montaje del controlador en el termo-tanque 31

4 −skip qtwayland −skip qtwebengine −skip qtwebchannel −skip qtwebglplugin\

5 −skip qtwebsockets −−recheck−a l l

La salida de consola que se obtuvo mediante los pasos indicados se puede ver enel apéndice A.

Luego de realizarse la configuración se ejecutó el siguiente comando para compi-lar el código fuente:

1. Primero se ejecuta para compilar ’make -j4’. En caso de poseer 4 nucleos, -j4mejoraría el tiempo de compilación.

2. Segundo se instala el programa compilado ’make install’.

Luego fue necesario realizar configuraciones dentro del software de Qt que seencuentran detalladas en las referencias [15] [16] [17].

3.6. Montaje del controlador en el termo-tanque

Para realizar la unión entre los diferentes de componentes del sistema de control,fue necesario interactuar con el cliente para poder determinar las dimensionesdel sistema en base al espacio disponible dentro del termo-tanque y al montajedel mismo sobre el panel frontal. Las partes intervinientes del sistema de controlson:

Raspberry Pi 3b+

Placa base: constituye las etapas de adquisición de temperaturas, acciona-miento de relés, comunicación con RTC y fuentes de alimentación de todoel sistema de control.

Módulo de pantalla táctil de 5 pulgadas.

Siendo la placa de la Raspberry Pi junto con la del display TFT-LCD de dimensio-nes reducidas con respecto a la placa base, se diseñó ésta última de manera tal decontener a las dos primeras. Además la placa base dispone agujeros de dimensio-nes y posicionamiento dadas por el cliente para efectuar el montaje del sistemasobre el panel frontal del termo-tanque.

La unión de las placas fue realizada mediante separadores hexagonales (usual-mente conocidos como "Tamecos") de diferentes longitudes, para obtener un di-seño firme evitando el contacto entre placas de forma indeseada. El PCB de laplaca base diseñado, la interconexión del mismo con la Raspberry Pi y el módulode pantalla táctil se muestran en la figura 3.9.

3.7. Interfaz gráfica desarrollada

En base al desarrollo mencionado en las secciones anteriores se implementó lainterfaz gráfica que se muestra en las figuras 3.10 en la misma se puede ver ellogo de Rheem desplazado, en esta versión se estaba empezando a desarrollar lanueva interfaz gráfica y fue la última desarrollada con este diseño, no se realizó lacorrección del mismo porque funcionalmente opera correctamente y se encuentra


(A) Vista dorsal

(B) Vista frontal

(C) Vista lateral

FIGURA 3.9: Prototipo del sistema de control desarrollado

3.8. Gestión de la calidad 33

en período de reemplazo por el nuevo diseño. En la figura 3.10 puede verse elmenu principal, y las secciones para seleccionar un modo de operación con unatemperatura dada. El funcionamiento del sistema operando en el termo-tanquese puede ver en el link1.

En la figura 3.11a se puede ver el sistema montado en el panel frontal del termo-tanque, el diseño del panel frontal fue realizado por Rheem S.A en conjunto conuna empresa de diseño industrial. Para obtener una interfaz que se ajuste al con-torno de la pantalla se realizó una nueva interfaz gráfica que se muestra en lafigura 3.11b. Esta nueva interfaz se encuentra actualmente en desarrollo, poseeun diseño con tonalidades más oscuras, la nueva interfaz es totalmente distintaa la desarrollada anteriormente y contempla el agregado de un gran número defuncionalidades. En la figura 3.11c se muestra cómo se seleccionan los modos deoperación en la nueva interfaz gráfica.

3.8. Gestión de la calidad

Para cada uno de los requerimientos del proyecto vistos en la sección 2.4 referi-dos a funcionalidades, se realizaron test unitarios automatizados, se integraronal sistema realizando test de integración y luego con el sistema totalmente im-plementado se le realizaron test funcionales, por último se realizaron pruebas decampo. Cada uno de los requerimientos es verificado y validado en base a lasetapas presentadas en las tablas 2.1 a 2.4.

1. Requerimiento 1: el sistema debe accionar tres relés para activar el compre-sor, el ventilador del evaporador, la resistencia según corresponda en baseal modo elegido y la temperatura del agua.

Validación: "1.1. Dimensionamiento del proyecto en base a requeri-mientos del cliente"se encarga de validar este requerimiento.

Verificación: "3.6 Verificar la funcionalidad de cada subetapa anterior"seencarga de verificar que el requerimiento ha sido logrado satisfactoria-mente.

2. Requerimiento 2: se debe sensar la temperatura en la parte inferior, superiordel tanque de agua y en el evaporador. En el caso de que la temperatura enel evaporador sea menor a 0°C debe encenderse el ventilador del evapora-dor hasta que el mismo se descongele.

Validación: "3.4 Diseño de la lógica del sistema"se encarga de validareste requerimiento.


3. Requerimiento 3: el sistema debe proveer de una interfaz gráfica fácil deutilizar e intuitiva para uso hogareño. Debe tener la capacidad de configu-ración de modos de operación y temperaturas deseadas.

1https://drive.google.com/file/d/1Hqc_yB3MFaqWk5mN7gngQjM2SnAqiwUB/view?usp=sharing

https://drive.google.com/file/d/1Hqc_yB3MFaqWk5mN7gngQjM2SnAqiwUB/view?usp=sharing

https://drive.google.com/file/d/1Hqc_yB3MFaqWk5mN7gngQjM2SnAqiwUB/view?usp=sharing


(A) Menú Principal. (B) Sección modo Económico.

(C) Sección modo Potencia. (D) Sección modo Confort.

FIGURA 3.10: Interfaz gráfica desarrollada.


(A) Interfaz gráfica montada en el panel frontal.

(B) Diseño de la nueva interfaz gráfica montadaen el panel frontal.

(C) Selección de modos de la nueva interfazgráfica.

FIGURA 3.11: Interfaz gráfica montada en el panel frontal, diseñode la nueva interfaz gráfica montada en el panel frontal.


Validación: "1.3. Selección de pantalla táctil compatible con el hardwa-re elegido"se encarga de validar este requerimiento.

Verificación: "2.4. Pruebas funcionales"se encarga de verificar que elrequerimiento ha sido logrado satisfactoriamente.

4. Requerimiento 4: el sistema debe funcionar mediante una pantalla táctil pa-ra la operación del termotanque.


Verificación: "2.4. Pruebas funcionales"se encarga de verificar que elrequerimiento ha sido logrado satisfactoriamente.

5. Requerimiento 5: se debe diseñar el circuito impreso siguiendo las dimen-siones provistas por el cliente para obtener un diseño compacto y de fácilmontaje.

Validación: "6.2. Diseño circuito impreso"se encarga de validar este re-querimiento.

Verificación: "6.3. Verificación del esquemático y circuito impreso"seencarga de verificar que el requerimiento ha sido logrado satisfacto-riamente.

6. Requerimiento 6: el sistema debe contener un RTC (real time clock) quepueda dar noción de tiempo al sistema para guardar logs de estado e im-plementar funciones periódicas.

Validación: "3.4 Diseño de la lógica del sistema"se encarga de validareste requerimiento.


7. Requerimiento 7: se debe diseñar el sistema priorizando la robustez del mis-mo y el tiempo de desarrollo por igual.


Verificación: "9.2 Dejar el termo-tanque funcionando unos días cam-biando parámetros de configuración y verificando su respuesta"se en-carga de verificar que el requerimiento ha sido logrado satisfactoria-mente.

8. Requerimiento 8: realizar entregas parciales mostrando las nuevas funcio-nalidades implementadas.


Verificación: Al finalizar cada etapa es informado al cliente los avancesobtenidos, a su vez se le informa al cliente el plazo de desarrollo de laetapa que vendrá a continuación.


9. Requerimiento 9: la aplicación debe inicializarse apenas el sistema se en-cienda.

Validación: "2.1. Configuración buildeo e instalación del software parauso en el hardware seleccionado"se encarga de validar este requeri-miento.

Verificación: "2.5 Corrección de posibles discrepancias. Mejora del soft-ware desarrollado"se encarga de verificar que el requerimiento ha sidologrado satisfactoriamente.

10. Requerimiento 10: debe restringirse al usuario de acceder a áreas que nocorrespondan a la operación del sistema de control.

Validación: "2.1. Configuración buildeo e instalación del software parauso en el hardware seleccionado"se encarga de validar este requeri-miento.


11. Requerimiento 11: la aplicación debe mostrar información importante alusuario como el modo en el que se encuentra el termotanque y la tempe-ratura actual del agua.

Validación: "2.3. Desarrollo de la aplicación gráfica del proyecto"se en-carga de validar este requerimiento.


12. Requerimiento 12: debe poder seleccionarse el modo de operación y la tem-peratura.



39

Capítulo 4

Ensayos y Resultados

El presente capítulo detalla cómo fueron realizados los test unitarios automati-zados y test exploratorios de todas las etapas que integran el sistema. Luego deobtenerse el sistema montado y con el software desarrollado, se validó el com-portamiento del mismo para luego realizarse una prueba de campo. Al final delcapítulo se detallan los resultados obtenidos de los ensayos y pruebas realizadas.

4.1. Test unitarios automatizados

En base a la información obtenida del modelado del sistema en la sección 3.2,se realizaron test unitarios automatizados en base a test scripts legales e ilegales,basados en las técnicas ECT y STT. Los test scripts legales pueden verse en lastablas 4.1 y 4.2. También se confeccionó una tabla de casos de prueba ilegales quecorresponden a todas las transiciones de estados que no deben suceder frente adeterminados eventos, por ser la tabla muy extensa no se incluye en el presentedocumento. Estos test scripts fueron la información base para el desarrollo de testunitarios automatizados que evaluaron el correcto comportamiento del sistema.

Los test unitarios automatizados se realizaron mediante la herramienta Ceedlingque es un framework para analizar bloques de código escritos en C y evaluarcómo se comportan frente a diferentes casos de prueba. Ceedling está dirigidoprincipalmente al desarrollo basado en pruebas en C y está diseñado para unirCMock, Unity y CException [18].

En el trabajo desarrollado sólo fueron utilizadas las características de Unity paraarmar las pruebas unitarias.

Comúnmente los test unitarios son confeccionados mediante el paradigma TDDo Test-Driven Development (desarrollo dirigido por tests), que es una práctica deprogramación que consiste en escribir primero las pruebas (generalmente unita-rias), después escribir el código fuente que pase la prueba satisfactoriamente y,por último, refactorizar el código escrito [19]. Con esta práctica se consigue entreotras cosas: un código con mayor robustez, seguridad, mantenibilidad y rapidezen el desarrollo.

En este caso no se realizó el software utilizando TDD, debido a que la región decódigo encargada de la máquina de estados del sistema ya estaba desarrolladapreviamente al aprendizaje de esta herramienta en la materia "Testing de softwa-re en sistemas embebidos"de la CESE. De todos modos, esta herramienta poseecaracterísticas interesantes como poder correr test unitarios sobre el código para

40 Capítulo 4. Ensayos y Resultados

TABLA 4.1: Tabla de casos de prueba legales 1-2

Input Expected resultID Event Guard Action State

L1.1.1temperaturaEvaporador>0ModoDeseadoEconomico

El sistema se debeencontrar dentro delmodo Potencia.

Cambiaral mododeseado

Económico

L1.1.2temperaturaEvaporador>0ModoDeseadoEconomico

El sistema se debeencontrar dentro delmodo Confort.


Económico

L1.2.1temperaturaEvaporador>0ModoDeseadoConfort

El sistema se debeencontrar dentro delmodo Económico.


Confort

L1.2.2temperaturaEvaporador>0ModoDeseadoConfort

El sistema se debeencontrar dentro delmodo Potencia.


Confort

L1.3.1temperaturaEvaporador>0ModoDeseadoPotencia

El sistema se debeencontrar dentro delmodo Económico.


Potencia

L1.3.2temperaturaEvaporador>0ModoDeseadoPotencia

El sistema se debeencontrar dentro delmodo Confort.


Potencia

L1.4.1 temperaturaEvaporador<0El sistema se debeencontrar dentro delmodo Económico

Descongelarevaporador

Descongelar

L1.4.2 temperaturaEvaporador<0El sistema se debeencontrar dentro delmodo Potencia


Descongelar

L1.4.3 temperaturaEvaporador<0El sistema se debeencontrar dentro delmodo Confort


Descongelar

L1.4.4 temperaturaEvaporador<0El sistema se debeencontrar dentro delmodo Antibacterial


Descongelar

L1.5temperaturaEvaporador>0ModoDeseadoEconomicoStandbyDesactivado

El sistema se debeencontrar dentro delmodo Standby


Económico

L1.6temperaturaEvaporador>0ModoDeseadoConfortStandbyDesactivado



Confort

L1.7temperaturaEvaporador>0ModoDeseadoPotenciaStandbyDesactivado



Potencia

L1.8temperaturaEvaporador<0StandbyDesactivado



Descongelar

L1.9.1 StandbyButtonPressedEl sistema se debeencontrar dentro delmodo Económico

Dejar alsistemapausado

Standby

4.1. Test unitarios automatizados 41

TABLA 4.2: Tabla de casos de prueba legales 2-2

L1.9.2 StandbyButtonPressedEl sistema se debeencontrar dentro delmodo Potencia


Standby

L1.9.3 StandbyButtonPressedEl sistema se debeencontrar dentro delmodo Confort


Standby

L1.9.4 StandbyButtonPressedEl sistema se debeencontrar dentro delmodo Antibacterial


Standby

L1.9.5 StandbyButtonPressedEl sistema se debeencontrar dentro delmodo Descongelar


Standby

L2.1 tiempoTranscurrido6mesesEl sistema se debeencontrar dentro delmodo Potencia.

Realizar elproceso an-tibact.

Antibacterial

L2.1 tiempoTranscurrido6mesesEl sistema se debeencontrar dentro delmodo Confort.


Antibacterial

L2.1 tiempoTranscurrido6mesesEl sistema se debeencontrar dentro delmodo Económico.


Antibacterial

L2.2 temperaturaAlcanzo70°CEl sistema se debeencontrar dentro delmodo Antibacterial.


Descongelar

L2.3temperaturaAlcanzo70°CtemperaturaEvaporador>0ModoDeseadoEconomico

El sistema se debeencontrar dentro delmodo Antibacterial.


Económico

L2.4temperaturaAlcanzo70°CtemperaturaEvaporador>0ModoDeseadoConfort



Confort

L2.5temperaturaAlcanzo70°CtemperaturaEvaporador>0ModoDeseadoPotencia



Potencia

L2.6temperaturaEvaporador>3ModoDeseadoEconomico

El sistema se debeencontrar dentro delmodo Descongelar.


Económico

L2.7temperaturaEvaporador>3ModoDeseadoConfort


Cambiaral mododeseadoo

Confort

L2.8 temperaturaEvaporador>3El sistema se debeencontrar dentro delmodo Descongelar.


Potencia

L2.9tiempoTranscurrido6mesesStandbyDesactivado

El sistema se debeencontrar dentro delmodo Standby.


Antibacterial

L3.0tiempoTranscurrido6mesestemperaturaEvaporador>0



Antibacterial


evaluar el sistema en todas las condiciones de operación. Dado que en el momen-to cuando fue presentado el paradigma TDD se estaba por comenzar con tareasde testing en diferentes regiones del sistema, fue oportuno hacer uso de dichaherramienta. TDD es excelente para poder evaluar el código con los mismos testunitarios desarrollados, una y otra vez frente a cambios en la máquina de estadosdel sistema, ya sea por optimización en la performance, corrección de errores y/oel agregado de funcionalidades.

Como se tiene alrededor de 2500 líneas de código referidas a test unitarios, seejemplifica en la presente sección cómo fue implementado el desarrollo de los testcases mediante ejemplos, donde frente a una serie de cambios en el sistema seespera que la máquina de estados responda de una manera en particular.

A continuación se detallan diferentes regiones del código encargado de realizarun caso de prueba el cual se muestra en en algoritmo 4.1:

La instrucción HP_State_t registro_estado; muestra el registro que almacenatodas las variables representativas al estado actual y deseado del termo-tanque.

La función HP_processor (& registro_estado); corresponde a la función queimplementa el diagrama de estados del termo-tanque.

Para poder analizar su comportamiento se aplican precondiciones en cadatest case a la estructura registro_estado, pasándose la misma por referencia ala función HP_processor.

Luego se analiza funcionamiento esperable del sistema comparando loscampos de registro_estado con respecto al comportamiento que debe cum-plir.

1 # include " unity . h"2 # include " HP_processor . h"3 # include <stdbool . h>4 # include < s t r i n g . h>5

6 HP_State_t r e g i s t r o _ e s t a d o ;7

8 void setUp ( void ) {9 // I n i c i a l i z a m o s v a r i a b l e s de estado i n i c i a l

10

11 r e g i s t r o _ e s t a d o . modoActual = DETENIDO;12 r e g i s t r o _ e s t a d o . releComp = OFF ;13 r e g i s t r o _ e s t a d o . re leRes = OFF ;14 r e g i s t r o _ e s t a d o . re leVent = OFF ;15 r e g i s t r o _ e s t a d o . cambioModo = 0 ;16

17 }18

19 void test_inic ia l izacion_del_sistema_hp_modoDetenido_es_modoActual ( void ){

20 //Temperaturas "MEDIDAS" ( simulo l e c t u r a de temperaturas )21 r e g i s t r o _ e s t a d o . temperaturaActualSup = 2 7 ;22 r e g i s t r o _ e s t a d o . temperaturaActualInf = 2 4 ;23 r e g i s t r o _ e s t a d o . temperaturaActualEvap = 1 3 ;24 //Se encuentra l i s t o para poder cambiar de modo25 r e g i s t r o _ e s t a d o . botonRun = ON;26 HP_processor(& r e g i s t r o _ e s t a d o ) ;27

4.1. Test unitarios automatizados 43

28 //Verif icamos que s ig a en modo detenido luego de hacer un llamado aHP_processor

29 TEST_ASSERT_EQUAL(DETENIDO, r e g i s t r o _ e s t a d o . modoActual ) ;30

31

32 }33 void tes t_ in ic ia l izac ion_del_s i s tema_re lesapagados_en_modoDetenido ( void )

{34 //Temperaturas "MEDIDAS" ( simulo l e c t u r a de temperaturas )35 r e g i s t r o _ e s t a d o . temperaturaActualSup = 2 7 ;36 r e g i s t r o _ e s t a d o . temperaturaActualInf = 2 4 ;37 r e g i s t r o _ e s t a d o . temperaturaActualEvap = 1 3 ;38 //Se encuentra l i s t o para poder cambiar de modo39 r e g i s t r o _ e s t a d o . botonRun = ON;40 HP_processor(& r e g i s t r o _ e s t a d o ) ;41

42 //Verif icamos que s ig a en modo detenido luego de hacer un llamado aHP_processor

43 TEST_ASSERT_EQUAL(DETENIDO, r e g i s t r o _ e s t a d o . modoActual ) ;44 //ver i f i camos que l o s r e l e s se encuentran apagados45 TEST_ASSERT_EQUAL(OFF , r e g i s t r o _ e s t a d o . releComp ) ;46 TEST_ASSERT_EQUAL(OFF , r e g i s t r o _ e s t a d o . re leVent ) ;47 TEST_ASSERT_EQUAL(OFF , r e g i s t r o _ e s t a d o . re leRes ) ;48 }49 void test_cambio_de_modoActual_igual_a_modoDeseado_con_botonRunON ( void ) {50 //Temperaturas "MEDIDAS" ( simulo l e c t u r a de temperaturas )51 r e g i s t r o _ e s t a d o . temperaturaActualSup = 2 7 ;52 r e g i s t r o _ e s t a d o . temperaturaActualInf = 2 4 ;53 r e g i s t r o _ e s t a d o . temperaturaActualEvap = 1 3 ;54 //Se encuentra l i s t o para poder cambiar de modo55 r e g i s t r o _ e s t a d o . botonRun = ON;56 //Var iab les ingresadas por e l usuario s e l e c c i o n a modo economico con

una temperatura deseada de 35 grados57 r e g i s t r o _ e s t a d o . modoDeseado = ECONOMICO;58 r e g i s t r o _ e s t a d o . temperaturaDeseada = 3 5 ;59

60 HP_processor(& r e g i s t r o _ e s t a d o ) ;61

62 //Verif icamos que se h a l l a r e a l i z a d o e l cambio de modo63 TEST_ASSERT_EQUAL(ECONOMICO, r e g i s t r o _ e s t a d o . modoActual ) ;64 //Verif icamos que l a temepratura deseada se h a l l a seteado

correctamente65 TEST_ASSERT_EQUAL( 3 5 , r e g i s t r o _ e s t a d o . temperaturaDeseada ) ;66 //ver i f i camos que l o s r e l e s se encuentran encendidos segun su modo67 //Como l a temperatura deseada es mayor l a temperaturaActualInf68 //Se debe c a l e n t a r u t i l i z a n d o solo e l Compresor y e l v e n t i l a d o r .69 //La r e s i s t e n c i a se encuentra apagada siempre en e s t e modo70 TEST_ASSERT_EQUAL(ON, r e g i s t r o _ e s t a d o . releComp ) ;71 TEST_ASSERT_EQUAL(ON, r e g i s t r o _ e s t a d o . re leVent ) ;72 TEST_ASSERT_EQUAL(OFF , r e g i s t r o _ e s t a d o . re leRes ) ;73 }74 void test_cambio_de_modoActual_igual_a_modoDeseado_con_botonRunOFF ( void )

{75 //Este TestCase es s i m i l a r a l a n t e r i o r pero por e s t a r e l s is tema Run

=OFF e l modo76 //debe pernamecer en detenido i n c l u s o cuando e l usuario s e t e a un

modo deseado .77

78 //Temperaturas "MEDIDAS" ( simulo l e c t u r a de temperaturas )79 r e g i s t r o _ e s t a d o . temperaturaActualSup = 2 7 ;80 r e g i s t r o _ e s t a d o . temperaturaActualInf = 2 4 ;81 r e g i s t r o _ e s t a d o . temperaturaActualEvap = 1 3 ;82


83 //El sis tema NO se encuentra l i s t o para poder cambiar de modo84 r e g i s t r o _ e s t a d o . botonRun = OFF ;85 //Var iab les ingresadas por e l usuario s e l e c c i o n a modo economico con

una temperatura deseada de 35 grados86 r e g i s t r o _ e s t a d o . modoDeseado = ECONOMICO;87 r e g i s t r o _ e s t a d o . temperaturaDeseada = 3 5 ;88

89 HP_processor(& r e g i s t r o _ e s t a d o ) ;90

91 //Verif icamos que se h a l l a quedado en modo detenido i n c l u s o a lt r a t a r de cambiar e l modo

92 TEST_ASSERT_EQUAL(DETENIDO, r e g i s t r o _ e s t a d o . modoActual ) ;93 //Verif icamos que l a temepratura deseada se h a l l a seteado

correctamente94 TEST_ASSERT_EQUAL( 3 5 , r e g i s t r o _ e s t a d o . temperaturaDeseada ) ;95

96 //Al e s t a r en modoDetenido l o s r e l e s deben permanecer apagados97 TEST_ASSERT_EQUAL(OFF , r e g i s t r o _ e s t a d o . releComp ) ;98 TEST_ASSERT_EQUAL(OFF , r e g i s t r o _ e s t a d o . re leVent ) ;99 TEST_ASSERT_EQUAL(OFF , r e g i s t r o _ e s t a d o . re leRes ) ;

100 }

ALGORITMO 4.1: Test case desarrollado con Ceedling sobre elbloque que conforma la máquina de estados

4.2. Revisiones eléctricas y funcionales del PCB

Luego del montaje de los componentes en el circuito impreso se realizaron prue-bas funcionales en puntos claves del mismo como por ejemplo:

1. La tensión de 5,1 V de alimentación a la Raspberry Pi, tensión de 3,3 V deprecisión para la medición de los sensores PT100 y tensión en 12 V a laentrada de los relés.

2. Activación de los relés mediante el GPIO de la Raspberry. Se analiza su sa-lida mediante leds para validar visualmente el comportamiento ya que solopor su sonido característico al cambiar de estado, no se puede determinarcuál está activo y cuál no.

3. Simulación de las resistencias de los PT100 para verificar la lectura correctaen el conversor AD. Además se calibró la temperatura medida con respectoa la resistencia conectada a la entrada del sistema. Luego conectaron lossensores PT100 y se calibró el sistema mediante el sensado de diferentesvalores de temperatura en base a un sensor de referencia.

4.3. Testeo a nivel exploratorio y funcional

Luego de realizar la verificación del PCB se procedió a la revisión del sistemadesde la interfaz táctil cuando se comunica internamente con la lógica del con-trolador. En base a los parámetros de entrada y el estado actual del sistema, seevalúa el funcionamiento esperado en las salidas y variables internas. A conti-nuación se enumera una serie de procedimientos llevados a cabo para realizar eltesteo exploratorio del sistema:

Se evaluó el comportamiento dinámico del sistema que no contemplaba lamáquina de estados analizada con los test unitarios automatizados.

4.4. Prueba de campo 45

Se analizó el comportamiento de la interfaz gráfica para detectar cualquierinconsistencia en el funcionamiento y poder corregirla.

Se analizaron los archivos creados por el sistema para verificar que la infor-mación sea correcta.

•

4.4. Prueba de campo

4.4.1. Consideraciones previas a la realización del ensayo

La presente subsección realiza un análisis de los datos obtenidos del sistema du-rante los días 27/8/19 a 03/09/19.

Para la confección del ensayo se seteó el sistema en modo Económico (sólo bombade calor en funcionamiento) se realizó el calentamiento para diferentes tempera-turas de set-point durante cada ciclo realizado.

El sistema de bomba de calor no se encontraba totalmente ajustado para operarcon normalidad durante el ensayo. Se estaban realizando diferentes configura-ciones de los componentes que integran la BC del termo-tanque. El evaporadorno era de las dimensiones requeridas por el equipo por lo cual no lograba adqui-rir suficiente calor del ambiente y producía que no estén asegurados los nivelesde presión y temperatura a la entrada del compresor para poder restablecer sufuncionamiento con normalidad. El compresor se encontraba bastante solicitadoen algunas situaciones y provocaba que se requiera de un tiempo muerto unavez apagado para volver a encenderse. Si no se respetaba dicho tiempo muerto,el compresor no encendía y quedaba en una situación que podría ocasionar larotura del mismo. Se agregó un delay al sistema de control para que luego deapagarse el compresor deba esperar 20 minutos para volver a encenderse.

El sistema posee un tratamiento de las muestras de temperatura del tipo ventanamóvil, el cual realiza el promedio de las últimas 100 muestras. Al llegar una nuevamuestra descarta la muestra más antigua y agrega la nueva muestra al cálculo dela media.

Al encender la bomba de calor, primero se enciende el ventilador del evaporadory luego de 30 segundos se enciende el compresor para asegurarse que a la entradadel compresor, el líquido refrigerante se encuentre totalmente en estado gaseoso.

Las temperaturas de encendido y corte del modo descongelar son de 3 °C y 12 °Crespectivamente.

Para realizar el posterior análisis del ensayo, el sistema almacena en un archivode texto el estado actual del mismo (modos de operación, temperatura medida enlos sensores, estado de relés, etc) a razón de una muestra por segundo aproxima-damente.

4.4.2. Descripción del ensayo

En la figura 4.1 se pueden ver las curvas de las temperatura dadas por la dinámicatérmica del sistema durante los 8 días de ensayo. Las Figuras 4.2, 4.3, 4.4 y 4.5corresponden a subperíodos de tiempo de la figura 4.1 para poder analizar conmayor detalle el comportamiento del sistema.


En todos los gráficos:

La curva negra corresponde a la temperatura deseada.

La curva roja corresponde a la temperatura en la región inferior del termo-tanque.

La curva azul a la temperatura en la región superior del termo-tanque.

La curva verde corresponde a la temperatura en el evaporador.

FIGURA 4.1: Resultados obtenidos del ensayo realizado

Durante las primeras 24 horas del ensayo (figura 4.2) se realizaron ajustes en laválvula de expansión para evitar que el sistema se enfríe rápidamente al encen-der la bomba de calor. Esto es necesario para no entrar en el modo descongelarrepetidamente lo que produciría que el sistema no pueda calentar el agua.

Con respecto a la figura, se puede notar que se realizaron tres calentamientos (A,C, D) y se dejó en reposo al sistema en dos ocasiones (B y E), la región E continúaen la figura 4.3.

FIGURA 4.2: Resultados obtenidos del ensayo realizado subsec-ción 1-4


En la figura 4.3, terminó el proceso de enfriado (etapa E) que comenzó en la figura4.2, se procedió a calentar el sistema nuevamente (etapa F) y luego el sistemaquedó en reposo (etapa G) hasta comienzos de la figura 4.4.


En la figura 4.4, en la etapa H, el Licenciado en Matemática y Física Juan RicardoLauretta, encargado del diseño e implementación del sistema BC, estuvo modi-ficando las presiones de alta y de baja del sistema debido que la presión de bajaestaba en 4 bar y según el datasheet del compresor debe estar alrededor de los 2.5bar. Luego de cierto tiempo la temperatura a la salida del compresor estaba alre-dedor de los 80 grados con una presión de 24 bar, mientras que el compresor estádiseñado para operar a 15 bar. Debido a este comportamiento que podría originarla rotura del compresor, se baja la temperatura del set point de 55 °C a 51 °C paraque el compresor pueda enfriarse (Etapa I).



Al quedar el sistema un poco inestable por la situación de la etapa anterior, cuan-do la temperatura es inferior al set-point de temperatura inferior (figura 4.5) queindica que el modo debe comenzar a calentar, el evaporador comienza a enfriarserápidamente y en consecuencia el sistema entra repetidamente en modo descon-gelar (etapa final de I) sin poder calentar el agua. Luego de un cierto tiempo, seinterrumpe el ensayo del sistema (etapa J).

En la etapa K no se realizaron mediciones a razón de una muestra por segundo,sino que lo que se grafica es la interpolación de datos al comienzo de la etapacon respecto a algunas muestras tomadas el día 3/9. El sistema no se encontró enfuncionamiento durante los días 31/08, 01/09 y 02/09, pero se decidió agregarlas muestras del día 03/09 para poder evaluar cuánto descendió la temperaturadel termo-tanque en dicho período.


4.4.3. Análisis de los datos

En esta subsección se calculan las pendientes de las curvas de calentamiento yenfriamiento para poder determinar la temperatura obtenida por hora duranteel calentamiento del termo-tanque para diferentes set points y la pérdida de tem-peratura por hora cuando el sistema se encuentra en reposo. Los resultados sepresentan en la tabla 4.3.

Promediando el ritmo de cambio obtenido de las etapas A, C, D, F se obtiene unarazón de cambio de temperatura por hora (°C/hora) con respecto al calentamien-to de:

Sensor de temperatura inferior ∆T/∆t = 2,76 °C/hora

Sensor de temperatura superior ∆T/∆t = 2,59 °C/hora

Si bien en cada ensayo de calentamiento los resultados obtenidos son del mis-mo orden de magnitud, las variaciones obtenidas como resultado de cada uno deellos, se deben a que el sistema estuvo en calentamiento en diferentes períodos de


TABLA 4.3: Performance del termo-tanque durante el Calenta-miento y Reposo

EtapaDuración(min)

Estado Sensor

Diferenciade tem-peratura(°C)

Razón decambio(°C/Hora)

A 130 Calentando Inferior 6.3 2.91A 130 Calentando Superior 5.8 2.68B 130 Reposo Inferior -0.3 -0.138B 130 Reposo Superior -0.5 -0.231C 57 Calentando Inferior 3 3.15C 57 Calentando Superior 3 3.15D 140 Calentando Inferior 6.2 2.66D 140 Calentando Superior 5.6 2.4E 960 Reposo Inferior -3.2 -0.2E 960 Reposo Superior -3.2 -0.2F 330 Calentando Inferior 12.7 2.31F 330 Calentando Superior 11.7 2.13G 1170 Reposo Inferior -5.1 -0.26G 1170 Reposo Superior -4.9 -0.25H Sin Analizar - Inferior - -H Sin Analizar - Superior - -I 1230 Reposo Inferior -5.4 -0.26I 1230 Reposo Superior -5.7 -0.28J Sin Analizar - Inferior - -J Sin Analizar - Superior - -K 8100 Reposo Inferior -13.6 -0.10K 8100 Reposo Superior -14.2 -0.11


tiempo. En algunos casos, el refrigerante y el compresor no llegaron a su tempe-ratura y presión de funcionamiento en estado permanente. Además, las tempe-raturas dentro del tanque de agua y del ambiente también variaron durante losensayos.

Al promediar el ritmo de cambio obtenido de las etapas B, E, G, I se obtiene unarazón de cambio de temperatura por hora (°C/hora) con respecto al sistema enestado de reposo obteniéndose los siguientes resultados:

Sensor de temperatura Inferior ∆T/∆t = -0.21 °C/hora

Sensor de temperatura Superior ∆T/∆t = -0.24 °C/hora

En el caso del sistema en reposo, la etapa K no se tuvo en cuenta para el análisisanterior por ser un ensayo muy prolongado, el cual se realizó una sola vez ycarece de datos durante el período de análisis, sólo se tienen datos en los extremosdel intervalo.

4.4.4. Resultados obtenidos

El sistema de control funcionó correctamente durante los 8 días en los cuales seefectuó el ensayo. Fue particularmente útil realizar previamente test unitarios au-tomatizados para depurar el comportamiento de la máquina de estados del siste-ma. Las pruebas realizadas mediante leds en la salida de los relés y la simulaciónde valores de los sensores PT100 con resistencias ayudó a verificar que la lógicaejecutada por la máquina de estados muestre correctamente los resultados en lasvariables de salida.

Los resultados obtenidos dan una noción del desempeño del sistema con la confi-guración del termo-tanque actual. Se pueden utilizar como punto de partida paradeterminar cuán lejos o cerca se está del desempeño deseado que se pretende te-ner en el producto final. O incluso es un buen punto de partida para seguir elanálisis del desempeño del termo-tanque a lo largo de las modificaciones que serealicen a posteriori.

51

Capítulo 5

Conclusiones

5.1. Conclusiones generales

Se implementó un prototipo funcional, el cual demostró muy buenos resultadosdurante la prueba de campo y permitió obtener información relevante sobre laconfiguración actual del termo-tanque.

Si bien el sistema de control estaba concebido desde sus comienzos como un con-trolador de termo-tanque para un usuario final, con un simple escalamiento enlos sensores de temperatura es posible obtener un sistema dedicado al análisisdel comportamiento del termo-tanque.

Si se reemplazan componentes claves como el cambio de evaporador, o se prue-ban diferentes formas de transferir el calor, es posible analizar la performance de labomba de calor mediante el sistema de control implementado. Luego, se puededeterminar cómo se desempeñó la configuración ensayada por ejemplo, duranteel calentamiento, en el mantenimiento de la temperatura en estado de reposo, etc.

Esta primera iteración en el desarrollo del controlador provee un excelente puntode partida para saber qué se debe mejorar, tanto en hardware como en software.

Durante el diseño del trabajo no sólo se orientó el desarrollo del controlador a unprototipo, sino también se evaluó como debería ser el diseño del producto final,pensando en que sea escalable desde el prototipo implementado. Al reemplazarla Raspberry Pi 3 a un Compute Module 3+ se obtiene desarrollo más compacto. ElSoM posee una memoria EMMC que le provee robustez al sistema frente a vibra-ciones. Es posible portar todo el software implementado al diseño final realizandouna simple copia de la imagen del sistema.

5.2. Próximos pasos

Para mejorar el prototipo desarrollado es necesario agregar funcionalidades yprestaciones que lo acerquen al desarrollo del producto final.

Se presentan a continuación una serie de aspectos que son necesarios agregar alsistema desarrollado.

Desarrollo del PCB para la Raspberry Compute Module 3++ para obtener unPCB más cercano al del producto final.

Implementación de la nueva interfaz gráfica según especificaciones y reque-rimientos por parte del cliente.

52 Capítulo 5. Conclusiones

Conexión WiFi para ser utilizado en la configuración del mismo o en elenvío de notificaciones por parte del termo-tanque.

Agregado de sensores de temperatura a los prototipos para poder analizardiferentes regiones de la bomba de calor y tener mayor información de quéestá sucediendo en el sistema.

Ajustes a nivel del sistema operativo para que la aplicación se ejecute exac-tamente después de haber encendido el sistema. En estos momentos semuestra el terminal durante la iniciación de la Raspberry y luego se ejecutala aplicación gráfica.

Robustez frente a cortes repentinos en la alimentación del sistema.

Control de los led backlight de la módulo LCD para ahorrar energía y mejorarla vida útil de la pantalla.

Luego de todos los desarrollos mencionados previamente, es necesario realizaruna nueva prueba de campo con el producto final para evaluar el correcto funcio-namiento de todo el sistema fabricado y ensamblado respetando el procedimientoque se lleva a cabo durante fabricación.

53

Apéndice A

Configuración de Qt 5.10.1 paracompilación cruzada

1 Configure summary :2

3 Building on : l inux−g++ ( x86_64 , CPU f e a t u r e s : mmx sse sse2 )4 Building f o r : devices/linux−rasp−pi3−g++ ( arm , CPU f e a t u r e s : neon )5 Configurat ion : cross_compile enable_new_dtags l a r g e f i l e neon

precompile_header shared rpath r e l e a s e c++11 concurrent dbusreduce_exports r e l e a s e _ t o o l s s t l

6 Build options :7 Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . r e l e a s e ; optimized t o o l s8 Optimize r e l e a s e bui ld f o r s i z e . . . . . . . . no9 Building shared l i b r a r i e s . . . . . . . . . . . . . . yes

10 Using C++ standard . . . . . . . . . . . . . . . . . . . . . C++1111 Using ccache . . . . . . . . . . . . . . . . . . . . . . . . . . . no12 Using gold l i n k e r . . . . . . . . . . . . . . . . . . . . . . no13 Using new DTAGS . . . . . . . . . . . . . . . . . . . . . . . . yes14 Using precompiled headers . . . . . . . . . . . . . . yes15 Using LTCG . . . . . . . . . . . . . . . . . . . . . . . . . . . . . no16 Target compiler supports :17 NEON . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . yes18 Build p ar t s . . . . . . . . . . . . . . . . . . . . . . . . . . . . l i b s19 Qt modules and options :20 Qt Concurrent . . . . . . . . . . . . . . . . . . . . . . . . . . yes21 Qt D−Bus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . yes22 Qt D−Bus d i r e c t l y l inked to l ibdbus . . . . yes23 Qt Gui . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . yes24 Qt Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . yes25 Qt Sql . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . yes26 Qt T e s t l i b . . . . . . . . . . . . . . . . . . . . . . . . . . . . . yes27 Qt Widgets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . yes28 Qt Xml . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . yes29 Support enabled f o r :30 Using pkg−conf ig . . . . . . . . . . . . . . . . . . . . . . . yes31 QML debugging . . . . . . . . . . . . . . . . . . . . . . . . . . yes32 udev . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . yes33 Using system z l i b . . . . . . . . . . . . . . . . . . . . . . yes34 Qt Core :35 DoubleConversion . . . . . . . . . . . . . . . . . . . . . . . yes36 Using system DoubleConversion . . . . . . . . yes37 GLib . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . yes38 iconv . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . yes39 ICU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . no40 Logging backends :41 journald . . . . . . . . . . . . . . . . . . . . . . . . . . . . . no42 sys log . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . no43 s log2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . no

54 Apéndice A. Configuración de Qt 5.10.1 para compilación cruzada

44 Using system PCRE2 . . . . . . . . . . . . . . . . . . . . . no45 Qt Network :46 g e t i f a d d r s ( ) . . . . . . . . . . . . . . . . . . . . . . . . . . . yes47 IPv6 ifname . . . . . . . . . . . . . . . . . . . . . . . . . . . . yes48 l ibproxy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . no49 OpenSSL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . yes50 Qt d i r e c t l y l inked to OpenSSL . . . . . . . . no51 SCTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . no52 Use system proxies . . . . . . . . . . . . . . . . . . . . . yes53 Qt Gui :54 A c c e s s i b i l i t y . . . . . . . . . . . . . . . . . . . . . . . . . . yes55 FreeType . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . yes56 Using system FreeType . . . . . . . . . . . . . . . . yes57 HarfBuzz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . yes58 Using system HarfBuzz . . . . . . . . . . . . . . . . yes59 Fontconf ig . . . . . . . . . . . . . . . . . . . . . . . . . . . . . yes60 Image formats :61 GIF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . yes62 ICO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . yes63 JPEG . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . yes64 Using system l i b j p e g . . . . . . . . . . . . . . . yes65 PNG . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . yes66 Using system libpng . . . . . . . . . . . . . . . . yes67 EGL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . yes68 OpenVG . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . no69 OpenGL :70 Desktop OpenGL . . . . . . . . . . . . . . . . . . . . . . . no71 OpenGL ES 2 . 0 . . . . . . . . . . . . . . . . . . . . . . . . yes72 OpenGL ES 3 . 0 . . . . . . . . . . . . . . . . . . . . . . . . yes73 OpenGL ES 3 . 1 . . . . . . . . . . . . . . . . . . . . . . . . yes74 OpenGL ES 3 . 2 . . . . . . . . . . . . . . . . . . . . . . . . yes75 Vulkan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . no76 Sess ion Management . . . . . . . . . . . . . . . . . . . . . yes77 Features used by QPA backends :78 evdev . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . yes79 l i b i n p u t . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . yes80 INTEGRITY HID . . . . . . . . . . . . . . . . . . . . . . . . . . no81 mtdev . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . yes82 t s l i b . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . yes83 xkbcommon−evdev . . . . . . . . . . . . . . . . . . . . . . . . yes84 QPA backends :85 DirectFB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . no86 EGLFS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . yes87 EGLFS d e t a i l s :88 EGLFS OpenWFD . . . . . . . . . . . . . . . . . . . . . . . . no89 EGLFS i . Mx6 . . . . . . . . . . . . . . . . . . . . . . . . . . no90 EGLFS i . Mx6 Wayland . . . . . . . . . . . . . . . . . . no91 EGLFS RCAR . . . . . . . . . . . . . . . . . . . . . . . . . . . no92 EGLFS EGLDevice . . . . . . . . . . . . . . . . . . . . . . no93 EGLFS GBM . . . . . . . . . . . . . . . . . . . . . . . . . . . . yes94 EGLFS Mali . . . . . . . . . . . . . . . . . . . . . . . . . . . no95 EGLFS Raspberry Pi . . . . . . . . . . . . . . . . . . . yes96 EGL on X11 . . . . . . . . . . . . . . . . . . . . . . . . . . . no97 LinuxFB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . yes98 VNC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . yes99 Mir c l i e n t . . . . . . . . . . . . . . . . . . . . . . . . . . . . . no

100 X11 :101 Using system−provided XCB l i b r a r i e s . . yes102 EGL on X11 . . . . . . . . . . . . . . . . . . . . . . . . . . . no103 Xinput2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . yes104 XCB XKB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . yes105 XLib . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . yes106 XCB render . . . . . . . . . . . . . . . . . . . . . . . . . . . yes

Apéndice A. Configuración de Qt 5.10.1 para compilación cruzada 55

107 XCB GLX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . yes108 XCB Xl ib . . . . . . . . . . . . . . . . . . . . . . . . . . . . . yes109 Using system−provided xkbcommon . . . . . . no110 Native paint ing ( experimental ) . . . . . . . yes111 Qt Widgets :112 GTK+ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . no113 S t y l e s . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Fusion Windows114 Qt PrintSupport :115 CUPS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . yes116 Qt Sql :117 DB2 (IBM) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . no118 I n t e r B a s e . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . no119 MySql . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . no120 OCI ( Oracle ) . . . . . . . . . . . . . . . . . . . . . . . . . . . no121 ODBC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . yes122 PostgreSQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . yes123 SQLite2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . yes124 SQLite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . yes125 Using system provided SQLite . . . . . . . . . no126 TDS ( Sybase ) . . . . . . . . . . . . . . . . . . . . . . . . . . . yes127 QtXmlPatterns :128 XML schema support . . . . . . . . . . . . . . . . . . . . . yes129 Qt QML:130 QML i n t e r p r e t e r . . . . . . . . . . . . . . . . . . . . . . . . yes131 QML network support . . . . . . . . . . . . . . . . . . . . yes132 Qt Quick :133 Direct3D 12 . . . . . . . . . . . . . . . . . . . . . . . . . . . . no134 AnimatedImage item . . . . . . . . . . . . . . . . . . . . . yes135 Canvas item . . . . . . . . . . . . . . . . . . . . . . . . . . . . yes136 Support f o r Qt Quick Designer . . . . . . . . . . yes137 F l i p a b l e item . . . . . . . . . . . . . . . . . . . . . . . . . . yes138 GridView item . . . . . . . . . . . . . . . . . . . . . . . . . . yes139 ListView item . . . . . . . . . . . . . . . . . . . . . . . . . . yes140 Path support . . . . . . . . . . . . . . . . . . . . . . . . . . . yes141 PathView item . . . . . . . . . . . . . . . . . . . . . . . . . . yes142 P o s i t i o n e r items . . . . . . . . . . . . . . . . . . . . . . . yes143 ShaderEf fec t item . . . . . . . . . . . . . . . . . . . . . . yes144 S p r i t e item . . . . . . . . . . . . . . . . . . . . . . . . . . . . yes145 Qt Bluetooth :146 BlueZ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . no147 BlueZ Low Energy . . . . . . . . . . . . . . . . . . . . . . . no148 Linux Crypto API . . . . . . . . . . . . . . . . . . . . . . . no149 WinRT Bluetooth API ( desktop & UWP) . . . . no150 Qt Sensors :151 sensorfw . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . no152 Qt Quick Controls 2 :153 S t y l e s . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Defaul t Fusion Imagine

Mater ia l Universal154 Qt Quick Templates 2 :155 Hover support . . . . . . . . . . . . . . . . . . . . . . . . . . yes156 Multi−touch support . . . . . . . . . . . . . . . . . . . . yes157 Qt Multimedia :158 ALSA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . yes159 GStreamer 1 . 0 . . . . . . . . . . . . . . . . . . . . . . . . . . yes160 GStreamer 0 . 1 0 . . . . . . . . . . . . . . . . . . . . . . . . . no161 Video f o r Linux . . . . . . . . . . . . . . . . . . . . . . . . yes162 OpenAL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . no163 PulseAudio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . yes164 Resource Pol i cy ( l i b r e s o u r c e q t 5 ) . . . . . . . no165 Windows Audio S e r v i c e s . . . . . . . . . . . . . . . . . no166 DirectShow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . no167 Windows Media Foundation . . . . . . . . . . . . . . . no168

56 Apéndice A. Configuración de Qt 5.10.1 para compilación cruzada

169 Note : Also a v a i l a b l e f o r Linux : l inux−clang linux−i c c170

171 Note : PKG_CONFIG_LIBDIR automat i ca l ly s e t to /home/nelson/ r a s p i /sysroot/usr/ l i b /pkgconfig :/home/nelson/ r a s p i /sysroot/usr/share/pkgconfig :/home/nelson/ r a s p i /sysroot/usr/ l i b /arm−l inux−gnueabihf/pkgconfig

172

173 Note : PKG_CONFIG_SYSROOT_DIR automat i ca l ly s e t to /home/nelson/ r a s p i /sysroot

174

175 Note : −optimized−t o o l s i s not use fu l in −r e l e a s e mode .176

177 Note : Dropped compiler f l a g s ’−pthread ’ when d e t e c t i n g l i b r a r y ’ g l i b ’ .178

179 Note : Dropped compiler f l a g s ’−pthread ’ when d e t e c t i n g l i b r a r y ’gstreamer ’ .

180

181 Note : Dropped compiler f l a g s ’−pthread ’ when d e t e c t i n g l i b r a r y ’gstreamer_app ’ .

182

183 Qt i s now configured f o r bui lding . J u s t run ’make ’ .184 Once everything i s b u i l t , you must run ’make i n s t a l l ’ .185 Qt w i l l be i n s t a l l e d i n t o ’/home/nelson/ r a s p i /qt5pi ’ .186

187 P r i o r to r eco nf i gur a t i on , make sure you remove any l e f t o v e r s from188 the previous bui ld .

57

Bibliografía

[1] Eugene Silberstein. Heat Pumps. Thomson, Delmar Learning, United States,New York, 2003.

[2] Definition of frame buffer. https://en.wikipedia.org/wiki/Framebuffer. November2019.

[3] AN4861 Application note. LCD-TFT display controller (LTDC) on STM32MCUs. ST, February 2017.

[4] AN4323 Application note. Getting started with STemWin Library. ST, April 2018.

[5] ARM Cortex M family. https://www.arm.com/products/silicon-ip-cpu. ARM, No-vember 2019.

[6] Single Board Computer definition. https://www.explainingcomputers.com/sbc.html.November 2019.

[7] System On Module definition. http://processors.wiki.ti.com/index.php/System-On-Module. November 2019.

[8] Hub USB definition. https://www.definitions.net/definition/usb+hub. November2019.

[9] Bart Broekman y Edwin Notenboom. Testing Embedded Software. Addison-Wesley Professional, 2003.

[10] TCP Handshake explaination. https://www.geeksforgeeks.org/tcp-3-way-handshake-process/. November 2019.

[11] Signals and Slots documentation. https://doc.qt.io/qt-5/signalsandslots.html. Qt,November 2019.

[12] Beej, guides for Sockets communication and OS programming.http://beej.us/guide/. November 2019.

[13] Datasheet ADS1115. ADS111x Ultra-Small, Low-Power, I 2C-Compatible, 860-SPS, 16-Bit ADCs With Internal Reference, Oscillator, and Programmable Compa-rator. Texas Instruments, January 2018.

[14] Features of EGLFS with Qt. https://doc.qt.io/qt-5/embedded-linux.html. Novem-ber 2019.

[15] Documentation to Cross-compile Qt with EGLFS on RPi.https://wiki.qt.io/RaspberryPi2EGLFS. November 2019.

[16] Documentation to Configure the source code of Qt.http://jheyman.github.io/blog/pages/QtOnRaspberryPi/. November 2019.

[17] Qt EGLFS configuration. https://doc.qt.io/qt-5/embedded-linux.html. November2019.

58 BIBLIOGRAFÍA

[18] Ceedling documentation. https://github.com/ThrowTheSwitch/Ceedling. No-vember 2019.

[19] James W. Grenning. Test-Driven Development for Embedded C. PragmaticBookshelf, 2011.

Control de termotanque basado en el sistema “Heat...

Documents

Transcript of Control de termotanque basado en el sistema “Heat...