UNIVERSIDAD DE BUENOS AIRES

FACULTAD DE INGENIERÍA

CARRERA DE ESPECIALIZACIÓN EN SISTEMAS

EMBEBIDOS

MEMORIA DEL TRABAJO FINAL

Control de bombas elevadoras de aguadel Hospital Alemán

Autor:Lic. Horacio Martinez

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

Jurados:Esp. Ing. Pablo Ridolfi (UTN-FRBA, FIUBA)

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

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

III

Resumen

En el presente trabajo se describe la implementación de un dispositivo para elcontrol de bombas elevadoras de agua de un tanque y cisterna del Hospital

Alemán, que utiliza la CIAA-NXP y permite obtener datos de consumos, fallas ypresentarlos mediante una salida UART para su posterior análisis.

Para realizar el proyecto se utilizó un sistema operativo de tiempo real,herramientas de gestión de proyectos, control de versiones de software,protocolos de comunicación, generación de documentación automática.

V

Agradecimientos

En primer lugar quiero agradecer a mi mamá y mi hermana por su apoyo y com-prensión a lo largo de mi carrera.

A mis compañeros, en especial a Guillermo Evangelista por su amistad.

A mis profesores por su predisposición a transmitir su valioso conocimiento du-rante toda la carrera. En especial al Dr. Ing. Ariel Lutenberg por su motivación yánimo para llevar adelante este posgrado.

A mis compañeros de trabajo por comprender lo importante que fue para mihacer esta carrera.

Muchas gracias.

VII

Índice general

Resumen III

1. Introducción General 11.1. Sistemas de control de reservas de agua . . . . . . . . . . . . . . . . 11.2. Motivación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2. Introducción Específica 52.1. Funcionamiento general del sistema . . . . . . . . . . . . . . . . . . 52.2. Requerimientos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62.3. Planificación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.3.1. Diagrama de activity on node . . . . . . . . . . . . . . . . . . 72.3.2. Diagrama de Gantt . . . . . . . . . . . . . . . . . . . . . . . . 8

3. Diseño e Implementación 113.1. Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

3.1.1. Sensores y actuadores . . . . . . . . . . . . . . . . . . . . . . 123.2. Arquitectura del firmware . . . . . . . . . . . . . . . . . . . . . . . . 14

3.2.1. Capas de abstracción . . . . . . . . . . . . . . . . . . . . . . . 153.2.2. Protocolos de comunicación . . . . . . . . . . . . . . . . . . . 163.2.3. Desarrollo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

4. Ensayos y Resultados 214.1. Test de software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214.2. Test de prototipo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

5. Conclusiones 255.1. Conclusiones generales . . . . . . . . . . . . . . . . . . . . . . . . . 255.2. Próximos pasos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

IX

Índice de figuras

1.1. Sistema por XILEM water solutions para grandes consumos1. . . . 21.2. Sistema SCADA por XILEM water solutions2. . . . . . . . . . . . . . 2

2.1. Sistema de bombas con CIAA-NXP. . . . . . . . . . . . . . . . . . . 62.2. Diagrama activity on node. . . . . . . . . . . . . . . . . . . . . . . . 82.3. Diagrama de Gannt. . . . . . . . . . . . . . . . . . . . . . . . . . . . 82.4. Diagrama de Gannt, desarrollo en el primer periodo de tiempo. . . 92.5. Diagrama de Gannt, desarrollo en el segundo periodo de tiempo. . 9

3.1. Placa CIAA-NXP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113.2. Regulador de nivel Flygt modelo ENM-103. . . . . . . . . . . . . . . 133.3. Arranque suave Scheneider Electric4. . . . . . . . . . . . . . . . . . . 133.4. Conexión de arranque suave a dos hilo y linea de tiempo. . . . . . . 143.5. Valvula solenoide marca Winner. . . . . . . . . . . . . . . . . . . . . 143.6. Diagrama de bloques del firmware. . . . . . . . . . . . . . . . . . . . 153.7. Diagrama de bloques funcionales del Firmware. . . . . . . . . . . . 153.8. Ciclo de vida del Firmware. . . . . . . . . . . . . . . . . . . . . . . . 163.9. Esquematico del puerto RS-485. . . . . . . . . . . . . . . . . . . . . . 17

