• No se han encontrado resultados

Propuesta de software base para el desarrollo de sistemas embebidos

N/A
N/A
Protected

Academic year: 2020

Share "Propuesta de software base para el desarrollo de sistemas embebidos"

Copied!
161
0
0

Texto completo

(1)Universidad Central «Marta Abreu» de las Villas Facultad de Matemática - Física - Computación Departamento de Ciencia de la Computación. Propuesta de software base para el desarrollo de sistemas embebidos Tesis presentada en opción al Título Académico Máster en Ciencia de la Computación. Lic. Reinier Millo Sánchez. Año 58 de la Revolución Santa Clara 2016.

(2) Universidad Central «Marta Abreu» de las Villas Facultad de Matemática - Física - Computación Departamento de Ciencia de la Computación. Propuesta de software base para el desarrollo de sistemas embebidos Tesis presentada en opción al Título Académico Máster en Ciencia de la Computación. Lic. Reinier Millo Sánchez. Tutor: DrC. Carlos Morell Pérez. Año 58 de la Revolución Santa Clara 2016.

(3) DICTAMEN El que suscribe, Lic. Reinier Millo Sánchez, hago constar que el trabajo titulado «Propuesta de software base para el desarrollo de sistemas embebidos» fue realizado en la Universidad Central «Marta Abreu» de las Villas como parte de la culminación de los estudios de la especialidad de Ciencia de la Computación, autorizando a que el mismo sea utilizado por la institución, para los fines que estime conveniente, tanto de forma parcial como total, y que además no podrá ser presentado en eventos ni publicado sin la autorización de la Universidad.. Firma del autor Lic. Reinier Millo Sánchez. Los firmantes que aparecen a continuación certifican que el presente trabajo ha sido realizado según acuerdos de la dirección del centro y el mismo cumple con los requisitos que debe tener una investigación de esta envergadura referida a la temática señalada.. Firma del tutor DrC. Carlos Morell Pérez. Firma del jefe del seminario DrC. Carlos Pérez Risquet. 24 de junio del 2016 Fecha.

(4) Pensamiento. «Hay dos formas de escribir programas sin errores; sólo la tercera funciona». Alan J. Perlis.

(5) Dedicatoria. A la memoria de mi abuela Nena ... A la memoria de mi abuelo Marcelo ... A la memoria de mi abuela Olga ... A mis padres ... A Patri, mi linda sobrina ... A mi familia... A todos mis amigos... En fin, a todos aquellos que siempre creyeron en la realización de este trabajo..

(6) Agradecimientos. A mi tutor DrC. Carlos Morell Pérez por todo su apoyo, dedicación y momentos en los que fumamos para la realización de este trabajo y el desarrollo de la ciencia. A mi familia en especial mis padres y mi hermana, por quererme y tener siempre todo su apoyo... ... a mis abuelos y tíos, por su cariño ... ... a todos ellos por hacer de mi la persona que soy. A mi Betty Boop, esa persona especial que llegó a mi vida, y hoy es motivo de mi alegría e inspiración, gracias por todo su cariño, paciencia y apoyo en la realización de este trabajo. A Yadira Benavides Zaila por todo su apoyo y dedicación para la realización de este trabajo, por todas sus sugerencias oportunas para la redacción del documento y el desarrollo de la investigación en general. A Lenniet Coello Blanco y Mabel Frías, camagüeyanas especiales que conocí durante la maestría, por brindarme su amistad y apoyo incondicional, aunque no les gustara mi trabajo, por ser motivo de inspiración y mostrarme que siempre se puede. A Isabel Cristina Pérez Verona, simplemente Is, una amiga muy especial que conocí durante la maestría, por brindarme su amistad y confianza, por soportarme como soy y siempre tener una sonrisa. A Fernando Rosales, Jarvin Antón, Osmany Morffa, Guillermo Sosa, Claudia Companioni, Karelia Díaz, Marilyn Bello, Adis Perla, Addel Goya, Frank Reyes, Alejandro Boix, Mario Amores, Waldo Paz, Tahimy Morffa, amigos de la carrera, de la universidad y compañeros de trabajo, por soportarme y confiar en mi. Al equipo de desarrollo de Sistema Operativo UCLV-XETID, Waldo Paz, Alexy Gallardo, Humberto López, Alexy Fajardo, Jorge A. Polo, algunos ya no pertenecen al equipo de trabajo pero de ellos dependió mucho la realización de este trabajo..

(7) Agradecimientos Al grupo de trabajo de la XETID en la UCLV, Eva, Randy, Yosmel, Leonardo, Alexy, Humberto, Carlos, Ernesto, Liliana, Michel, Daniel, Claudia, Alejandro, Luis Javier, Yanelys, Yadira, Loreni, Julio, por todos los días trabajados en colectivo y los momentos compartidos. A los compañeros de la XETID, en especial Vasconcelo, Arce y Frank, por todo el apoyo brindado para el desarrollo de este trabajo. A las comunidades de desarrollo de Fiasco.OC y GenodeOS por toda su ayuda y el apoyo brindado durante el desarrollo de este trabajo. A Tania Rendón, periodista de profesión que sin conocimientos de la temática me brindó oportunas sugerencias para la redacción del documento. A todo el claustro de profesores de la maestría por todo el conocimiento brindado. A todos los que nos tildaron de locos al comenzar este trabajo y nos hicieron esforzarnos más para obtener un buen resultado. En fin, para que no quede nadie por mencionar, a todas las personas que de una forma u otra han colaborado con la realización de este trabajo.. A todos muchas gracias.

(8) RESUMEN El empleo de sistemas embebidos se ha convertido en un fenómeno común de nuestros días, ya que se pueden encontrar dispositivos embebidos desde las fábricas automatizadas hasta en el hogar. Aunque el funcionamiento de los sistemas embebidos es predeterminado por la funcionalidad para la cual se van a emplear, resulta necesario tener un sistema operativo que controle el dispositivo. El desarrollo de sistemas operativos para controlar estos sistemas embebidos tiene nuevos retos con el auge de nuevas plataformas de hardware y nuevos requisitos de sistema. Dos de los enfoques más empleados para el desarrollo de kernels de sistema son el monolítico y el microkernel. El enfoque basado en microkernel tiene un enfoque minimalista y es una mejor alternativa para el desarrollo de sistemas embebidos. En el presente trabajo se propone XEOS, una combinación del microkernel Fiasco.OC con el framework de desarrollo GenodeOS, para el desarrollo de un software base cuyo fin es ser empleado en sistemas embebidos desarrollados por la XETID. Asimismo, en la investigación se aplican pruebas de rendimiento al sistema propuesto, demostrando que existen diferencias significativas respecto a sistemas con un enfoque monolítico, tomado como referencia, pero se logra un mejor aprovechamiento del hardware subyacente. La factibilidad de emplear XEOS para el desarrollo de sistemas embebidos en la XETID es probada con el caso de estudio ErosXD, un controlador de domótica desarrollado en la XETID.. i.

(9) ABSTRACT The use of embedded systems has become a common phenomenon today, these embedded devices can be found from automated factories to home. Although the operation of embedded systems it is predetermined by functionality for which are to be used, it must have an operating system that control the device. The development of operating systems to control these embedded systems has new challenges with the rise of new hardware platforms and new system requirements. Two of most commonly used approaches for the development of system kernels are monolithic and microkernel. Microkernel-based approach has a minimalist approach and is a better alternative for the development of embedded systems. In this thesis it is proposed XEOS, a combination of Fiasco.OC microkernel with the GenodeOS development framework, for the development of a basis software used in embedded systems developed by XETID. Also, in this research are applied performance tests to the system, demonstrating that there are significant differences compared to systems with a monolithic approach that were taken as reference, but achieves a better use of the underlying hardware. The feasibility of using XEOS for development of embedded systems in the XETID is tested with the case ErosXD, home automation controller developed in the XETID.. ii.

