Control de Acuario con la CIAAlaboratorios.fi.uba.ar/lse/tesis/LSE-FIUBA-Trabajo-Final...III Resumen...

UNIVERSIDAD DE BUENOS AIRES

FACULTAD DE INGENIERÍA

CARRERA DE ESPECIALIZACIÓN EN SISTEMAS

EMBEBIDOS

MEMORIA DEL TRABAJO FINAL

Control de Acuario con la CIAA

Autor:Ing. Patricio BOS

Director:Ing. Juan Manuel CRUZ

Jurados:Esp. Ing. Ramiro Alonso (FIUBA)

Ing. Eric Pernia (UNQ)Esp. Ing. Pablo Ridolfí (UTN)

Este trabajo fue realizado en las Ciudad Autónoma de Buenos Aires, entre agostode 2015 y julio de 2016.

III

Resumen

En esta memoria de Trabajo Final se documenta la implementación de unfirmware de control de acuarios sobre la base de un Web Server embebido para la

plataforma CIAA-NXP V1.0, utilizando el Sistema Operativo de Tiempo RealfreeRTOS V8.0.1 y el stack TCP/IP lwip V1.41.

En el capítulo 1 se da una introducción general a la temática de los acuarios y delproyecto CIAA. En el capítulo 2 se presenta el planeamiento del trabajo y la

modelación adoptada para el comportamiento del acuario. En el capítulo 3 seabordan cuestiones del diseño y la implementación del servidor web. En elcapítulo 4 se define la metodología de ensayo del sistema y se analizan los

resultados que se muestran en forma gráfica. Finalmente, en el capítulo 5 sepresentan las conclusiones y se plantean las líneas de trabajo futuro.

V

Agradecimientos

En estas líneas quisiera expresar mi profundo y sincero agradecimiento a todasaquellas personas que con su ayuda han colaborado, directa o indirectamente, enla realización del presente trabajo.

Principalmente a Carla por ser fuente de apoyo constante e incondicional. Sin sucariñoso acompañamiento esta empresa no hubiera llegado a buen término.

A mis padres, Irene y Arnoldo, por haberme transmitido una forma de ver elmundo que tanto tiene que ver con esta profesión y por la comprensión y el cariñoa través de los años.

A la Lic. Silvia Blanc por su permanente y desinteresado estímulo para que al-cance mis metas y crezca profesionalmente. De su compromiso y dedicación altrabajo aprendo cotidianamente.

A mis compañeros de la División Acústica Submarina por el apoyo recibido y porhacer, todos los días, del lugar de trabajo un ámbito alegre y cultivante. Les agra-dezco asimismo por haber soportado alguna de mis tareas cuando los tiemposapremiaban.

Al Ing. Juan Manuel Cruz por la orientación, el seguimiento y la supervisión du-rante el trabajo y al Ing. Sebastián Bedín por sus valiosos aportes en la resoluciónde problemas en la codificación y la excelente predisposición.

A todos ellos, muchas gracias.

VII

Índice general

Resumen III

1. Introducción General 11.1. Motivación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2. ¿Qué es un acuario? . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.2.1. Parámetros del agua . . . . . . . . . . . . . . . . . . . . . . . 41.3. ¿Qué es el Proyecto CIAA? . . . . . . . . . . . . . . . . . . . . . . . . 5

1.3.1. Plataforma CIAA-NXP . . . . . . . . . . . . . . . . . . . . . . 6

2. Introducción Específica 92.1. Definición del trabajo . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.1.1. Objetivos y alcances . . . . . . . . . . . . . . . . . . . . . . . 92.1.2. Requerimientos y Criterios de aceptación . . . . . . . . . . . 102.1.3. Desglose de tareas / GANTT . . . . . . . . . . . . . . . . . . 10

2.2. Planteo del problema . . . . . . . . . . . . . . . . . . . . . . . . . . . 122.2.1. ¿Qué hace falta medir, actuar, alertar? . . . . . . . . . . . . . 122.2.2. Modelación de la dinámica de acuario . . . . . . . . . . . . . 132.2.3. Alternativas tecnológicas . . . . . . . . . . . . . . . . . . . . 14

3. Diseño e Implementación 173.1. Diseño . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

3.1.1. Principio de funcionamiento . . . . . . . . . . . . . . . . . . 173.1.2. Arquitectura . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183.1.3. Lógica de control . . . . . . . . . . . . . . . . . . . . . . . . . 20

3.2. Implementación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223.2.1. Interfaz web embebida . . . . . . . . . . . . . . . . . . . . . . 223.2.2. Server Side Includes . . . . . . . . . . . . . . . . . . . . . . . 263.2.3. Common Gateway Interface . . . . . . . . . . . . . . . . . . . 283.2.4. AJAX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

4. Ensayos y Resultados 314.1. Ensayos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

4.1.1. Ensayos de caja negra . . . . . . . . . . . . . . . . . . . . . . 314.2. Resultados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

4.2.1. Respuesta a una única alarma . . . . . . . . . . . . . . . . . . 344.2.2. Respuesta a dos alarmas . . . . . . . . . . . . . . . . . . . . . 364.2.3. Respuesta a tres alarmas . . . . . . . . . . . . . . . . . . . . . 38

5. Conclusiones 395.1. Conclusiones del trabajo realizado . . . . . . . . . . . . . . . . . . . 395.2. Trabajo futuro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

Bibliografía 43

IX

Índice de figuras

1.1. Especies exóticas de peces tropicales. . . . . . . . . . . . . . . . . . . 11.2. Acuario de agua dulce. . . . . . . . . . . . . . . . . . . . . . . . . . . 31.3. Plataforma CIAA-NXP. . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2.1. Alternativas comerciales de sensores de nivel. . . . . . . . . . . . . 142.2. Alternativas comerciales de sensores de temperatura. . . . . . . . . 152.3. Sonda comercial para la medición de pH. . . . . . . . . . . . . . . . 15

3.1. Diagrama en bloques del firmware. . . . . . . . . . . . . . . . . . . . 183.2. Estructura jerárquica de archivos. . . . . . . . . . . . . . . . . . . . . 193.3. Interfaz web: página principal Inicio. . . . . . . . . . . . . . . . . . . 233.4. Interfaz web: página para controlar el sistema. . . . . . . . . . . . . 233.5. Interfaz web: configuración de red. . . . . . . . . . . . . . . . . . . . 233.6. Interfaz web: condición de alarma presente. . . . . . . . . . . . . . . 243.7. Interfaz web: botón deshabilitado por el control. . . . . . . . . . . . 253.8. Interfaz web: control deshabilitado. . . . . . . . . . . . . . . . . . . . 253.9. Diagrama de secuencia AJAX. . . . . . . . . . . . . . . . . . . . . . . 29

4.1. Respuesta del sistema frente a variaciones en el nivel de agua. . . . 344.2. Respuesta del sistema frente a variaciones en la temperatura. . . . . 354.3. Respuesta del sistema frente a variaciones en el pH. . . . . . . . . . 354.4. Respuesta a dos alarmas simultáneas. Nivel de agua alto y otras. . 364.5. Respuesta a dos alarmas simultáneas. Nivel de agua bajo y otras. . 374.6. Respuesta a dos alarmas simultáneas. Temperatura y pH. . . . . . . 374.7. Respuesta a tres alarmas simultáneas. Nivel de agua alto y otras. . 384.8. Respuesta a tres alarmas simultáneas. Nivel de agua bajo y otras. . 38

XI

Índice de Tablas

1.1. Costos estimados de distintas especies de peces. . . . . . . . . . . . 2

2.1. Declaración de Sensores. . . . . . . . . . . . . . . . . . . . . . . . . . 122.2. Declaración de Alarmas. . . . . . . . . . . . . . . . . . . . . . . . . . 132.3. Declaración de Actuadores. . . . . . . . . . . . . . . . . . . . . . . . 13

3.1. Configuración MAC del servidor web. . . . . . . . . . . . . . . . . . 22

4.1. Tabla de decisión para el control de una sola alarma. . . . . . . . . . 324.2. Tabla de decisión para el control de dos alarmas. . . . . . . . . . . . 324.3. Tabla de decisión para el control de tres alarmas. . . . . . . . . . . . 33

XIII

Dedicado a mi hijo Dante

1

Capítulo 1

Introducción General

1.1. Motivación

En el presente trabajo se busca satisfacer una necesidad relacionada con los acua-rios utilizando la plataforma CIAA. En particular, interesa poder controlar unnúmero de variables indicativas del estado de un acuario. Se busca implemen-tar una interfaz que permita visualizar información relevante sobre el estado delsistema bajo control y permita actuar sobre las variables cuyas desviaciones res-pecto a valores de referencia pueden afectar negativamente al entorno. Asimismo,se pretende facilitar tareas de mantenimiento que se deben realizar en forma ru-tinaria y que son de vital importancia para la supervivencia de los seres vivosque habitan estos espacios, principalmente peces, invertebrados y plantas. En lasección 1.2 se abordan detalles referidos a los acuarios.

El firmware de control se implementa sobre una de las plataformas de hardwa-re desarrollada por el Proyecto CIAA (Computadora Industrial Abierta Argentina),específicamente la versión CIAA-NXP. El Proyecto CIAA se trata en la sección1.3.