4.1. Simulacion de los sensores de nivel. . . . . . . . . . . . . . . . . . . 224.2. verificacion de los sensores mediante debuggin. . . . . . . . . . . . 224.3. validacion de los datos mediante salida UART-USB. . . . . . . . . . 23

XI

Índice de Tablas

4.1. Arreglo de sensores . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214.2. Estados del sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

XIII

Dedicado a mi Madre.

1

Capítulo 1

Introducción General

En este capítulo se describen las diferentes soluciones usadas para control de re-servas de agua. También se describen los objetivos y alcances del proyecto.

1.1. Sistemas de control de reservas de agua

Un sistema de reserva de agua es el conjunto de infraestructura, equipos y ser-vicios destinados al suministro de agua potable para consumo humano. Los sis-temas convencionales pueden ser de dos tipos, por gravedad o por bombeo. Lossistemas convencionales por gravedad aprovechan la fuerza de gravedad por di-ferencias de cotas topográficas. Los sistemas por bombeo necesitan de energíaexterna, generalmente eléctrica, para conducir el agua. La fuente se encuentrauna cota de altura inferior a la de servicio.

En muchas ciudades del mundo el abastecimiento de agua hacia el área de ser-vicio es de gran importancia, debido a que están ubicadas en zonas en las que elagua no es captada de forma natural o no se encuentra cerca de algún depósitonatural. Para esto utilizan grandes tanques de agua comunicados de tal maneraque puedan cooperar por si falta agua en alguna zona, distribuyendo el caudalpor la red hidráulica mediante bombas o válvulas de paso. Así como en los pro-cesos industriales modernos también se utiliza un concepto de sistema SCADApara la supervisión, control y adquisición de datos a distancia. Esto facilita la re-troalimentación en tiempo real de los dispositivos y controla automáticamente elproceso. Este es un método que ayuda a la gestión del recurso y de la infraestruc-tura que interviene en su distribución, permitiendo proveer un medio de super-visión y control al personal de operaciones, asistiendo con información confiablesobre las condiciones operativas de las estaciones de bombeo y tanques de reser-va. En la figura 1.1 se puede observar un sistema comercial moderno en el cual sedistinguen los siguientes puntos de interés.

Monitorización: Representación de datos en tiempo real a los operadores dela planta. Da una vista general del sistema de forma rápida, comunmentede forma esquematica.

Supervisión: Supervisión, mando y herramientas de gestión para la toma dedecisiones (mantenimiento predictivo, por ejemplo). Tienen además la ca-pacidad de ejecutar programas que puedan supervisar y modificar el con-trol establecido, y bajo ciertas condiciones, anular o modificar tareas asocia-das a los autómatas. Evita una continua supervisión humana.

2 Capítulo 1. Introducción General

Adquisición de datos: Recepción de información para documentar o analizarposteriormente. Se debe tener en cuenta la frecuencia de muestreo de estosdatos según el proceso que se esta evaluando.

Visualización de alarmas y eventos: Reconocimiento de eventos excepcionalesque se presentan en la planta y su inmediata puesta en conocimiento de losoperarios para efectuar las acciones correctivas pertinentes.

Mando: Posibilidad que los operadores puedan cambiar consignas u otrosdatos claves del proceso directamente desde la computadora (marcha, pa-rada, modificación de parámetro). Se escriben datos sobre los elementos decontrol.

FIGURA 1.1: Sistema por XILEM water solutions para grandesconsumos1.

Para proyectos de menor escala se usan sistemas con las mismas característicaspero de un alcance menor. Se puede optar por algunos de los beneficios que brin-da el sistema completo teniendo así un sistema a medida de nuestras necesidadescomo se muestra en la figura 1.2.

FIGURA 1.2: Sistema SCADA por XILEM water solutions2.