(10) TABLA DE CONTENIDOS Listado de figuras. VI. Listado de tablas. VIII. Listado de acrónimos. IX. Introducción Capítulo 1: Acerca del desarrollo de sistemas operativos 1.1 El kernel del sistema operativo . . . . . . . . . . . . . . 1.1.1 Planificación de la CPU . . . . . . . . . . . . . . 1.1.2 Administración de la memoria . . . . . . . . . . . 1.1.3 Administración de dispositivos de I/O . . . . . . 1.1.4 Mecanismo de comunicación . . . . . . . . . . . . 1.1.5 Llamadas al sistema . . . . . . . . . . . . . . . . 1.2 Enfoques para el desarrollo de kernel del sistema . . . . . 1.2.1 Kernel monolítico . . . . . . . . . . . . . . . . . . 1.2.2 Microkernel . . . . . . . . . . . . . . . . . . . . . 1.2.3 Kernel híbrido . . . . . . . . . . . . . . . . . . . . 1.2.4 Exokernel . . . . . . . . . . . . . . . . . . . . . . 1.2.5 Kernel monolítico vs. microkernel . . . . . . . . . Consideraciones finales del capítulo . . . . . . . . . . . . . . .. 1. . . . . . . . . . . . . .. . . . . . . . . . . . . .. . . . . . . . . . . . . .. Capítulo 2: Selección del microkernel y el framework de propuesta 2.1 Microkernels para el desarrollo de sistemas embebidos . . . . . 2.1.1 Minix3 . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.1.2 Microkernel de la familia L4 . . . . . . . . . . . . . . . 2.1.2.1 Fiasco.OC . . . . . . . . . . . . . . . . . . . . 2.1.2.2 OKL4 . . . . . . . . . . . . . . . . . . . . . . 2.1.2.3 seL4 . . . . . . . . . . . . . . . . . . . . . . . 2.1.3 FreeRTOS . . . . . . . . . . . . . . . . . . . . . . . . . 2.1.4 Selección del microkernel . . . . . . . . . . . . . . . . . 2.2 Frameworks de desarrollo de sistemas operativos . . . . . . . . 2.2.1 LibOS . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . .. . . . . . . . . . . . . .. 8 8 9 9 10 11 11 12 13 14 16 17 19 21. . . . . . . . . . .. 22 22 22 23 24 25 26 26 27 30 30. la . . . . . . . . . .. iii.

(11) Tabla de contenidos 2.2.2 Graphene . . . . . . . . . . 2.2.3 LynxOS . . . . . . . . . . . 2.2.4 Quantum Leaps . . . . . . . 2.2.5 Mentor Embedded Multicore 2.2.6 GenodeOS . . . . . . . . . . 2.2.7 L4Re . . . . . . . . . . . . . 2.2.8 Selección del framework . . Consideraciones finales del capítulo . . .. . . . . . . . . . . . . . . . . . . . . . Framework . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. 31 31 32 32 33 35 36 38. . . . . . . . .. 39 39 40 44 45 46 48 49 51. . . . . . . .. 53 53 54 55 58 58 62 68. Capítulo 5: Caso de estudio: Controlador de domótica ErosXD 5.1 Introducción a la domótica . . . . . . . . . . . . . . . . . . . . . . 5.2 Controlador de domótica ErosXD . . . . . . . . . . . . . . . . . . 5.3 Soporte para el controlador de domótica en XEOS . . . . . . . . . 5.3.1 Dependencias de software . . . . . . . . . . . . . . . . . . 5.3.2 Controlador de domótica . . . . . . . . . . . . . . . . . . . 5.4 Pruebas del controlador de domótica en XEOS . . . . . . . . . . . 5.4.1 Pruebas con emulación de los sensores . . . . . . . . . . . 5.4.2 Pruebas con sensores y actuadores . . . . . . . . . . . . . . 5.4.3 Pruebas de estrés . . . . . . . . . . . . . . . . . . . . . . . Consideraciones finales del capítulo . . . . . . . . . . . . . . . . . . . .. 69 69 70 72 73 75 76 78 79 81 82. Capítulo 3: XEOS, software base de sistemas embebidos 3.1 XEOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2 Plataformas de hardware RaspberryPI y Odroid-X2 . . . . 3.2.1 El TCB del sistema . . . . . . . . . . . . . . . . . . 3.3 Soporte de XEOS para las plataformas de hardware . . . . 3.3.1 Portando la plataforma RaspberryPI a XEOS . . . 3.3.2 Portando la plataforma Odroid-X2 a XEOS . . . . 3.4 Seguridad del software base . . . . . . . . . . . . . . . . . Consideraciones finales del capítulo . . . . . . . . . . . . . . . . Capítulo 4: Pruebas de software 4.1 Pruebas de software . . . . . . . . . . . 4.1.1 Pruebas de software estáticas . 4.1.2 Pruebas de software dinámicas . 4.1.3 Pruebas automáticas . . . . . . 4.2 Pruebas de software sobre XEOS . . . 4.3 Pruebas de rendimiento . . . . . . . . . Consideraciones finales del capítulo . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . .. iv.

(12) Tabla de contenidos Conclusiones. 84. Recomendaciones. 85. Referencias bibliográficas. 86. Anexo A:. Comparaciones de Fiasco.OC vs. kernel de Linux. A-1. Anexo B: Guía para la puesta a punto de las herramientas de trabajo con XEOS B-1 Anexo C:. Puesta a punto de ejemplos básicos en XEOS. C-1. Anexo D: Guía para el soporte de nuevas plataformas de hardware en XEOS D-1 Anexo E:. Resultados de las pruebas de rendimiento. E-1. v.

(13) LISTADO DE FIGURAS 1.1. Relación de tamaño del TCB en cada uno de los enfoques de desarrollo de. . . . . . . . . . . . . . . . . . . Estructura de un sistema basado en kernel monolítico . Estructura de un sistema basado en microkernel . . . . Estructura de un sistema basado en kernel híbrido . . . Estructura de un sistema basado en exokernel . . . . .. 12 13 15 17 18 Comparación del TCB de un sistema basado en kernel monolítico vs. microkernel 19. kernel del sistema. 1.2 1.3 1.4 1.5 1.6 1.7. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . . . . . . . . . . . . . .. .. 24. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 34. Estructura jerárquica de GenodeOS para reducir el TCB de una aplicación (Feske, 2015). 2.3. Estructura básica de un sistema compuesto por el L4Re (TU-DresdenOSGroup,. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 35. . . . . . . . . . . . . . . . . . . . . .. . . . . . . Comparación en cuando a LOC Fiasco.OC vs. Linux . . . . . . . . . . . . Comparación en cuando al memory footprint Fiasco.OC vs. Linux . . . . .. 40 41 42 44 45. . . . . .. 64. 2015b). 3.1 3.2 3.3 3.4 3.5. Componentes internos de XEOS. 4.1 4.2. Mflops calculados por algoritmos de operaciones de punto flotante. Plataforma de hardware RaspberryPI 1 Modelo B (SoC Broadcom BCM2835) Plataforma de hardware Odroid-X2 (SoC Samsung Exynos4412). Rendimiento de la CPU basado en el tiempo de ejecución de algoritmos de cálculo intensivo. 4.3. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 66 67. Rendimiento de la memoria del sistema basado en el tiempo de inicialización. . . . . . . . . . . . . . .. 68. Componentes del controlador de domótica ErosXD desarrollado en la XETID. 71 72. de un arreglo en memoria con valores aleatorios. 5.1 5.2. 66. Rendimiento de la CPU basado en el tiempo de solución del problema de las n-reinas. 4.6. . . . . . . . . . . . . . . . .. Rendimiento de la CPU basado en el tiempo de cálculo de los números de Fibonacci. 4.5. 65. Rendimiento de la CPU basado en el tiempo de cifrado de cadenas de texto empleado el algoritmo de sumas hash MD5. 4.4. 20. Árbol de la familia de microkernels L4 (Las flechas negras indican mayor herencia del código fuente y las flechas verdes una mayor herencia del ABI). 2.2. . . . . .. Interacción entre las aplicaciones de un sistema basado en microkernel vs. kernel monolítico (Härtig y Engel, 2014). 2.1. . . . . .. Despliegue de los sensores y ErosXD en el salón de reuniones de la XETID. .. vi.

(14) Listado de figuras 5.3 5.4 5.5 5.6 5.7 5.8 5.9 5.10. . . . . . . . . . . . . Memory footprint de ErosXD de un total de 33029803 bytes . Rendimiento de la red obtenido por le herramienta netperf . Despliegue del sistema XEOS-ErosXD . . . . . . . . . . . . Simulador del Arduino desplegado en la XETID . . . . . . .. . . . . . Despliegue de los sensores y ErosXD en el local XETID-UCLV . Esquema eléctrico para la conexión del relé G2RL-5V . . . . .. . . . . . . .. 73 76 77 78 79 80 80. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 81. 5.11 Cantidad de lectura de los sensores perdidas en el sistema bajo sobrecarga de peticiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 82. Estructura del sistema XEOS-ErosXD. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. Resultados de las prueba de estrés de ErosXD utilizando la herramienta Apache Bench. vii.

