-
Arquitectura de Aplicaciones de Software Embebido en Micro
Controladores para Tarjetas de
Captura de Datos de la IOT.
José Fernando Mendoza Ibarra , [email protected]
Tesis de Maestría presentada para optar al título de Magíster en
Ingeniería de Software
Asesor: Hugo Armando Ordoñez Eraso Doctor (PhD) en Ingeniería
Telemática
Universidad de San Buenaventura Colombia
Facultad de Ingeniería
Maestría en Ingeniería de Software
Santiago de Cali, Colombia 2018
-
Citar/How to cite [1]
Referencia/Reference
Estilo/Style:
IEEE (2014)
[1] J. Mendoza, “Arquitectura de Aplicaciones de Software
Embebido en Micro
Controladores para Tarjetas de Captura de Datos de la IOT”,
Tesis Maestría en
Ingeniería de Software, Universidad de San Buenaventura Cali,
Facultad de
Ingeniería, 2018..
Bibliotecas Universidad de San Buenaventura
Biblioteca Fray Alberto Montealegre OFM - Bogotá.
Biblioteca Fray Arturo Calle Restrepo OFM - Medellín, Bello,
Armenia, Ibagué.
Departamento de Biblioteca - Cali.
Biblioteca Central Fray Antonio de Marchena – Cartagena.
Universidad de San Buenaventura Colombia
Universidad de San Buenaventura Colombia -
http://www.usb.edu.co/
Bogotá - http://www.usbbog.edu.co
Medellín - http://www.usbmed.edu.co
Cali - http://www.usbcali.edu.co
Cartagena - http://www.usbctg.edu.co
Editorial Bonaventuriana -
http://www.editorialbonaventuriana.usb.edu.co/
Revistas - http://revistas.usb.edu.co/
Biblioteca Digital (Repositorio)
http://bibliotecadigital.usb.edu.co
-
Dedicatoria
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.
Deuda de gratitud para ellos.
Gracias.
-
TABLA DE CONTENIDO
RESUMEN
.......................................................................................................................................
9
I. INTRODUCCION
......................................................................................................................
11
II. PLANTEAMIENTO DEL PROBLEMA
..................................................................................
14
III. JUSTIFICACIÓN
.....................................................................................................................
15
IV. OBJETIVOS
............................................................................................................................
16
A. Objetivo general
....................................................................................................................
16
B. Objetivos específicos
.............................................................................................................
16
V. RESULTADOS OBTENIDOS
.................................................................................................
17
VI. MARCO TEÓRICO
.................................................................................................................
19
Trabajos Relacionados.
..............................................................................................................
19
VII. ARQUITECTURA DE SOFTWARE
....................................................................................
22
A. Importancia de la Arquitectura de Software .
........................................................................
22
B. Definición de Atributos de Calidad.
......................................................................................
23
C. Estilos de Arquitectura.
.........................................................................................................
23
D. Frameworks y Vistas.
............................................................................................................
24
E. Internet de la Cosas.
...............................................................................................................
25
F. Dispositivos Inteligentes.
.......................................................................................................
25
G. Arquitectura de Software IOT.
..............................................................................................
26
H. Nivel Arquitectural Propuesto.
..............................................................................................
29
1. Arquitectura de Software.
...................................................................................................
29
2. Micro-Controlador.
.............................................................................................................
29
3. Caracterización de los MicroControladores.
.......................................................................
31
4. Soluciones IOT.
..................................................................................................................
33
I. Arquitectura de Software Propuesta.
......................................................................................
33
-
1. Atributos Arquitectónicos.
..................................................................................................
35
2. Requisitos Funcionales.
......................................................................................................
35
3. Estilo Arquitectónico.
.........................................................................................................
36
4. Patrones de Arquitectura vs Capas.
....................................................................................
36
5. Vista General de la Arquitectura.
........................................................................................
39
6. Capa de Abstracción del Sistema (Hardware).
...................................................................
40
7. Relación entre los componentes.
.........................................................................................
41
8. Vista Lógica.
.......................................................................................................................
41
9. Vista Física.
.........................................................................................................................
42
VIII. APLICACIONES
..................................................................................................................
45
Ejemplo Práctico
........................................................................................................................
45
A. Problema Propuesto en caso de estudio
.............................................................................
45
B. Solución Planteada
.............................................................................................................
46
Vista General
..............................................................................................................................
46
Arquitectura Detallada.
..............................................................................................................
47
Vista Lógica.
..............................................................................................................................
48
A. Capa Lógica.
......................................................................................................................
48
B. Capa de Hardware.
.............................................................................................................
50
Vista de Procesamiento.
.............................................................................................................
51
Vista Física.
................................................................................................................................
53
IX. EVALUACION
.......................................................................................................................
54
Evaluación
..................................................................................................................................
54
A. Evaluando la Arquitectura Propuesta.
................................................................................
54
B. Priorización de Atributos y Escenarios ATAM para validación
........................................ 55
C. Escenarios de Evaluación.
..................................................................................................
57
-
A. Resultados Obtenidos.
........................................................................................................
61
X. CONCLUSIONES
.....................................................................................................................
63
Conclusiones y trabajos futuros
.................................................................................................
63
REFERENCIAS
.............................................................................................................................
65
-
LISTA DE TABLAS
Tabla I. Generacion De Nuevo Conocimiento Y Desarrollo
Tecnologico .................................... 17
Tabla II. Fortalecimiento De La Comunidad Cientifica
................................................................
17
Tabla III. Apropiacion Social Del Conocimiento Involucrado En El
Desarrollo De La
Investigacion
..........................................................................................................................
17
Tabla IV. Frameworks De Arquitectura
.........................................................................................
24
Tabla V. Caracterizacion De Los Microcontroladores
...................................................................
31
-
LISTA DE FIGURAS
Figura 1. Harvard Microcontroller Architecture
............................................................................
30
Figura 2. Diagrama de Componentes de una tarjeta de la IoT.
..................................................... 31
Figura 3. Arquitectura de Referencia en el diseño
arquitectónico. ................................................
34
Figura 4. Capas y Componentes de la arquitectura propuesta.
..................................................... 37
Figura 5. Vista Lógica de la Arquitectura Propuesta.
....................................................................
42
Figura 6. Modelo Orientado a Servicios de un sistema embebido en
la IOT. ............................... 43
Figura 7.Vista Física de la Arquitectura de Referencia.
................................................................
44
Figura 8. Vista de la Arquitectura Concreta.
..................................................................................
47
Figura 9. Vista de la Arquitectura detallada.
..................................................................................
48
Figura 10. Vista Lógica de la Arquitectura detallada.
....................................................................
50
Figura 11. Vista Lógica de la Arquitectura detallada (Hardware
Layer). ...................................... 51
Figura 12. Diagrama de Actividad UML para la interpretación de
una petición de usuario o
sistema externo.
......................................................................................................................
52
Figura 13. Vista Física de la Arquitectura detallada.
.....................................................................
53
Figura 14. Priorización de Atributos y Escenarios de Validación.
................................................ 57
Figura 15. Visualización del Comportamiento de la Variable
Tempera en la Aplicación Móvil. . 59
Figura 16. Visualización del Comportamiento de la Variable
Temperatura vs Humedad vs
Volumen.
................................................................................................................................
61
Figura 17. Montaje de los colectores de agua de niebla con
dispositivo de captura. ..................... 61
Figura 18. Agua Colectada Vs Hora del día por fibra.
...................................................................
62
-
ARQUITECTURA DE APLICACICONES DE SOFTWARE EMBEBIDO EN
MICROCONTROLADOR…. 9
RESUMEN
Esta investigación de tesis en maestría presenta una propuesta
de modelo de arquitectura de
software para el desarrollo de aplicaciones que se ejecutan en
microcontroladores sobre tarjetas
de captura de datos para la IOT, la arquitectura de software
explica la estructura, funcionamiento
e interacción de los diferentes componentes del software y no se
centra en algoritmos ni
estructuras de datos, muestra el diseño y especificación global
del sistema.
La propuesta muestra los componentes y subcomponentes de la
arquitectura de software y plantea
una alternativa de modelamiento arquitectónico para la escritura
de aplicaciones, teniendo en
cuenta los diferentes componentes de hardware tales como
memoria, procesamiento entradas y
salidas de datos, logrando un desarrollo de aplicaciones
modulares y parametrizables.
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
Keywords: Microcontrollers, Software Architecture, Internet od
Things, IOT, Smart Cities
-
ARQUITECTURA DE APLICACICONES DE SOFTWARE EMBEBIDO EN
MICROCONTROLADOR…. 11
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
sitios distintos al de su captura.
Los micro-controladores han existido desde mucho tiempo atrás y
han sido utilizados en tareas
tanto específicas como generales, el desarrollo de los mismos ha
dado origen a grandes
soluciones hardware las cuales han originado desarrollos
tecnológicos que han aportado de la
misma manera al crecimiento y evolución tanto de la ciencia como
de la tecnología.
El micro-controlador, en un ámbito general, es el elemento
hardware capaz de realizar todos las
operaciones aritmético-lógicas que permiten capturar, procesar y
entregar los resultados para los
cuales son programados, en ese sentido, es donde aparece el
desarrollo de software como
complemento para poder tener una solución integra, robusta,
eficiente y capaz de resolver un
problema en particular. Es entonces donde entra a ser parte
fundamental el modelado
arquitectónico de las aplicaciones que se ejecutan en los
micro-controladores. Ahora bien, poder
encontrar una arquitectura para desarrollo de software embebido
en micro-controladores que sea
una referencia, y que permita al equipo de desarrolladores
centrarse en la implementación de la
misma y de la lógica de negocio, no ha sido una tarea fácil, la
literatura se enfoca en tratar
aspectos de patrones y ligeras iniciativas sin entrar en detalle
de una arquitectura como tal.
En la actualidad, la mayoría de las soluciones IoT se enfocan en
campos específicos y utilizan
dispositivos y tecnologías particulares [3]. Esta situación
redunda en soluciones con arquitecturas
específicas del dominio con poca capacidad de integrarse o
replicarse [10]. En este orden de
ideas, en la práctica ha sido difícil unificar una arquitectura
de software para la construcción de
sistemas embebidos para IoT [3][11][12][13].
En ese contexto, la propuesta está direccionada a definir una
arquitectura para aplicaciones
embebidas que permita la interacción entre el software que se
ejecuta en el micro-controlador y el
resto de componentes hardware que cohabita en las tarjetas
electrónicas de captura de datos,
teniendo en cuenta que algunas de estas tarjeta son de propósito
general y otras de propósito
específico.
La arquitectura propuesta va más allá del ámbito de la tarjeta
del sistema y propone un
modelamiento genérico de la solución software completa que se
ejecuta en el micro-controlador.
Igualmente incluye las diferentes capas de software de la
aplicación a desarrollar. La arquitectura
busca servir de marco para el desarrollo de soluciones software
escalables y mantenibles que se
ejecuten en micro-controladores en tarjetas para la captura de
datos de soluciones para IoT.
-
ARQUITECTURA DE APLICACICONES DE SOFTWARE EMBEBIDO EN
MICROCONTROLADOR…. 13
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
II. PLANTEAMIENTO DEL PROBLEMA
En la actualidad, se desarrollan soluciones para problemas
específicos para la Internet de la cosas
(Internet of the things ó IOT [5]), con dispositivos
particulares o una tecnología en particular [3],
lo cual termina en aplicaciones específicas con arquitecturas de
software específicas con poco
lugar para interactuar con otros sistemas [11]. En ese ámbito se
detecta esta problemática en
varios trabajos [3],[14],[15],[12], no se han identificado
arquitecturas de software prácticas y
concretas para la construcción de sistemas embebidos que puedan
ser integrados al ecosistema
del Internet de las Cosas [16]. En [17],[18], se propone un
modelo arquitectónico de referencia,
desde dispositivos físicos hasta el consumo y análisis de datos
en las capas superiores
(aplicación), es decir en las aplicaciones que usaran los datos,
modelo mediante el cual a través
de algunos requerimientos se puede obtener una arquitectura
concreta. Sin embargo, si bien los
autores identifican a los dispositivos como sistemas embebidos
que interactúan entre el mundo
digital y el físico, conectando entidades físicas del mundo real
a internet, el modelo no contempla
ni define qué arquitectura o qué componentes debe tener el
software de un sistema embebido para
que pueda formar parte de un ecosistema del Internet de las
Cosas [11].
-
ARQUITECTURA DE APLICACICONES DE SOFTWARE EMBEBIDO EN
MICROCONTROLADOR…. 15
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.
El desarrollo de esta tesis en Maestría “Arquitectura de
Aplicaciones de Software Embebido en
Micro Controladores para Tarjetas de Captura de Datos de la
IOT”, presenta una propuesta de un
modelo arquitectónico validado que permite desarrollar
soluciones software que se ejecuten en
micro-controladores, con una estructurada definida y
generalizada, capaz de satisfacer los
requisitos funcionales y de calidad, y que al mismo tiempo
permite tener soluciones de software
robustas que hagan parte del ecosistema de la IOT.
-
ARQUITECTURA DE APLICACICONES DE SOFTWARE EMBEBIDO EN
MICROCONTROLADOR…. 16
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
1. Definir los componentes arquitectónicos que soportarán la
arquitectura.
2. Diseñar una arquitectura de software que satisfaga los
requisitos funcionales de un
producto software embebido
3. Evaluar la arquitectura a través de un estudio de caso,
aplicado en el desarrollo de
software embebido para tarjetas de captura de datos
agro-climáticos.
-
ARQUITECTURA DE APLICACICONES DE SOFTWARE EMBEBIDO EN
MICROCONTROLADOR…. 17
V. RESULTADOS OBTENIDOS
A continuación se describe los resultados obtenidos en esta
investigación con relación a:
Tabla 1. Generación de nuevos conocimientos y desarrollos
tecnológicos.
Tabla 2. Fortalecimiento de la comunidad científica
nacional.
Tabla 3. Apropiación social del conocimiento involucrado en el
desarrollo de la
investigación.
En cada uno de los tipos de resultados obtenidos se definen los
resultados, el indicador o los
beneficiarios de los mismos.
TABLA I. GENERACION DE NUEVO CONOCIMIENTO Y DESARROLLO
TECNOLOGICO
Resultados Indicador
Una Arquitectura propuesta para
desarrollo de software embebido
en microcontroladores de tarjetas
para internet de las cosas.
Documento de tesis de maestría, trabajos en
eventos nacionales e internacionales y revistas.
TABLA II. FORTALECIMIENTO DE LA COMUNIDAD CIENTIFICA
Resultados Beneficiarios
Formación de talento humano a
nivel Tecnológico – Especialización
Sena.
40 aprendices del Centro de Electricidad y
Automatización Industrial Diplomado de
desarrollo Móvil con integración de
dispositivos electrónicos para la IOT del
Sena Regional Valle.
TABLA III. APROPIACION SOCIAL DEL CONOCIMIENTO INVOLUCRADO EN EL
DESARROLLO
DE LA INVESTIGACION
Resultados Indicador
Dos artículos en eventos y
publicaciones internacionales en
temáticas directamente relacionadas
1. J. Mendoza, H. Ordoñez, A. Ordoñez.
“Architecture for embedded software in
-
ARQUITECTURA DE APLICACICONES DE SOFTWARE EMBEBIDO EN
MICROCONTROLADOR…. 18
con el proyecto de investigación. microcontrollers for Internet
of Things
(IoT) in fog water collection”. 8th
International Conference on Ambient
Systems, Networks and Technologies,
ANT-2017 and the 7th International
Conference on Sustainable Energy
Information Technology, SEIT 2017, 16-
19 May 2017, Madeira, Portugal. Artículo
publicado en Procedia Computer Science
109C (2017) 1092–1097
www.elsevier.com/locate/procedia ó
https://www.sciencedirect.com/science/art
icle/pii/S1877050917310700.
2. J. F. Mendoza, H. Ordóñez, A. Ordóñez,
R. P. C. do Nascimento. “Software
Architecture for IoT Microcontrollers
with Emphasis on Agroclimatics Data
Capture”. IEEE Latinoamerica, 2017
http://www.elsevier.com/locate/procedia
-
ARQUITECTURA DE APLICACICONES DE SOFTWARE EMBEBIDO EN
MICROCONTROLADOR…. 19
VI. MARCO TEÓRICO
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.
En [24] es expuesta la importancia de la arquitectura de
software en los sistemas embebidos y
trata temas importantes como son la confiabilidad y la
eficiencia de estos sistemas para que sean
exitosos. De otro lado, le da importancia al papel que juegan
las restricciones técnicas de los
dispositivos al momento de proponer alguna arquitectura. Esta
propuesta se apoya en UML para
explicar los patrones y expone ejemplos de patrones en una
arquitectura. Sin embargo, esta
propuesta no tiene una postura definida frente a una
arquitectura como tal.
En [25] se plantea una arquitectura MVC
(Modelo-Vista-Controlador), que puede ser
implementada en sistemas embebidos haciendo énfasis en un
dispositivo Lector RFID, el cual se
ejecuta en la plataforma OpenMoko. Esta propuesta describe una
breve ilustración del
funcionamiento del Software, dejando de lado modelo
arquitectónico.
La propuesta presentada en [26] se limita a describir
situaciones presentadas en sistemas de
control con sistema embebidos y sus soluciones, aborda distintos
problemas y plantea soluciones,
a través de patrones de diseño, tales como patrones orientados a
mensajes (publicador/suscriptor),
proxy, blackboard, no se centra en describir ninguna
arquitectura, pero si trata en detalle los
patrones para este tipo de sistemas.
En [27] se describe una arquitectura de software para un sistema
embebido de BroadCasting
(audio e imágenes), muestra ligeramente el detalle algunas capas
arquitectónicas (interface de
usuario, capa de control de procesos del sistema, capa de
gestión recursos del sistema). El
planteamiento de la arquitectura se basa en el documento de
Garlan y Shaw[22]. A pesar de su
intención de hablar en temas de arquitectura de software, la
descripción de la arquitectura y sus
componentes es demasiado general.
-
ARQUITECTURA DE APLICACICONES DE SOFTWARE EMBEBIDO EN
MICROCONTROLADOR…. 21
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
VII. ARQUITECTURA DE SOFTWARE
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í:
La Arquitectura de Software es la organización fundamental de un
sistema embebido en sus
componentes, las relaciones entre ellos y el ambiente y los
principios que orientan su diseño y
evolución.
A. Importancia de la Arquitectura de Software .
El concepto de arquitectura de software (AS) se refiere a la
estructuración del sistema que se crea
en etapas tempranas del desarrollo. Esta estructuración
representa un diseño de alto nivel del
sistema que tiene dos propósitos primarios: satisfacer los
atributos de calidad (desempeño,
seguridad, modificabilidad) [19], y servir como guía en el
desarrollo. El no crear este diseño
desde etapas tempranas del desarrollo puede limitar severamente
el que el producto final satisfaga
las necesidades de los clientes. Además, el costo de las
correcciones relacionadas con problemas
en la arquitectura es muy elevado. Es así, que la arquitectura
de software juega un papel
-
ARQUITECTURA DE APLICACICONES DE SOFTWARE EMBEBIDO EN
MICROCONTROLADOR…. 23
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.
B. Definición de Atributos de Calidad.
Los atributos de calidad son la base para la selección de los
estilos arquitectónicos, y por
consiguiente también la de una AS exitosa, por eso cuando se
inicia con la creación de una AS se
debe realizar un estudio y análisis profundo que permita definir
las calidades sistémicas que
necesita la arquitectura [34].
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
Física Tecnología
Tecnología
Desarrollo Despliegue
Desarrollo Representación Casos de
Uso Casos de Uso
Funcionamiento
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.
G. Arquitectura de Software IOT.
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.
En [11] se propone un modelo arquitectónico de referencia que
provee vistas y perspectivas de
diferentes aspectos arquitectónicos, que son de interés de los
participantes en un proyecto IOT.
En su publicación se menciona que la mayor contribución la da el
Modelo de Referencia que
provee conceptos y definiciones sobre los cuales se pueden
construir arquitecturas IOT. El
modelo de referencia a su vez consiste en tres submodelos:
- 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.
Por último, el Submodelo de Comunicación establece algunos
lineamientos sobre cómo
administrar diversos protocolos de comunicación.
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:
- Descomposición Funcional que hace referencia al proceso
dividir componentes funcionales
- Componentes Funcionales que son los que arman la arquitectura
de referencia
El objetivo principal de la descomposición funcional es la de
utilizar la estrategia “divide y
vencerás” para disminuir la complejidad de la solución en piezas
más pequeñas y comprensibles.
Uno de los resultados que produce la descomposición funcional es
el modelo funcional que es
una forma de representación abstracta de los grupos funcionales
de componentes que integran la
arquitectura de referencia. En el modelo funcional se encuentran
los siguientes grupos
funcionales:
-
ARQUITECTURA DE APLICACICONES DE SOFTWARE EMBEBIDO EN
MICROCONTROLADOR…. 28
- Gestión de Procesamiento: cubre los requerimientos de negocio
respecto la posibilidad de
construir servicios y aplicaciones sobre los servicios de IOT
que se ofrecen.
- Seguridad: cubre cuestiones de confiabilidad, seguridad y
privacidad.
- Gestión: cubre trasversalmente la interacción entre los demás
grupos funcionales.
- 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.
H. Nivel Arquitectural Propuesto.
1. Arquitectura de Software.
La arquitectura de software explica la estructura,
funcionamiento e interacción de los diferentes
componentes del software y no se centra en algoritmos ni
estructuras de datos. Esta arquitectura
muestra el diseño y especificación global del sistema [19].
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.
La arquitectura propuesta utiliza elementos arquitectónicos como
patrones de diseño de software
(singlenton, interfaces, builders, factories, froncontroller,
composition, aggregation) con el fin de
conseguir una fácil implementación del patrón de arquitectura
modelo vista control MVC como
lo referenciado en [41] y [42]. La arquitectura se muestra como
un marco de referencia de alto
nivel y no llega a la especificidad detallada de la
implementación ni de los patrones
arquitectónicos, como tampoco de los distintos componentes que
modelará la arquitectura. La
arquitectura actúa como marco referencia para el desarrollo de
aplicaciones embebidas en micro-
controladores y será en tiempo de programación donde se defina a
nivel algorítmico la
implementación de la misma.
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.
Figura 1. Harvard Microcontroller Architecture
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
Figura 2. Diagrama de Componentes de una tarjeta de la IoT.
3. Caracterización de los MicroControladores.
Como se mencionó antes, los sistemas embebidos tienen como
principal protagonista el
microcontrolador, la importancia de este y sus características
hacen que una solución IoT, tenga
posibilidades múltiples para interactuar con el mundo exterior y
el internet. La Tabla 5, presenta
una variedad de clasificaciones dependiendo de distintas
características de estos elementos
electrónicos.
TABLA V. CARACTERIZACION DE LOS MICROCONTROLADORES
CLASIFICACIÓN DESCRIPCIÓN
Según Bits
8
Puede Procesar datos de 8 bits a la vez, los ejemplos de
Micro-controladores de 8 bits son Intel 8031/8051. Estos se
utilizan en el control de posición, las aplicaciones de control de
velocidad.
16
Tiene mayor precisión y rendimiento en comparación con el de 8
bits. Estos se han desarrollado para el propósito de aplicaciones
de alta velocidad, tales como sistema de control servo, robots etc.
Algunos ejemplos de micro-controlador de 16 bits son Intel 8096 y
el Motorola MC68HC12 y sus familias.
32
Utiliza las instrucciones de 32 bits para realizar las
operaciones aritméticas y lógicas estos se desarrollan con el
propósito de uso en aplicaciones de muy alta velocidad en el
procesamiento de imágenes, telecomunicaciones, sistema de control
inteligente etc. Algunos ejemplos son Intel / 251 Atmel familia,
PIC3x , ARM
Según Ubicación
de la Memoria
Embebida en el Micro-
controlador
La Memoria se encuentra en el mismo micro-controlador y en el
mismo integrado, el programa y los datos están en la misma memoria.
Por ejemplo , el 8051 tiene programa y memoria de datos , puertos I
/ O , la comunicación en serie , contadores y temporizadores e
interrupcines en el mismo chip o integrado.
-
ARQUITECTURA DE APLICACICONES DE SOFTWARE EMBEBIDO EN
MICROCONTROLADOR…. 32
Memoria Externa al
Micro-controrlador
Tiene el programa en una memoria externa, por ejemplo 8031
Según Instruction
Set
CICS CISC significa Complex Instruction Set Computing , que
permite al usuario aplicar 1 instrucción como alternativa a muchas
instrucciones simples
RISC RISC Reduced Instruction Set significa Informatics . RISC
reduce el tiempo de operación por el acortamiento de la ciclo de
reloj por instrucción. El RISC da una mejor ejecución que la
CISC.
Según la Arquitectur
a de Memoria
Harvard Memory
Estos Micro-controladores tienen en el mismo espacio de memoria
los datos y los programas.
Von Neuman & Princetone
Estos Micro-controladores tienen en el mismo espacio de memoria
tanto datos como programas. La memoria externa al micro-controlador
en el mismo integrado.
Según el tipo de
Integrado
8051
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 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.
PIC
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 de
periféricos. Son clasificados como RISC. Una cosa interesante sobre
PIC es que su ciclo de máquina se compone de sólo 4 pulsos de reloj
en contraste 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
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-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.
AVR
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 RISC de Vegard Wollan . AVR toma sólo un
ciclo reloj por instrucción. Se clasifican en TyniAVR, Mega AVR,
XMegaAVR
De acuerdo a [45], la tendencia en los Micro-controladores para
la tarjetas electrónicas de captura
de datos para la IoT, deberían ser de bajo consumo. Esto debido
a que las soluciones que se están
implementando y se visiona implementar estarán en cualquier
sitio donde no necesariamente
tendrá alimentación de una fuente de energía como la red
eléctrica, sino que serán alimentados
por baterías de plomo-acido, gel-acido, níquel-cadmio, entre
otras, y en otros escenarios se usará
-
ARQUITECTURA DE APLICACICONES DE SOFTWARE EMBEBIDO EN
MICROCONTROLADOR…. 33
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].
I. Arquitectura de Software Propuesta.
En función del análisis realizado en el capítulo 1
correspondiente a la Descripción del Problema,
se considera de interés citar nuevamente el problema abierto que
se aborda en este trabajo de
investigación, recordando que el mismo se focaliza en el diseño
de una arquitectura de referencia
-
ARQUITECTURA DE APLICACICONES DE SOFTWARE EMBEBIDO EN
MICROCONTROLADOR…. 34
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).
Figura 3. Arquitectura de Referencia en el diseño
arquitectónico.
Requerimientos Arquitectura de
Referencia
Arquitectura
Concreta
-
ARQUITECTURA DE APLICACICONES DE SOFTWARE EMBEBIDO EN
MICROCONTROLADOR…. 35
Para el planteamiento de la arquitectura, se definieron algunos
elementos importantes como
punto de partida, estos se describen a continuación.
1. Atributos Arquitectónicos.
La definición de los atributos de calidad que se establecen en
la arquitectura de software,
permiten la implementación de los requisitos funcionales / no
funcionales, los atributos como
rendimiento, interoperabilidad, usabilidad, conectividad,
flexibilidad, mantenibilidad, seguridad y
escalabilidad son abordados en [46] y [19]. De la misma forma
estos atributos de calidad
permiten la evaluación de la arquitectura, aplicando alguna
métrica para tal fin. La definición de
atributos de calidad tiene como base el ámbito del problema
(captura y vigilancia en tiempo real
para variables agro-climáticas), seguidamente los requisitos
funcionales y finalmente las
restricciones técnicas. Además de los atributos de calidad, se
abordan atributos intrínsecos a la
arquitectura tales como: la mantenibilidad del software [47],
atributo que permite la
comunicación del equipo de desarrollo, la rápida evolución del
producto y la disminución de los
costos por mantenimiento del mismo, al igual que una mejor
documentación del producto final
[21]. Los atributos de calidad para la evaluación la
arquitectura propuesta se especifican el
numeral IX-B.
2. Requisitos Funcionales.
La arquitectura planteada en la Figura. 4 permite implementar
requisitos funcionales que son
parte de la lógica de negocio en el dominio de la IoT, los
requerimientos aquí planteados fueron
definidos de acuerdo a la revisión del estado del arte y de las
necesidades encontradas en [48]
[11] [49] :
A. El Sistema deberá capturar datos de sensores conectados a
puertos análogos o digitales.
B. El sistema deberá normalizar los datos capturados aplicando
algoritmos de normalización
según sea el caso del sensor.
C. El sistema deberá permitir cambiar el estado (ON/OFF) de un
actuador conectado a un puerto.
-
ARQUITECTURA DE APLICACICONES DE SOFTWARE EMBEBIDO EN
MICROCONTROLADOR…. 36
D. El Sistema deberá permitir conectarse al internet haciendo
uso de comunicación GSM/GPRS,
Wifi ó Ethernet.
E. El sistema deberá permitir él envió de datos capturados a un
sistema remoto utilizando un
protocolo de comunicación definido (HTTP, REST, CoAP, MQTT)
F. El sistema deberá permitir configurarse desde una interface
gráfica móvil o html.
G. El sistema deberá permitir ser consultado o monitoreado desde
comandos externos haciendo
uso de la interfaz serial ó TX/RX.
3. Estilo Arquitectónico.
La arquitectura propuesta es multicapa, y está basada en el
patrón modelo-vista-controlador-
comunicación [19][41], la cual está compuesta por diferentes
capas y componentes
arquitectónicos que dan origen a la arquitectura propuesta. La
arquitectura permite implementar
capas que interactúan con los distintos componentes del
hardware, estas capas son las
abstracciones a nivel de software que representan, tanto la
lógica del negocio como los elementos
del hardware tal como se ve en la Figura 4.
4. Patrones de Arquitectura vs Capas.
La Figura 4, permite visualizar las diferentes capas de software
donde cada uno de los
componentes estará representados en la arquitectura
planteada.
Interface.
La Interface, es la capa que permite la comunicación con el
sistema embebido y el mundo
exterior, implementa un Listener (clase abstracta) encargado de
identificar las peticiones
entrantes, decodificar las ordenes y entregar la responsabilidad
al componente capaz de resolver
la petición (Commands). Esta a su vez implementa componentes
dependiendo del origen de las
-
ARQUITECTURA DE APLICACICONES DE SOFTWARE EMBEBIDO EN
MICROCONTROLADOR…. 37
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).
Figura 4. Capas y Componentes de la arquitectura propuesta.
La sub-capa de comandos (Commands), implementa todas las
acciones (peticiones o eventos)
posibles que pueden llevar se a cabo gracias a las solicitudes
entrantes, y esta acciones a su vez
interactúan con las capa de rutinas propias de la lógica del
dominio o administradores de casos de
uso, tales como captura de datos de temperatura, humedad, ruido,
radiación, luminosidad, entre
otros.
-
ARQUITECTURA DE APLICACICONES DE SOFTWARE EMBEBIDO EN
MICROCONTROLADOR…. 38
Capa de Control.
Controladores de Dominio (Dommain Controllers) ó administradores
de casos de uso, gestionan
la lógica de negocio, de sensores, actuadores, rutinas de
cliente web para consulta de datos en un
servidor remoto y rutinas cuando el dispositivo se comporte como
servidor, en cuyo caso la
aplicación implementará una interface web si es necesario para
la interacción directa entre
usuario y dispositivo vía HTTP.
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.
La Capa del Sistema.
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
La sub-capa de Comunicación implementa los medios de
comunicación (COMMUNICATIONS
SERVICES) que utilizará la tarjeta para interactuar con el medio
exterior (internet) ya sea
para enviar o recibir información, son rutinas de servicio, y
dependiendo de cuál se
implemente cada una tendrá su propia configuración.
La sub-capa COM de bajo nivel para la comunicación, implementa
la interrogación o envió de
datos a los puertos de comunicación análogos o digitales del
micro-controlador, esta
implementación es necesaria para poder interactuar con los
sensores, actuadores u otro
dispositivo externo (mundo físico) que se conecte a la
tarjeta.
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.
5. Vista General de la Arquitectura.
Capa Lógica.
El objetivo de la arquitectura planteada es contemplar los
requerimientos generales (Numeral
VII-I-2 Requisitos funcionales) que deben satisfacer los sistema
embebido IOT. En términos
generales, el sistema embebido interactúan directamente con el
usuario/sistema remoto pero
también lo hacen con otros tipos de hardware como computadores,
dispositivos móviles, es decir,
sistemas externos.
La interacción con el usuario y sistemas externos es claramente
distinta, el usuario pretende
entender lo que el dispositivo le comunica en un lenguaje claro,
natural y comprensible, mientras
que los sistemas externos necesitan otro tipo de lenguajes como
protocolos, estándares y
notaciones, como podrían ser el protocolo HTTP y la notación
JSON. Por este motivo, las capas
más altas de la arquitectura son los extremos de la comunicación
con el usuario y sistemas
externos.
-
ARQUITECTURA DE APLICACICONES DE SOFTWARE EMBEBIDO EN
MICROCONTROLADOR…. 40
La capa de Lógica ( Logic Layer ) controla la entrada y salida
del hardware con dos principales
objetivos:
1) Abstraer al usuario de la complejidad en términos de
electrónica, dado que se trata de un
sistema embebido y
2) Abstraer a las capas inferiores de lo que el usuario ingresa
o espera como respuesta en
términos de formatos. Por ejemplo, la capa de presentación se
puede encargar del control
de un LCD inteligente, una pantalla táctil como así también
botones y otros métodos de
entrada.
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.
6. Capa de Abstracción del Sistema (Hardware).
El objetivo de la capa de abstracción del sistema es exponer la
implementación de los elementos
virtuales del hardware (componentes de software) que se
comunicarán los recursos reales de
hardware.
La capa de abstracción del sistema es la más importante dentro
de la arquitectura dado que de ella
depende la información extraída del contexto del sistema
embebido. Para lograr este objetivo, el
recurso virtual debe incluir las librerías o componentes
software necesario para interactuar con el
recurso físico asociado y en muchos de los casos dependiendo del
hardware de entrada/salida
usado, se depende de lo que el fabricante indique. Esto quiere
decir que si, por ejemplo, el
recurso físico es un componente ZigBee, pues el recurso virtual
deberá poder dialogar ZigBee
con el recurso físico. Cabe aclarar que estos recursos virtuales
obtienen información de entrada
-
ARQUITECTURA DE APLICACICONES DE SOFTWARE EMBEBIDO EN
MICROCONTROLADOR…. 41
para el objeto inteligente, mientras que los de las capas
superiores son para consumir la
información de salida del objeto inteligente.
7. Relación entre los componentes.
En esta sección se describe cómo se relacionan los distintos
componentes de la arquitectura de la
sección 3.3.5. Para esto, se hace referencia al modelo 4+1 [40].
Para este trabajo se optó por
omitir la vista de desarrollo y de escenarios, dado que ambos
diagramas dependen
exclusivamente de los requerimientos específicos para el sistema
embebido, cosa que este trabajo
carece, por ser una arquitectura de referencia. En las secciones
4.3.1 a 4.3.3 se documentan
entonces la vista lógica, vista de procesamiento y vista física,
respectivamente.
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
Figura 5. Vista Lógica de la Arquitectura Propuesta.
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
Figura 6. Modelo Orientado a Servicios de un sistema embebido en
la IOT.
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.
Cliente Sistema
Embebido
Hardware
Petición Lectur
Respuesta Respuesta
-
ARQUITECTURA DE APLICACICONES DE SOFTWARE EMBEBIDO EN
MICROCONTROLADOR…. 44
Figura 7.Vista Física de la Arquitectura de Referencia.
-
ARQUITECTURA DE APLICACICONES DE SOFTWARE EMBEBIDO EN
MICROCONTROLADOR…. 45
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.
El segundo ejemplo práctico se trata en el numeral 5.1. y
corresponde al monitoreo de las
variables de temperatura, humedad y nivel de agua para el caso
de cosecha de agua de niebla,
para este caso se toma la arquitectura del 1er caso y se hacen
ligeros cambios para incluir el
sensor ultrasonido que medirá el nivel de agua que determina la
cantidad de agua cosechada.
A. Problema Propuesto en caso de estudio
La vigilancia de la temperatura en la agroindustria es
importante para calcular unidades térmicas
de crecimiento de cultivos [50], comúnmente llamadas unidades
calor o grados-día, mediante las
cuales es posible medir la influencia de la temperatura en la
velocidad de desarrollo de los
cultivos e insectos, y con ello predecir la aparición de etapas
fenológicas de cultivos y estadios
biológicos en los insectos. Los registros de temperatura también
se usan para calcular horas o
unidades frío requeridas por los frutales caducifolios y algunos
insectos durante la etapa de
hibernación, al igual que la temperatura, la humedad también es
una variable climática clave para
el pronóstico de enfermedades de cultivos, y se utiliza en
combinación con otras variables para
estimar la evapotranspiración.
En la vigilancia y control de las variables de humedad y
temperatura en un cultivo de cilantro en
la vereda San José de Pavas, municipio de La Cumbre, Valle del
Cauca Colombia, cuyo clima
está definido como cálido tropical, con una altura de 1591 mts
sobre el nivel del mar, la
plantación se encuentra en la llanura de Pavas, que a pesar que
su cabecera municipal la
temperatura esta entre 19°C y 23°C según lo definido en
[51].
Se requiere tomar medidas cautelares en virtud de las altas
temperaturas y debido al fenómeno
del niño ( año 2015), el riego sobre el cultivo se debe realizar
conforme al comportamientos de
-
ARQUITECTURA DE APLICACICONES DE SOFTWARE EMBEBIDO EN
MICROCONTROLADOR…. 46
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:
1. Medidor de Humedad: Que efectúa mediciones sobre el sensor de
humedad.
2. Medidor de Temperatura: Que efectúa mediciones sobre el
sensor de temperatura.
-
ARQUITECTURA DE APLICACICONES DE SOFTWARE EMBEBIDO EN
MICROCONTROLADOR…. 47
Figura 8. Vista de la Arquitectura Concreta.
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.
Figura 9. Vista de la Arquitectura detallada.
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
controlador de dominio respectivo (DomainController) quien tiene
la lógica algorítmica para
enviar a al Visor LCD la información suministrada por los
recursos interrogados.
La capa de Control asume la interrogación de los sensores
(recursos) implementando una clase
Controladora de Dominio (DomainController) que estará
interrogando los sensores de humedad y
temperatura cada instante de tiempo, tiempo que es configurado
por parámetros.
La capa de Interface provee una interface (Listener),
implementando un controlador frontal
(patrón de diseño) el cual puede escuchar peticiones de sistemas
ó usuario externo. En este caso,
es la encargada de resolver el llamado mediante servicios web,
por lo tanto la resolución
consistirá en el análisis de parámetros que hayan sido enviados,
y los recursos que hayan sido
solicitados, haciendo uso del interpretador de comandos
pertinente, en este caso vía TCP (TCP-
UDP CLI MANAGER) ver figura 4. Posteriormente después de la
interpretación de la petición
el controlador frontal envía al comando (clase que controla el
evento) la información
suministrada por el usuarios externo para que el comando a su
vez llame al controlador de