Existe una necesidad parcialmente satisfecha de conocer y mantener el buen es-tado de los acuarios debido a que, en algunos casos, los peces que los habitanpueden llegar a valer considerables sumas de dinero. Las especies tropicales co-mo las de la figura 1.1 pueden tener valores del orden de los miles de pesos, quevarían en función de cuán exótica sea la especie y del tamaño del ejemplar. En latabla 1.1 se listan algunas especies con tamaños y valores de referencia disponi-bles en el mercado local.

(A) Paracanthurus Hepatus1 (B) Amphiprion Ocellaris2

FIGURA 1.1: Especies exóticas de peces tropicales.

1GFDL 1.2, https://commons.wikimedia.org/w/index.php?curid=6549942De Tewy - Trabajo propio, CC BY 2.5, https://commons.wikimedia.org/w/index.php?curid=1382534

2 Capítulo 1. Introducción General

TABLA 1.1: Costos estimados de distintas especies de peces3.

Especie Tamaño Valor aprox.

Amphiprion Ocellaris 10 cm $ 6.000Hepatus Blue Tang 15 cm $ 7.000Zebrasoma Xanthurus 12 cm $ 6.800Cirujano Naso Rubio 14 cm $ 5.700Zebrasoma Cirujano 10 cm $ 4.500Zebrasoma Desjardinii 10 cm $ 3.200

Debido a la vasta difusión de las redes de computadoras y la tendencia mundiala incorporar cada día más dispositivos a Internet, fenómeno también conocidocomo el Internet de las cosas o Internet of Things (IoT) se opta por desarrollar unainterfaz web embebida en el dispositivo de control. Dicha interfaz será accesiblemediante el protocolo Ethernet a través de un equipo conectado a la misma redde área local o Local Area Network (LAN).

Asimismo, el control de acuarios sirve como punto de partida para desarrollar unmarco de trabajo que, sin pérdida de generalidad, se puede aplicar a otros domi-nios de control como la domótica, agricultura inteligente, etc. En este sentido, losmecanismos utilizados en la interfaz web para comunicar al usuario con el objetobajo control, (CGI, SSI, AJAX) no se encuentran acoplados a ninguna aplicaciónen particular y, dentro de un diseño modular, se pueden reutilizar en distintosproyectos. Detalles de la implementación se abordan en el capítulo 3.

3Fuente: http://mercadolibre.com.ar

http://mercadolibre.com.ar

1.2. ¿Qué es un acuario? 3

1.2. ¿Qué es un acuario?

El acuarismo es una actividad comercial y recreativa ampliamente difundida enla Argentina que consiste en establecer y mantener un ecosistema acuático artifi-cial. El término acuario o pecera se utiliza indistintamente para referirse tanto alcontenedor de agua como a todo el ecosistema artificial.

Un acuario puede albergar a un número determinado de peces, plantas e inverte-brados y para su mantenimiento es preciso recrear un biotopo4 en función de loshábitos y costumbres de las especies que lo habiten. Existen vertebrados acuáticosaptos para vivir en agua fría, otros requieren un sistema calefactor para mantenerel agua en un microclima cálido; incluso las especies marinas precisan cuidadosmás específicos en cuanto al tratamiento del agua. En la figura 1.2 se puede ob-servar un acuario de agua dulce sencillo, habitado por peces y plantas.

FIGURA 1.2: Acuario de agua dulce5.

Los acuarios se clasifican principalmente según las condiciones del agua:

Por temperatura

• Agua fría; entorno a los 18 C.

• Agua tropical; normalmente entre 22 y 27 C.

Por salinidad

• Agua dulce; baja concentración de sales disueltas.

• Salobre; agua con entre 0.5 y 30 gr. de sal por litro.

• Agua de mar o marinos; 35 gr. de sal por litro.

El punto de entrada recomendado para principiantes en la disciplina es el acua-rio de agua dulce y fría de al menos 90 litros. Su mantenimiento es más sencilloque el de los acuarios marinos y los peces de agua fría son los más resistentes ylos que presentan mayor compatibilidad entre especies. Normalmente se puedenmantener con agua de red debidamente declorada y acondicionada. Finalmente,

4Territorio o espacio vital cuyas condiciones ambientales son las adecuadas para que en él sedesarrolle una determinada comunidad de seres vivos.

5Dominio público, https://commons.wikimedia.org/w/index.php?curid=113425


un acuario de mayor tamaño es más fácil de mantener, sobre todo en lo referidoal tratamiento del agua y a conseguir una temperatura estable para los peces [5].

1.2.1. Parámetros del agua

A través del agua los peces, plantas y microorganismos que habitan el acuario in-corporan nutrientes y eliminan desechos. Entre ellos se conforma una cadena bio-lógica con interacciones complejas [12]. A modo de ejemplo se puede mencionarcómo las colonias de microorganismos (básicamente bacterias), en etapas diferen-ciadas, pueden “procesar” los compuestos orgánicos contaminantes provenientesde los peces y plantas, y transformarlos en compuestos inofensivos o que puedanser integrados en los tejidos de algas y plantas del acuario. En un acuario madurose establecen ciclos beneficiosos donde lo que para unos son desechos,para otrosson nutrientes.

Es necesario que el agua se encuentre debidamente tratada de acuerdo con lasnecesidades específicas que requiera la especie de peces que se pretenda albergar.Asimismo, se debe asegurar la mayor estabilidad de las condiciones del aguaposible ya que los seres vivos que en ella habitan son sensibles a las variacionesbruscas.

Se deben tener en cuenta los siguientes parámetros del agua:

La Dureza del agua es una medida de la cantidad de sales minerales, par-ticularmente las sales de calcio y magnesio, que se encuentran disueltas.Estas sales pueden ser sulfatos, cloruros, carbonatos o bicarbonatos. Nóteseque la suma de todos estos compuestos es lo que se denomina Dureza Total(Gh). Los carbonatos y bicarbonatos son eliminados rápidamente debido ala evaporación del agua y gracias a las plantas (consumidoras de anhídricocarbónico). Al contenido de estas sales en el agua se lo denomina DurezaTemporal (Kh) e influye directamente en el pH del acuario.

El valor de Concentración de anhídrido carbónico o CO2 es fundamentalpara que las plantas puedan crecer y desarrollarse. La cantidad recomenda-da oscila entre las veinte y las treinta partes por millón (ppm).

El valor de pH refiere a la cantidad de iones libres de hidrógeno. Refleja elcarácter ácido o alcalino del medio. El pH viene establecido por dos compo-nentes, la dureza de carbonatos y el CO2. La relación entre ambos, la durezade carbonatos como el componente alcalino y el CO2 como componente áci-do, es la que establece el valor del pH en un acuario. Si la relación es similar,el pH es neutro, cercano al valor 7.

La Temperatura determina la actividad metabólica de los organismos den-tro del acuario. Cada especie tiene un rango de temperaturas en las quepuede desarrollarse con normalidad.

En general los peces viven adecuadamente en un medio con un pH que oscile en-tre 5 y 9. Con valores de pH extremos, tanto hacia lo ácido como hacia lo alcalino,se establecen medios sólo aptos para peces muy especiales. Normalmente, el pHmás correcto para el pleno desarrollo de los peces es el que se encuentra entre 5.5y 7.5.

1.3. ¿Qué es el Proyecto CIAA? 5

1.3. ¿Qué es el Proyecto CIAA?

El Proyecto CIAA (Computadora Industrial Abierta Argentina) nació en 2013 co-mo una iniciativa conjunta del sector académico y el industrial, representados porla ACSE6 y CADIEEL7, respectivamente [7].

Objetivos del proyecto:

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

Darle visibilidad positiva a la electrónica argentina.

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

Este proyecto se desarrolla en el marco de un trabajo libre, colaborativo y articu-lado entre industria y academia. Dentro de esta iniciativa se han elaborado dis-tintas plataformas de hardware, un firmware con drivers y ejemplos de aplicación yun entorno de desarrollo basado en Eclipse.

Dentro de las plataformas de hardware se encuentran versiones basadas en dis-tintos microcontroladores de distintos fabricantes y versiones sobre FPGA (FieldProgrammable Gate Array). También hay versiones pensadas para trabajar en am-bientes industriales y versiones educativas que utilizan el mismo microcontrola-dor dentro de una placa de menores prestaciones y, por lo tanto, menor costo totalque la versión industrial.

A continuación se listan las plataformas que se encuentran en fase de comerciali-zación.

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

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

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

Debido a que el trabajo requiere una plataforma totalmente desarrollada y ca-pacidad de conexión Ethernet, se elige la plataforma industrial CIAA-NXP. Sedetallan en la sección 1.3.1 las principales características de esta plataforma.

6Asociación Civil para la investigación, promoción y desarrollo de los Sistemas electrónicosEmbebidos.

7Cámara Argentina de Industrias Electrónicas, Electromecánicas y Luminotécnicas.


1.3.1. Plataforma CIAA-NXP

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

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

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

FIGURA 1.3: Plataforma CIAA-NXP.

Esta plataforma se compone de:

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.

1.3. ¿Qué es el Proyecto CIAA? 7

LV-GPIO:

• 14 GPIOs.

• I2C.