(15) LISTADO DE TABLAS 2.1 2.2. . . . . . . . . . . . . . . . . Comparación de los frameworks de desarrollo estudiados . . . . . . . . . .. 29 37. 3.1. Características de las plataformas de hardware empleadas. . . . . . . . . .. 43. 5.1. Relación entre los componentes de ErosXD y las bibliotecas agregadas al. Comparación de los microkernels estudiados. framework. 5.2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 75. Relación entre los componentes de hardware empleados para el despliegue de la domótica en el local XETID-UCLV. . . . . . . . . . . . . . . . . . . .. 80. A.1 Cantidad LOC de los componentes del kernel . . . . . . . . . . . . . . . A-1 A.2 Memory footprint de los componentes del kernel . . . . . . . . . . . . . . A-1 E.1 E.2 E.3 E.4 E.5 E.6. . . . . . . . . . . Tiempo de cálculo de algoritmos de uso intensivo de la CPU (segundos) . Tiempo de cifrado empleando el algoritmo MD5 (segundos) . . . . . . . Tiempo de cálculo del n-ésimo número de Fibonacci (segundos) . . . . . Tiempo de solución del problema de las n-reinas (segundos) . . . . . . Tiempo de inicialización de arreglos con datos aleatorios (segundos) . . . Mflops de las pruebas de rendimiento de SciMark 2.0. . . . . . .. . . . . . .. E-1 E-1 E-1 E-2 E-3 E-3. viii.

(16) LISTADO DE ACRÓNIMOS ABI Acrónimo del inglés Application Binary Interface API Acrónimo del inglés Application Programming Interface CPU Acrónimo del inglés Central Processing Unit DoS Acrónimo del inglés Denial of Service DVD Acrónimo del inglés Digital Video Disc FAR Fuerzas Armadas Revolucionarias FFT Transformada Rápida de Fourier, acrónimo del inglés Fast Fourier Transform FIQ Acrónimo del inglés Fast Interrupt Request FPU Acrónimo del inglés Float Point Unit GSMA Acrónimo del inglés GSM Association IDE Acrónimo del inglés Integrated Development Environment IMS Acrónimo del inglés Intelligent Mechatronic Systems ITU Acrónimo del inglés International Telecommunications Union IoT Internet de las cosas, acrónimo del inglés Internet of Things IPC Acrónimo del inglés Inter-Process Communication I/O Entrada/Salida, acrónimo del inglés Input/Output L4Re Entorno de ejecución de L4, acrónimo del inglés L4 Runtime Environment LOC Líneas de código, acrónimo del inglés Lines of Code LU Acrónimo del inglés Lower Upper factorization Mflops Millones de operaciones de punto flotante por segundo, acrónimo del inglés Million Floating point Operation Per Second MMC Acrónimo del inglés Multi-Media Card. ix.

(17) Listado de acrónimos MMU Acrónimo del inglés Memory Management Unit PCC Partido Comunista de Cuba POSIX Acrónimo del inglés Portable Operating System Interface RAM Acrónimo del inglés Random Access Memory RPC Acrónimo del inglés Remote Procedure Call seL4 Acrónimo del inglés Secure Embedded L4 SIC Servidores de Integración Continua SoC Acrónimo del inglés System in Chip SOR Acrónimo del inglés Jacobi Successive Over-Relaxation TCB Acrónimo del inglés Trusted Computing Base TICs Tecnologías de la Información y las Comunicaciones UART Acrónimo del inglés Universal Asynchronous Reciver-Transmitter UCLV Universidad Central «Marta Abreu» de Las Villas UML Acrónimo del inglés Unified Modeling Language USB Acrónimo del inglés Universal Serial Bus VFP Acrónimo del inglés Vector Floating-point XEOS Acrónimo del inglés XETID Embedded Operating System XETID Empresa de Tecnologías de la Información para la Defensa. x.

(18) Introducción.

(19) INTRODUCCIÓN Hoy día se ha hecho recurrente el uso de la telefonía móvil, de los dispositivos inteligentes y de pequeños sistemas embebidos. En reiteradas ocasiones se emplean sin tener conocimiento del software con el que trabajan y la revolución tecnológica que se desarrolla tras ellos. Es muy frecuente encontrar sistemas embebidos tanto en fábricas automatizadas como en equipos empleados en el hogar. Con el auge alcanzado por la tecnología y la interconexión de estos dispositivos ha surgido lo que algunos han denominado «fenómeno» y otros, «revolución»: el Internet de las cosas (IoT). Los sistemas embebidos como refieren Tanenbaum (2009); Silberschatz et al. (2013) son sistemas cuyo hardware y software están específicamente diseñados y optimizados para resolver un problema concreto de forma eficiente. El término «embebido» o «empotrado» hace alusión al sistema electrónico de control que es fundamental en el sistema general. A diferencia de otros sistemas electrónicos, los sistemas embebidos se encuentran insertados en el dispositivo al que controlan y deben cumplir requisitos de tamaño, fiabilidad, consumo y coste. El término IoT fue definido en 1999 por Kevin Ashton para describir un sistema en el cual los objetos físicos están conectados a Internet a través de sensores como plantea Rose et al. (2015). El diccionario de Oxford (OxfordDictionaries, 2015) lo define como «la interconexión vía Internet de dispositivos de cómputo embebidos en objetos de uso cotidiano, permitiéndoles enviar y recibir datos». Aunque existen otras tantas definiciones, todas coinciden en que IoT no es más que un conjunto de dispositivos embebidos interconectados a la red de redes, lo que permite el intercambio y el procesamiento de información casi de forma autónoma o, como lo definiese el Dr. Carlo Ratti en Consumer Electronics Association (2015), es «la digitalización en línea de nuestro mundo físico». Debido al alto impacto económico y social (GSMAssociation, 2014), los servicios médicos constituyen el área de mayor influencia de los sistemas embebidos y el IoT. Actualmente existen dispositivos embebidos (portátiles o no) para controlar los signos vitales, la temperatura corporal y la presión arterial, los niveles de azúcar en sangre y monitorear varias enfermedades crónicas. También han sido empleados en otras áreas (UKGoverment, 2014) como la. 1.

(20) Introducción agricultura, la meteorología, edificios inteligentes, sistemas de domótica, sistemas de radares marítimos y aéreos, cajeros automáticos y sistemas para la defensa, entre otras. A pesar de que las soluciones donde se ha visto el uso efectivo de los sistemas embebidos se encuentran divididas por áreas de aplicación, existen proyectos que buscan la estandarización de los mismos, tal es el caso de los proyectos fomentados por la Unión Europea (Spirito et al., 2014): OpenIoT, iCore, Compose, SmartSantander, Fitman y OSMOSE. El estudio y desarrollo de estas tecnologías han ido alcanzando auge a la par de los propios dispositivos. Estudios de analistas de la industria como IMS, GSMA, ITU, Cisco, Dell, entre otros, aseguran que para el 2020 existirán entre 20 y 100 billones de dispositivos inteligentes interconectados (Cisco, 2014; UKGoverment, 2014; Rose et al., 2015), lo cual es una cifra considerable comparada con los 14 billones actualmente estimados. Aunque el funcionamiento de estos dispositivos es predeterminado por la funcionalidad para la cual se emplea, es necesario tener un sistema operativo que los controle y garantice la seguridad y privacidad de la información que estos manejan. La diversidad de dispositivos y su tamaño, cada vez más reducido, hacen que el desarrollo de sistemas operativos para controlar estos sistemas embebidos sea una tarea mucho más compleja. En muchos casos se tienen requisitos de tiempo real, mientras que en otros se tienen restricciones de recursos computacionales; por lo que el software base o sistema operativo de estos dispositivos tiene que ajustarse a estas características para así disminuir los costos de desarrollo y mantenimiento de los sistemas. En la actualidad existen varios sistemas operativos de propósito general, centrados principalmente en dos grandes familias: Microsoft Windows y GNU/Linux. Estos sistemas, en su mayoría, están formados por un núcleo o kernel monolítico, el cual concentra todas las funciones básicas del sistema operativo: gestión de los procesos, manipulación del sistema de archivos, control de los dispositivos de hardware, gestión de memoria, entre otras. Estos sistemas facilitan la realización de muchas tareas; pero en áreas como la automática, la robótica y la telefonía ha tenido auge el empleo de microcontroladores como parte de los equipos electrónicos. Debido a los reducidos recursos computacionales que estos presentan, los sistemas operativos han tenido que disminuir su magnitud, ya que su estructura es demasiado compleja y en la mayoría de los casos no requieren de todos los componentes que los conforman. La reducción de la estructura de los sistemas operativos ha sido objeto de. 2.