En este tipo de sitemas se ofrecen un control del proceso, un analizador de ener-gia, un historial de datos, un historial de eventos y alarmas y un pagina web don-de poder gestionar los recursos de forma remota, ademas de un panel de controlpara un operador en un lugar cercano al proceso.

1http://www.xylemwatersolutions.com

1.2. Motivación 3

1.2. Motivación

Esta sección ha sido removida parapublicación online ya que elpresente trabajo tiene fines

comerciales

5

Capítulo 2

Introducción Específica

En este capítulo se presenta el trabajo realizado durante la materia Gestión de pro-yectos en el marco de la carrera de Especialización en sistemas embebidos, y se da unaidea aproximada del funcionamiento del sistema.

2.1. Funcionamiento general del sistema

El sistema está compuesto por un tanque de reserva al nivel de la entrada de redal que llamaremos cisterna y otro tanque de reserva elevado al que llamaremossimplemente tanque. La cisterna obtiene el agua por la presión de la red y eltanque debe ser llenado mediante bombas centrífugas que impulsan el agua hastala altura del tanque.

Existen dos bombas centrífugas pero solamente actua una sola, la otra queda dereserva por alguna eventual falla. Solo son activadas si la cisterna tiene un nivelde agua adecuado para evitar el ingreso de aire al circuito. Para esto se instalandos reguladores de nivel para el control y dos para las alarmas colocadas a unadistancia que indique que es un nivel crítico. Estas son la alarma por bajo nivel yla alarma por sobre nivel. Cuando el nivel de control bajo de la cisterna está des-activado se permite activar la bomba centrífuga si el tanque estuviera solicitandoagua hasta que el regulador de nivel alto del tanque se active, esto indicará queel tanque esta lleno. Si el regulador de nivel bajo de la cisterna está activado nodejara encender la bomba centrífuga para protegerlo de la entrada de aire. Si poralgún motivo la alarma de nivel bajo de la cisterna se activa no dejara encenderlas bombas y enviará una alarma indicando que hay un problema. De la mismaforma si la alarma de nivel alto del tanque se activa se deberá apagar la bomba yenviar una alarma indicando el problema.

Las variables que se deben medir son de naturaleza digital y están asociadas aprocesos físicos lentos. En este sentido, se adopta en principio una tasa de mues-treo de 1 Hz para la adquisición de dichas variables.

Se definen puntos de control límite para las variables medidas y se establecencondiciones de alarma. Se definen dos alarmas por tanque de reserva, una porexceso, en caso de que se supere el valor punto máximo permitido y otra por de-fecto, para el caso en que el punto de control se encuentre por debajo del valorumbral mínimo. Se representó de forma esquemática la conexiones de los dispo-sitivos y funciones que tiene el sistema tal como se muestra en la figura 2.1.

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

FIGURA 2.1: Sistema de bombas con CIAA-NXP.

En los lazos de control se aplican acciones binarias del tipo ON/OFF sobre losactuadores del sistema en función de las condiciones de alarma presentes. Las ac-ciones de control se deben sostener en el tiempo mientras la condición de alarmaque las haya iniciado esté presente. De todas formas cuando haya alguna accióniniciada por el control de una condición de alarma, el estado del actuador debepoder ser cambiado manualmente, tanto para encenderse como apagarse, segúnsea el caso. Cuando no haya alarmas controlando un determinado actuador, estetámbien se debe poder operar manualmente.

2.2. Requerimientos

Mediante una entrevista con la jefatura de mantenimiento e infraestructura delHospital Alemán se establecieron los requerimientos necesarios para poder pre-sentar el proyecto e instalar definitivamente el modúlo de control con la CIAA-NXP.

1. Requerimientos sobre la monitorización.

a) La institución cuenta con tres torres. Cada torre cuenta con una cisternay un tanque elevado. Con dos bombas por cada torre. El sistema deberápoder monitorear todos los tanques y sus respectivas bombas.

b) Los sensores de nivel deben ser de la marca FLYGT modelo ENM-10.

c) Las bombas tienen un arranque suave Schneider Altistart 01.

2.3. Planificación 7

d) El consumo será monitoreado con un Sensor de corriente toroidal porcada fase en el tablero o de ser posible por cada fase de cada bomba.