• SPI.

• 4 canales analógicos.

• Aux. USB.

Interfaces de comunicación:

• Ethernet.

• USB On-The-Go.

• RS232.

• RS485.

• CAN.

9

Capítulo 2

Introducción Específica

2.1. Definición del trabajo

Al comienzo del Trabajo Final, y como parte de la asignatura Gestión de Proyectos,se elaboró un plan de trabajo. Se incorporan en esta memoria aspectos relevantesde dicho trabajo. En la sección 2.1.1 se definen los objetivos y alcances del pro-yecto. En la sección 2.1.2 se listan los requerimientos del sistema y los criterios deaceptación. Asimismo, se realizó un desglose de tareas a llevar a cabo en la que seestableció un cronograma para estas, según se puede apreciar en la sección 2.1.3.

2.1.1. Objetivos y alcances

Objetivos:Desarrollar un software que permita utilizar la plataforma CIAA como uncontrolador de acuarios. Agregar valor al ecosistema del proyecto CIAAincorporando nuevas aplicaciones para la plataforma.

Alcance:El proyecto incluye únicamente el desarrollo de un software de control parala plataforma CIAA.

Restricciones:Finalización del proyecto 1 de agosto de 2016.

Suposiciones:Contar con los fondos solicitados al Ministerio de Industria Nacional per-mitirá costear los sensores y actuadores para armar una planta piloto dedesarrollo. En caso de que los fondos no estén disponibles tanto por el re-chazo del proyecto presentado como por una demora en los plazos de ad-judicación, está contemplado la utilización de simulaciones para emular loselementos que no se hayan podido adquirir.

Asimismo, se estima que estará disponible durante el desarrollo del proyec-to una plataforma CIAA-NXP.

Cabe mencionar que las suposiciones respecto a los fondos no se cumplieron y sedebieron ejecutar las acciones previstas para tal caso.

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

2.1.2. Requerimientos y Criterios de aceptación

Se listan a continuación los requerimientos del sistema de control de acuario. Es-tos serán retomados en la sección 4.1 para definir el plan de ensayos que permitaverificar que los criterios de aceptación se cumplen satisfactoriamente.

REQ1:El software se debe desarrollar para la plataforma de hardware CIAA, en Len-guaje C.

REQ2:El sistema debe poder medir las siguientes variables del entorno de un acua-rio:

• REQ2_A: temperatura en el rango de 16 a 30 C con una resolución de0,5 C o superior.

• REQ2_B: pH en el rango mínimo de 5 a 9 con una resolución de 0,1 osuperior.

REQ3:El sistema debe poder actuar sobre los siguientes elementos del entorno deun acuario:

• REQ3_A: Encender/apagar un artefacto de iluminación.

• REQ3_B: Encender/apagar bombas para el llenado/vaciado de agua.

• REQ3_C: Encender/apagar una bomba de CO2.

• REQ3_D: Encender/apagar un calefactor.

REQ4:El equipo debe poder ser administrado mediante una interfaz web. Se debepoder visualizar el estado del sistema y realizar su programación.

REQ5:El equipo debe poder emitir una alarma por un medio adecuado, sonoroy/o visual, cuando las variables bajo control salgan de su rango de opera-ción segura.

Criterio de aceptación:

Correcta visualización de todas las variables de estado del sistema enume-radas en el REQ2 mediante una interfaz web.

Correcto comportamiento al accionar los actuadores enumerados en el REQ3desde la interfaz web.

2.1.3. Desglose de tareas / GANTT

Como parte de la planificación se definieron las tareas necesarias para completarel trabajo y se establecieron las relaciones de correlatividad entre ellas. Se presen-ta esta información en la forma de diagrama de Gantt. En color azul oscuro sepueden ver las tareas del camino crítico.

2.1.D

efinicióndeltrabajo

11


2.2. Planteo del problema

Resulta necesario definir el modelo de control a utilizar y aclarar las suposicionesy limitaciones con que se trabajará. A su vez, se extienden los requerimientosdefinidos en la sección 2.1.2 a la luz del análisis de la problemática que se pretendeabordar.

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

Se definen valores umbrales límite para las variables medidas y se establecencondiciones de alarma. Se definen dos alarmas por cada variable medida, una porexceso, en caso de que se supere el valor máximo permitido y otra por defecto,para el caso en que la variable se encuentre por debajo del valor umbral mínimo.

Dado que la planta que se utiliza para el desarrollo del firmware no es un acuarioreal, en el presente trabajo no se profundiza sobre la dinámica del acuario en símismo. En los lazos de control se aplican acciones binarias del tipo encender/a-pagar sobre los actuadores del sistema en función de las condiciones de alarmapresentes.

Las acciones de control se deben sostener en el tiempo mientras la condición dealarma que las haya iniciado esté presente. Asimismo, cuando haya alguna ac-ción iniciada por el control de una condición de alarma, el estado del actuadorsiendo operado no debe poder ser cambiado manualmente, tanto para encender-se como apagarse, según sea el caso. Cuando no haya alarmas controlando undeterminado actuador, este se debe poder operar manualmente.

2.2.1. ¿Qué hace falta medir, actuar, alertar?

En esta sección se definen los sensores, actuadores y alarmas que serán parte delsistema de monitoreo y control. En la tabla 2.1 se declaran los sensores con lascaracterísticas principales que deben tener. Se declaran las condiciones de alarma,asociadas a los valores máximos y mínimos de cada sensor, en la tabla 2.2. En latabla 2.3 se declaran los actuadores del sistema con las características principalque deben tener.

TABLA 2.1: Declaración de Sensores.

Nombre Rango Unidad Resolución

Nivel de agua 0 - 20 cm 0,1 cmTemperatura 16 - 30 C 0,5 CpH 5 - 9 - 0,1

2.2. Planteo del problema 13

TABLA 2.2: Declaración de Alarmas.

Nombre Sensor asociado Condición

Nivel de agua alto Nivel de agua > 15 cmNivel de agua bajo Nivel de agua < 5 cmTemperatura alta Temperatura > 21,5 CTemperatura baja Temperatura < 17,5 CValor de pH alto pH > 7,5Valor de pH bajo pH < 6,5

TABLA 2.3: Declaración de Actuadores.

Nombre

Bomba de entrada de aguaBomba de entrada de aguaCalefactorIluminaciónBomba de O2

Bomba de CO2

2.2.2. Modelación de la dinámica de acuario

Como ya fuera mencionado, la dinámica del acuario está fuera de los alcances delpresente trabajo. Sin embargo, resulta necesario adoptar un modelo, si bien sen-cillo, mínimamente realista para describir la evolución de las variables de estadodel sistema cuando los actuadores se encuentran en funcionamiento. Por este mo-tivo, se describen los efectos esperables de los actuadores sobre el sistema.

Las bombas de entrada y salida de agua hacen variar el nivel de agua a la mismatasa pero en distinto sentido. Se asume que si ambas se encuentran en funcio-namiento el nivel de agua no se modifica significativamente. Para aumentar odisminuir el nivel de agua del acuario se debe encender la bomba de entrada yapagar la de salida o viceversa, respectivamente.

El funcionamiento del calefactor incrementa la temperatura del agua del acuario.Para disminuir la temperatura se debe recircular el agua encendiendo simultá-neamente ambas bombas de agua. Se asume que en esta situación el agua queingresa al acuario tiene menor temperatura que la que egresa.

La iluminación y la bomba de O2 no tienen efectos mensurables sobre las varia-bles que miden nivel, temperatura ni valor de pH del agua.

El funcionamiento de la bomba de CO2 disminuye el pH del agua del acuario, esdecir, la vuelve más ácida. Para restituir el valor de pH del agua a la neutralidad,en caso de que esta se encuentre demasiado ácida, se debe recircular el agua en-cendiendo simultáneamente ambas bombas de agua. Se asume que el agua queingresa al acuario tiene pH neutro.


2.2.3. Alternativas tecnológicas

En esta sección se presentan las alternativas tecnológicas que se evaluaron paralos sensores en base a los requerimientos y la disponibilidad en el mercado local.Se consultaron tiendas de acuarios para conocer el estado del arte y los sensoresque pudieran conectarse a un sistema de control electrónico. El relevamiento nopretende ser exhaustivo sino proporcionar una guía confiable para el desarrollodel firmware de control.

Existen múltiples maneras de medir el nivel de agua en un recipiente. En cuan-to a los principios de funcionamiento de los sensores más utilizados se puedenmencionar:

Detección mecánica de nivel mediante el cierre de un contacto por la acciónde un flotador o boya. Proporciona un valor binario que indica si el nivelde agua llegó hasta el punto que acciona el contacto o no. Un sensor de estetipo se puede observar en la figura 2.1a.

Utilización de la presión hidroestática del fluido para determinar la alturade la columna de agua. En la figura 2.1b se muestra un ejemplo de este tipode sensor cuya salida es un valor de resistencia proporcional al nivel deagua.

(A) Electrol serie 5025 1 (B) Milonetech eTape 2

FIGURA 2.1: Alternativas comerciales de sensores de nivel.