(21) Introducción estudio por varios años, por lo que se han definido varios paradigmas o enfoques arquitectónicos para la implementación del kernel de un sistema operativo (Tanenbaum, 2009; Silberschatz et al., 2013). El kernel es el componente principal del sistema operativo y se encarga de la comunicación entre la capa de software y la capa de hardware. En la actualidad existen cuatro enfoques de desarrollo bien marcados: kernel monolítico, microkernel, kernel híbrido y exokernel. Aunque todos los enfoques han sido empleados en el desarrollo de sistemas embebidos, los enfoques de kernel monolítico y microkernel han sido los más empleados. El kernel de Linux, uno de los principales exponentes del enfoque monolítico, ha sido ampliamente utilizado y hoy día se emplea en los sistemas Android y cuenta con varias versiones reducidas para sistemas embebidos. Mientras, los microkernel tienen una concepción minimalista. Como plantea Liedtke (1995), el microkernel solo debe implementar los elementos básicos o «primitivas» para el funcionamiento del sistema, los demás elementos deben ser implementados a nivel de aplicaciones de usuarios. Esta concepción permite tener un sistema más modular, flexible y tolerable a fallos con respecto al enfoque monolítico. De forma general, el desarrollo de sistemas operativos es una tarea de gran complejidad debido a que se necesitan conocimientos tanto de software y hardware como de las herramientas de desarrollo a emplear. La complejidad y el tiempo de desarrollo aumentan cuando este es realizado desde cero, de forma manual o scratch. Para agilizar y automatizar las distintas fases de este proceso han surgido varios frameworks de desarrollo de sistemas operativos con soporte para diversas API y aplicaciones, las cuales se emplean fundamentalmente en las etapas de compilación, construcción y empaquetado, además de que proveen facilidades para la extensión del propio framework. El fenómeno del IoT no ha tenido un impacto directo en la sociedad cubana, pese a que cada día aumenta el empleo de dispositivos inteligentes y el acceso a redes de información. En Cuba es posible encontrar sistemas embebidos tanto en lavadoras de control automático, sistemas decodificadores para la televisión digital, hornos, ventiladores, sistemas de alumbrado automático, como en reproductores DVD, entre otros. Todos estos dispositivos son resultado de importaciones que ha tenido que hacer el país al no disponer de los recursos materiales ni del personal calificado. En este sentido, los Lineamientos de la Política Económica y Social, aprobados en el VI Congreso del PCC, definen nuevas líneas estratégicas para fomentar el desarrollo de las TICs y la industria en general, basados en la soberanía. 3.

(22) Introducción tecnológica que posee la nación cubana y la producción de servicios científicos y tecnológicos de alto valor agregado, así como el desarrollo de la industria del software para sustituir importaciones. Los avances en las TICs son un complemento clave para garantizar la defensa y el desarrollo del sector industrial, como bases de la soberanía económica de la Mayor de las Antillas. El Centro de Sistemas Embebidos, perteneciente a la División de Automática y Telecomunicaciones de la XETID, utiliza diversas tecnologías como parte del software base para el desarrollo de sus sistemas. La creciente demanda de soluciones para la defensa, la industria, sistemas de seguridad, plataformas telefónicas, sistemas de adquisición de datos, sistemas automáticos de control industrial y la modernización de la técnica y el armamento de las FAR ha requerido el empleo de sistemas embebidos. Estas soluciones precisan un dominio total de la tecnología utilizada de forma tal que permita extenderla, modificarla y sostenerla acorde con las necesidades nacionales de la defensa y la industria, además de ser competitiva a nivel internacional con un alto valor agregado. La asimilación, extensión y soporte de tecnologías para desarrollar los componentes del software base de los sistemas embebidos constituyen actividades que demandan profesionales con alto grado de especialización en esta rama del conocimiento. Los tiempos estimados para acometerlas están relacionados directamente al paradigma de diseño, a la complejidad del esquema de la arquitectura de software y al volumen de LOC que posean las tecnologías. No ejecutar acciones para lograr el dominio de las tecnologías empleadas en el desarrollo mantendría un alto grado de dependencia del software base, lo que atentaría contra la defensa, la productividad de la industria, la soberanía tecnológica y con la posibilidad de brindar mayor cantidad y calidad de servicios de alto valor agregado, entre los que se encuentran: Implementación de controladores de dispositivos de hardware. Soporte a nivel de kernel de diversas plataformas de hardware que sean de interés para la defensa y la industria. Modelación y construcción de nuevos algoritmos de planificación como soporte al procesamiento en tiempo real y aplicaciones de automatización y telecomunicaciones. Consultoría para la adquisición y diagnóstico de hardware. Las soluciones técnicas con las que ha trabajado el centro de Sistemas Embebidos se basan en el kernel de Linux, sin proveer los tiempos de respuesta requeridos. 4.

(23) Introducción en los sistemas industriales para tiempo real y de brindar garantías de seguridad, fiabilidad y disponibilidad, debido a su arquitectura monolítica. Tampoco se cuenta a nivel nacional con equipos de trabajo experimentados en el estudio, modificación y personalización de kernel de sistema y, en específico, el kernel de Linux. A nivel internacional se refleja una marcada tendencia al desarrollo de embebidos utilizando arquitectura de microkernel, alternativa a las soluciones monolíticas, además de un auge en su aplicación en áreas de la robótica, automovilística e industriales. Ante la situación expuesta se plantea como problema de la investigación: ¿Cómo contribuir al desarrollo de sistemas embebidos en la XETID empleando tecnologías de microkernel? El objetivo general de la investigación consiste en realizar una propuesta de software base, compuesta por el kernel del sistema y un framework de desarrollo, que utilice tecnologías de microkernel y pueda ser empleada por la XETID para el desarrollo de sistemas embebidos. Con el propósito de dar respuesta al problema de investigación se proponen los siguientes objetivos específicos: 1. Realizar un estudio crítico sobre los enfoques de desarrollo del kernel del sistema y las herramientas para el desarrollo de sistema operativos embebidos. 2. Proponer el diseño del software base para sistemas embebidos empleando tecnologías de microkernel. 3. Dar soporte a las tecnologías de software y hardware empleadas para el desarrollo de sistemas embebidos en la XETID. 4. Validar el software base propuesto tomando como caso de estudio el Controlador de Domótica ErosXD. Las preguntas de investigación planteadas son: ¿Cómo diseñar un software base para sistemas embebidos empleando tecnologías de microkernel? ¿Qué impacto puede tener el empleo de un enfoque de microkernel en el rendimiento del sistema? ¿Cómo validar el software base propuesto tomando como caso de estudio el. 5.

(24) Introducción Controlador de Domótica ErosXD? Para la realización de esta investigación se formuló la siguiente hipótesis: El empleo del enfoque de microkernel para el desarrollo de sistemas operativos brinda un sistema de tamaño reducido con algunas garantías de seguridad que pueden mejorar el desarrollo de sistemas embebidos en la XETID permitiendo un mejor dominio de la tecnología para garantizar la independencia tecnológica. Para lograr los objetivos planteados y demostrar la hipótesis establecida se acometieron las tareas de investigación siguientes: 1. Realizar un estudio sobre los enfoques de desarrollo de kernel del sistema. 2. Realizar un estudio sobre las herramientas de software base que utilizan el enfoque de microkernel y son empleadas a nivel internacional. 3. Realizar una propuesta de microkernel y framework para el desarrollo del software base. 4. Realizar un estudio sobre las pruebas de software para la validación de la solución propuesta. 5. Instalar y configurar las herramientas necesarias para la modificación del software base. 6. Brindar soporte del software base sobre las plataformas de hardware RaspberryPI y Odroid-X2. 7. Brindar soporte a las dependencias de software del Controlador de Domótica ErosXD. 8. Brindar soporte a ErosXD. 9. Realizar pruebas sobre ErosXD. El aporte de esta investigación científica se manifiesta en: Disposición de tecnologías de software base, kernel y framework de desarrollo, para el desarrollo de sistema embebidos. Adquisición de un dominio sobre las tecnologías de software base. Disposición de soporte de las tecnologías de software base en las plataformas. 6.

(25) Introducción de hardware RaspberryPI y Odroid-X2 utilizadas en las soluciones de la XETID. Disposición de soporte de las tecnologías de software empleadas para el desarrollo de las soluciones embebidas de la XETID en el software base. Utilización de los conocimientos adquiridos para dar soporte a nuevas plataformas de hardware y controladores de dispositivos. La tesis está estructurada en cinco capítulos capítulos. El capítulo 1 presenta las funciones del kernel del sistema y muestra un estudio del estado del arte de los enfoques de desarrollo del kernel, así como las ventajas y desventajas del enfoque de desarrollo de microkernel. En el capítulo 2 se describen varios kernels de sistema que se desarrollan bajo este enfoque y varios frameworks empleados para el desarrollo de sistemas operativos. El capítulo 3 presenta la propuesta de software base empleando un enfoque de microkernel, así como el framework de desarrollo a emplear y el diseño general del sistema. Además, se presentan las plataformas de hardware utilizadas para la experimentación y las garantías de seguridad que brinda el software base. En el capítulo 4 se realiza un análisis sobre las pruebas de software que se pueden emplear en el desarrollo de sistemas embebidos. Además, se describen las pruebas realizadas sobre la propuesta de software base. El capítulo 5 demuestra la factibilidad del empleo de la propuesta de software base, tomando como base el caso de estudio de un controlador de domótica desarrollado en la XETID. Se explica cómo se probó el caso de estudio y las pruebas realizadas sobre el mismo. El trabajo finaliza con las conclusiones, recomendaciones, referencias bibliográficas y los anexos.. 7.

(26) Capítulo 1 Acerca del desarrollo de sistemas operativos.

