Documentos de Académico
Documentos de Profesional
Documentos de Cultura
A mi Madre Francia Elena Ibarra quien me formó, gran mujer formadora de grandes hombres, ser
incansable y justo. A todos mis mentores, que por mi vida han pasado, por enseñarme que del
fracaso se aprende y que en las dificultades salen las mejores cosas y se superan los grandes
desafíos. JJGA.
Agradecimientos
Al Supremo por permitirme culminar mis estudios de Maestría al igual que poder aplicar la
investigación a mi área de desarrollo en casos reales.
Reconocer, el soporte y aporte académico en diferentes áreas del saber entregado por cada uno
de los profesores que integran la investigación en el laboratorio de LIDIS de la Universidad
de San Buenaventura Cali, en estudios de Maestría en Ingeniería del Software.
Al director de este proyecto, el Ingeniero Hugo Armando Ordoñez, PhD, por sus aportes y
grado de confianza generado al desarrollo del mismo.
A los demás investigadores y colaboradores, que con su ayuda y compresión pusieron un
granito de arena en la construcción de esta investigación, al igual a todas las personas que de
una u otra forma brindaron su aporte desinteresado al desarrollo este proyecto.
Gracias.
TABLA DE CONTENIDO
RESUMEN ....................................................................................................................................... 9
I. INTRODUCCION ...................................................................................................................... 11
III. JUSTIFICACIÓN..................................................................................................................... 15
2. Micro-Controlador. ............................................................................................................. 29
9. Vista Física.......................................................................................................................... 42
Evaluación .................................................................................................................................. 54
X. CONCLUSIONES..................................................................................................................... 63
REFERENCIAS ............................................................................................................................. 65
LISTA DE TABLAS
RESUMEN
Palabras clave: Microcontroladores, Arquitectura de software, Internet de las cosas, IOT, Smart
Cities
ARQUITECTURA DE APLICACICONES DE SOFTWARE EMBEBIDO EN MICROCONTROLADOR…. 10
ABSTRACT
This Tesis presents an software architectural model for applications to be executed in Micro-
controllers running on capture data cards for Internet of Things (IoT). The proposed software
architecture describes the structure, function and interaction of software components.
Architecture it also describes the overall design and system specification and does not focus on
algorithms and data structures. Thus, The present approach describes the components of the
software architecture and proposes an architectural modeling which considers hardware
components such as memory, processing input and output data. This architectural approach
leverages the development of modular and configurable applications
I. INTRODUCCION
En la actualidad se tiene la necesidad [1] de capturar variables análogas y digitales en tiempo real
[2], las cuales deben estar siendo tomadas y vigiladas continuamente en sitios cercanos ó
distantes del lugar de donde son capturadas. Para ello existen soluciones electrónicas que
permiten realizar esta actividad, soluciones que requieren de componentes de captura (sensores),
procesamiento (micro-controladores) de datos, los cuales trabajan con software embebido.
La captura de datos en tiempo real y el creciente desarrollo de la Internet en muchos de los
ámbitos de la vida cotidiana, ha contribuido a acercar la tecnología a las personas y a las
empresas. Este acercamiento permite una mayor interacción entre los diferentes entes que
conforman la gran red mundial [3][4]. Todo este desarrollo ha llevado a que cada vez más
dispositivos estén interconectados a esta red, dando así, nacimiento a la internet de las Cosas (IoT
– Internet of Things, en inglés) [5]. Este término hizo referencia a que en algún momento las
cosas estarían comunicadas y trabajando en conjunto con las personas.
Con base en lo anterior, es notable en la actualidad el uso masivo de dispositivos electrónicos
como el Smartphone o aparatos de uso doméstico como televisores, aires acondicionados,
puertas, entre otros, que pueden estar conectados a la gran red mundial, aportando servicios de
publicación y consulta de información, de esta misma forma todos los dispositivos (Cosas)
conectados a Internet poden ser vigilados y analizados desde cualquier parte del planeta solo con
una conexión a Internet [6]. Los dispositivos electrónicos “inteligentes” que conforman el IoT
varían ampliamente en su uso, y son soportados por micro-controladores encargados de procesar
la información que se comparte en entre estos dispositivos [7][8][9][10].
El desarrollo de aplicaciones software, hace parte de un sin número de aportes tecnológicos que
ayudan a la evolución de las nuevas tecnologías en todos los ámbitos en los cuales se requiera el
procesamiento de datos y, el electrónico no se escapa al ámbito de aplicación del desarrollo de
software.
Existe software que se ejecutan en grandes máquinas desde los main frames, hasta las super
computadoras que hoy procesan grandes cantidades de datos; pero también podemos decir que
existen pequeñas maquinas (hardware electrónico, basado en micro-controladores) capaces de
procesar datos y que resultan ser muy útiles a la hora de capturar, procesar y enviar información a
ARQUITECTURA DE APLICACICONES DE SOFTWARE EMBEBIDO EN MICROCONTROLADOR…. 12
El enfoque arquitectónico propuesto está dado para soluciones software que se ejecuten en micro-
controladores en tarjetas para la captura de datos orientadas a soluciones para internet de las
cosas.
ARQUITECTURA DE APLICACICONES DE SOFTWARE EMBEBIDO EN MICROCONTROLADOR…. 14
III. JUSTIFICACIÓN
A pesar de la existencia de distintas arquitecturas de alto nivel como las presentadas en [12],[3],
[17] ó [11], ninguna abarca específicamente una arquitectura para que se adapte al paradigma de
la IOT, haciendo que quienes desarrollen soluciones software para micro-controladores que
ejecutan software en tarjeta para la IOT , tengan que definir su propia arquitectura para un
problema en particular, sin tener un esquema de referencia en el cual basarse o poder reutilizar.
IV. OBJETIVOS
A. Objetivo general
Diseñar una arquitectura de software para sistemas embebidos que se ejecuten en Micro-
Controladores para tarjetas de captura de datos de la IOT.
B. Objetivos específicos
V. RESULTADOS OBTENIDOS
Trabajos Relacionados.
La arquitectura de software es una disciplina estudiada por la Ingeniería de software, la cual tiene
variados exponentes y tendencias dependiendo del objeto de aplicabilidad, algunos delos
referentes importantes en estos temas son Booch, Martin, Jacobson, Rumbaugh, Larman [19][20],
quienes hacen sus primeras apreciaciones en términos de arquitectura refiriéndose a patrones de
diseño en UML y orientados a objetos. Buschmann y Sommerlad comenzaron a hablar de
patrones de diseño orientados a la arquitectura de software [20], ilustrando una serie de patrones
que en su interior, muestran los componentes del software y sus relaciones para cumplir con los
requisitos.
Bazz, Clements y Kazman [19] presentan un enfoque basado en las decisiones de tipo técnico que
son influenciadas por factores como: Stakeholders, la organización, la experiencia del arquitecto,
el ambiente técnico, entre otros. El énfasis de estos autores está en que la arquitectura debe estar
enfocada en casos de estudio y no en generalidades. Trata también lo referente a la importancia
de la arquitectura de software y los beneficios de la misma para el equipo de desarrollo, el
crecimiento del producto, la mantenibilidad del software y la trasferencia de conocimiento. Estos
autores no dejan de lado el uso de patrones para solucionar los problemas planteados por los
requisitos.
En [21] y [22] Garlan y Shaw exponen distintos estilos arquitectónicos que podrían adaptarse
dependiendo del tamaño del software. Estas propuestas hablan de los Frameworks como
elemento fundamental en la construcción de software y de la importancia de considerar estos
frameworks a la hora de optar por una arquitectura de software. Este grupo de trabajos enfatiza
que la arquitectura de software está compuesta por componentes, sus relaciones y las
restricciones que imponen los requisitos funcionales y no funcionales.
ARQUITECTURA DE APLICACICONES DE SOFTWARE EMBEBIDO EN MICROCONTROLADOR…. 20
En este sentido, existen algunas iniciativas de arquitecturas para sistemas embebidos, en [23] se
destaca que en el dominio de sistemas embebidos se podrían implementar los patrones de diseño
arquitectónicos expuestos por autores antes mencionados y en qué tipo de soluciones se usarían.
Sin embargo, esta propuesta no presenta una arquitectura de software para sistemas embebidos,
sino que se concentra en el uso de patrones para el desarrollo de software.
Los trabajos antes mencionados se centran en tratar las arquitecturas de software para la IoT
desde una perspectiva general y de alto nivel, describiendo la interactúan entre diversos
componentes, como son hardware, software, comunicaciones, protocolos, estándares. Las
propuestas existentes se enfocan en el uso de la Web como un factor determinante para estas
arquitecturas, dejando de lado la arquitectura que se ejecuta dentro de los micro-controladores de
las tarjetas electrónicas para la IoT tal como se describe en [15],[14],[17],[3] y [28]. Sin embargo
en otros casos [26],[29],[23] y [30] los autores se centran en la utilización de patrones de diseño,
en el ámbito de la ingeniería de software, que dan solución a un problema de la realidad usando
sistemas embebidos.
ARQUITECTURA DE APLICACICONES DE SOFTWARE EMBEBIDO EN MICROCONTROLADOR…. 22
Es conveniente definir el concepto Arquitectura de Software debido a que hoy en día el término
de arquitectura se usa para referirse a varios aspectos relacionados con las tecnologías de la
información. De acuerdo al Software Engineering Institute (SEI), la Arquitectura de Software se
refiere a “las estructuras de un sistema, compuestas de elementos con propiedades visibles de
forma externa y las relaciones que existen entre ellos [31].
Una definición reconocida es la de Clements [32]: Es una vista del sistema que incluye los
componentes principales del mismo, la conducta de esos componentes según se la percibe desde
el resto del sistema y las formas en que los componentes interactúan y se coordinan para alcanzar
la misión del sistema.
David Garlan [33] establece que la arquitectura de Software constituye un puente entre el
requerimiento y el código, ocupando el lugar que en los gráficos antiguos se reservaba para el
diseño. La definición “oficial” de arquitectura de software se ha acordado que sea la que brinda el
documento de IEEE Std 1471-2000, adoptada también por Microsoft, que dice así:
fundamental dentro del desarrollo. Para lograr esto, es de vital importancia poder contar con un
lenguaje de descripción de arquitectura (ADL) que permite modelar una arquitectura mucho antes
que se lleve a cabo la programación de las aplicaciones que la componen, analizar su adecuación,
determinar sus puntos críticos y eventualmente simular su comportamiento.
C. Estilos de Arquitectura.
¿Cuántos y cuáles son los estilos?. En un estudio comparativo de los estilos, Mary Shaw [35]
considera los siguientes, mezclando referencias a las mismas entidades a veces en términos de
“arquitecturas”, otras invocando “modelos de diseño”: Arquitecturas orientadas a objeto,
Arquitecturas basadas en estados, Arquitecturas de flujo de datos: Arquitecturas de control de
realimentación, Arquitecturas de tiempo real, Modelo de diseño de descomposición funcional,
Modelo de diseño orientado por eventos, Modelo de diseño de control de procesos, Modelo de
diseño de tabla de decisión, Modelo de diseño de estructura de datos.
El mismo año, Mary Shaw, junto con David Garlan [22], propone una taxonomía diferente, en la
que se entremezclan lo que antes llamaba “arquitecturas” con los “modelos de diseño”: Tubería-
filtros, Organización de abstracción de datos y orientación a objetos, Invocación implícita, basada
en eventos, Sistemas en capas, Repositorios, Intérpretes orientados por tablas, Procesos
distribuidos, ya sea en función de la topología (anillo, estrella) o de los protocolos entre procesos
(p. ej. algoritmo de pulsación o heartbeat). Una forma particular de proceso distribuido es, por
ejemplo, la arquitectura cliente-servidor. Entre otros el autor nombra: Organizaciones programa
principal / subrutina, Arquitecturas de software específicas de dominio, Sistemas de transición de
estado, Sistemas de procesos de control.
ARQUITECTURA DE APLICACICONES DE SOFTWARE EMBEBIDO EN MICROCONTROLADOR…. 24
D. Frameworks y Vistas.
La mayoría de los frameworks y estrategias reconoce entre tres y seis vistas, que son las que se
incluyen en el cuadro. Una vista es, para definirla sucintamente, un subconjunto resultante de
practicar una selección o abstracción sobre una realidad, desde un punto de vista determinado
[36][37][38].
TABLA IV. FRAMEWORKS DE ARQUITECTURA
Zachman TOGAF 4+1[34] Booch,Rumbaugh[31] POSA Microsoft
Niveles (Arquitecturas) (Vistas) Vistas (Vistas) (Vistas)
Scope Negocio Lógica Diseño Lógica Lógica
Empresa Datos Proceso Proceso Proceso Conceptual
Sistema Lógico Aplicación Física Implementación Física
Tecnología Desarrollo Despliegue
Física
Representación Tecnología Casos de Desarrollo
Casos de Uso
Funcionamiento Uso
En [29] se proporciona una sistematización de clases de estilo en cinco grupos, que para utilizar
la arquitectura de software se sigue un conjunto de patrones arquitectónicos, entre los cuales
podemos encontrar:
• Cliente-Servidor
• Blackboard.
• Sistemas en capas.
• Intérprete.
• Orientado a servicios.
Un patrón arquitectónico que se adapta con mayor robustez a los sistemas embebidos para IOT es
el Modelo de capas, este patrón permite mayor flexibilidad dado el caso que se le quieran
adicionar componentes en una misma capa o varias capas, sin tener que modificar las
componentes existente. Este es un beneficio importante porque a pesar que es de muy bajo
acoplamiento entre capas y componentes, permite que la arquitectura se pueda utilizar con
independencia del micro-controlador que se esté utilizando, y adicionalmente la permite que el
software sea mantenibilidad.
ARQUITECTURA DE APLICACICONES DE SOFTWARE EMBEBIDO EN MICROCONTROLADOR…. 25
E. Internet de la Cosas.
El término Internet de las Cosas (Internet of Things o IOT) se refiere a una evolución de lo que
hoy se conoce como Internet para convertirla en una red interconectada de objetos que no solo
recolectan información del ambiente e interactúa con el mundo físico, sino que usa estándares de
Internet para proveer servicios de información[17]. Esto implica, además de tener determinada
infraestructura, servicios y demás, la construcción de estos objetos inteligentes en sistemas
embebidos de forma tal que tengan la conectividad necesaria para construir un ecosistema en
donde todos los artefactos (tanto hardware como software) estén interconectados[13].
IOT se refiere también a la conexión de estos dispositivos a Internet de manera que puedan
conectarse con otros objetos, comunicarse e interactuar de la misma forma que las personas lo
hacen hoy a través de la Web [13]. De hecho, la principal fortaleza del concepto de IOT es el
impacto que tendrá en los aspectos de la vida cotidiana en los potenciales usuarios [3]. Algunas
aplicaciones de IOT son: transporte y logística [3], cuidado de la salud [3], [12], ambientes
inteligentes [3], [12].
La IoT ha traído consigo entre otras cosas el uso integrado de las tecnologías de la información y
las comunicaciones, el desarrollo y acuerdos sobre estandarización, y un nuevo modo de ver a
toda la sociedad interactuando con una infraestructura de comunicaciones Persona-Máquina o
Máquina a Máquina (M2M) que proporcionará una nueva generación de servicios en una Internet
del Futuro con la interconexión de dispositivos de detección inalámbricos en Redes de Sensores
Inalámbricas (WSN Wireless Sensor Network) basadas en IP [28].
F. Dispositivos Inteligentes.
Son computadores de bajos recursos y autónomos que realizan el mismo trabajo infinitamente y
están dotadas de un micro-controlador y dispositivos de entrada y salida. En este contexto, surge
el concepto de dispositivo inteligente que trata de un sistema embebido que puede entender y
reaccionar a lo que está ocurriendo en su alrededor [39] y que no solo se interesa por la
interacción con el usuario sino también de la interacción con otros dispositivos inteligentes o
ARQUITECTURA DE APLICACICONES DE SOFTWARE EMBEBIDO EN MICROCONTROLADOR…. 26
incluso otro software. Para esto, se necesita que los dispositivos inteligentes: tengan capacidad
de obtener información sobre su entorno a través de la medición y control de sensores y
actuadores, una configuración que se pueda adaptar a cada necesidad como pueden ser cuestiones
de conectividad o seguridad , deben tener un módulo de gestión de seguridad y credenciales,
deben permitir el control automático de tareas de forma tal que se programe el objeto inteligente
para realizar tareas, y puedan comunicarse con otros sistemas como servicios web o servicios en
la nube.
En [3] y [40] se propone una arquitectura orientada a servicios para un middleware para IOT ya
que según los autores es fundamental abstraer a los desarrolladores de IOT de cierta
infraestructura de IOT. El hecho de haber elegido SOA, explican los autores, es porque la
adopción de este tipo de arquitecturas permite descomponer sistemas complejos y monolíticos en
aplicaciones consistentes de un ecosistema de componentes simples y bien definidos. Esta
arquitectura está compuesta básicamente por cinco capas: Aplicaciones, Composición de
Servicios, Gestión de Servicios, Abstracción de Objetos.
En [12] se propone una arquitectura modular, escalable que soporte agregar o eliminar
funcionalidades dependiendo de los requerimientos. Esta arquitectura de alto nivel está
compuesta por cuatro capas: Espacio físico y/o virtual, Sensor como un servicio, Gestión de
datos, Estadísticas/Análisis de datos.
- Submodelo de Dominio
ARQUITECTURA DE APLICACICONES DE SOFTWARE EMBEBIDO EN MICROCONTROLADOR…. 27
- Submodelo de Información
- Submodelo de Comunicación
El Submodelo de Dominio, que define los conceptos desde el punto de vista de la información en
IOT. Este Submodelo de Dominio es la base del modelo de referencia y sirve como soporte a la
arquitectura de referencia para que todas las arquitecturas concretas hagan referencia a los
mismos conceptos, introduciendo los principales conceptos como Dispositivos, Servicios IOT,
Entidades Virtuales y la relación entre estos conceptos, como por ejemplo la relación “Los
servicios exponen recursos”.
El Submodelo de Información que en realidad surge a partir del Submodelo de Dominio y explica
cómo se modela la información en IOT a través de una estructura abstracta que contiene
relaciones y atributos, sin entrar en detalles de cómo se va a terminar representando esa
información en los casos concretos.
Otro Modelo importante definido en [15] y [16] es el Modelo Funcional. Para explicar el
concepto de Modelo Funcional primero hay que definir dos conceptos:
- Organización de los servicios: actúa como un concentrador entre los demás grupos funcionales.
- Entidad virtual y servicio IOT: incluyen funciones relacionadas con la obtención y el envío de
datos desde y hacia los dispositivos, respectivamente.
En [16] se define un conjunto de componentes que están presentes en la mayoría de los artefactos
software independientemente de los requerimientos que se tengan. La capa de presentación
contiene toda la funcionalidad relacionada con el usuario para administrar la relación sistema-
usuario.
La capa de negocios implementa las funcionalidades centrales del sistema y las encapsula
exponiendo sólo las funcionalidades necesarias para las capas superiores. Por lo general, tiene un
conjunto de interfaces para que el resto de los componentes puedan consumir su información.
La capa de datos provee acceso a: Datos almacenados localmente, Datos expuestos por sistemas
externos dentro de la misma red Además, al igual que la capa de negocios, provee interfaces para
que el resto de los componentes puedan consumir su información. En una vista más detallada de
la arquitectura propuesta en [41] y [42] se presentan los subcomponentes que cada capa posee y
se agregan la capa de servicios y las transversales.
Las capas transversales varían de un escenario a otro y deben ser identificadas para cada caso de
uso. Este grupo de capas por lo general incluye funcionalidades como logging, caching,
validaciones, autenticación y manejo de errores. El hecho de identificar estas funcionalidades
transversales es de extremada importancia dado que fomenta una mejor reusabilidad y
mantenimiento, mientras que al mismo tiempo evita duplicar componentes software. Las capas de
ARQUITECTURA DE APLICACICONES DE SOFTWARE EMBEBIDO EN MICROCONTROLADOR…. 29
esta vista detallada y sus subcomponentes son: Capa de Presentación (interfaz de usuario y
componente lógicos), Capa de Negocios (Facha de la aplicación y Lógica de negocio), Capa de
acceso a datos y Capa de servicio donde se exponen la comunicación para integración.
1. Arquitectura de Software.
En este contexto, la arquitectura software que se propone en este trabajo, intenta ser un marco de
referencia que permita a los diferentes componente del hardware interactuar entre sí (según lo
disponga el programador), con el fin de permitir tener una solución de captura, procesamiento y
transferencia de información (envío de datos) enfocada a soluciones IoT.
2. Micro-Controlador.
Los sistemas embebidos trabajan con Micro-controladores que realizan operaciones de entrada,
procesamiento y salida de información [10]. El sistema embebido es el cargado de administrar la
ARQUITECTURA DE APLICACICONES DE SOFTWARE EMBEBIDO EN MICROCONTROLADOR…. 30
memoria y de interactuar con los periféricos de todos los elementos que componen una tarjeta de
toma de datos que está conectada a la IoT, en este sentido, el software embebido es quien
gobierna el funcionamiento de los elementos de la tarjeta (micro-controladores) [7][43] como se
muestra en la Figura 1.
Desde el fabricante el micro-controlador tiene cargado una capa de software llamada bootloader,
que hace parte del firmware [44], que es el encardo de exponer a los desarrolladores las interfaces
de programación tanto de puertos análogos, digitales, I2C , UART,s entre otros, al igual que el
acceso a la memoria y demás componentes del hardware, para que así desde la capa de
aplicación se pueda interactuar con el micro-controlador. Además, el bootloader es el encargado
de cargar la capa de software desarrollada por el usuario (aplicación) y transferir el control del
micro-controlador a esta, tanto la capa de software bootloader (en otros Micro-controladores
también se conoce como firmware y contiene componentes más robustos como micro sistema
operativos embebidos), como la de aplicación son guardadas en memoria no volátil, permitiendo
que las dos capaz de software nunca se borren, salvo cuando el usuario decida hacerlo o
actualizarlas. La Figura 2 muestra un diagrama, de alto nivel, el cual permite la visualización de
las diferentes capaz que conforman los componentes de software y hardware en una tarjeta de la
IOT.
ARQUITECTURA DE APLICACICONES DE SOFTWARE EMBEBIDO EN MICROCONTROLADOR…. 31
Memoria
Externa al
Tiene el programa en una memoria externa, por ejemplo 8031
Micro-
controrlador
CISC significa Complex Instruction Set Computing , que permite al usuario
CICS
Según aplicar 1 instrucción como alternativa a muchas instrucciones simples
Instruction RISC Reduced Instruction Set significa Informatics . RISC reduce el tiempo
Set RISC de operación por el acortamiento de la ciclo de reloj por instrucción. El
RISC da una mejor ejecución que la CISC.
Harvard Estos Micro-controladores tienen en el mismo espacio de memoria los datos
Según la Memory y los programas.
Arquitectur
a de Estos Micro-controladores tienen en el mismo espacio de memoria tanto
Von Neuman
Memoria & Princetone datos como programas. La memoria externa al micro-controlador en el
mismo integrado.
8051 es un micro-controlador de ocho bits inventado en 1981 por Intel
Corporation . Está disponible en 40 pines. Este es el micro-controlador
básico pero todavía muchas empresas están fabricando este tipo de micro-
controladores. Los tipos más antiguos de 8051 tienen 12 ciclos por
8051 instrucción que lo hacen lento mientras que el reciente 8051 tienen 6
instrucciones por
ciclo de reloj. El micro-controlador 8051 no tiene memoria integrada ni
convertidores A / D y está clasificado como CISC , el 8051 utiliza la
arquitectura de Von Neuman.
Peripheral Interface Controller, es una familia de Micro-controladores de
Microchip Technology EE.UU. con la arquitectura Harvard . Originalmente,
este fue desarrollado como dispositivo de soporte para PDP (procesador de
datos de programa) para apoyar a los dispositivos electrónicos en el control
Según el PIC de periféricos. Son clasificados como RISC. Una cosa interesante sobre PIC
tipo de es que su ciclo de máquina se compone de sólo 4 pulsos de reloj en contraste
Integrado con 12 pulsos de reloj en Intel 8051. Estos Micro-controladores están siendo
usados en aplicaciones como teléfonos inteligentes, accesorios de audio,
vídeo y periféricos para juegos y dispositivos médicos avanzados.
ARM es un Micro-controladores de 32 bits cuyo núcleo está diseñado por
ARM Limited con arquitectura RISC . ARM tiene Von Neumann
arquitectura (programa y RAM en el mismo espacio) . Los Micro-
ARM controladores ARM son muy utilizados para el ahorro de energía y están
presentes dispositivos de muy bajo consumo de energía. Se caracteriza por
ejecutar muchas instrucciones en 1 solo ciclo de reloj. Son muy utilizados en
dispositivos inteligentes o Smart Devices.
El AVR es de Harvard arquitectura RISC de 8 bits fue desarrollado por
Atmel en 1996. El AVR es sinónimo de Alf - Egil Bogen y el procesador
AVR
RISC de Vegard Wollan . AVR toma sólo un ciclo reloj por instrucción. Se
clasifican en TyniAVR, Mega AVR, XMegaAVR
energía solar. Debido a este tipo de situaciones los fabricantes están diseñando nuevas
alternativas de micro-controladores que cuenten con esta característica, con el propósito de que
el micro-controlador sea más competitivo en el desarrollo de las tarjetas electrónicas para la IoT.
Por tal motivo, la arquitectura propuesta, provee una restricción importante para la
implementación del software teniendo como argumento lo antes expuesto, una capa de software o
componente de capa debe implementar el manejo de alimentación o en su defecto, tiempos
adormecimiento (sleep times) dependiendo del uso para el cual se está desarrollando la aplicación
embebida.
4. Soluciones IOT.
El término IOT, se refiere a una evolución de lo que hoy se conoce como Internet para convertirla
en una red interconectada de objetos que no solo recolectan información del ambiente e
interactúa con el mundo físico, sino que usa estándares de Internet para proveer servicios de
información [17]. Esto implica, además de tener determinada infraestructura, servicios y demás,
la construcción de “cosas” inteligentes en sistemas embebidos de forma tal que tengan la
conectividad necesaria para construir un ecosistema en donde todos los artefactos (Tanto
hardware como software) estén interconectados [13].
La IoT ha traído consigo entre otras cosas el uso integrado de las tecnologías de la información y
las comunicaciones, el desarrollo y acuerdos sobre estandarización, y un nuevo modo de ver a
toda la sociedad interactuando con una infraestructura de comunicaciones Persona-Máquina o
M2M (Máquina a Máquina) que proporcionará una nueva generación de servicios en una Internet
del Futuro con la interconexión de dispositivos de detección inalámbricos en Redes de Sensores
Inalámbricas (WSN Wireless Sensor Network) basadas en IP [28].
de software para objetos inteligentes en IOT. Tal como se mencionó en el capítulo 3 como un
sistema embebido que puede entender y reaccionar a lo que está ocurriendo en su alrededor [39]
y que no solo se interesa por la interacción con el usuario sino también de la interacción con otros
sistemas embebidos o incluso otro software, es decir, contempla la interacción con el mundo
físico y virtual al mismo tiempo. El concepto internet de las cosas implica la construcción de
estos sistemas embebidos de forma tal que tengan la conectividad necesaria para construir un
ecosistema en donde todos los artefactos (Tanto hardware como software) estén interconectados
[13].
La ausencia de una arquitectura con estos fines dificulta el desarrollo de soluciones haciendo que
los existentes terminen siendo “a medida”, lo cual eleva costos y disminuye el grado de
reutilización del software, dado que para cada solución se plantea una nueva arquitectura en vez
de reutilizar componentes arquitectónicos de un problema similar anterior. Esto se debe a que el
diseño arquitectónico de software es un proceso que debe tomar como entrada los requerimientos
del sistema y tener como salida una arquitectura de software que los satisfaga. Por lo general, este
proceso de diseño arquitectónico es iterativo, hasta que se asegura que su estructura es acorde a
los requerimientos. Con la existencia de una arquitectura de referencia, se disminuirán
considerablemente las iteraciones dado que solo se necesita adaptar una arquitectura ya existente
a los requerimientos específicos del problema a resolver. Además las arquitecturas de referencia
sirven como base para producir arquitecturas concretas que resuelven casos particulares [15]. La
arquitectura actúa entonces, como enlace entre la fase de ingeniería de requerimientos y diseño
del software, describiendo la forma en que se organiza el sistema como un conjunto de
componentes relacionados entre sí (Figura 3).
Arquitectura
Requerimientos Arquitectura de
Concreta
Referencia
1. Atributos Arquitectónicos.
2. Requisitos Funcionales.
3. Estilo Arquitectónico.
La Figura 4, permite visualizar las diferentes capas de software donde cada uno de los
componentes estará representados en la arquitectura planteada.
Interface.
peticiones, los cuales pueden venir por algún puerto de comunicación para recepción y trasmisión
de datos como el puerto serial o una comunicación por puerto TX/RX usando algún protocolo de
comunicación (el cual se implementa en la capa del sistema que contiene los protocolos de
comunicación).
Capa de Control.
Capa de Modelo.
En la capa del Modelo (Model) se gestiona toda la lógica que interactúa directamente con las
rutinas de bajo nivel expuestas por el firmware del micro-controlador, rutinas que son
implementadas por la capa del sistema (System Abstraction Layer) en un componente de
comunicación (COM) entre el micro-controlador y los puertos de entrada salida.
System Abstraction Layer está dividida en sub-capas, que permiten la implementación de rutinas
de bajo nivel o de servicio para que la lógica de negocio pueda ser soportada, para ello el
componente Kernel o capa moderadora se vale de rutinas que permiten la ejecución normal de la
aplicación en el micro-controlador, para ello, debe implementar la rutina inicial de
configuración(setup) y una rutina de ciclo infinito (loop) que se termina ya sea por algún evento
programado en la aplicación o por desconexión de la alimentación de la tarjeta electrónica.
Una sub-capa importante que hace parte del sistema es la que implementa los Protocolos de
Comunicación (COMMUNICATIONS PROTOCOLS), en esta capa se desarrollan las rutinas
que permiten implementar los protocolos de comunicación con el mundo exterior. En este
sentido, es posible, implantar protocolos que se enmascaran en HTTP como REST ó CoAP, o
MQTT.
ARQUITECTURA DE APLICACICONES DE SOFTWARE EMBEBIDO EN MICROCONTROLADOR…. 39
Finalmente, la capa del sistema implementa una sub-capa encargada de la Gestión de los
Almacenamiento (Local Store Service) de datos locales, esto para el caso que la aplicación lo
requiera.
Capa Lógica.
La capa de Lógica ( Logic Layer ) controla la entrada y salida del hardware con dos principales
objetivos:
La subcapa WEB RUTINES / SERVER RUTINES, por otra parte, sirve a las peticiones externas
que consumen información del sistema embebido directamente a través de servicios, publicados
por el sistema embebido, sin pasar por la capa de presentación. Es posible que el usuario esté del
otro lado del sistema externo, monitorizando o controlando la información que llega, pero esto no
es estrictamente necesario ya que el proceso de medición puede también ser automatizado a
través de sistemas informáticos sin necesidad de hacer uso de una interface gráfica del lado del
sistema embebido que interactúe con el usuario.
para el objeto inteligente, mientras que los de las capas superiores son para consumir la
información de salida del objeto inteligente.
8. Vista Lógica.
Tal como se mencionó en capítulos anteriores la vista lógica de una arquitectura soporta los
requerimientos funcionales (lo que el sistema debe proveer a los usuarios en términos de
servicios) [40]. Si bien se pueden usar cualquier tipo de diagramas para documentar esta vista, los
más comunes son Diagramas de Clase UML y Diagramas Entidad-Relación. En este trabajo se
optó por diagramas de clase UML. En la figura 5 se puede observar la vista lógica de la
arquitectura de referencia. En las secciones 4.1.1 a 4.1.4 se explican por separado las relaciones
entre los componentes más importantes.
ARQUITECTURA DE APLICACICONES DE SOFTWARE EMBEBIDO EN MICROCONTROLADOR…. 42
9. Vista Física.
Esta vista representa cómo se distribuyen los componentes entre los distintos componentes del
sistema. En otras palabras, se ubica cada parte del software en un nodo, de forma tal que se
mapeen software y hardware.
En la figura 6, se muestra un diagrama de despliegue de alto nivel, que describe cómo se ubica al
sistema embebido en un modelo orientado a servicios. En el diagrama se puede observar cómo el
sistema embebido provee servicios a los clientes y, para generar una respuesta a esa petición,
consume los valores que lee del hardware (recursos), los procesa y luego emite una respuesta. La
idea de pensar a los sistemas embebidos como un Gateway, es decir, un intermediario, entre el
consumidor y el recurso permite contemplar que hay recursos como sensores de temperatura, de
luz o de humedad que no tienen la capacidad de integrarse a un ambiente de internet de las cosas.
ARQUITECTURA DE APLICACICONES DE SOFTWARE EMBEBIDO EN MICROCONTROLADOR…. 43
Petición Lectur
Sistema
Cliente Hardware
Embebido
Respuesta Respuesta
La figura 7 muestra la vista física de la arquitectura de referencia y es una versión detallada del
modelo orientado a servicios propuesto en la figura 6. La vista comienza con el usuario
realizando peticiones al sistema embebido a través de actuadores o software externo como
pueden ser sistemas empresariales, aplicaciones web, o bien otros Sistemas Embebidos. Por
ejemplo, en el caso de la biblioteca, la comunicación podría darse entre el sistema de reservas y el
sistema embebido, aunque si un usuario administrador quisiera acceder directamente al sistema
embebido, también podría hacerlo. Luego, dentro del sistema embebido se encuentran aquellos
componentes que resuelven las peticiones generadas por el entorno. Básicamente, a través del
Controlador Frontal (Listener) se delega el trabajo en los componentes de negocio y las
componentes transversales (Se las reemplazó por un solo componente para ahorrar espacio en el
diagrama), y los recursos virtuales ofrecen una interfaz hacia los recursos físicos del sistema
embebido (Como pueden ser sensores de presencia o actuadores para encender una lámpara,
sensores de temperatura, humedad, etc) como así también una interfaz hacia otros recursos
virtuales, que pueden estar alojados en otro sistema embebido. Notar que los recursos físicos del
sistema embebido impactan directamente sobre los objetos del mundo físico real, es decir, objetos
no abstractos que el usuario puede ver y tocar. Por último, el componente de acceso a datos junto
a su repositorio también es incluido dentro del sistema embebido.
ARQUITECTURA DE APLICACICONES DE SOFTWARE EMBEBIDO EN MICROCONTROLADOR…. 44
VIII. APLICACIONES
Ejemplo Práctico
Se proponen dos ejemplos prácticos para mostrar cómo se puede utilizar esta arquitectura para
resolver una problemática actual. En la sección 4.1.2 se enuncia el problema correspondiente al
monitoreo de variables de humedad y temperatura para la optimización de riego en cultivos de
cilantro, y en la sección 4.1.3 una solución con base a la arquitectura de referencia propuesta.
las variables agroclimáticas, esto garantiza una cosecha exitosa; gracias al uso de la medición de
las variables se pude tomar decisiones para aumentar la frecuencia de riego en momentos donde
las temperaturas llegare a superar los 30°C.
Del control de las variables de humedad y temperatura se podrá tomar decisiones importantes
para la optimización de los recursos hídricos y tener una mejor cosecha con reducción en los
costos de producción.
B. Solución Planteada
Para solucionar el problema enunciado, se procedió a adaptar la arquitectura de referencia a la
problemática propuesta. Esta es, una mirada general de la arquitectura concreta (Vista General),
detalle de la arquitectura concreta (Arquitectura Detallada), una vista lógica (Vista Lógica), una
vista de procesamiento (Vista de Procesamiento) y una vista física (Vista Física).
Vista General
La arquitectura concreta se puede observar en la figura 8. La misma comienza con una capa de
sistemas externos que, para este escenario en particular, está compuesta por dos aplicaciones:
Una para smartphones y otra para el consumo remoto de servicios web de una aplicación en la
nube. Esta capa interactúa directamente con la capa de servicios, que es implementada a través de
servicios web. En cuanto a la capa de presentación, del enunciado se extrae que la misma va a
estar encargada de mostrar mensajes sobre un visor LCD. Luego, la capa lógica de negocios se
transforma en este caso en lógica del sistema medición, implementando las funcionalidades
requeridas. La capa acceso a datos se encarga de la lectura y escritura sobre memoria EEPROM y
por último, los recursos virtuales 2:
Arquitectura Detallada.
La vista a continuación de la arquitectura parte de la planteada en la sección 4.1.4, aumentando el
nivel de detalle de los componentes (Figura 9).
La capa de presentación muestra sus dos subcomponentes: Display LCD y Lógica de
Presentación. El primero contiene los drivers necesarios para manejar el hardware del Display
LCD, es decir, le envía la información que tiene que mostrar. La lógica de presentación, de forma
complementaria y anterior, pre-procesa la información que se debe mostrar de forma tal que
quede fija y presentable en el display LCD, es decir, se agregan saltos de línea y detalles de
formato.
La capa de Servicios Web, por definición, expone la funcionalidad del sistema hacia la aplicación
web y smartphone. Internamente, está compuesta por dos subcapas: La primera, interfaz del
servicio (Listener), que efectivamente envía y recibe datos hacia y desde el exterior y la segunda,
metadata, que expone información necesaria para que los sistemas externos sepan cómo está
estructurada la capa de servicios y así poder consumirla. En este caso, por ser servicios web, la
interfaz del servicio está basada en protocolo HTTP y la metadata está descrita en un archivo
JSON.
ARQUITECTURA DE APLICACICONES DE SOFTWARE EMBEBIDO EN MICROCONTROLADOR…. 48
La capa de lógica de negocio nuevamente se divide en varios componentes que dan soporte a las
funcionalidades del sistema. Para este enunciado en particular, no hay variaciones en la cantidad
de capas y todas cumplen las mismas funcionalidades que tienen por definición, al igual que las
capas transversales.
Vista Lógica.
En esta sección se muestra la vista lógica (Figura 10) de la arquitectura. En las secciones
siguientes se explican por separado las relaciones entre los componentes más importantes.
A. Capa Lógica.
En esta sección se explica la relación entre las capas de interface, control, modelo y las capas de
abstracción del sistema (System Abstraction Layer) (Figura 10).
En este escenario, la capa de interface debe implementar la funcionalidad de mostrar los datos el
visor LCD, para ello se apoya en la clase de publicación de contenido ( publisher content), clase
que es usada por la clase principal de aplicación (Application) que a su vez en llamada por el
ARQUITECTURA DE APLICACICONES DE SOFTWARE EMBEBIDO EN MICROCONTROLADOR…. 49
B. Capa de Hardware.
En esta sección se explica la relación entre las capas de abstracción del hardware (System
Abstraction Layer) Figura 11.
Todos los componentes del hardware tienen una abstracción en una capa de software que los
representa, a pesar que el fabricante de las tarjetas para IOT liberan librerías para acceder al
hardware, las librerías cubren solo una parte que corresponde al uso de la electrónica sin
adentrarse en temas de ingeniería, sino que se limitan a lo puntal, es por ello que la arquitectura
de referencia propone una capa de abstracción para cada uno de los componentes y recursos de
tal forma que permita una construcción de software escalable y mantenible.
Para ello podemos observar en la capa de hardware que se define una clase DeviceMeasuring que
representa el dispositivo con todas sus partes, se sugiere una implantación de esta clase con un
ARQUITECTURA DE APLICACICONES DE SOFTWARE EMBEBIDO EN MICROCONTROLADOR…. 51
patrón builder que permita construir dinámicamente el dispositivos con todos sus componentes
basado en una configuración definida, se definen alguna generalizaciones para los sensores y los
puertos de comunicación, las cuales pueden ser implementadas con factorías.
También se puede observar que la clase Aplicación (ApplicationMeasuring), es la encargada de
comunicarse con la clase que gestiona la lógica del hardware ( DeviceMeasuring) de tal forma
que se separen las responsabilidades y se pueda implementar soluciones escalables.
Con base en lo anterior se puede observar la implementación de la arquitectura en concreto para
el hardware con base en lo expuesto en el numeral 3.3.5.4 Capas y patrones.
Vista de Procesamiento.
En esta sección se muestran las diferencias principales entre la vista de procesamiento de la
arquitectura de referencia y la concreta.
Al contrario de la vista lógica, la vista de procesamiento considera los requerimientos no
funcionales, como rendimiento y disponibilidad. Esta vista estudia el procesamiento de datos
desde el punto de vista de los sistemas distribuidos, abarcando cuestiones de concurrencia e
integridad, como así también cuestiones de comunicación. Sin embargo, para esta arquitectura se
adopta a la vista de procesamiento como un medio para especificar los algoritmos que se utilizan
ARQUITECTURA DE APLICACICONES DE SOFTWARE EMBEBIDO EN MICROCONTROLADOR…. 52
para ofrecer la funcionalidad requerida. Para documentar esta vista se optó por el uso de
diagramas de actividades UML.
El diagrama de la figura 12 muestra el flujo de datos al atender una petición realizada por el
usuario. El comienzo del flujo lo da únicamente listener encargado de recibir la petición y pasarla
al interpretador de comando CLI para que este decida si la acepta o rechaza, en cuyo caso al ser
aceptada el controlador frontal (Listener), le pedirá a la aplicación que invoque el comando
(servicio) que podrá ejecutar la petición entregándole los parámetros pertinentes enviados por el
peticionario. El resto del algoritmo sigue tal como está descrito en la arquitectura de referencia.
Las capas de software que hacen la abstracción del hardware, en el diagrama no han sido
implementadas, estas hacen referencia a la capa de hardware (Hardware Layer).
Tal como se muestra en vista lógica (figura 12) la clase Aplicación (ApplicationMeasuring), se
encargara de interactuar con la clase del hardware (DeviceMeasuring) quien a su vez usara las
demás clases que abstraen la lógica de los elementos del hardware.
Figura 12. Diagrama de Actividad UML para la interpretación de una petición de usuario o sistema externo.
ARQUITECTURA DE APLICACICONES DE SOFTWARE EMBEBIDO EN MICROCONTROLADOR…. 53
Vista Física.
Esta vista representa cómo se distribuyen los componentes entre los distintos nodos del sistema.
En otras palabras, se ubica cada parte del software en un nodo, de forma tal que se mapeen
software y hardware.
La figura 13 muestra la vista física de la arquitectura concreta. La vista comienza con el usuario
realizando peticiones al objeto inteligente a través de la aplicación web o smartphone. En el
sistema embebido se encuentran el display LCD y la capa interface serial y web atendida por el
listener, que resuelven las peticiones generadas por el entorno. Básicamente, la aplicación de
Medición es quien interviene en todos los procesos tanto de negocio como de hardware, se
evidencia claramente la implementación de las capas de abstracción del hardware que interactúan
con los recursos físicos (sensores reales), en este caso se trata de los sensores de humedad y
temperatura que son interrogados por la aplicación a través del hardware y los datos publicados
ya sea en el visor LCD del dispositivo o a través del publicador de contenido.
IX. EVALUACION
Evaluación
El proceso de evaluación de la arquitectura propuesta se divide en tres partes, a) identificación de
un método o metodología orientada a la evaluación de arquitecturas de software, b)
caracterización del escenario de evaluación y c) definición de las variables a evaluar o medir en
la captura de datos desde los Microcontroladores.
La disponibilidad permite medir capacidad de uso y ejecución del software desarrollado durante
intervalos de tiempo (un mes). Por ejemplo, en el caso de estudio, se evaluó la captura de datos
agro climáticos.
Durante este periodo, el software presentó estabilidad y seguridad. Lo que permitió concluir que
la arquitectura propuesta provee el atributo de calidad en el sentido de la disponibilidad.
Estos resultados nos permitieron concluir que la arquitectura propuesta cumple con los requisitos
de calidad propuestos.
Disponibilidad
El atributo fue abordado des de la perspectiva de poder tener los dispositivos de captura con la
mayor cantida de tiempo realizando la captura.
Los escenarios planteados para la evaluación :
Escenario 1 : Fallos en la conexión de datos, fue definida como de alto impacto debido a
que esto impediría el envio de los datos al servicio web.
Seguridad
El atributo de seguridad fue abordado desde la perspectiva de la fiabilidad y credibilidad del dato
capturado.
Escenario 1 : Fallo en la captura del dato.
Rendimiento
El redimiento fue abordado como el paralelismo para captura varias variables en un mismo
instante de tiempo.
Escenario 1 : Fallo en transmisión.
Modificabilidad
El atributo se define en esta arquitectura como la capacidad de quitar o poner capaz para hacer
escalable el software, se aborda una escalabilidad horizontal entendida como la facilidad de
adicionar elementos de lectura ( sensores ) y actuadores al software.
ARQUITECTURA DE APLICACICONES DE SOFTWARE EMBEBIDO EN MICROCONTROLADOR…. 57
C. Escenarios de Evaluación.
Los escenarios que se plantean para la evaluación, están orientados a la captura en tiempo real de
datos agro-climáticos, los datos tomados sirven para la vigilancia y control de variables como
temperatura y humedad, niveles de UV, luminosidad, velocidad y dirección de vientos, emisiones
de CO2, NOX, O2, calidad del agua ( PH y Turbidez) y ruido. Con el ánimo de realizar la
evaluación se plantea un estudio de caso para captura de variables análogas usando micro-
controladores de 32 bits, con arquitectura RISC y envió información a internet haciendo uso de
conexión GSM(GPRS).
Para el desarrollo de la evaluación en concreto, se desarrolló un software haciendo uso de la
arquitectura planteada, para la captura y vigilancia de variables de temperatura, humedad relativa
y cantidad de agua colectada en el proyecto “Implementación de un prototipo tecnológico
ARQUITECTURA DE APLICACICONES DE SOFTWARE EMBEBIDO EN MICROCONTROLADOR…. 58
La captura de agua de niebla es una práctica que se viene desarrollando en sur américa desde los
años 60 [52] y es Chile pionero en el uso de colectores de agua, debido a que una crisis hídrica en
la ciudad de Antofagasta incentivó la investigación de soluciones alternativas para el
abastecimiento de agua, cuya técnica está basada en el uso de telas de materiales sintéticos los
cuales son instaladas sobre pilares de un material resistente y templadas en contra de las corriente
de aire cargada de agua en estado gaseoso (vapor de agua).
Para la investigación desarrollada por el CLEM – SENA, que pretendía concluir, basado en un
prototipo colector de agua de niebla con diseño propio, cuál de 3 tipos de fibras distintas usadas
en diferente colectores, sería la más eficiente colectando agua. Con el propósito de poder registrar
con mayor exactitud los datos de las variables definidas por los investigadores en cada colector
de agua, como la temperatura, humedad relativa y cantidad de agua colectada, se instalaron 18
colectores de agua en los cuales 10 de ellos se ubicaron dispositivos como los nombrados en el
numeral 4.2. Los datos fueron usados para construir las curvas de comportamiento de la cosecha
ARQUITECTURA DE APLICACICONES DE SOFTWARE EMBEBIDO EN MICROCONTROLADOR…. 60
de agua que permitían visualizar, las horas en las cuales eran más eficientes cada fibra (tela) a
determinada humedad y temperatura.
Los datos fueron tomados por un sensor DHT22, este dispositivo se compone de un sensor
capacitivo y de un termistor para medir la humedad. Funcionan con ciclos de operación de
duración determinada. Está diseñado para medir temperaturas entre -40 y 80°C con una precisión
de ±0.5°C y para medir humedad entre 0% y 100% con una precisión de 2% [53] y para el
cálculo del nivel de agua se utilizó un sensor de ultrasonido SRF05 diseñado para medir
distancias entre 3cm y 400 cm, distancia que permitirá identificar la altura del agua dentro de un
tanque de 200 litros y con ello poder, aplicando algoritmos, calcular el volumen del agua
colectada dentro del mismo.
En la Figura. 16 se presentan los datos de un periodo de 2 meses promedio mes para las variables
humedad y temperatura y volumen de agua colectada (cosechada, litros de agua), durante las
horas (entre 5 p.m. y 8 a.m.) donde la niebla circulante inicia su recorrido por la zona donde están
ubicados los colectores en Montañitas corregimiento del municipio de Yumbo Valle del Cauca
Colombia, ubicado a 17 kilómetros de la cabecera municipal, sobre la cordillera occidental, a una
altura de 1500 mts sobre el nivel del mar; con temperatura promedio entre 19°C y 23°C según lo
definido en [51], su clima es cálido-húmedo tropical y se caracteriza por vientos provenientes del
pacifico Colombiano los cuales llegan cargados de agua condensada en forma de niebla
circulante no estacionaria; tiene una temperatura promedio de 27 grados Celsius en el día y
durante la noche baja a un promedio entre 16°C y 5°C grados Celsius, con una humedad relativa
promedio entre 80% y 100%. Tal como se ve en la figura 5, el volumen de agua colectada es de
87 litros por día, y la temperatura llega a su nivel más bajo (13. C) y la humedad alcanza su nivel
más alto (99%). El agua colectada tiene unos altos niveles de pureza y bajo niveles de minerales
debido a que es agua de niebla, y esta podrá ser usada para uso doméstico y la agricultura.
ARQUITECTURA DE APLICACICONES DE SOFTWARE EMBEBIDO EN MICROCONTROLADOR…. 61
Los prototipos colectores de agua de niebla, en la figura 17, son construidos con fibras que
capturan el agua y la investigación intenta resolver la pregunta ¿Cuál es la fibra más eficiente en
la captura de agua?, para lo cual se usaron Fibras ZARAN, RACHET y POLISOMBRA, es por
esto que toma gran importancia las mediciones en tiempo real para poder concluir con base en la
data.
Figura 17. Montaje de los colectores de agua de niebla con dispositivo de captura.
A. Resultados Obtenidos.
De acuerdo a la data entregada por los dispositivos en sitio como se muestra en la Figura 18,
información que hace referencia a los colectores con la fibra ZARAN, el volumen de agua
recolectada por cada colector en promedio diario es de 87 litros.
También en la data colectada, se pudo observar, que para los colectores cuya fibra usada es
RACHET, a pesar que también tiene alta eficiencia, no fue superada el agua colectada con
respecto a la fibra ZARAN, el promedio en el mismo periodo de tiempo tomado como medición
de los colectores con RACHET, fue de 65 litros diarios tal como lo muestra la Figura 18.
ARQUITECTURA DE APLICACICONES DE SOFTWARE EMBEBIDO EN MICROCONTROLADOR…. 62
De otro lado con respecto a la fibra POLISOMBRA, se pudo evidenciar con la data, como lo
muestra la figura 18, que su promedio diario fue de 48 litros, siendo esta la menos eficiente en
comparación con las 2 fibras anteriores, tal como se puede observar en la figura 18.
También se puedo concluir con base en las mediciones y uso de la arquitectura que a pesar que
tanto la humedad y temperatura en los tres tipos de colector tienen un comportamiento similar, el
factor determinante para la colecta de agua está dado por la fibra utilizada en cada caso, siendo
este el factor crítico de éxito en la implementación de este tipo de tecnología.
X. CONCLUSIONES
REFERENCIAS
[1] R. Greenberg, “Using Innovation and Technology to Improve City Services,” pp. 1–61,
2015.
[2] N. BRYANT , CHRISTOPHER L., GANDHI, “Real-time data acquisition and control
system for the measurement of motor and neural data,” 2015.
[3] L. Atzori, A. Iera, and G. Morabito, “The Internet of Things: A survey,” Comput.
Networks, vol. 54, no. 15, pp. 2787–2805, 2010.
[4] O. Zeleznik and Z. Havlice, “Knowledge Based Embedded System Modeling With Real-
Time Response Requirements,” Int. J. Comput. Theory Eng., vol. 4, no. 1, pp. 103–111,
2012.
[5] K. Ashton, “That ‘Internet of Things’ Thing,” RFiD J., p. 4986, 2009.
[6] B. Dorsemaine, J. P. Gaulier, J. P. Wary, N. Kheir, and P. Urien, “Internet of Things: A
Definition and Taxonomy,” Proc. - NGMAST 2015 9th Int. Conf. Next Gener. Mob. Appl.
Serv. Technol., no. July, pp. 72–77, 2016.
[7] G. J. Lipovski, “Introduction to Microcontrollers,” Introd. to Microcontrollers, pp. 379–
414, 2004.
[8] M. J. Pont, “Programming Embedded Systems II,” pp. 2002–2004, 2004.
[9] A. Massa and M. Barr, “Programming Embedded Systems,” O`Reilly Media, 2006.
[10] R. Feynman, “Programming Embedded Systems , Second Edition with C and GNU
Development Tools,” pp. 1–288, 2007.
[11] M. Bauer, M. Boussard, N. Bui, F. Carrez, P. Giacomin, S. Haller, E. Ho, C. Jardak, J. De
Loof, C. Magerkurth, S. Meissner, A. Nettsträter, A. Olivereau, A. Serbanati, M. Thoma,
and J. W. Walewski, “Introduction to the Architectural Reference Model for the Internet of
Things,” Internet-of-Things Archit. – IoT-A Deliv. D1.3 – Updat. Ref. Model IoT v1.5,
2012.
[12] P. Misra, Y. Simmhan, and J. Warrior, “Towards a Practical Architecture for the Next
Generation Internet of Things,” Arxiv, no. 7, pp. 1–6, 2015.
[13] J. Holler, V. Tsiatsis, C. Mulligan, S. Avesand, S. Karnouskos, and D. Boyle, From
Machine-to-Machine to the Internet of Things: Introduction to a New Age of Intelligence,
2014th ed. MA: Elsevier B.V., 2014.
[14] J. Carretero and J. D. García, “The Internet of Things: connecting the world,” Pers.
Ubiquitous Comput., vol. 18, no. 2, pp. 445–447, 2013.
[15] M. Bauer, M. Boussard, N. Bui, and F. Carrez, “Project Deliverable D1.5 – Final
Architectural Reference Model for IoT,” no. 257521, pp. 53–59, 2013.
[16] Microsoft, Microsoft Patterns & Practices Team, 2da ed. Microsoft, 2009.
[17] J. Gubbi, R. Buyya, and S. Marusic, “Internet of Things (IoT): A Vision, Architectural
Elements, and Future Directions,” no. 1, pp. 1–19.
[18] J. Holler, From machine-to-machine to the internet of things introduction to a new age of
intelligence. .
[19] L. Bass, P. Clements, and R. Kazman, Software Architecture in Practice, vol. 2nd. 2003.
[20] F. Bushmann, R. Meunier, and H. Rohnert, “Pattern-oriented software architecture: A
system of patterns,” John Wiley&Sons, vol. 1, p. 476, 1996.
[21] P. Clements and D. Garlan, “Software Architectures,” no. November 2001, pp. 1–6, 2002.
ARQUITECTURA DE APLICACICONES DE SOFTWARE EMBEBIDO EN MICROCONTROLADOR…. 66
[22] D. Garlan and M. Shaw, “An Introduction to Software Architecture,” Knowl. Creat.
Diffus. Util., vol. 1, no. January, pp. 1–40, 1994.
[23] F. Lakhani and N. Faisal, “Design Patterns : From Architecture to Embedded Software
Development,” Int. J. Comput. Sci. Issues, vol. 12, no. 1, pp. 146–152, 2015.
[24] B. P. Douglass and D. Ph, Real-Time Design Patterns. 1998.
[25] A. Bajpai, “Model View Controller Architecture on Embedded Systems,” no. 1.
[26] V. Eloranta, J. Koskinen, M. Leppänen, and V. Reijonen, “Software Architecture Patterns
for Distributed Embedded Control System.,” EuroPLoP, 2009.
[27] S. Republic, “Software Architectures for Real-time Embedded Applications for
Broadcasting,” Electr. Eng., vol. 10th Inter, pp. 63–70, 2007.
[28] I. Ishaq, D. Carels, G. Teklemariam, J. Hoebeke, F. Abeele, E. Poorter, I. Moerman, and P.
Demeester, IETF Standardization in the Field of the Internet of Things (IoT): A Survey,
vol. 2, no. 2. 2013.
[29] R. Martin, “Design principles and design patterns,” Object Mentor, no. c, pp. 1–34, 2000.
[30] O. Florescu, J. Voeten, and H. Corporaal, “Modelling Patterns for Analysis and Design of
Real-Time Systems,” Econ. Aff., no. July, 2006.
[31] MIT - Massachusetts Institute of TechNology, “Arquitectura de Software,” 2016. [Online].
Available: http://www.sei.cmu.edu/architecture/definitions.html.
[32] P. Clements, “A Survey of Architecture Description Languages,” in Proceedings of the
International Workshop on Software Specification and Design, 1996.
[33] D. Garlan, Software Architecture: A Roadmap, En Anthony Finkelstein (ed.). Press, ACM,
2000.
[34] D. Riehle, “Framework Design A Role Modeling Approach.” Hamburg, 2000.
[35] Ga. D. Shaw, Mary, “Formulations and Formalisms in Software Architecture,” in Lecture
Notes in Computer Science, vol. 1000, Springer-Verlag, Ed. Springer-Verlag, 1995.
[36] D. Garlan, “Next generation software architectures: Recent research and future directions,”
Columbia, 2001.
[37] Z. J, “A Framework for Information Systems Architecture,” IBM Syst. J., 1987.
[38] T. R, “Architectural styles and the design of network-based software architectures,”
University of California, 2000.
[39] V. Kortuem, G., Kawsar, F., Fitton, D., & Sundramoorthy, “Smart objects as building
blocks for the Internet of things,” IEEE Comput. Soc., 2010.
[40] P. Kruntchen, “Architectural blueprints–the” 4+ 1” view model of software architecture,”
IEEE Softw., vol. 12, no. November, pp. 42–50, 1995.
[41] P. Jivani, C. Chopara, and M. Prashant, “Over All Idea about MVC : How to use Model-
View-Controller ( MVC ),” Int. J. Innov. Eng. Technol., vol. 2, no. 1, pp. 391–395, 2013.
[42] S. Sauer and G. Engels, “MVC-Based Modeling Support for Embedded Real-Time
Systems,” OMER Work., pp. 11–14, 1999.
[43] R. Khadse, N. Gawai, and B. M. Faruk, “Overview and Comparative Study of Different
Microcontrollers,” vol. 2, no. Xii, pp. 311–315, 2014.
[44] D. Hercog and B. Gergi??, “A flexible microcontroller-based data acquisition device,”
Sensors (Switzerland), vol. 14, no. 6, pp. 9755–9775, 2014.
[45] N. Kumari, N. Patel, S. Anand, and P. P. Bhattacharya, “Designing Low Power Wireless
Sensor Networks : A Brief Survey,” pp. 4447–4456, 2013.
[46] P. Clements and R. Kazman…, “Evaluating software architectures: methods and case
ARQUITECTURA DE APLICACICONES DE SOFTWARE EMBEBIDO EN MICROCONTROLADOR…. 67
studies .” .
[47] A. Patidar and U. Suman, “A survey on software architecture evaluation methods,” vol.
49, no. 16, pp. 967–972, 2015.
[48] J. Liu, Y. Li, M. Chen, W. Dong, and D. Jin, “Software-defined internet of things for smart
urban sensing,” IEEE Commun. Mag., vol. 53, no. 9, pp. 55–63, 2015.
[49] I. Ganchev and M. O’Droma, “A Generic IoT Architecture for Smart Cities,” 25th IET
Irish Signals Syst. Conf. 2014 2014 China-irel. Int. Conf. Inf. Communities Technol. (ISSC
2014/CIICT 2014), pp. 196–199, 2014.
[50] Vaisala, “Las mediciones climáticas en los invernaderos garantizan un óptimo crecimiento
de las plantas,” p. 2, 2013.
[51] CVC, “Distribución y Analisis Espacial de la variables Climatológicas Medidas en el
Valle,” Corporación Autonoma Regional del Valle del Cauca CVC, 2015. [Online].
Available:
http://www.cvc.gov.co/cvc/RecursoHidrico/aplicativos/Climatologia/Eva_Brillo_MultiVal
le.php. [Accessed: 01-Jan-2016].
[52] R. Román, “Obtención de agua potable por métodos no tradicionales,” Cienc. Al Día Int.,
vol. 2, no. 2, pp. 1–13, 1999.
[53] A. Ashley and A. Aliana, “Automatización De Bajo Costo Utilizada En La Producción
Agrícola En Invernaderos Y Huertos Caseros,” no. 13, pp. 1–9, 2015.