Para la medición de la temperatura del agua del acuario se encontraron princi-palmente sensores de temperatura tipo termistor NTC (Negative Temperature Coef-ficient). El principio de funcionamiento se basa en presentar un valor de resisti-vidad que disminuye con el incremento de la temperatura. En la figura 2.2a sepuede observar un sensor de este tipo de 10 kΩ a 25 C en un encapsulado deacero inoxidable sumergible con un cable de 30 cm.

Por otra parte, se encontró un termómetro digital basado en el integrado DS18B20que proporciona lecturas de la temperatura de 9 a 12 bits en forma configurable,sobre una interfaz “1-Wire” [2] que requiere un solo un cable de señal conectadoal microcontrolador. En la figura 2.2b se puede observar un sensor de este tipoque también cuenta con un encapsulado de acero inoxidable apto para inmersióncon un cable de 90 cm.

1http://www.electrolsrl.com.ar/docs/5025-01D.pdf2http://milonetech.com/p/about-etape

http://www.electrolsrl.com.ar/docs/5025-01D.pdf

http://milonetech.com/p/about-etape

2.2. Planteo del problema 15

(A) Termistor NTC3 (B) Termómetro digital DS18B204

FIGURA 2.2: Alternativas de sensores de temperatura.

Se halló una sonda compuesta por un electrodo de vidrio combinado con unamembrana de Ag/AgCl (plata / cloruro de plata), que se puede utilizar en unavariedad de mediciones de pH. En la figura 2.3a se puede apreciar la sonda paralas mediciones de pH. En la figura 2.3b se muestra un detalle del electrodo. Esteinstrumento provee una señal analógica lineal en el rango de pH 0-14 y es ap-to para mediciones online por tiempo prolongado (1 año) [sensor_pH]. Debe sercalibrado periódicamente con una solución de referencia.

(A) Sonda para la medición de pH5. (B) Detalle del electrodo para medir pH6.

FIGURA 2.3: Sonda comercial para la medición de pH.

3https://www.openhacks.com/uploadsproductos/im120628010_2.jpg4https://www.openhacks.com/uploadsproductos/_igp1391-500x500.jpg5http://www.dfrobot.com/wiki/images/f/f4/DFR0169_picture.JPG6https://www.openhacks.com/uploadsproductos/_dsc0555-600x600.jpg

https://www.openhacks.com/uploadsproductos/im120628010_2.jpg

https://www.openhacks.com/uploadsproductos/_igp1391-500x500.jpg

http://www.dfrobot.com/wiki/images/f/f4/DFR0169_picture.JPG

https://www.openhacks.com/uploadsproductos/_dsc0555-600x600.jpg

17

Capítulo 3

Diseño e Implementación

3.1. Diseño

En esta sección se tratan las consideraciones de diseño que se utilizaron paradesarrollar el sistema siguiendo los lineamientos de trabajo planteados en la asig-natura “Ingeniería de Software en Sistemas Embebidos”. Se tomó como guía elport de LPCOPEN v2.16 [4], provisto por NXP para la familia de microcontro-ladores LPC43XX, que contiene un ejemplo de aplicación sencillo que integrafreeRTOS y lwIP. Para el servidor web se utilizó un ejemplo de los desarrolla-dores del stack TCP/IP lwIP [10]. A su vez, también fueron consultados otrosejemplos de utilización de lwIP con la CIAA [8] y [6].

3.1.1. Principio de funcionamiento

En términos generales, un servidor web es un programa que permite publicarinformación en la World Wide Web (WWW) o una red de área local (LAN). Esta in-formación puede ser consultada desde cualquier navegador web estándar comoMozilla Firefox, Internet Explorer o Google Chrome, entre otros. El servidor ope-ra utilizando el protocolo HTML [1] en la capa de aplicación del modelo OSI [13]y establece un canal de comunicación entre un servidor y un cliente. El servidorejecuta las peticiones del cliente.

En el presente trabajo, el servidor web se encuentra embebido en la plataformaCIAA y proporciona al usuario una interfaz para monitorear y controlar el siste-ma. El servidor web es capaz de soportar los siguientes servicios:

HTTP 2.0: HyperText Transfer Protocol (HTTP) es un protocolo orientado atransacciones y sigue el esquema petición/respuesta entre un cliente y unservidor [1]. En particular, la version 2.0 posibilita la utilización de conexio-nes persistentes o keep-alive sessions que permiten transmitir múltiples paresde petición/respuesta multiplexados sobre una única conexión TCP. De es-ta manera se puede reducir el tráfico y mejorar el desempeño en cuanto altiempo de respuesta del servidor web. Resulta necesario para implementarmétodos AJAX.

SSI: Server Side Include (SSI) es un lenguaje interpretado sencillo que consisteen un conjunto de directivas que se incluyen dentro de la codificación deuna página HTML y que se evalúan en el servidor web cuando la páginaHTML es solicitada. Permite incluir contenido generado en forma dinámicaen tiempo de ejecución.

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

AJAX: Asynchonous JavaScript And XML (AJAX) es un conjunto de técnicasutilizadas desde el lado del cliente para enviar y recibir información de unservidor en forma asincrónica. Es una forma de desacoplar el intercambiode información y la visualización de la página web. Permite que se cambieel contenido de una página web en forma dinámica sin necesidad de re-cargar la totalidad de la página. Para implementar AJAX, el servidor debesoportar directivas SSI. El cliente debe soportar JavaScript para peticionarinformación en segundo plano y es responsable de realizar dichas peticio-nes a intervalos regulares.

Formularios web (peticiones GET): Los formularios se utilizan para enviarinformación al servidor. GET es un método del protocolo HTTP que se utili-za para solicitar información de un servidor [3]. Durante una petición GETse produce un request HTTP por parte del cliente y un response del servi-dor. La solicitud de información se transmite a través de la Uniform ResourceIdentifier (URI) agregando parámetros a la Uniform Resource Locator (URL).En la presente implementación el método GET se utiliza para enviar infor-mación al servidor en lugar de utilizar lo que sería más correcto, el métodoPOST, debido a la mayor sencillez del primero por sobre el segundo.

CGI (peticiones GET): Common Gateway Interface (CGI) es un estándar queprovee una interfaz sencilla para ejecutar programas externos en un servi-dor HTTP [9]. En esta implementación se utiliza CGI para ejecutar rutinasespecíficas dentro del microcontrolador y generar una nueva página webcomo respuesta. Las funciones asociadas a un CGI se ejecutan cuando seenvía un formulario web con el método GET al servidor para su procesa-miento.

3.1.2. Arquitectura

El sistema está diseñado con una arquitectura de capas, según se puede observaren la figura 3.1. Agrupados por color se pueden apreciar los distintos niveles deabstracción y, dentro de cada capa, los bloques funcionales que la integran .

Apps HTTP Server 2.0 Control de Acuario

HIL FreeRTOS v8.1 (RTOS) lwip v1.4.1 TCP/IP Stack

HAL

BOARD DRIVERS

LPCOPEN v2.16

HARDWARE

FIGURA 3.1: Diagrama en bloques del firmware.

3.1. Diseño 19

En cuanto a los niveles de abstracción, la primer capa la constituye el hardware dela plataforma CIAA. La segunda capa, Hardware Abstraction Layer (HAL), permitedesacoplar las capas superiores del hardware. Aquí se encuentran los drivers del fa-bricante del microcontrolador, en el bloque funcional LPCOPEN, y los desarrolla-dos para la plataforma CIAA en el bloque BOARD. La capa Hardware IndependentLayer (HIL) incluye los módulos del RTOS y el stack TCP/IP y, como su nombrelo indica, no está asociada a ningún hardware en particular. Finalmente, la últimacapa contiene dos aplicaciones, el servidor web y el control del acuario.

Se puede apreciar la estructura jerárquica de archivos del sistema en la figura 3.2,donde se han incluido los archivos fuente relevantes de cada bloque.

Sistema

main.c

Apps

Control de Acuario

actuadores.c

alarmas.c

sensores.c

HTTP Server 2.0

httpd.c

fsdata.c

http_cgi.c

http_ssi.c

HIL

freeRTOS

freeRTOSconfig.h

lwip

lwipopts.h

HAL

Board

adcs.c

board.c

gpios.c

lpc_phy_smsc87x0.c

uart.c

Chip

lpcopen v2.16

Base

cr_startup_lpc43xx.c

sysinit.c

FIGURA 3.2: Estructura jerárquica de archivos.


3.1.3. Lógica de control

Se presenta una descripción en pseudocódigo de las funciones más relevantes dela lógica de control. El lazo principal de control consiste en una tarea de freeRTOS,llamada vControl, que se ejecuta periódicamente a intervalos regulares de 500ms. Esta tarea llama secuencialmente a tres funciones auxiliares para actualizarlos valores de los sensores, actualizar los valores de las alarmas y controlar losactuadores del sistema, respectivamente.

1 # def ine MAX_SENSOR_NUMBER 32 # def ine MAX_ALARM_NUMBER 63 # def ine MAX_ACTUATOR_NUMBER 64

5 u i n t 3 2 _ t sensorValue [MAX_SENSOR_NUMBER] ;6 F u n c t i o n a l S t a t e alarmControl [MAX_ALARM_NUMBER] ; //ENABLE or DISABLE7 s t a t e _ t a larmState [MAX_ALARM_NUMBER] ; //ON or OFF8 s t a t e _ t a c t u a t o r S t a t e [MAX_ACTUATOR_NUMBER] ; //ON or OFF9