e) Cada torre tendrá una placa CIAA-NXP para controlar y monitorizarel proceso.

f ) Debe tener una interfaz gráfica para ver los datos requeridos.

g) No se debe poder modificar ningún parámetro desde la interfaz demonitoreo.

h) Debe tener alarmas sobre fallas en el relevo térmico de las bombas.

i) Debe mostrar el consumo en Amp. de cada bomba.

j) Debe poder discriminar los datos en dos franjas horarios de 12hs.

k) Debe mostrar el tiempo de uso de cada bomba en cada franja horaria.

l) Debe contar la cantidad de arranques que tuvo cada bomba en cadafranja horaria.

m) Debe poder estimar la cantidad de agua consumida en cada franja ho-raria.

n) Debe poder mostrar un historial con los datos.

2. Requerimientos sobre el control:

a) Debe funcionar como un sistema de cisterna - tanque elevado.

b) Debe contar con un proceso de relevo de bombas en falla.

Se hicieron los siguientes supuestos sobre el proyecto que permitieron realizar elproyecto.

Será posible conseguir los materiales para realizar el prototipo del sistemade control.

Se supone que será posible realizar el proyecto en tiempo y forma.

Será posible realizar una conexión Ethernet mediante las cual se mostraranla información requerida.

Estos requerimientos fueron separados en dos secciones una que se refiere a laparte de monitorización y la otra a la de control.

2.3. Planificación

2.3.1. Diagrama de activity on node

En el diagrama de Activity on node de la figura 2.2 se muestran todas las tareasque se planificaron para realizar el proyecto, con su respectiva cantidad de ho-ras que fueron determinadas para cada tarea. En color rojo se muestra el caminocrítico que determina la cadena de tareas vinculadas que afectan directamente lafinalización del proyecto.

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

FIGURA 2.2: Diagrama activity on node.

2.3.2. Diagrama de Gantt

Como parte de la planificación se definieron las tareas necesarias para completarel trabajo y se establecieron las relaciones de correlatividad entre ellas. En la figura2.3 se muestra el desglose de las tareas con la duración estimada para cada tareacon la fecha de inicio y fin para cada tarea.

FIGURA 2.3: Diagrama de Gannt.

En la figura 2.4 y en la figura 2.5 se puede ver el diagrama de Gantt en el cual semuestra de forma grafica en dos periodos en la cual se pueden ver la duracion decada tarea y su realacion con las otras tareas. Se puede distinguir el camino críticocon las tareas de un color oscuro.

2.3. Planificación 9

FIGURA 2.4: Diagrama de Gannt, desarrollo en el primer periodode tiempo.

FIGURA 2.5: Diagrama de Gannt, desarrollo en el segundo periodode tiempo.

El periodo más largo que corresponde a la tarea de desarrollo del software que seextendió por una mala gestión de tiempos, dificultades con el aprendizaje de lasherramientas necesarias para llevar a cabo el proyecto, como el lenguaje JavaS-cript, lwIP y HTML.

11

Capítulo 3

Diseño e Implementación

La idea central de esta sección es describir los dispositivos y el firmware que seutilizaron en el proyecto.

3.1. Hardware

Se eligió para la plataforma de control a la CIAA-NXP basada en el microcontrola-dor NXP LPC4337 por ser un proyecto que se desarrolla en el marco de un trabajolibre, colaborativo y articulado entre industria y academia. En el cual se han ela-borado distintas plataformas de hardware, un firmware con drivers y ejemplosde aplicación y un entorno de desarrollo basado en Eclipse.

Debido a que el trabajo requiere una plataforma totalmente desarrollada y capa-cidad de conexión Ethernet, se eligió la plataforma industrial CIAA-NXP.

FIGURA 3.1: Placa CIAA-NXP.

La CIAA-NXP es la primera y única computadora del mundo que reúne dos cua-lidades:

Ser Industrial: Su diseño está preparado para las exigencias de confiabili-dad, temperatura, vibraciones, ruido electromagnético, tensiones, cortocir-cuitos, etc., que demandan los productos y procesos industriales.

