Descarga la aplicación para disfrutar aún más
Vista previa del material en texto
Arquitectura de Aplicaciones de Software Embebido en Micro Controladores para Tarjetas de Captura de Datos de la IOT. José Fernando Mendoza Ibarra , fmendoza06@gmail.com 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 muchosde 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 quesoportará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íade 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 solucionesIoT. 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 EMBEBIDOEN 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, implementaun 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
Compartir