10 void vControl ( ) 11

12 i n i t G l o b a l V a r i a b l e s ( ) ;13

14 period = 500 ms ;15

16 while ( 1 ) 17

18 t i c k s = xTaskGetTickCount ( ) ;19

20 updateSensors ( ) ;21

22 updateAlarms ( ) ;23

24 con t ro lAc tua to rs ( ) ;25

26 vTaskDelayUntil (& t i c k s , period ) ;27 28

ALGORITMO 3.1: Pseudocódigo del lazo principal de control.

1 void updateSensors ( ) 2

3 // f o r every sensor4 f o r ( i =0 ; i < MAX_SENSOR_NUMBER; i ++) 5

6 // read ADCs7 data_ i = readDataFromADC ( sensorChannel_i ) ;8

9 // apply s c a l e convert ion10 data_ i = scaleConvert ion ( data_i , i ) ;11

12 // impact sensor value to g loba l v a r i a b l e13 sensorValue [ i ] = data_ i14 15

ALGORITMO 3.2: Pseudocódigo del control de los sensores.

3.1. Diseño 21

1 void updateAlarms ( ) 2

3 // f o r every sensor ; i goes from 0 to 24 f o r ( i =0 ; i < MAX_SENSOR_NUMBER; i ++ ) 5

6 //check sensor upper threshold7 i f ( sensorValue [ i ] > sensorMaxLimit [ i ] ) 8 setAlarmState (2∗ i ) ; // alarmState ’ s index goes from 0 to 59

10 e l s e 11 c learAlarmState (2∗ i ) ;12 13

14 //check sensor lower threshold15 i f ( sensorValue [ i ] < sensorMinLimit [ i ] ) 16 setAlarmState ( (2∗ i ) +1 ) ;17 18 e l s e 19 c learAlarmState ( (2∗ i ) +1 ) ;20 21 22

ALGORITMO 3.3: Pseudocódigo del control de las alarmas.

1 void cont ro lAct ua tor s ( ) 2

3 s t a t e _ t a c t u a t o r F a k e S t a t e [MAX_ACTUATOR_NUMBER] ;4

5 // f o r every actuator ,6 f o r ( i =0 ; i < MAX_ACTUATOR_NUMBER; i ++ ) 7 // Get current s t a t e8 a c t u a t o r F a k e S t a t e [ i ] = g e t A c t u a t o r S t a t e ( i ) ;9

10 // I f c o n t r o l i s enable checks alarm and operates a c t u a t o r s x , y , . . .11 i f (ENABLE == alarmControl [ i ] ) 12

13 i f ( ON == alarmState [ i ] ) 14 a c t u a t o r F a k e S t a t e [ x ] = ( Necesary a c t i o n ) ; // ON or OFF15 a c t u a t o r F a k e S t a t e [ y ] = ( Necesary a c t i o n ) ;16 alarmFlag [ i ] = ON; // f l a g i n d i c a t e s c o n t r o l a c t i o n s underway17 18 // alarm = OFF & f l a g = ON then c o n t r o l a c t i o n s should be stoped19 e l s e i f ( ON == alarmFlag [ i ] ) 20 a c t u a t o r F a k e S t a t e [ x ] = ! ( Necesary a c t i o n ) ;21 a c t u a t o r F a k e S t a t e [ y ] = ! ( Necesary a c t i o n ) ;22 alarmFlag [ i ] = OFF ;23 24 25 26

27 // Impact changes to a c t u a t o r s28 f o r ( i =0 ; i < MAX_ACTUATOR_NUMBER; i ++ ) 29

30 a c t u a t o r S t a t e [ i ] = a c t u a t o r F a k e S t a t e [ i ] ;31 32

ALGORITMO 3.4: Pseudocódigo del control de los actuadores.


3.2. Implementación

Para acceder a los sockets, el servidor web utiliza la RAW API1 de lwIP que em-plea una serie de callbacks para manejar los eventos de la comunicación. La fun-ción httpd_init() inicia el demonio del servidor y debe ser llamada luego de que elstack se encuentre inicializado con la función lwip_init(). Para alojar el contenidoHTML que se debe servir se utiliza un sistema de archivos dedicado implementa-do en ROM [11]. A través del script makefsdata, provisto por lwIP, se puede per-sonalizar los archivos HTML e integrarlos al sistema mediante el archivo fuentefsdata.c. Se debe tener especial cuidado al utilizar las funciones de la RAW APIen un entorno con múltiples hilos de ejecución como freeRTOS, ya que las fun-ciones no cuentan con protección frente a accesos concurrentes. Las funciones deesta API deben ser invocadas desde un único hilo de ejecución.

El servidor inicia con la configuración detallada en la tabla 3.1.

TABLA 3.1: Configuración MAC del servidor web.

Parámetro Valor

Dirección MAC 00:60:37:12:34:56DHCP DeshabilitadoDirección IP 192.168.200.99Máscara de red 255.255.255.0Puerta de enlace 192.168.200.1Puerto 80

3.2.1. Interfaz web embebida

Se presenta la interfaz web implementada para monitorear y controlar el acuario.Esta consta de un menú de navegación en la parte izquierda, que permite accedera tres pantallas, detalladas a continuación:

Inicio, con un resumen del estado del sistema sin posibilidad de modifica-ciones. Se puede observar en la figura 3.3.

Control, donde se encuentran los controles para operar las alarmas y actua-dores. Se puede observar en la figura 3.4.

Configuración, donde se puede cambiar la configuración de red del servi-dor. Se muestra en la figura 3.5.

En la página inicio se pueden observar tres bloques de información referida a lossensores, las alarmas y los actuadores, respectivamente. Esta información se ac-tualiza una vez por segundo mediante el método AJAX, según está documentadoen la sección 3.2.4. El estado de las alarmas se indica como “NORMAL” en colorverde o “ALARMA” en color rojo cuando el control automático está habilitado, oel mismo texto en gris cuando el control automático está deshabilitado. El estadode los actuadores se indica como “ENCENDIDO” en color verde o “APAGADO”en color rojo sin importar el estado del control de alarmas.

1http://lwip.wikia.com/wiki/Raw/TCP

http://lwip.wikia.com/wiki/Raw/TCP

3.2. Implementación 23

FIGURA 3.3: Interfaz web: página principal Inicio.

FIGURA 3.4: Interfaz web: página para controlar el sistema.

FIGURA 3.5: Interfaz web: configuración de red.


Tanto en la página Inicio como en la página Control, en el apartado SENSORESse muestra el valor numérico de cada sensor junto con una representación gráficade dicho valor. Se utiliza un gráfico de barra horizontal proporcional al valor nu-mérico que se construye en tiempo de ejecución mediante rutinas de JavaScript.Cada sensor tiene una escala que se ajusta según su valor máximo definido den-tro del microcontrolador. Mientras exista una condición de alarma para un sensor,tanto por exceso como por defecto, la gráfica asociada se muestra en color rojo,caso contrario se muestra en color verde.

La página Control, según se puede observar en la figura 3.6, posee además dela información mostrada en la página Inicio, columnas llamadas “control” paraoperar sobre las alarmas y los actuadores, respectivamente.

En el apartado ALARMAS se encuentra un checkbox para cada alarma que permitehabilitar el control automático sobre la condición de alarma o deshabilitarlo. No-tar que existe un botón “APLICAR” al final de la columna de control que impactael contenido de los checkboxes en la lógica de control dentro del microcontrolador.Para lograr esto se utiliza el método CGI según se documenta en la sección 3.2.3.El valor seleccionado/no seleccionado de los checkboxes se guarda en los datos desesión del navegador web del cliente.

FIGURA 3.6: Interfaz web: condición de alarma presente.

En el apartado actuadores, y dentro de la columna control, se pueden observarbotones para iniciar o detener los actuadores en forma manual. En el caso parti-cular que se muestra en la figura 3.6, frente a la condición de alarma por nivel deagua alto, la lógica de control mantiene la bomba de entrada apagada y la bombade salida encendida. Los botones de los actuadores mencionados se encuentrandeshabilitados mientras la alarma esté presente y si fueran presionados no pro-ducirían efectos sobre el sistema. Al posar el cursor sobre un botón deshabilitadoaparece un cuadro de diálogo como se muestra en la figura 3.7, indicando que sedebe deshabilitar el control de alarma para operar el actuador manualmente.


FIGURA 3.7: Interfaz web: botón deshabilitado por el control.

Cuando el control automático de una alarma se encuentra deshabilitado, el texto“NORMAL” o “ALARMA” se muestra sobre un fondo gris, como se puede obser-var en la figura 3.8. Como ya fuera mencionado, los actuadores asociados a estacondición son las dos bombas de agua que para el caso del control automáticodeshabilitado no se encuentran inhibidos y pueden ser operados manualmente.Cabe mencionar que en la figura 3.8 se puede ver cómo la bomba de agua SA-LIDA se encuentra apagada pese a que la condición de alarma se encuentra pre-sente. Sin pérdida de generalidad, este comportamiento puede extenderse parala totalidad de las condiciones de alarma y sus actuadores asociados.