Ser Abierta:Toda la información sobre su diseño de hardware, firmware,software, etc. está libremente disponible en Internet bajo la Licencia BSD,para que cualquiera la utilice según sus necesidades.

Esta plataforma se compone de:

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

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

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

Memorias:

• IS42S16400F - SDRAM. 64Mbit @ 143MHz.

• S25FL032P0XMFI011 - Flash SPI. 32 Mbit, Quad I/O Fast read: 80 MHz.

• 24AA1025 - EEPROM I2C. 1 Mbit, 400 kHz. Almacenamiento de pro-pósito general, datos de calibración del usuario, etc.

• 24AA025E48 - EEPROM I2C. 2 kbit, 400 kHz. Para implementación deMAC-Address o almacenamiento de propósito general.

Entradas y salidas:

• 8 entradas digitales opto-acopladas.

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

• 4 salidas Open-Drain.

• 4 salidas con Relay DPDT.

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

LV-GPIO:

• 4 GPIOs.

• I2C.

• SPI.

• 4 canales analógicos.

• Aux. USB.

Interfaces de comunicación:

• Ethernet.

• USB On-The-Go.

• RS232.

• RS485.

• CAN.

3.1.1. Sensores y actuadores

Regulador de nivel: Es de la marca Flygt modelo ENM-10 que tiene un grado deprotección IP68 con un microswitch enchapado en oro que asegura la robustezde operación, esta hechos con materiales que tienen un menor deterioro ante lapresencia de hipoclorito de sodio presente en el agua de red. Su funcionamientoes sencillo como se muestra en la figura 3.2. Es un contacto NC/NA que cambiade estado cuando el nivel de agua pasa por la altura a la que esta regulado.

3.1. Hardware 13

FIGURA 3.2: Regulador de nivel Flygt modelo ENM-101.

Arrancador porgresivo: Es de la marca Schneider Electric modelo Altistart 01, comose muestra en la figura 3.3 es un arrancador suave de motores asincronicos trifa-sicos. Se eligió este dispositivo por ser uno con el cual ya estamos familiarizadosy cumple con todos los requerimientos y está siendo usado en diferentes lugaresdel hospital. De los diferentes tipos de conexionado se eligió este por ser la quese ajusta al uso con un PLC y se requiere menos cableado.

FIGURA 3.3: Arranque suave Scheneider Electric2.

La marcha y la parada son controladas por una sola entrada lógica. En la figura 3.4se muestra la conexión electrica de comando y la línea de tiempo de los distintosestados del dispositivo. El estado «1» de la entrada lógica LI2 ordena la marcha yel estado «0» la detención.

Valvula solenoide: La elegida es una válvula de la marca Winner modelo WRA3como se muestra en la figura 3.5. Consiste en una válvula de cierre esférico con unactuador paso a paso que le da las característica de exactitud y rapidez. Tiene unmodo de control digital tipico y control analogico tradicional. Es especialmenteutilizado en Sistemas de tratamiento de agua o climatización.

1http://www.xylemwatersolutions.com2http://www.schneider-electric.com.ar

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

FIGURA 3.4: Conexión de arranque suave a dos hilo y linea detiempo.

Para este proyecto se utilizo en modo digital de control ON/OFF con una alimen-tación de 24VDC.

FIGURA 3.5: Valvula solenoide marca Winner.

3.2. Arquitectura del firmware

En la presente sección se trata de presentar el desarrollo del proyecto tomando encuenta los lineamientos que fueron vistos en las materias Ingeniería de Software enSistemas Embebidos, Programacion de Microcontroladores, Arquitectura de Micropro-cesadores, Protocolos de Comunicación, Sistemas Operativos de Tiempo Real. Se tomócomo base el firmware usado en la materia Sistemas Operativos de Tiempo Real.También fueron consultados otros ejemplos como los del firmware del proyectoCIAA y ejemplos porpuestos por las materias de RTOS, protocolos de comunica-ciones y programación de microprocesadores.

3.2. Arquitectura del firmware 15

3.2.1. Capas de abstracción