(27) CAPÍTULO 1 ACERCA DEL DESARROLLO DE SISTEMAS OPERATIVOS En este capítulo se define el kernel del sistema operativo y sus funciones básicas dentro del sistema operativo. Se presenta un estudio del estado del arte de los cuatro enfoques de desarrollo de kernel del sistema haciendo mayor énfasis en el enfoque de desarrollo de microkernel, de acuerdo con el interés de la investigación.. 1.1.. El kernel del sistema operativo. El kernel del sistema operativo, como lo define Tanenbaum (2009); Silberschatz et al. (2013), es la parte fundamental del sistema y el encargado de mediar toda la comunicación entre la capa de software y la capa de hardware. De ahí que sus funciones más importantes están enfocadas en la manipulación e interacción con el hardware, así como el intercambio de información entre los diferentes procesos del sistema; incluyendo la planificación de la CPU, administración de la memoria, administración de los dispositivos de I/O y el mecanismo de comunicación. El acceso a las funcionalidades del kernel y a los recursos de hardware no se realiza de forma directa. Para ello el kernel del sistema debe proveer una interfaz para la comunicación de las aplicaciones en modo usuario con el kernel del sistema. Esta interfaz es conocida como llamadas al sistema y son el eje principal del sistema operativo (Tanenbaum, 2009). Todas estas funcionalidades, por lo general, son implementadas en el kernel del sistema, pero también existen implementaciones de kernels donde estas funciones se implementan en programas que ejecutan en el modo usuario (Liedtke, 1992, 1994, 1995; Kaashoek et al., 1995; Zoor y Nagibin, 2014). En este último caso las aplicaciones pueden acceder a estas funcionalidades a través de la interfaz de llamadas al sistema y el mecanismo de comunicación que debe ser provisto por el. 8.

(28) Capítulo 1. Acerca del desarrollo de sistemas operativos kernel (Hansen, 1970; Tanenbaum, 2009; Silberschatz et al., 2013).. 1.1.1.. Planificación de la CPU. La planificación de la CPU conforma la base fundamental de los sistemas operativos multiprogramados (Tanenbaum, 2009; Silberschatz et al., 2013), donde existen varios programas en ejecución. Como cada procesador puede ejecutar un solo programa a la vez, el kernel debe decidir de los programas en ejecución a cuál se le debe asignar la CPU para su ejecución. Esta selección del programa, que se debe ejecutar en la CPU, se realiza empleando algún criterio de selección, los cuales se conocen como algoritmos de planificación de procesos. Cuando el kernel asigna la CPU a un programa para su ejecución, la información del programa que anteriormente se estaba ejecutando debe ser guardada, para luego ser restaurada cuando se le vuelve a asignar la CPU a dicho programa. Este cambio de la información del programa en ejecución debe ser debidamente controlado por el kernel para evitar la alteración de esta información. En muchos casos existen algunos valores de registros que solo pueden ser modificados en modos privilegiados de la CPU, por lo que el kernel es el único responsable de manipular esta información.. 1.1.2.. Administración de la memoria. Toda la información para la ejecución de un programa, instrucciones ejecutables y datos, deben estar almacenados en la memoria física para su correcta ejecución. En ocasiones esta información no se encuentra presente en la memoria o la memoria para la ejecución es insuficiente. El kernel del sistema, como intermediario entre la capa de software y hardware, tiene el control completo sobre la memoria física del sistema. Este es el encargado de gestionar de forma segura la porción de memoria que usará cada uno de los programas que se ejecutan en el sistema. En ocasiones, varios programas se pueden ejecutar de forma concurrente y hacer referencia a una misma dirección de memoria para acceder a información diferente. Esto es posible gracias al mecanismo de memoria virtual (Tanenbaum, 2009), una extensión de la memoria física que permite la ejecución de programas que no están completamente cargados en memoria, la ejecución de programas en espacios de memorias aislados y la ejecución de programas que necesitan más. 9.

(29) Capítulo 1. Acerca del desarrollo de sistemas operativos memoria que la cantidad de memoria física del sistema. El direccionamiento o traducción de direcciones de la memoria virtual a la memoria física debe ser controlado a través del kernel, apoyado en algunas facilidades que brinda el hardware subyacente. Este proceso por lo general es realizado por segmentación o paginación de la memoria, como describen varios autores (Tanenbaum, 2009; Silberschatz et al., 2013), aunque también existen modelos híbridos para el direccionamiento. Cuando los programas solicitan una dirección de memoria siempre realizan una solicitud de memoria virtual, y esta solicitud es transformada a una dirección física si la información se encuentra cargada en memoria. Si la información no está cargada en memoria, entonces el kernel carga la información en memoria y luego realiza el direccionado. El empleo de la memoria virtual permite que un programa se ejecute como si fuese el único programa en ejecución en el sistema (Silberschatz et al., 2013), lo cual evita que la ejecución de un programa interfiera con otro programa en ejecución.. 1.1.3.. Administración de dispositivos de I/O. Casi todas las aplicaciones que se ejecutan en un sistema operativo acceden a los dispositivos de I/O, tanto para obtener como para devolver alguna información durante su ejecución. Acceder directamente a estos dispositivos desde la aplicación implica el conocimiento del funcionamiento del dispositivo, lo cual convierte el desarrollo de una aplicación sencilla en una tarea compleja. En un sistema multitarea, varias aplicaciones podrían acceder al dispositivo de forma concurrente, lo que pone en riesgo la integridad del sistema. El kernel del sistema es el encargado de permitir el acceso a estos dispositivos de forma controlada y para ello se emplean los controladores de dispositivos o device drivers. En Corbet et al. (2005) se define un controlador de dispositivo como un programa que permite al kernel interactuar con un dispositivo de hardware. Estos controladores brindan una abstracción para el acceso a los dispositivos de hardware, traduciendo llamadas al kernel en llamadas específicas del dispositivo. Las aplicaciones no necesitan conocer los detalles de la implementación y el funcionamiento del dispositivo para interactuar con éste, ya que solo deben realizar las llamadas al kernel a través de las interfaces que brinda. Para garantizar el acceso a los recursos o dispositivos de hardware por varias aplicaciones, como se plantea en Tanenbaum (2009), los controladores de. 10.

(30) Capítulo 1. Acerca del desarrollo de sistemas operativos dispositivos y el kernel deben permitir multiplexar o compartir estos recursos en dos formas distintas: en el tiempo y en el espacio. Compartir un recurso en el tiempo no es más que determinar el tiempo que cada aplicación empleará ese recurso; mientras que cuando un recurso se comparte en el espacio varias aplicaciones pueden emplear ese recurso de forma concurrente.. 1.1.4.. Mecanismo de comunicación. La comunicación entre procesos es un método para el intercambio de información entre varios procesos que se pueden estar ejecutando en una misma computadora o en computadoras diferentes. La comunicación también sirve como un mecanismo para la sincronización de varios procesos. Todo este mecanismo debe ser controlado por el kernel del sistema (Tanenbaum, 2009), aunque cada uno de los procesos es responsable de la información que transmite, así como de la interpretación que realiza de la información recibida (Liedtke, 1994, 1995). El kernel solo se encarga de mediar de forma segura la comunicación. Varios son los mecanismos de comunicación que se implementan en los sistemas operativos, los cuales pueden ser implementados a través de archivos, señales, sockets, cola de mensajes, semáforos, memoria compartida, entre otros; no teniendo que estar presentes todas las implementaciones en un kernel. Para garantizar la comunicación entre procesos de forma segura el kernel del sistema debe garantizar un «principio básico para la comunicación», tal como se plantea en Liedtke (1995), el «principio de integridad» garantiza que un subsistema o aplicación A1 se comunique o intercambie información con una aplicación A2 , sin que esta comunicación o intercambio sea corrompida o escuchada por otra aplicación S3 .. 1.1.5.. Llamadas al sistema. Las llamadas al sistema (Tanenbaum, 2009) proveen el mecanismo para la comunicación de las aplicaciones que se ejecutan en modo usuario con el kernel. En muchos sistemas la interacción con los dispositivos de hardware y la comunicación propia entre los programas en ejecución son operaciones que requieren ser ejecutadas por el kernel del sistema. Cuando un programa solicita una llamada al sistema se cambia el modo de ejecución de la CPU al modo privilegiado o kernel, y se le cede el control de la. 11.