FIGURA 3.8: Interfaz web: control deshabilitado.


3.2.2. Server Side Includes

La interfaz web contiene información del estado del sistema que se genera enforma dinámica en tiempo de ejecución. Mediante directivas SSI embebidas enlas páginas HTML, el servidor web reemplaza cadenas de caracteres debidamenteseñalizadas por el contenido dinámico. En el algoritmo 3.5 se muestra la funciónque inicializa el soporte para SSI, registrando la función que se debe llamar paramanejar las directiva SSI, la lista de etiquetas válidas y el número de etiquetas.

1 /∗∗ Set the SSI handler funct ion .2 ∗3 ∗ @param s s i _ h a n d l e r the SSI handler funct ion4 ∗ @param tags an array of SSI tag s t r i n g s to search f o r in SSI−enabled

f i l e s5 ∗ @param num_tags number of tags in the ’ tags ’ array6 ∗/7 void h t t p _ s e t _ s s i _ h a n d l e r ( tSSIHandler ss i_handler , const char ∗∗ tags ,

i n t num_tags ) 8

9 g_pfnSSIHandler = s s i _ h a n d l e r ;10 g_ppcTags = tags ;11 g_iNumTags = num_tags ;12

ALGORITMO 3.5: Inicialización del SSI handler

Se instala en manejador de directivas SSI con la siguiente línea de código:1 h t t p _ s e t _ s s i _ h a n d l e r ( SSIHandler , pccSSITags , s i z e o f ( pccSSITags ) /

s i z e o f ( char ∗ ) ) ;

Las etiquetas tienen la forma de comentario HTML, <! - - # tag - - >donde la pala-bra “tag” se debe reemplazar por los distintos valores particulares. Se utilizaronlas etiquetas definidas en el algoritmo 3.6 para el estado encendido/apagado delos actuadores, los valores de los sensores, el estado normal/alarma de las alar-mas y el control automático activado/desactivado, respectivamente.

1 // The SSI s t r i n g s t h a t are embedded in the served html f i l e s .2 s t a t i c const char ∗pccSSITags [ ] = 3 " a c t 0 " ,4 " a c t 1 " ,5 " a c t 2 " ,6 " a c t 3 " ,7 " a c t 4 " ,8 " a c t 5 " ,9 " sensor0 " ,

10 " sensor1 " ,11 " sensor2 " ,12 " alarma0 " ,13 " alarma1 " ,14 " alarma2 " ,15 " alarma3 " ,16 " alarma4 " ,17 " alarma5 " ,18 " ctr lAlrm0 " ,19 " ctr lAlrm1 " ,20 " ctr lAlrm2 " ,21 " ctr lAlrm3 " ,22 " ctr lAlrm4 " ,23 " ctr lAlrm5 " ;

ALGORITMO 3.6: Definición de etiquetas SSI


A continuación se presenta, en el algoritmo 3.7, un ejemplo parcial de la funciónpara reemplazar las etiquetas embebidas en el código HTML por el contenidodinámico. El ejemplo se restringe por simplicidad a las primeras seis etiquetas,referidas al estado de los actuadores y puede ser extendido al resto de las etique-tas de manera análoga.

Se muestra la función SSIHandler que es invocada cada vez que el servidor HTTPDdetecta una etiqueta de la Forma <! - - # tag - - >en un archivo con extensión.shtml, .ssi o .shtm, donde “tag” aparece como una de las etiquetas suministradasa http_set_ssi_handler en el array ppcTags. El parámetro iIndex proporciona el ín-dice de base cero de la etiqueta como se encuentra en el array ppcTags e identificala etiqueta que se va a procesar.

1 u i n t 1 6 _ t SSIHandler ( i n t iIndex , char ∗pcBuffer , i n t iBufferLength )2 3

4 // Unused parameter .5 ( void ) iBuf ferLength ;6

7 // The SSI handler funct ion t h a t generates t e x t depending on the indexof the SSI tag encountered .

8

9 char ∗ p t r S t a t e ;10

11 switch ( i Index )12 13

14 case ssiACT0_INDEX :15 p t r S t a t e = getActuatorCharState ( portNum_0 ) ;16 s t rcpy ( pcBuffer , p t r S t a t e ) ;17 break ;18






44 re turn s t r l e n ( pcBuffer ) ;45

ALGORITMO 3.7: Handler de etiquetas SSI


La cadena de caracteres que se copia en pcBuffer se agrega luego de la etiqueta“<! - - # tag - - >” en el archivo que se envía al cliente.

3.2.3. Common Gateway Interface

Se utilizan funciones CGIs asociadas a la petición de un nombre específico dearchivo. La interfaz web, a través de un formulario GET, solicita un archivo conextensión .cgi al servidor y envía en la URL los argumentos para la función CGI.En el algoritmo 3.8 se muestra la función para iniciar el soporte CGI que recibecomo argumento un array de pares “nombre de archivo”/función. Las funcionesregistradas se ejecutan cuando el cliente solicita el archivo con extensión .cgi aso-ciado.

1 /∗∗ Set an array of CGI f i lenames/handler f u n c t i o n s2 ∗ @param c g i s an array of CGI f i lenames/handler f u n c t i o n s3 ∗ @param num_handlers number of elements in the ’ c g i s ’ array4 ∗/5

6 void h t t p _ s e t _ c g i _ h a n d l e r s ( const tCGI ∗ cgis , i n t num_handlers ) 7

8 LWIP_ASSERT( " no c g i s given " , c g i s != NULL) ;9 LWIP_ASSERT( " i n v a l i d number of handlers " , num_handlers > 0) ;

10

11 g_pCGIs = c g i s ;12 g_iNumCGIs = num_handlers ;13

ALGORITMO 3.8: Handler de funciones CGI

Se instala en manejador de funciones CGI con la siguiente línea de código:

1 h t t p _ s e t _ c g i _ h a n d l e r s ( cgi_handlers , ( s i z e o f ( cg i_handlers ) / s i z e o f (tCGI ) ) ) ;

En el algoritmo 3.9 se pueden ver las definiciones de pares “nombre de archi-vo”/función. Estas funciones manejan el estado encendido/apagado de los ac-tuadores y el estado habilitado/deshabilitado del control automático de las alar-mas, respectivamente.

1 tCGI cgi_handlers [ ] = 2

3 "/actuadores . c g i " , actuatorsHandler ,4 "/alarmas . c g i " , alarmsHandler 5 ;6 tCGI ∗ ptrCGIHandlers ;

ALGORITMO 3.9: Registro de nombres y funciones CGI


3.2.4. AJAX

La implementación del servidor web soporta Asynchronous JavaScript and XML(AJAX). AJAX es un método que permite actualizar el contenido de una páginaweb en segundo plano, o sin recargar la totalidad de la página. El navegador webes responsable de solicitar regularmente un pequeño archivo con la informaciónque se debe actualizar y de ubicar dicha información en lugares específicos de lapágina web. Todas las transacciones se inician a través del navegador web del la-do del cliente. La utilización de este método da un aspecto dinámico al contenidoweb.

Para la utilización de AJAX se requiere que :

El cliente solicite el archivo con extensión .ssi o .shtml a intervalos regulares(1 segundo) y que el servidor pueda suministrar el archivo.

El código fuente HTML embebido en el servidor contenga sentencias AJAX.

El archivo solicitado esté escrito usando directivas SSI. De esta manera, den-tro del servidor se reemplazan las etiquetas SSI y la operatoria resulta trans-parente para el cliente.

El servidor web soporte la característica HTTP persistent connection que estáincluida en el stack TCP/IP lwIP.

Se presenta en la figura 3.9 un diagrama de secuencia con las transacciones entreel navegador del cliente y el servidor. Como ya fuera mencionado, el navegadores responsable de iniciar la transacción y luego procesar y posicionar la respuestadel servidor. En el código fuente HTML embebido en el servidor se encuentranuna serie de funciones en JavaScript que periódicamente realizan una petición dela página ajax.shtml, que contiene las directivas SSI, y luego procesan la respues-ta.

sd AJAX transactions

interaction frame

FIGURA 3.9: Diagrama de secuencia AJAX.

31

Capítulo 4

Ensayos y Resultados

4.1. Ensayos

Para verificar y validar la correcta implementación del sistema se procede a eva-luar el funcionamiento aplicando técnicas de ensayos de caja negra.

4.1.1. Ensayos de caja negra

Se utiliza la técnica de inyección de fallas para evaluar la respuesta del sistemafrente a las distintas condiciones de alarma posibles. El ensayo consiste en forzarlas entradas de los sensores a valores que disparen las condiciones de alarma ycontrastar las acciones de control del sistema con las esperadas.

Se utiliza la UART para realizar un seguimiento en el tiempo del valor de lossensores, del estado de las alarmas y del estado de los actuadores. Se tomaronmuestras a una tasa de una muestra por segundo mientras se hacían variar lasentradas del sistema para recorrer todas las posibles combinaciones de alarmas.La información fue procesada mediante rutinas de MATLAB elaboradas ad-hocpara obtener gráficas del estado del sistema que permitieran corroborar su co-rrecto funcionamiento. Los resultados se pueden observar en la sección 4.2.