El sistema esta diseñado con una arquitectura en capas, como se puede observaren la figura 3.6 .Están Agrupados e identificados por color segun los distintosniveles de abstracion, dentro de cada capa los distintos bloques funcionales quela integran.

FIGURA 3.6: Diagrama de bloques del firmware.

En cuanto a los niveles, la primer capa que la constituye es el Hardware de la pla-taforma CIAA-NXP. La segunda capa es la de abstraccion el Hardware AbstractionLayer (HAL), que permite desacoplar las capas superiores del hardware. Aquí seencuentran los drivers del fabricante del microcontrolador, en el bloque funcionalLPCOPEN, y los drivers desarrollados para la plataforma CIAA se encuentran enel bloque Drivers CIAA. La capa Hardware Independent Layer (HIL) son los mo-dulos que no estan asociados a ningun hardware en particular, la integran losmódulos de RTOS. Por último, la capa de Aplicaciones contiene los modulos conlos que interactua el sistema y el usuario, en este caso es el Control del sistema detanque-cisterna.

Para entender la dinámica del sistema en general se presenta un diagrama debloques funcionales en la figura 3.7

FIGURA 3.7: Diagrama de bloques funcionales del Firmware.

El prototipo utiliza un sistema operativo de tiempo real o RTOS (Real-Time Ope-rating System) que es un sistema operativo optimizado para uso en aplicaciones

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

embebidas de tiempo real. El principal objetivo al utilizar un RTOS es aseguraruna respuesta determinística a los eventos que debe atender el sistema.

Para el desarrollo del firmware se utilizó el modelo de ciclo de vida en espiral, elcual puede verse en la figura 3.8. Este modelo es iterativo, expandiendo la com-plejidad en cada ciclo, y permitiendo la obtención de un prototipo funcional alfinalizar cada iteración. Esto fue determinante para la elección de este ciclo devida para el presente proyecto ya que los prototipos funcionales de firmware per-mitieron la realización de los diferentes ensayos sin necesidad de esperar a tenerel prototipo final. También fue importante la utilización de un software para elcontrol de versiones ya que en cada iteración que superó la evaluación se teniaun versión funcional y siempre se podía volver a esa versión si fuese necesario.

FIGURA 3.8: Ciclo de vida del Firmware.

3.2.2. Protocolos de comunicación

Para realizar la comunicación se eligió el puerto UART por la facilidad para usarloy la rápida implementación. UART (Universal Asynchronous Receiver-Transmitter)Transmisor-Receptor Asíncrono Universal, es el dispositivo que controla los puer-tos y dispositivos serie. De este modo se pueden ver los datos solicitados en losrequerimientos. El UART toma bytes de datos y transmite los bits individualesde forma secuencial. En el destino, un segundo UART reensambla los bits en by-tes completos. La transmisión serie de la información digital (bits) a través de uncable único u otros medios es mucho más efectiva en cuanto a costo que la trans-misión en paralelo a través de múltiples cables. Se utiliza un UART para convertirla información transmitida entre su forma secuencial y paralela en cada terminalde enlace. Cada UART contiene un registro de desplazamiento que es el méto-do fundamental de conversión entre las forma secuencial y paralela. Las señalesexternas pueden ser de variada índole. Ejemplos de estándares para señalizaciónpor voltaje son RS-232, RS-422 y RS-485 de la EIA.

Para este proyecto se utilizara el puerto RS-485 que se muestra en la figura 3.9que se presenta en la CIAA-NXP y en la EDU-CIAA lo que facilito el debuggingdel firmware.

3.2. Arquitectura del firmware 17

FIGURA 3.9: Esquematico del puerto RS-485.

3.2.3. Desarrollo

En esta subsección se presentan las tareas que implementa el sistema operativo enpseudocódigo, para hacer foco en la funcionalidad de las mismas y no en detallesde la implementación.

Las tareas son:

Relevar sensores: Se consulta el estado de todos los sensores para despuesclasificar el estado del sistema. En la maquina de estados.

Control del sistema: Se realizan las acciones que requiera cada estado eva-luando las alarmas.