(31) Capítulo 1. Acerca del desarrollo de sistemas operativos ejecución al kernel para que éste ejecute la llamada al sistema. Una vez finalizada la llamada al sistema, se retorna la ejecución al programa que realizó la llamada cambiando el modo de ejecución de la CPU al modo usuario (Tanenbaum, 2009; Silberschatz et al., 2013).. 1.2.. Enfoques para el desarrollo de kernel del sistema. Según lo anteriormente expuesto, el kernel es el elemento principal para el funcionamiento del sistema operativo, por lo que cualquier error en el kernel puede hacer colapsar el sistema, de ahí que haya que tener mucho cuidado durante el diseño y la implementación de cada una de las funcionalidades del kernel. Las tendencias o enfoques empleados para el desarrollo del kernel han ido variando con el desarrollo de la propia tecnología. Actualmente existen cuatro grandes enfoques bien determinados para su desarrollo: kernel monolítico, microkernel, kernel híbrido y exokernel. Estos enfoques difieren entre sí por la forma en que se organizan y estructuran las funcionalidades básicas del sistema, tanto dentro como fuera del kernel. Esta organización se refleja directamente en el tamaño del kernel (en LOC) en cada uno de los enfoques y, por tanto, en el TCB del sistema (Vemuri y Al-Hamdani, 2011). Los enfoques de microkernel y exokernel reducen considerablemente el TCB por su tamaño, como se muestra en la Figura 1.1.. Figura 1.1.: Relación de tamaño del TCB en cada uno de los enfoques de desarrollo de kernel del sistema. Los kernels monolíticos y los microkernels han sido los dos enfoques más empleados en el desarrollo de kernel para sistemas embebidos. Estos dos enfoques también han sido objeto de estudios y de grandes comparaciones en cuanto a sus ventajas y desventajas (Roch, 2004), como fue el polémico debate entre Andrew Tanenbaum y Linux Torvalds en los años 90 (DiBona y Ockman, 1999). A partir. 12.

(32) Capítulo 1. Acerca del desarrollo de sistemas operativos de estos dos enfoques ha tomado auge el desarrollo de kernels híbridos, tratando de aprovechar las ventajas de los enfoques anteriores. Los exokernels por sus características solo han sido empleados en aplicaciones muy específicas.. 1.2.1.. Kernel monolítico. Tanenbaum (2009) y Silberschatz et al. (2013) definen un kernel monolítico como una colección de procedimientos enlazados entre sí en un único programa binario. Hasta la fecha el enfoque monolítico para el diseño de kernel es el más utilizado en la construcción de los mismos. En este enfoque todas las funcionalidades básicas del sistema se ejecutan como un solo programa en modo kernel. Con esta técnica cada procedimiento del sistema puede llamar a cualquier otro y solicitar algún servicio de forma directa. Como el sistema tiene miles de procedimientos y estos se pueden llamar entre sí, sin restricciones, esto puede hacer que el sistema sea difícil de comprender (Tanenbaum, 2009). A pesar de esto, el diseño de los kernels monolíticos es más sencillo que el de los microkernels y los otros enfoques (Tanenbaum, 2009; Silberschatz et al., 2013). Los kernels monolíticos se implementan en su totalidad como un único proceso que se ejecuta en un solo espacio de direcciones. Por lo general, en el disco se pueden ver como un único binario estático. En la Figura 1.2 se pueden observar los diferentes servicios o abstracciones de hardware que brinda este enfoque y los cuales se ejecutan en el gran espacio de direcciones del kernel (Love, 2010).. Figura 1.2.: Estructura de un sistema basado en kernel monolítico La comunicación dentro del kernel es trivial, ya que todos los servicios se ejecutan en modo kernel y dentro del mismo espacio de direcciones, pues el kernel puede invocar funciones directamente sin necesidad de realizar un cambio de contexto. Los defensores de este modelo citan la simplicidad y rendimiento del enfoque monolítico. La mayoría de los sistemas Unix tienen un diseño monolítico (Love, 2010).. 13.

(33) Capítulo 1. Acerca del desarrollo de sistemas operativos A diferencia de otros enfoques de desarrollo de kernel del sistema, los kernels monolíticos son más fáciles de diseñar correctamente, ya que el código para el control del sistema es mucho más sencillo y todos los elementos se encuentran en un mismo espacio de direcciones, el espacio de direcciones del kernel. Cuando se realiza alguna modificación al kernel es necesario recompilar el código fuente del kernel por completo. El tamaño del código fuente, expresado en LOC, es considerablemente grande, lo que hace su comprensión más compleja (Roch, 2004), y los hace más vulnerables a la existencia de errores o bugs que pueden provocar la falla del sistema en su totalidad. La implementación más conocida de kernel monolítico es el kernel de Linux. Este desde sus inicios es un kernel monolítico que ha ido evolucionando y actualmente, aunque es modular, o sea, extensible mediante módulos cargables en tiempo de ejecución, continúa siendo un kernel monolítico (Bovet y Cesati, 2000; Love, 2010). Todos los elementos cargados en tiempo de ejecución a través de módulos, así como los controladores de dispositivos, siguen ejecutando en el modo privilegiado, lo cual no permite garantizar la integridad completa del sistema. A pesar de ello, ha sido muy empleado en sistemas embebidos (Acosta et al., 2013; Govindharajan, 2013; Nguyen, 2014; Silva y Silva, 2014; Suppiah y Abbas, 2014) y sistemas de tiempo real (Wang y Lin, 1999; Mantegazza et al., 2000; Dozio y Mantegazza, 2003; Barbalace et al., 2007; Yan et al., 2014). Varios han sido los estudios y trabajos realizados con el objetivo de mejorar la seguridad en estos (Loscocco y Smalley, 2001; Wright et al., 2002; Loscocco et al., 2007; Lombardi y Di Pietro, 2009; Kurmus et al., 2013; Faruki et al., 2015), en algunos casos haciendo empleo de la virtualización (Govindharajan, 2013; Nemati et al., 2015).. 1.2.2.. Microkernel. A diferencia de los kernels monolíticos, los microkernels tienen un enfoque de desarrollo minimalista, donde se debe implementar a nivel de kernel solo los elementos principales que son nombrados conceptos o «primitivas». En Liedtke (1995) se definen cuatro primitivas necesarias y suficientes para el correcto desarrollo de un microkernel: espacio de direcciones, abstracción de procesos, mecanismo de comunicación e identificadores únicos, como se muestra en la Figura 1.3. Este enfoque busca establecer una separación entre los mecanismos y las políticas del sistema operativo. El autor plantea que la definición de las primitivas está dada por la funcionalidad y no por el rendimiento del sistema. Liedtke (1995) considera una primitiva. 14.

(34) Capítulo 1. Acerca del desarrollo de sistemas operativos. Figura 1.3.: Estructura de un sistema basado en microkernel aquel elemento que implementado correctamente fuera del kernel no permite la implementación de las funcionalidades requeridas del sistema. Actualmente la política de planificación de la CPU es la única política que aún se implementa a nivel de microkernel, buscando garantizar la seguridad del sistema, aunque existen algunos trabajos en los cuales se ha incursionado en la planificación a nivel de usuario (Kneib y Reininger, 2014; Zoor y Nagibin, 2014). Las políticas para el manejo de la memoria son implementadas en servidores a nivel de usuario, permitiendo la existencia de varios servidores para la manipulación de la memoria sin que estos entren en conflicto entre sí (Scheuermann, 2002; Klimiankou, 2014). De igual forma, los controladores de dispositivos son implementados a nivel de usuario, implementándose a nivel de microkernel solo los elementos mínimos e indispensables para garantizar la multiplexación de los recursos de forma segura. Adicionalmente a las primitivas, el desarrollo de un microkernel se rige por dos principios básicos, como se plantea en Liedtke (1995), el «principio de independencia» y el «principio de integridad», este último nombrado también «principio básico de la comunicación». El principio de independencia expresa que debe ser posible implementar un subsistema o aplicación A1 arbitrario de forma tal que éste no pueda ser perturbado o corrompido por otro subsistema A2 . Este principio debe dar garantía de independencia de A1 respecto a cualquier otro subsistema A2 . El diseño del kernel siguiendo el enfoque de microkernel tiene el objetivo de lograr una alta fiabilidad del sistema. El sistema se divide en módulos pequeños y bien definidos que con frecuencia son llamados servidores y se ejecutan en modo usuario. De todos los elementos que componen el sistema solo el microkernel se ejecuta en modo kernel (Herder, 2005). Las ventajas que esto brinda es que un. 15.