Si bien el sistema tiene seis condiciones de alarma, cada uno de los tres sensorestiene dos condiciones, una por exceso y otra por defecto, que son mutuamente ex-cluyentes. Por este motivo, el máximo número de alarmas simultáneas que puedehaber en un momento dado es tres. Para analizar el comportamiento del sistemase agrupan las respuestas según la cantidad de alarmas en conjuntos de una únicaalarma, dos alarmas o tres alarmas simultáneas.

Para garantizar que se recorre todo el espacio de posibilidades de alarma se ela-boran tablas de decisión con las acciones que se deben tomar para las distintascombinaciones posibles. Se representa mediante una “Y” la condición de alarmapresente. En caso contrario se utiliza una “N”. Las acciones de contingencia ne-cesarias se indican con una “X” en el casillero correspondiente. Un casillero enblanco significa que esa acción en particular puede tener cualquiera de sus dosestados posibles sin que eso afecte la condición de alarma.

Se muestra en el cuadro 4.1 las acciones de contingencia para cuando hay unaúnica condición de alarma en el sistema. En el cuadro 4.2 se indican las accionespara las distintas combinaciones de dos alarmas. En el cuadro 4.3 se indican lasacciones de contingencia para las combinaciones de tres alarmas.

32 Capítulo 4. Ensayos y Resultados

TABLA 4.1: Tabla de decisión para el control de una sola alarma.

CONDICIONES

Nivel de agua alto Y N N N N N

Nivel de agua bajo N Y N N N N

Temperatura alta N N Y N N N

Temperatura baja N N N Y N N

pH alto N N N N Y N

pH bajo N N N N N Y

ACCIONES

Encender bomba de entrada de agua X X X

Apagar bomba de entrada de agua X

Encender bomba de salida de agua X X X

Apagar bomba de salida de agua X

Encender calefactor X

Apagar calefactor X

Encender bomba de CO2 X

Apagar bomba de CO2 X

TABLA 4.2: Tabla de decisión para el control de dos alarmas.

CONDICIONES

Nivel de agua alto Y Y Y Y N N N N N N N N

Nivel de agua bajo N N N N Y Y Y Y N N N N

Temperatura alta Y N N N Y N N N Y Y N N

Temperatura baja N Y N N N Y N N N N Y Y

pH alto N N Y N N N Y N Y N Y N

pH bajo N N N Y N N N Y N Y N Y

ACCIONES

Encender bomba de entrada de agua X X X X X X X

Apagar bomba de entrada de agua X X X X

Encender bomba de salida de agua X X X X X X

Apagar bomba de salida de agua X X X X X

Encender calefactor X X X

Apagar calefactor X X X X X

Encender bomba de CO2 X X X X

Apagar bomba de CO2 X X X

4.1. Ensayos 33

TABLA 4.3: Tabla de decisión para el control de tres alarmas.

CONDICIONES

Nivel de agua alto Y Y Y Y N N N N

Nivel de agua bajo N N N N Y Y Y Y

Temperatura alta Y Y N N Y Y N N

Temperatura baja N N Y Y N N Y Y

pH alto Y N Y N Y N Y N

pH bajo N Y N Y N Y N Y

ACCIONES

Encender bomba de entrada de agua X X X X

Apagar bomba de entrada de agua X X X X

Encender bomba de salida de agua X X X X

Apagar bomba de salida de agua X X X X

Encender calefactor X X X X

Apagar calefactor X X X X

Encender bomba de CO2 X X X X

Apagar bomba de CO2 X X X X


4.2. Resultados

En esta sección se muestran los resultados correspondientes a las distintas com-binaciones de alarmas presentes en el sistema. Se puede observar el valor de lossensores junto con sus valores límite graficados en línea punteada y el estado ló-gico de los actuadores. Por simplicidad de la gráfica, el estado de los actuadoresde iluminación y bomba de O2 no se muestran para ningún caso de análisis, yaque no tienen efecto sobre las condiciones de alarma.

Se agrupan los resultados con el criterio ya mencionado de cantidad de alarmassimultáneas. En la sección 4.2.1 se muestran los resultados para una única alar-ma presente. En la sección 4.2.2 se pueden ver los resultados para dos alarmaspresentes y finalmente, en la sección 4.2.3 se encuentran los resultados para tresalarmas simultáneas.

4.2.1. Respuesta a una única alarma

Existen seis combinaciones de una única alarma, según fueron listadas en el cua-dro 4.1. En la figura 4.1 se muestra la respuesta del sistema frente a las alarmas denivel de agua alto y nivel de agua bajo . En la figura 4.2 se puede ver la respues-ta frente a las alarmas de temperatura alta y temperatura baja. Finalmente, en lafigura 4.3 se grafica la respuesta frente a las alarmas de pH alto y pH bajo.

Número de adquisición5 10 15 20 25 30 35

Niv

el d

e ag

ua

0

2

4

6

8

10

12

14

16

Nivel de AguaBomba de EntradaBomba de SalidaCalefactorBomba de CO2Umbral altoUmbral bajo

FIGURA 4.1: Respuesta del sistema frente a variaciones en el nivelde agua.

Observando la figura 4.1, se puede apreciar que en el momento en que el nivelde agua excede el valor límite superior se enciende la bomba de salida, que lue-go se apaga cuando valor vuelve a estar en el rango de valores permitidos. Enforma análoga, cuando el nivel de agua supera el valor límite inferior se encien-de la bomba de entrada para luego apagarse cuando el valor retorna a nivelesnormales.

Las variaciones en la temperatura en la figura 4.2 producen que se enciendanlas bombas de entrada y salida para recircular el agua cuando el valor excede el

4.2. Resultados 35

Número de adquisición5 10 15 20 25

Tem

pera

tura

0

5

10

15

20

25TemperaturaBomba de EntradaBomba de SalidaCalefactorBomba de CO2Umbral altoUmbral bajo

FIGURA 4.2: Respuesta del sistema frente a variaciones en la tem-peratura.

límite superior y que se encienda el calefactor cuando el valor de temperatura seencuentra por debajo del límite inferior. Todas los actuadores que se enciendeno apagan por medidas de control vuelven al estado anterior al restablecerse losvalores normales de temperatura.

Número de adquisición2 4 6 8 10 12 14 16 18

pH

-1

0

1

2

3

4

5

6

7

8

pHBomba de EntradaBomba de SalidaCalefactorBomba de CO2Umbral altoUmbral bajo

FIGURA 4.3: Respuesta del sistema frente a variaciones en el pH.

Como se puede observar en la figura 4.3, cuando varía el pH se enciende la bom-ba de CO2 si el valor excede el límite superior, y este actuador se apaga cuandoel valor se encuentra por debajo de dicho límite. En forma similar al comporta-miento frente a la alarma de temperatura alta, cuando el valor de pH se encuentrapor debajo del límite inferior, se encienden las bombas de entrada y salida pararecircular el agua.


4.2.2. Respuesta a dos alarmas

Existen doce combinaciones de dos alarmas al mismo tiempo, según fueron lis-tadas en el cuadro 4.2. En la figura 4.4 se muestra la respuesta del sistema paralas distintas combinaciones de dos alarmas que incluyen la condición de nivel deagua alto. En la figura 4.5 se puede ver las respuestas frente a las combinacio-nes de dos alarmas que incluyen la condición de nivel de agua bajo. Finalmente,en la figura 4.6 se grafica la respuesta frente a las combinaciones de alarma detemperatura alta y baja junto con pH alto y bajo, respectivamente.

A partir de esta sección, los valores límite en línea punteada se grafican del mismocolor que el sensor al cual refieren por simplicidad en la visualización.

Número de adquisición5 10 15 20 25 30 35 40

0

2

4

6

8

10

12

14

16

18

20

22Nivel de AguaTemperaturapHBomba de EntradaBomba de SalidaCalentadorBomba de CO2Umbrales Nivel de AguaUmbrales TemperaturaUmbrales pH

FIGURA 4.4: Respuesta a dos alarmas simultáneas.Nivel de agua alto y otras.

Se puede observar en la figura 4.4 la condición de nivel de agua alto junto conlas de temperatura alta y baja y junto a las de pH alto y bajo posteriormente.Cabe destacar que cuando la temperatura se encuentra por encima de su valorlímite, la bomba de entrada se encuentra inhibida y no se enciende pese a quela acción de contingencia para temperatura alta es ciclar el agua. Esto se debe aque la condición de nivel de agua alto tiene mayor prioridad. Lo mismo ocurrecon la condición de pH bajo que tiene la misma acción de contingencia que la detemperatura alta. Durante todo el tiempo que el nivel de agua supera su valorlímite, la bomba de salida se encuentra encendida.

De manera análoga al análisis precedente, en la figura 4.5 se muestran condicio-nes de dos alarmas simultáneas donde una de ellas es la de nivel de agua bajo.En este caso, frente a las condiciones de temperatura alta y pH bajo, el actuadorque se encuentra inhibido es la bomba de salida porque la condición de nivel deagua bajo tiene mayor prioridad que las anteriores. Durante todo el tiempo que elnivel de agua se encuentra por debajo de su límite inferior, la bomba de entradapermanece encendida y se apaga cuando el nivel de agua vuelve a estar entre losvalores permitidos.

4.2. Resultados 37


0

5