Procesamiento de datos y muestra en pantalla: Despues de cada proceso dellenado se envian los datos para que este modulo los procese y los imprimapor pantalla.

En el marco del modelo iterativo, cada iteración produjo un prototipo funcionalde firmware que desarrolló las siguientes tareas y en el siguiente orden:

Iteración 1: Lectura de entradas digitales.

Iteración 2: Procesamiento de control.

Iteración 3: Tarea de procesamiento de datos y muestra por pantalla.

En el algoritmo 3.1 se muestra la obtención de datos de las entradas digitales.

1

2

3 /∗ r e l e v a r sensores TK y CT4 ∗ ##############################∗/5

6 i f ( Chip_GPIO_GetPinState (LPC_GPIO_PORT , 3 , 0 ) == 0) /∗ ALARMA ALTO∗/

7 {8 tanque [ 0 ] = 1 ;9 }

10 e l s e11 {12 tanque [ 0 ] = 0 ;13 }14 i f ( Chip_GPIO_GetPinState (LPC_GPIO_PORT , 3 , 4 ) == 0) /∗ COMANDO ALTO

∗/

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

15 {16 tanque [ 1 ] = 1 ;17 }18 e l s e19 {20 tanque [ 1 ] = 0 ;21 }22 i f ( Chip_GPIO_GetPinState (LPC_GPIO_PORT , 5 , 16) == 0) /∗ COMANDO BAJO

∗/23 {24 tanque [ 2 ] = 1 ;25 }26 e l s e27 {28 tanque [ 2 ] = 0 ;29 }30 i f ( Chip_GPIO_GetPinState (LPC_GPIO_PORT , 3 , 6 ) == 0) /∗ ALARMA BAJO

∗/31 {32 tanque [ 3 ] = 1 ;33 }34 e l s e35 {36 tanque [ 3 ] = 0 ;37 }

ALGORITMO 3.1: Ejemplo de el relevamiento de entradasdigitales.

A continuación se muestra el algoritmo 3.2 para controlar el nivel del tanqueelevado. Se simulan con los LEDs de la EDU-CIAA las salidas de las alarmasy el accionamiento de la bomba.

1 /∗ etapa de c o n t r o l del s is tema tomando en cuenta l o s estados ∗2 ∗ ∗/3 i f ( h a b i l i t a ==1)4 {5 i f ( s o l i c i t a ==1)6 {7 /∗enciende l a s bombas8 ∗ empieza a contar e l tiempo9 ∗ tk_empy

10 ∗ ∗/11 i f ( sem==0) {12 Board_LED_Set ( 0 ,ON) ; //MOTOR13 sem=1;14 t i c k s _ g e n e r a l =0;15

16 }17

18 Ticks_motor_ON = t i c k s _ g e n e r a l ;19

20

21 }22 e l s e23 {24 /∗apaga l a s bombas25 ∗ termina de contar e l tiempo26 ∗ t k _ f u l l27 ∗ ∗/28 i f ( sem==1)29 {30 Board_LED_Set ( 0 ,OFF) ; //MOTOR

3.2. Arquitectura del firmware 19

31 sem=0;32 button . motor_ON=Ticks_motor_ON ;33 xQueueSend ( c , &button , 0 ) ;34 }35

36 }37

38 /∗esperando l lenado de c i s t e r n a ∗/39 }

ALGORITMO 3.2: Ejemplo de la etapa de control.

21

Capítulo 4

Ensayos y Resultados

4.1. Test de software

Se tomaron en cuenta todos los posibles estados de los sensores de nivel tantodel tanque como de la cisterna como se muestra en la tabla 4.2. Se representanlos cuatro sensores de nivel con una posicion de un vector como se muestra en latabla 4.1

TABLA 4.1: Vector de sensores que utilizan el tanque y cisterna.

Posicion del vector Tanque-Cisterna

vector[0] alarma nivel bajovectro[1] comando nivel bajovector[2] comando nivel altovector[3] alarma nivel alto

TABLA 4.2: Valores que pueden tomar los vectores de sensores.

Vector de sensores Tanque Cisterna