(35) Capítulo 1. Acerca del desarrollo de sistemas operativos error en uno de los componentes del sistema solo puede afectar el funcionamiento de este componente, pero no compromete el funcionamiento del sistema completo, como se plantea en Tanenbaum (2009); Silberschatz et al. (2013). Al implementar la mayor parte de las funcionalidades y los controladores de dispositivos a nivel de usuario, el modo en que interactúan las aplicaciones con el microkernel y los controladores de dispositivos difiere mucho del esquema de llamadas al sistema empleado en los kernels monolíticos. En los microkernels esta interacción se realiza a través del mecanismo de comunicación (Liedtke, 1995), el cual se realiza, en la mayoría de las ocasiones, utilizando el mecanismo de comunicación segura propuesto en Liedtke (1992) y a través del microkernel en función de garantizar la seguridad del sistema. La comunicación ha sido un elemento crítico en el desarrollo de los microkernels y es conocido como el cuello de botella en el rendimiento. En los inicios del desarrollo de los microkernels se pensó que estos no alcanzaban el rendimiento esperado por la ineficiencia del mecanismo de comunicación. En Liedtke (1994, 1995, 1996) se demuestra que el bajo rendimiento en las primeras generaciones de microkernels era producto de un mal diseño e implementación, por lo que propone los elementos básicos para el diseño de microkernel, así como los elementos básicos del mecanismo de comunicación (Liedtke, 1994), elementos empleados en el desarrollo de los microkernels de la familia L4. Varios son los kernels de sistema que se han diseñado siguiendo este enfoque de microkernel desde sus orígenes en la década de 1980, entre los que se pueden encontrar Mach (Accetta et al., 1986), FreeRTOS (Goyette, 2007), QNX (Hildebrand, 1992), GNU/Hurd (Le Mignot, 2005), Minix (Tanenbaum y S.Woodhull, 2006), Fiasco.OC (TU-DresdenOSGroup, 2015a), OKL4 (Heiser y Leslie, 2010; OpenKernelLabs, 2015), seL4 (Klein et al., 2010). Este último siendo el primer kernel de sistema al cual se le realiza una verificación formal de su especificación.. 1.2.3.. Kernel híbrido. Como su nombre lo indica, el kernel híbrido es un híbrido o combinación del enfoque monolítico con microkernel. Muchos elementos que antes se implementaban a nivel de kernel en el enfoque monolítico ahora son implementados fuera del kernel, lo cual los separa de los kernels monolíticos. Aunque no son considerados monolíticos, tampoco llegan a ser microkernels, pues existen otros elementos que aún se mantiene a nivel de kernel buscando mejoras en el rendimiento y la senci-. 16.

(36) Capítulo 1. Acerca del desarrollo de sistemas operativos llez del sistema, violando los principios para el desarrollo de microkernel definidos por Liedtke (1995).. Figura 1.4.: Estructura de un sistema basado en kernel híbrido El desarrollo de los kernels híbridos por lo general comienza como un kernel monolítico y luego estos van moviendo funcionalidades del sistema fuera del kernel, como es el caso del kernel de Windows, actualmente Windows NT (Probert, 2010). En la Figura 1.4 se muestra cómo está organizado un kernel híbrido de forma general. Otros kernels híbridos son Plan9 (Raymond, 2003), creado en Bell Labs y destinado a la investigación; el kernel XNU (Singh, 2006), desarrollado por Apple Inc. para los sistemas operativos iOS y MacOS X; ReactOS (Filby, 1999), implementado por ReactOS como una alternativa libre a los sistemas operativos de la familia Windows; Netware (Major et al., 1994), desarrollado para el empleo en servidores por Novell Inc.; y Haiku (Leavengood, 2012), un kernel de código abierto para computadoras personales y sucesor del kernel propietario BeOS.. 1.2.4.. Exokernel. El exokernel (Engler et al., 1995; Engler, 1998) es un enfoque para el desarrollo de kernel que, a diferencia de los otros enfoques, brinda la menor cantidad de. 17.

(37) Capítulo 1. Acerca del desarrollo de sistemas operativos abstracciones de hardware sobre el cual se ejecuta, permitiendo el acceso al hardware de forma casi directa por las aplicaciones y a través de las bibliotecas de programación. De tamaño muy reducido, comparado con los enfoques analizados anteriormente, sus funcionalidades están limitadas a garantizar la protección y la multiplexación de los recursos de hardware. La reducida cantidad de abstracciones y el acceso casi directo al hardware hacen que el enfoque exokernel sea mucho más simple que el paso de mensajes de los microkernels y las abstracciones de los kernels monolíticos e híbridos. En la Figura 1.5 se muestra el esquema de un sistema empleando un exokernel.. Figura 1.5.: Estructura de un sistema basado en exokernel Al permitir el acceso de las aplicaciones directamente al hardware, en aplicaciones específicas se pueden optimizar algunas operaciones directas sobre el hardware, como es el caso de la gestión de la memoria y el acceso a disco (Leschke, 2004; Larkby-Lahet et al., 2010). Estudios (Kaashoek et al., 1995; Leschke, 2004; Larkby-Lahet et al., 2010) han demostrado que el empleo de un exokernel para aplicaciones específicas puede aumentar significativamente el rendimiento del sistema. En Kaashoek et al. (1995) se hace un estudio del rendimiento de los exokernels y se optimiza el rendimiento del servidor web Cheetah. El desarrollo de exokernel es un proceso complejo, pues se deben diseñar las interfaces correctas y suficientes para manejar el hardware a bajo nivel y, a la vez, se debe mantener un equilibro entre la seguridad y el tamaño minimalista del sistema. En muchas ocasiones el empleo de varias bibliotecas de programación hacen el proceso de mantenimiento muy complejo. Los exokernels pueden ser empleados en la virtualización como si fuesen hipervisores para multiplexar el hardware subyacente entre varias máquinas virtuales (Tanenbaum, 2009). Varios han sido los proyectos desarrollados bajo el enfoque de exokernel, entre los. 18.

(38) Capítulo 1. Acerca del desarrollo de sistemas operativos cuales se pueden citar ExAmour (2015), Nemesis Nemesis (2015), EXO (2015), XOmB (Larkby-Lahet et al., 2010; XOmB, 2015) y BareMetal (Infinity, 2015).. 1.2.5.. Kernel monolítico vs. microkernel. El kernel monolítico libre más empleado hoy día es el kernel de Linux. Su arquitectura modular, portabilidad y soporte para gran variedad de dispositivos de hardware han permitido su empleo desde sistemas de propósito general hasta sistemas embebidos (Raghavan et al., 2006), como es el caso más conocido en el sistema operativo Android (GoogleInc, 2011). A diferencia del kernel de Linux, los microkernels en su enfoque minimalista disminuyen el tamaño en LOC del TCB, como se muestra en la Figura 1.61 . A partir de la versión 3.0 el kernel de Linux alcanza un aproximado de 2.5 millones de LOC (Wheeler, 2004) sin incluir los controladores de dispositivos de hardware; mientras que los microkernels están en el orden de los miles de LOC, lo cual es una diferencia significativa si se tiene en cuenta que por cada mil LOC es posible encontrar al menos un error o vulnerabilidad (Vemuri y Al-Hamdani, 2011). Como se puede ver en dicha figura, muchos de los elementos que se encontraban a nivel de kernel en el enfoque monolítico, en el microkernel se localizan a nivel de usuario, con lo cual se logra reducir drásticamente el tamaño del kernel y, por tanto, el tamaño del TCB.. Figura 1.6.: Comparación del TCB de un sistema basado en kernel monolítico vs. microkernel Una de las principales ventajas de los microkernels sobre los kernels monolíticos es la extensibilidad del sistema. En un sistema que emplea un microkernel se pueden 1. Tomada de: http://commons.wikimedia.org/wiki/File:OS-structure.svg. 19.

(39) Capítulo 1. Acerca del desarrollo de sistemas operativos agregar nuevas funcionalidades de sistema sin afectar el funcionamiento del mismo y sin necesidad de ser modificado y recompilado, puesto que las funcionalidades son implementadas como aplicaciones a nivel de usuario y se interactúa con ellas a través del mecanismo de comunicación. En cuanto a los sistemas de kernel monolítico, al agregar nuevas funcionalidades de sistema se puede poner en riesgo el propio sistema y es necesario la modificación de algunos subsistemas, así como la recompilación del kernel del sistema para el empleo de la nueva funcionalidad. Otra de las principales diferencias entre estos dos enfoques de diseño de kernel es la recuperación rápida ante fallos, fundamentalmente en los controladores de dispositivos de hardware. En el kernel monolítico la mayoría de los controladores funcionan a nivel de kernel y un controlador defectuoso puede hacer fallar el sistema en su totalidad. A diferencia de lo anterior, los microkernels implementan los controladores a nivel de usuario, por lo que un controlador defectuoso no afecta el funcionamiento del sistema. Estos dos enfoques también difieren en la forma en que las aplicaciones de modo usuario interactúan con las funcionalidades implementadas a nivel de kernel. En el enfoque monolítico esta interacción se realiza a través de las llamadas al sistema, proceso en el cual se cambia el modo de ejecución, del modo usuario al modo kernel. A diferencia de este, en el enfoque de microkernel la interacción se realiza a través del mecanismo de comunicación enviando mensajes al microkernel. Por ejemplo, en la Figura 1.7 se muestra una aplicación haciendo una llamada a un controlador de un dispositivo de hardware. Como se puede observar, en el caso del microkernel es necesario realizar dos cambios de contexto o modo de ejecución, mientras que en el kernel monolítico es suficiente con un solo cambio.. Figura 1.7.: Interacción entre las aplicaciones de un sistema basado en microkernel vs. kernel monolítico (Härtig y Engel, 2014). Como se mencionó anteriormente, este era conocido como el cuello de botella en el rendimiento de los microkernels, pero Liedtke (1994, 1995, 1996) demostró que el bajo rendimiento era producto de una mala implementación.. 20.