10

15

20

Nivel de AguaTemperaturapHBomba de EntradaBomba de SalidaCalentadorBomba de CO2Umbrales Nivel de AguaUmbrales TemperaturaUmbrales pH

FIGURA 4.5: Respuesta a dos alarmas simultáneas.Nivel de agua bajo y otras.

Las últimas cuatro combinaciones de dos alarmas se producen entre las asociadasa los sensores de temperatura y pH. En la figura 4.6 se puede observar cómo seencienden las bombas de entrada y salida si al menos una de las condiciones detemperatura alta o pH bajo están presentes. Por otra parte, si la temperatura seencuentra por debajo de su valor mínimo permitido se enciende el calefactor y siel pH supera su límite se enciende la bomba de CO2.


0

5

10

15

20


FIGURA 4.6: Respuesta a dos alarmas simultáneas.Temperatura y pH.


4.2.3. Respuesta a tres alarmas

Existen 8 combinaciones de 3 alarmas simultáneas según fueron listadas en elcuadro 4.3. Se presentan agrupadas en dos gráficas, en las figuras 4.7 y 4.8, segúnse mantenga fija la condición de alarma por nivel de agua alto o bajo, respectiva-mente.

Se puede observar en la figura 4.7, que las acciones de control de alarma son lasesperadas, teniendo en cuenta que, al igual que en el caso de dos alarmas, cuandose encuentra presente la condición de alarma de nivel de agua alto, se inhibe elencendido de la bomba de entrada.

Número de adquisición10 20 30 40 50 60

0

5

10

15

20


FIGURA 4.7: Tres alarmas: nivel de agua alto y otras.

En forma análoga al análisis precedente, en la figura 4.8 se puede observar quelas acciones de control son las esperadas, teniendo en cuenta que en este caso elactuador inhibido es la bomba de salida por la condición de alarma de nivel deagua bajo.


0

5

10

15

20


FIGURA 4.8: Tres alarmas: nivel de agua bajo y otras.

39

Capítulo 5

Conclusiones

5.1. Conclusiones del trabajo realizado

En la presente memoria de tesis se ha documentado el Trabajo Final para la ob-tención del grado de Especialista en Sistemas Embebidos.

Se obtuvo un firmware que permite controlar un acuario en forma remota me-diante una interfaz web embebida en la plataforma CIAA-NXP. Se aplicaron sim-plificaciones al modelo de acuario, principalmente debido a las restricciones detiempo establecidas para la finalización del trabajo y a la ejecución de acciones decontingencia de riesgos identificados al comienzo de la planificación del trabajo,a saber:

Riesgo: No contar con un subsidio para la adquisición de sensores y actua-dores de acuario.

Riesgo: No disponer de una CIAA-NXP a tiempo para el comienzo del pro-yecto.

Contingencia: Simular sensores y actuadores del modelo de acuario.

Con las mencionadas simplificaciones se obtuvo una “planta piloto” que permitióavanzar en el desarrollo del firmware de control y cumplir con los requerimientosde tiempo de finalización.

Se pudo integrar el stack TCP/IP lwIP con el RTOS freeRTOS al firmware de controlsobre la base de un port desarrollado por NXP, fabricante del microcontroladorLPC4337.

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. Resultó necesario tener conocimientossobre la Arquitectura ARM Cortex M para la programación de la plataformaCIAA-NXP y el uso de los periféricos.

40 Capítulo 5. Conclusiones

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: co-mentarios en las declaraciones de funciones y partes importantes del códi-go, constantes en mayúsculas, camelCase para poner nombres significativosa funciones y variables. Se utilizaron APIs1 para abstraer distintas capas delcódigo. Se obtuvo un código 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 vida delsoftware. Se hizo uso extensivo de Git como sistema de control de versionesdel software. Asimismo, se aplicaron metodologías de ensayo de softwareaprendidas en esta asignatura.

Gestión de Proyectos en Ingeniería. Resultó de gran utilidad elaborar unPlan de Proyecto para organizar el Trabajo Final. Parte del material elabora-do en esta asignatura como la planificación y el desglose de tareas se puedenencontrar en la presente memoria, en el capítulo 2.

Sistemas Operativos de Tiempo Real (I y II). Se aplicaron los conocimien-tos adquiridos sobre freeRTOS respecto a tareas, cambios de contexto ysemáforos entre otros. Asimismo, se utilizaron herramientas de desarrollopropias de freeRTOS para medir el uso de las pilas de las tareas creadas yoptimizar el uso de la memoria.

Protocolos de Comunicación. Se aplicaron ampliamente los conocimientosobtenidos en el área de Ethernet. En particular, resultó útil el material sobreel stack TCP/IP lwIP.

Diseño de Sistemas Críticos. Siempre que fue posible se utilizaron técnicasde programación defensiva para que el comportamiento del firmware resultelo más predecible posible. Se buscó obtener un sistema de control que nofalle en primer lugar, y que si lo hace, falle en forma segura evitando dañostanto a los seres vivos dentro y fuera del acuario como a la propiedad.

Asimismo, durante el desarrollo del trabajo final se adquirieron conocimientos enlas áreas de:

Programación en lenguaje HTML5.

Programación en lenguaje JavaScript.

Utilización de linker scripts para el entorno de desarrollo LPCXpresso.

Por lo tanto, se concluye que los objetivos planteados al comienzo del trabajohan sido alcanzados satisfactoriamente, habiéndose cumplido con los criterios deaceptación del sistema final y además, se han obtenido conocimientos valiosospara la formación profesional del autor.

1Application Program Interface

5.2. Trabajo futuro 41

5.2. Trabajo futuro

Se considera oportuno identificar las líneas de trabajo futuro para dar continui-dad al esfuerzo invertido. Se listan a continuación las principales.

Trabajar con una planta piloto real, con sensores y actuadores de acuario.Caracterizar la dinámica del entorno real y ajustar la lógica de control sifuera necesario.

Escalar el firmware desarrollado para obtener un framework que posibilitecambiar el dominio de aplicación a otras áreas de control donde el modelode “medir, alertar y actuar” aplique.

Permitir la introducción de nuevos sensores y actuadores debidamente pa-rametrizados mediante la interfaz de usuario.

Mejorar la portabilidad de la interfaz web utilizando técnicas de RWD (Res-ponsive Web Design) para que permita su correcta visualización en distintosdispositivos, navegadores y resoluciones de pantalla.

43

Bibliografía

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

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

[3] Jeffrey Mogul y col. Hypertext Transfer Protocol – HTTP/1.1. RFC 2616.Mar. de 2013. DOI: 10.17487/rfc2616. URL:https://rfc-editor.org/rfc/rfc2616.txt.

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

[5] Paradais Sphynx. Acuariofilia, recrear un espacio acuático en el entornodoméstico. Ed. por Revista Digital Paradais Sphynx Animales y Mascotas.http://peces.paradais-sphynx.com/acuarios-cuidados/consejos-y-recomendaciones-para-principiantes.htm. Disponible: 2016-06-25. 2014.

[6] Proyecto CIAA. CIAA Firmware Project. Disponible: 2016-06-25. 2016. URL:https://github.com/ciaa/Firmware.

[7] Proyecto CIAA. Computadora Industrial Abierta Argentina. Disponible:2016-06-25. 2014. URL:http://proyecto-ciaa.com.ar/devwiki/doku.php?id=start.

[8] Pablo Ridolfi. Embedded software development workspace for microcontrollers.Disponible: 2016-06-25. 2016. URL:https://github.com/pridolfi/workspace.

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

[10] Savannah. lwIP - A Lightweight TCP/IP stack. Disponible: 2016-06-25. 2016.URL: http://git.savannah.gnu.org/cgit/lwip/lwip-contrib.git.

[11] Savannah. lwIP - Wiki - Sample Web Server. Disponible: 2016-06-25. 2016.URL: http://lwip.wikia.com/wiki/Sample_Web_Server.

[12] J. Teton. Guía técnica de la acuariofilia. Guías técnicas. Tursen S.A. - H.Blume, 2003. ISBN: 9788489840249. URL:https://books.google.com.ar/books?id=6vrjovWkQicC.

[13] H. Zimmermann. «OSI Reference Model - The ISO Model of Architecturefor Open Systems Interconnection». En: IEEE Transactions onCommunications 28.4 (abr. de 1980), págs. 425-432. ISSN: 0090-6778. DOI:10.1109/TCOM.1980.1094702.

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

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



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



http://peces.paradais-sphynx.com/acuarios-cuidados/consejos-y-recomendaciones-para-principiantes.htm

http://peces.paradais-sphynx.com/acuarios-cuidados/consejos-y-recomendaciones-para-principiantes.htm

https://github.com/ciaa/Firmware

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

https://github.com/pridolfi/workspace



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

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

https://books.google.com.ar/books?id=6vrjovWkQicC

http://dx.doi.org/10.1109/TCOM.1980.1094702

Control de Acuario con la CIAAlaboratorios.fi.uba.ar/lse/tesis/LSE-FIUBA-Trabajo-Final...III Resumen...

Documents

Transcript of Control de Acuario con la CIAAlaboratorios.fi.uba.ar/lse/tesis/LSE-FIUBA-Trabajo-Final...III Resumen...