0000 alarma bajo nivel alarma bajo nivel0001 solicita agua vacio no habilita bombas00100011 solicita agua habilita bombas0100010101100111 lleno habilita bombas10001001101010111100110111101111 alarma nivel alto alarma nivel alto

Las funciones del sistema fueron verificadas en forma individual a medida quese desarrollaba el código de cada una utilizando la herramienta de debug delentorno de desarrollo Eclipse. Una vez que se comprobó el funcionamiento de

22 Capítulo 4. Ensayos y Resultados

cada bloque se compararon con las tablas. Luego de que cada módulo del siste-ma funcionó en forma individual, se procedió a realizar ensayos con el sistemacompleto.

Las pruebas que se hicieron simulando los sensores de nivel como se muestra enla figura 4.1. El testing del prototipo se realizó utilizando los bornes de las salidasdigitales de la CIAA-NXP. Se conectaron a estos pines unas llaves ON-OFF parasimular los estados de los sensores de nivel y sus diferentes combinaciones queinfluyen en los estados del sistema. Se verificaron las salidas digitales de la CIAA-NXP.

FIGURA 4.1: Simulacion de los sensores de nivel.

Se verificaron esos valores con la herramienta de debug de Eclipse para como semuestra en figura 4.2

FIGURA 4.2: verificacion de los sensores mediante debuggin.

4.2. Test de prototipo 23

4.2. Test de prototipo

En el Test del prototipo se validaron los datos requeridos mediante una salidaUART, en particular se eligió el puerto UART-USB por su rápido manejo pararealizar los test. La salida por pantalla como se puede observar en la figura 4.3,muestra los datos de los requerimientos.

FIGURA 4.3: validacion de los datos mediante salida UART-USB.

25

Capítulo 5

Conclusiones

5.1. Conclusiones generales

Se obtuvo un firmware que permite controlar un sistema de bombas elevadorasde agua, y cumplir con la mayoría de los requerimientos de la jefatura de mante-nimiento del Hospital Alemán.

Durante el desarrollo de este Trabajo Final se aplicaron conocimientos adquiri-dos a lo largo de la Carrera de Especialización en Sistemas Embebidos. Si bienel conjunto total de asignaturas cursadas aportaron conocimientos necesarios pa-ra la práctica profesional en el área de los Sistemas Embebidos, se quiere dejarconstancia en particular, de las asignaturas con mayor relevancia para el trabajopresentado.

Arquitectura de microprocesadores: Fue necesario para obtener los conoci-miento de la arquitectura ARM Cortex M para la programación de la plata-forma CIAA-NXP y el uso de los periféricos.

Programación de microprocesadores: Se utilizaron buenas prácticas de pro-gramación de Lenguaje C para microcontroladores y periféricos, aprendi-das en esta asignatura. Se empleó un formato de código consistente, comen-tarios en las declaraciones de funciones y partes importantes del código. Seutilizaron APIs para abstraer distintas capas del código. Se obtuvo un códi-go más legible y reutilizable.

Ingeniería de Software en Sistemas Embebidos: Se utilizaron técnicas pro-venientes de la Ingeniería de Software. Siempre que fue posible se utilizó unmétodo sistemático e iterativo de desarrollo pensando en el ciclo de vidadel software.Se hizo uso de Git como sistema de control de versiones delsoftware.

Gestión de Proyectos en Ingeniería: Resultó de gran utilidad elaborar unPlan de Proyecto para organizar el Trabajo Final.

Sistemas Operativos de Tiempo Real (I y II): Se aplicaron los conocimientosadquiridos sobre freeRTOS respecto a tareas, colas y semáforos entre otros.

Protocolos de Comunicación: Se consultó todo el material para realizar latransmisión de la información requerida.

26 Capítulo 5. Conclusiones

5.2. Próximos pasos

A continuación se presentan las futuras líneas de trabajo para dar continuidad alesfuerzo invertido:

Terminar de implementar el stack TCP/IP lwIP y dar un producto final.

Posibilitar una interfaz en la que el usuario pueda modificar el sistema.

Implementar test unitarios.