(40) Capítulo 1. Acerca del desarrollo de sistemas operativos Ambos enfoques de diseño de kernel han sido empleados para el desarrollo de sistemas embebidos, pero el enfoque basado en microkernel brinda un mejor aprovechamiento del hardware. A diferencia de los kernels monolíticos, los microkernels no proveen una capa de abstracción para la interacción con el hardware, como el caso de la CPU, la FPU y la memoria, estos son implementados de forma específica y optimizada para explotar al máximo todas las funcionalidades del hardware y alcanzar altos niveles de rendimiento.. Consideraciones finales del capítulo En este capítulo se definió el término de kernel del sistema establecido en la bibliografía consultada. Se describieron sus funciones principales dentro del sistema para controlar el acceso al hardware, la planificación de la CPU, administrar el acceso a la memoria física del sistema y los dispositivos de I/O, así como proveer un mecanismo de comunicación en aras de que las aplicaciones puedan intercambiar información entre sí. También se describió la interfaz para la comunicación de las aplicaciones con el kernel del sistema, la cual se conoce como llamadas al sistema. Se describieron los cuatro enfoques más empleados en la actualidad para el desarrollo de kernel de sistemas operativos: kernel monolítico, microkernel, kernel híbrido y exokernel. Cada uno de estos enfoques difieren en cuanto a la organización interna de las funcionalidades del sistema, siendo los microkernels y exokernels dos enfoques minimalistas. Los microkernels proveen una separación de los mecanismos y las políticas del sistema, minimizan el TCB del sistema, lo cual los hace menos vulnerables a errores y disminuye la superficie de ataque al sistema, una característica que los hace más seguros pero que atenta contra el rendimiento.. 21.

(41) Capítulo 2 Selección del microkernel y el framework de la propuesta.

(42) CAPÍTULO 2 SELECCIÓN DEL MICROKERNEL Y EL FRAMEWORK DE LA PROPUESTA En este capítulo se describen algunos de los kernels desarrollados bajo el enfoque de microkernel que se emplean a nivel internacional para el desarrollo de sistemas. Asimismo, se presentan varios frameworks que han sido empleados para el desarrollo de sistemas operativos. A partir de este estudio se definen las herramientas que formarán parte de la propuesta de software base que se presenta en el Capítulo 3.. 2.1.. Microkernels para el desarrollo de sistemas embebidos. Varios han sido los microkernels que se han empleado para el desarrollo de sistemas embebidos a nivel internacional. Muchas de las soluciones hacen uso de microkernels privativos o kernels construidos a la medida para el sistema en que se va a emplear. A continuación se describen algunos microkernels de código abierto que han sido utilizados para el desarrollo de sistemas embebidos y serán la base para la propuesta de software base, uno de los objetivos de la presente investigación.. 2.1.1.. Minix3. Minix es un microkernel desarrollado por Andrew S. Tanenbaum con fines educativos. En 2005 fue reescrito totalmente como un sistema altamente confiable (Herder et al., 2006). Se caracteriza por su modularidad, seguridad, extensibilidad. 22.

(43) Capítulo 2. Selección del microkernel y el framework de la propuesta y estabilidad, aunque tiene una alta complejidad de asimilación para su desarrollo. Desde sus orígenes tiene soporte para la arquitectura Intel x86 y recientemente se le incorporó soporte para la arquitectura ARM (Bravo Navarro et al., 2009). El microkernel no tiene capacidades de tiempo real y se distribuye bajo una licencia BSD que restringe su uso solo para fines educativos. El sistema en general está estructurado por capas: kernel, controladores de dispositivos, servidores y procesos de usuarios. Se emplean colas multinivel con varias colas y diferentes prioridades para la planificación de los procesos. Cada una de estas colas es procesada empleando un algoritmo de planificación Round Robin modificado, teniendo en cuenta prioridades según el orden de la capa a la cual pertenecen. Por ejemplo, los servidores son planificados con mayor prioridad que los procesos de usuarios. También hacen uso del quantum de tiempo, un mecanismo para controlar el tiempo de ejecución en la CPU, el cual es variable entre los procesos. Los controladores de dispositivos están implementados en forma de servidores que se ejecutan en modo usuario.. 2.1.2.. Microkernel de la familia L4. Los microkernels de la familia L4 son un conjunto de microkernels que se derivaron del microkernel L4, como se puede observar en la Figura 2.11 . Este microkernel L4 surgió a partir de las deficiencias encontradas en el diseño y la implementación del microkernel L3, el cual estaba basado en los principios de los microkernels de la primera generación como Mach y Chorus (Liedtke, 1994). Dentro de esta familia se pueden encontrar una variedad de microkernels usados en la actualidad, entre los que se pueden encontrar Fiasco.OC, OKL4, seL4 y el microvisor Nova. Este último solo con soporte para la arquitectura x86. Todos los microkernels de la familia L4 se basan en los principios establecidos por Liedtke (1992, 1994, 1995). De forma general están compuestos por tres mecanismos básicos: hilos, espacio de direcciones, el mecanismo IPC. Los hilos representan la unidad mínima de ejecución de la CPU y en este caso, a nivel del microkernel, solo se representa una abstracción básica para la ejecución de los mismos. Entretanto, el espacio de direcciones es una abstracción para encapsular la ejecución de los hilos de ejecución, asociado directamente a la memoria sobre la cual se ejecuta, pero no se encarga de manejar la memoria. El mecanismo IPC provee la comunicación entre los diferentes hilos de ejecución en el sistema. Este último es el mecanismo más importante del enfoque de microkernel y su 1. Tomada de: http://l4hq.org/projects/kernel/. 23.

(44) Capítulo 2. Selección del microkernel y el framework de la propuesta. Figura 2.1.: Árbol de la familia de microkernels L4 (Las flechas negras indican mayor herencia del código fuente y las flechas verdes una mayor herencia del ABI). implementación está basada en los principios de Liedtke (1994). La gestión de la memoria en los sistemas de la familia L4 suele ser realizada por aplicaciones a nivel de usuario. Las aplicaciones en ejecución pueden dar, a otras aplicaciones, derechos de acceso completo o restringido a secciones de su propia memoria. En estos casos, el kernel solo debe garantizar que se comparta la memoria de una manera segura, proceso que también se conoce como la asignación de memoria.. 2.1.2.1.. Fiasco.OC. El microkernel Fiasco.OC (TU-DresdenOSGroup, 2015a) es un microkernel de tercera generación, desarrollado y mantenido en la TU Dresden, aunque también es mantenido por una amplia comunidad de desarrollo internacional y la empresa alemana Kernkonzept. Tiene soporte para la ejecución de aplicaciones en tiempo real, tiempo compartido y virtualización (Warg, 2003; Werner, 2012), lo que permite que pueda ser empleado para construir sistemas flexibles. Fiasco.OC permite la ejecución de sistemas operativos invitados mediante la paravirtualización, como es el caso de L4Linux y el L4Android, la versión paravirtualizada de Linux y Android, respectivamente. También puede ser empleado para el desarrollo de sistemas complejos y aplicaciones embebidas (Partheymüller et al., 2012; Ludwig, 2011). Tiene un diseño basado en capacidades, de ahí su nombre OC (Object Capability). Las capacidades son un concepto que brindan seguridad y flexibilidad en la estructura del sistema, pues representan una referencia protegida a un objeto. 24.

Figure

Figura 1.1.: Relación de tamaño del TCB en cada uno de los enfoques de desarrollo de kernel del sistema
Figura 1.2.: Estructura de un sistema basado en kernel monolítico
Figura 1.6.: Comparación del TCB de un sistema basado en kernel monolítico vs. microkernel
Figura 2.2.: Estructura jerárquica de GenodeOS para reducir el TCB de una aplicación (Feske, 2015)
+7

Referencias

Documento similar

Pero antes hay que responder a una encuesta (puedes intentar saltarte este paso, a veces funciona). ¡Haz clic aquí!.. En el segundo punto, hay que seleccionar “Sección de titulaciones

Cedulario se inicia a mediados del siglo XVIL, por sus propias cédulas puede advertirse que no estaba totalmente conquistada la Nueva Gali- cia, ya que a fines del siglo xvn y en

Abstract: This paper reviews the dialogue and controversies between the paratexts of a corpus of collections of short novels –and romances– publi- shed from 1624 to 1637:

The part I assessment is coordinated involving all MSCs and led by the RMS who prepares a draft assessment report, sends the request for information (RFI) with considerations,

[r]

[r]

[r]

Ciaurriz quien, durante su primer arlo de estancia en Loyola 40 , catalogó sus fondos siguiendo la división previa a la que nos hemos referido; y si esta labor fue de