Suscríbete a DeepL Pro para poder editar este documento.

Entra en www.DeepL.com/pro para más información.

Sistemas de sensores inalámbricos IET

Número especial: Ciudades inteligentes y plataformas sensoriales inteligentes

Estudio exhaustivo de los sistemas operativos

de código abierto de la IO
Resumen: La Internet de los objetos (IO) ha atraído recientemente gran parte de la atención de la
investigación y de la industria y se prevé que apoye diversos ámbitos emergentes, como las ciudades
inteligentes, la informática sanitaria y las plataformas sensoriales inteligentes. El soporte de sistemas
operativos (SO) para la IO desempeña un papel fundamental en el desarrollo de aplicaciones escalables
e interoperables que sean fiables y eficientes. La IO es implementada tanto por dispositivos de gama
alta como de gama baja que requieren SOs. Recientemente, los autores han sido testigos de la aparición
de una diversidad de sistemas operativos en el entorno de la IO para facilitar su despliegue y desarrollo.
En este estudio, presentan una visión global de los sistemas operativos de código abierto comunes y
existentes para la IO. Cada sistema operativo se describe en detalle en base a un conjunto de aspectos
de diseño y desarrollo que ellos mismos establecieron. Estos aspectos incluyen arquitectura y kernel,
modelo de programación, programación, gestión de memoria, soporte de protocolos de red, soporte de
simuladores, seguridad, consumo de energía y soporte para multimedia. Presentan una taxonomía de
los actuales sistemas operativos de código abierto de la IO. El objetivo de esta encuesta es proporcionar
una guía bien estructurada a los desarrolladores e investigadores para determinar el sistema operativo
más apropiado para cada dispositivo/aplicación específica de la IO en función de sus requisitos
funcionales y no funcionales. Comentan que este es el primer documento de estilo tutorial de este tipo
sobre sistemas operativos de IO.

Introducción
La Internet de los objetos (IO) puede describirse como un sistema dinámico distribuido en red que representa la
revolución tecnológica más vigorosa de la actualidad[1]. La IO es una red que consiste en un gran número de cosas
(por ejemplo, sensores, máquinas o aparatos) que se comunican, envían y reciben datos a través de Internet[2]. El
número de objetos físicos que están conectados a Internet ha crecido exponencialmente[3]. Según el informe de
Gartner Inc., habrá unos 21.000 millones de dispositivos conectados para el año 2020[4]. Hay muchos ámbitos en los
que la IO puede desempeñar un papel esencial y mejorar la calidad de nuestras vidas[5]. Estos dominios y campos
van desde la informática de la salud, el transporte inteligente, las plataformas sensoriales inteligentes, hasta los casos
de emergencia en los que la toma de decisiones humanas puede resultar difícil[6].

Los dispositivos de IO tienen funcionalidades limitadas y una huella mínima, que consumen menos
almacenamiento interno, memoria y potencia de cálculo que los dispositivos típicos[7]. También funcionan con
baterías o están integrados en circuitos integrados. Algunos dispositivos de IO pueden sobrevivir de un mes a varios
años antes de que sea necesario colocar una nueva batería[8]. Sin embargo, ahora, debido a la revolución de la IO,
las funcionalidades de estos dispositivos se están ampliando. Por lo tanto, el dispositivo o el controlador debe ser más
inteligente en la monitorización de varias entradas, en la actualización de eventos en puertas de enlace o dispositivos,
así como en la recepción de comandos desde las puertas de enlace u otros dispositivos[9]. La IO permite a los objetos
físicos ver, oír y realizar varias tareas al permitirles comunicarse entre sí para compartir información y coordinarse a
fin de tomar decisiones[9]. Los dispositivos de IO se consideran heterogéneos y se utilizan en diferentes aplicaciones.
Varios tipos de aplicaciones requieren una arquitectura y un soporte de hardware diferentes que pueden funcionar
con fuentes de bajo consumo. Por lo tanto, es casi imposible tener un sistema operativo (SO) que satisfaga todos los
requisitos de los dispositivos de IO en varios ámbitos[10]. La IO es implementada por dispositivos de gama alta y
baja que requieren sistemas operativos apropiados. Los dispositivos de gama alta pueden funcionar con sistemas
operativos tradicionales (como Linux), mientras que los dispositivos de gama baja funcionan con sistemas operativos
de capacidades limitadas que no pueden realizar la misma tarea que los sistemas operativos tradicionales. Además,
el apoyo del SO a la IO desempeña un papel fundamental en el despliegue de despliegues de IO a gran escala fiables
y escalables. A lo largo de los años, hemos sido testigos de la aparición de diversos sistemas operativos en el entorno
de la IO para facilitar su despliegue y desarrollo. Además, se han dedicado varios trabajos de investigación para
mejorar el rendimiento y las capacidades de los sistemas operativos en diferentes dimensiones.

Con este fin, ofrecemos una visión general de los sistemas operativos de código abierto más comunes para la IO.
La elección de los sistemas operativos de código abierto se debe a que podemos tener más información sobre sus
requisitos y funcionalidades, lo que permite una investigación exhaustiva de dichos sistemas operativos. Este
artículo está escrito en un estilo de tutorial, donde cada sistema operativo se describe en profundidad de acuerdo a
un grupo de aspectos de diseño y desarrollo que nosotros definimos. Comentamos que este es el primer documento
de estilo tutorial de este tipo sobre este tema. El objetivo principal de este documento es proporcionar una guía fácil
de seguir y bien estructurada para los investigadores y desarrolladores de plataformas de IO. En primer lugar,
establecemos un conjunto de aspectos de diseño y desarrollo para los sistemas operativos de la IO con el fin de
ayudar a evaluar y comprender en profundidad cada uno de ellos. En segundo lugar, presentamos una taxonomía
para proporcionar una clasificación de los diferentes tipos de SOs de código abierto para la IO desde diferentes
perspectivas. Luego, estudiamos cada sistema operativo desde los siguientes aspectos: arquitectura y kernel, modelo
de programación, programación, gestión de memoria, protocolos de red, simulador, seguridad, consumo de energía
y soporte para multimedia. Este documento revela las fortalezas y debilidades de cada sistema operativo que se
presentan en él. Finalmente, proporcionamos varios análisis comparativos de los sistemas operativos presentados en
este documento y resumimos sus características.

El resto de este documento está organizado de la siguiente manera. La sección 2 presenta una visión general de
la IO y sus retos, así como de los sistemas operativos existentes para el entorno de la IO. La sección 3 muestra
los aspectos relacionados con el diseño y desarrollo de un sistema operativo de IO. En la sección 4 se ilustra una
taxonomía propuesta para los sistemas operativos de código abierto de la IO. En la Sección 5, discutimos los
sistemas operativos de código abierto para dispositivos de IO de gama baja, mientras que en la Sección 6
presentamos los sistemas operativos de código abierto para dispositivos de IO de gama alta. En la sección 7 se
presentan tres comparaciones entre los sistemas operativos de la IO examinados, seguidas de la conclusión del
presente documento en la sección 8.

2 Background
En esta sección ofrecemos una visión general de la IO y sus retos. También explicamos por qué necesitamos sistemas
operativos diferentes y modificados para la IO.

2.1 Internet de las cosas

El número de dispositivos y máquinas conectados a Internet aumenta exponencialmente[11]. Estos dispositivos y
máquinas crean una red dinámica que consiste en miles de millones de cosas/objetos que se comunican entre sí. Uno
de los principales objetivos de la IO es facilitar el acopio de datos de un punto a otro en cualquier momento y lugar
mediante conexiones eficientes, seguras y fiables[5]. La IO se caracteriza por sus elementos, cosas y sus
representaciones virtuales excepcionalmente identificables en una estructura similar a la de Internet[12]. Las cosas
pueden interactuar entre sí en cualquier momento y lugar, de cualquier manera y desde cualquier dispositivo. Pueden
entrar y salir de la red sin necesidad de limitarse a una única ubicación física para intercambiar datos[13]. En la IO,
millones, si no miles de millones, de dispositivos heterogéneos deberían estar conectados a Internet[14]. Estos
dispositivos varían en potencia computacional, memoria disponible, comunicación y capacidad de energía. El entorno
de la IO consiste en protocolos, diseños de redes y arquitecturas de servicios que tratan un gran número de objetos y
dispositivos de IO para intercambiar datos[15]. Así pues, la IO debe soportar múltiples objetos basados en diferentes
tipos de interfaces radioeléctricas con diversos números de necesidades en relación con los recursos disponibles[16].
Las aplicaciones de la IO se aplican a diferentes ámbitos y disciplinas, como los hogares inteligentes, la vigilancia
del medio ambiente, la asistencia sanitaria, la gestión de inventarios y productos, los detectores de humo e incendios,
el transporte, la seguridad y los sistemas de vigilancia[17, 18].

2.2 Desafíos de la IO
Uno de los retos cruciales de la IO es gestionar, mantener y tratar un enorme número de dispositivos heterogéneos y
los datos generados por ellos. Este enorme número de cosas y objetos conectados entre sí plantea muchos retos
técnicos y de aplicación. A continuación se presentan los principales retos y problemas de la IO:

Heterogeneidad: la IO conecta y gestiona un gran número de dispositivos heterogéneos (por ejemplo, servidores web
completos y otros dispositivos), lo que constituye un reto crítico que tiene diferentes condiciones de funcionamiento,
plataformas, etc. para proporcionar aplicaciones avanzadas que pueden mejorar nuestra vida[18]. Como resultado, la
complejidad aumentará. Por lo tanto, el desarrollo de aplicaciones que se ejecuten en todas las plataformas será
extremadamente difícil y aumentará la necesidad de una arquitectura interoperable estándar[18]. Asimismo, deben
intercambiarse datos de elementos de red heterogéneos a gran escala en autonomía local dinámica con una
convergencia de red altamente eficiente[18].
Problemas de seguridad: Debido al número de dispositivos heterogéneos que intercambian datos a través de Internet,
existe un riesgo para la privacidad de las personas. Esto se debe a que estos dispositivos registrarán grandes cantidades
de datos sobre la vida diaria de las personas que podrían ser recopilados colectivamente para crear un retrato en
profundidad de su presencia[19]. Por lo tanto, es esencial garantizar un canal de datos seguro entre los dispositivos
participantes en la IO. Además, es imprescindible contar con una conexión segura y fiable entre dispositivos
heterogéneos en el entorno de la IO[19].
Escalabilidad: Con un gran número de dispositivos heterogéneos, como sensores inteligentes y bombillas dotadas de
unidades de procesamiento y almacenamiento mínimas, la escalabilidad se convierte en un reto crucial para el
crecimiento actual de la IO[20]. Por ejemplo, el cálculo de las variaciones diarias de temperatura en todo el país
puede requerir millones de dispositivos, lo que resulta en una cantidad sustancial de datos que no pueden ser
fácilmente procesados y administrados. Por ello, la IO necesita compresión y fusión de datos para reducir este
importante volumen de datos[21].

Interoperabilidad: Uno de los principales retos de las aplicaciones de la IO es la interoperabilidad para el cruce de
capas entre los distintos dispositivos y despliegues de la IO[22]. El desafío de la interoperabilidad aparece cuando
los dispositivos heterogéneos utilizan formatos de datos y protocolos diferentes para colaborar en la comunicación
y el intercambio de datos[23]. En las aplicaciones de IO, existen múltiples protocolos, funciones y dispositivos a
nivel de aplicación que compiten entre sí para proporcionar interoperabilidad de comunicación. Cada uno de estos
protocolos mantiene características y arquitectura de mensajería únicas para diferentes tipos de aplicaciones de IO.
Tradicionalmente se construyen con diferentes lenguajes y protocolos. Por lo tanto, es esencial diseñar una
arquitectura IO escalable, llamada capa de middle-ware, para soportar un gran número de dispositivos heterogéneos
y trabajar independientemente de las normas de protocolo de mensajería[22].
Arquitectura: La IO incluye un número creciente de dispositivos y sensores heterogéneos interconectados que a
menudo son transparentes e invisibles. Debido al número de estos dispositivos y máquinas, no se puede aplicar una
arquitectura única a todos estos dispositivos heterogéneos[24]. Las arquitecturas de referencia heterogéneas
adaptadas al entorno de la IO deben ser abiertas y no deben restringir a los usuarios el uso de soluciones fijas o de
extremo a extremo[24]. Además, deben ser flexibles para hacer frente a diferentes despliegues, tales como
identificaciones (identificación por radiofrecuencia, etiquetas), dispositivos inteligentes y objetos inteligentes[24].

2.3 Sistemas operativos para el entorno de la IO

Como cualquier otro software nuevo, un sistema operativo debe integrarse con el entorno existente de la IO. Para
mantener en funcionamiento el complejo entorno de la IO, es necesario personalizar un nuevo sistema operativo
para satisfacer requisitos específicos. Debido a algunas limitaciones que existen en muchos sistemas operativos
tradicionales, no es práctico utilizarlos en la IO, ya que los dispositivos de IO están diseñados con recursos
limitados[25]. El proceso de adopción de un sistema operativo requiere que el sistema operativo sea capaz de hacer
funcionar eficazmente los dispositivos de IO. Además, puede ser necesario personalizar cada dispositivo de IO para
hacer uso de sus componentes que pueden no estar disponibles en otros dispositivos. Hoy en día, estamos rodeados
de muchos dispositivos inteligentes que son diferentes en sus niveles de complejidad dependiendo de sus propósitos.
Todos ellos disponen de un procesador, una memoria para almacenar datos y otros periféricos[9]. Para adaptarse
con éxito a las limitaciones de los dispositivos típicos de IO, es necesario disponer de un sistema operativo adecuado
que permita un control, una conectividad y unas comunicaciones fáciles. Estamos siendo testigos de algunos
sistemas operativos para implementaciones de IO y despliegues a gran escala[25]. Sin embargo, existe una rápida
necesidad de herramientas de desarrollo, estandarización, fácil mantenimiento y portabilidad de aplicaciones a
través de una amplia variedad de plataformas de hardware.

3 Designing y los aspectos de desarrollo de los sistemas operativos de la IO

El sistema operativo es el software de sistema más básico que se ejecuta directamente sobre los recursos de hardware
para actuar como intermediario entre las aplicaciones/usuarios y el hardware. Un sistema operativo contiene
principalmente varios componentes, pero es necesario un núcleo, un software de utilidad y un intérprete de órdenes
del sistema[26]. El núcleo es la parte esencial de un sistema operativo. Es un programa que gestiona todas las
actividades del sistema y da permisos a otros programas y usuarios para realizar cualquier acción[26]. Los sistemas
operativos tradicionales están diseñados para estaciones de trabajo y ordenadores personales (PC) con muchos
recursos. Por esta razón, no son apropiados para dispositivos de IO con recursos limitados y aplicaciones diversas
centradas en los datos. Los dispositivos de IO necesitan un tipo de sistema operativo personalizado, teniendo en
cuenta sus características únicas. Además, los dispositivos de IO requieren una arquitectura de SO completamente
diferente y una amplia gama de soporte de hardware. En esta sección se presentan las principales características y
criterios a tener en cuenta a la hora de diseñar y desarrollar un sistema operativo para dispositivos de IO. Estas
características y criterios se discuten a continuación.

3.1 Arquitectura y modelos de kernel

La arquitectura es uno de los criterios más críticos para diseñar un sistema operativo. El componente principal de
software de un sistema operativo se conoce como kernel. La arquitectura de un sistema operativo tiene un efecto
sobre el tamaño del núcleo y sobre cómo proporcionar servicios a las aplicaciones. Existen principalmente cinco
arquitecturas estándar para el SO: monolítica, microkernel, máquina virtual, modular y de capas[27]. Discutiremos
todas las arquitecturas de SO en las siguientes secciones.

3.1.1 Arquitectura monolítica: Este modelo de arquitectura no sigue ninguna estructura específica, donde la
arquitectura del SO está trabajando en el espacio del núcleo como Linux y Unix. También se le llama arquitectura
multinivel porque las aplicaciones monolíticas se dividen en cuatro o más capas, como presentación, aplicación, base
de datos y capas de negocio. Consiste principalmente en un conjunto de llamadas primitivas o de sistema para acceder
a dispositivos de entrada/salida (E/S), memoria, interrupciones de hardware, la pila de la unidad central de
procesamiento (CPU), sistemas de archivos y protocolos de red[27]. El núcleo monolítico tiene mejor rendimiento
que otros núcleos porque manejan muchos aspectos del procesamiento por ordenador al nivel más bajo[28]. Por lo
tanto, requiere incorporar código que se ocupe de muchos dispositivos, E/S, canales de interrupción y otros
operadores de hardware[28]. La principal desventaja de este tipo de arquitectura es que su funcionalidad tiene una
alta complejidad porque todos sus componentes están colocados en un solo elemento[28]. Por lo tanto, si se modifica
algún componente del programa, hay que reescribir toda la aplicación, lo que puede provocar fallos en la
instalación[28].

3.1.2 Arquitectura de Microkernel: Este modelo arquitectónico se divide en varios procesos separados[28].
Algunos de estos procesos se ejecutan en el espacio del núcleo y otros en el espacio del usuario. La arquitectura del
microkernel proporciona sólo las principales funcionalidades de los sistemas operativos, como la programación, la
comunicación entre procesos (IPC) y la sincronización. Todas las demás funcionalidades del sistema operativo,
incluidos los controladores de dispositivos y las bibliotecas de sistema, funcionan en hilos[28]. La arquitectura del
microkernel proporciona una alta flexibilidad de implementación. Por lo tanto, permite añadir características
adicionales como plugins a la aplicación principal, y proporcionar extensibilidad de manera eficiente y fácil. Además,
permite construir otros SOs sobre este microkernel como Windows NT[28].

3.1.3 Arquitectura VM: Esta arquitectura permite al usuario ejecutar un sistema operativo en otro sistema operativo
para permitir un mayor grado de portabilidad y flexibilidad del software[29]. Un sistema operativo que se ejecuta en
esta arquitectura se llama SO huésped, y la máquina virtual se suele llamar hipervisor[29]. El hipervisor se puede
ejecutar en la parte superior de un sistema operativo. La VM se implementa a menudo como una combinación de
máquina real y software de virtualización. El hipervisor proporciona acceso a los recursos de hardware para el sistema
operativo a través de interfaces específicas. Su principal ventaja es su portabilidad, mientras que su principal
desventaja es el bajo rendimiento del sistema[29].

3.1.4 Arquitectura modular: Esta arquitectura permite reemplazar o añadir componentes del kernel dinámicamente
en tiempo de ejecución. En un kernel modular, algunos componentes con funcionalidad similar se ubicarán en
archivos separados llamados módulos que pueden ser configurados y manejados para varios tipos de funcionalidades
fácilmente[28].

3.1.5 Arquitectura en capas: Esta arquitectura consiste en varias capas, en las que cada capa se construye sobre la
de abajo[30]. La capa inferior (capa 0) es la capa de hardware, y la capa superior (capa n) es la capa de interfaz de
usuario. La arquitectura en capas es manejable, fácil de entender y confiable. La principal desventaja es que no son
una arquitectura muy flexible desde el punto de vista del diseño del sistema operativo porque requiere una definición
adecuada de las diferentes capas y una planificación precisa de la correcta colocación de una capa[30].

3.2 Modelo de programación y entorno de desarrollo

El modelo de programación representa el estilo de programación aplicado para crear un software que se utiliza
principalmente para guiar el desarrollo a través de los lenguajes de programación. Muchos factores influyen en la
elección de un modelo de programación apropiado, como el mecanismo de control de la concurrencia, el diseño de
la jerarquía de la memoria y otros factores[31]. Existen dos tipos de modelos de programación: multihilo y
programación basada en eventos[31]. El multihilo es el modelo más familiar para los desarrolladores, pero no se
considera adecuado para dispositivos con recursos limitados, como los sensores. La programación basada en eventos
es el modelo más común para escribir programas. Es útil para el desarrollo de dispositivos de IO, pero se considera
inconveniente para los desarrolladores de aplicaciones tradicionales[27].

A veces es necesario modificar el comportamiento de los dispositivos y sus algoritmos, ya sea por su
funcionalidad o por sus propiedades de consumo de energía. Por lo tanto, el sistema operativo debería poder
reprogramarse y actualizarse cuando sea necesario[32]. Sin embargo, un kit de desarrollo de software (SDK) para
un sistema operativo proporciona el marco de software para que los programadores interactúen con diferentes
microcontroladores, sensores y dispositivos para que funcionen en dispositivos IoT. El SDK consiste en un conjunto
de bibliotecas[33]. Además, debe proporcionarse una interfaz de programación estándar (API), como la interfaz de
sistema operativo portátil (POSIX) o la biblioteca de plantillas estándar (STL), para facilitar el desarrollo de
programas informáticos y simplificar la transferencia de los programas informáticos existentes[34]. Además,
cuando un código se propaga, todo un sistema operativo puede estar en un estado disfuncional porque varios
programas se ejecutarán simultáneamente. Este tiempo de transición entre programas se considera tiempo perdido
y, por lo tanto, energía agotada. A este respecto, debe utilizarse una técnica de reprogramación eficaz y robusta para
propagar y mantener rápidamente el nuevo código[35].

3.3 Programación
La selección de la estrategia de programación está estrechamente ligada a las capacidades de un sistema para
cumplir con los requisitos en tiempo real, con el fin de apoyar las diferentes prioridades y grados de interacción con
los usuarios[34]. Existen diferentes algoritmos de programación, como los programadores basados en prioridades
y los no basados en prioridades. Los programadores basados en prioridades se clasifican en preventivos y no
preventivos. Los programadores preventivos seleccionan la tarea de mayor prioridad para ejecutar incluso si hay
otra tarea en ejecución. Los programadores no preventivos esperarán hasta que la tarea en ejecución inferior
complete su ejecución en el procesador[36]. La programación preventiva se llama así porque es posible interrumpir
los procesos durante la ejecución. El procesador puede cambiar del estado de listo o en espera al estado de
funcionamiento. La programación no preventiva se lleva a cabo cuando un proceso termina o pasa de funcionar a
un estado de espera. Se llama no preventiva porque los procesos no pueden ser interrumpidos o programados[36].

3.4 Gestión y rendimiento de la memoria

En un sistema operativo tradicional, la gestión de memoria se refiere al método de asignar y anular la asignación de
memoria para las operaciones. Existen dos técnicas convencionales de gestión de memoria: los métodos de gestión
de memoria estática y dinámica[27]. El método de gestión de memoria estática es simple y útil cuando se trata de
recursos de memoria limitados. Sin embargo, los resultados son inflexibles debido a la asignación de memoria de
tiempo de ejecución que no puede ocurrir. Por otro lado, el método de gestión de memoria dinámica es más flexible
porque la memoria se puede asignar y desasignar en tiempo de ejecución. Una protección de la memoria de proceso
también es importante, lo que significa la protección de un espacio de direcciones de proceso frente a otro para
evitar interferencias o pérdidas de datos no autorizadas[27]. El sistema operativo debe estar diseñado con la huella
más pequeña para proporcionar el rendimiento más rápido, incluidas las operaciones de memoria. La gestión de la
memoria y el rendimiento son características significativas de los dispositivos de IO y es la razón principal por la
que tantos sistemas operativos sofisticados no pueden adaptarse fácilmente a los dispositivos de IO[32].

3.5 Soporte de protocolos de comunicación y de red

Otro aspecto importante a la hora de elegir o diseñar un sistema operativo es la comunicación y el protocolo de red
soportado. Los protocolos especifican las interacciones entre las diferentes entidades comunicantes. Existen a
diferentes niveles en una conexión de telecomunicaciones[37]. La elección de un protocolo de comunicación y de
red optimizado para una aplicación concreta es esencial[37]. Especialmente, con una amplia gama de protocolos de
comunicación y redes tales como fidelidad inalámbrica (WiFi), ZigBee, Bluetooth, y tecnologías celulares de segunda
generación (2G)/3G/4G, etc. [37]. También hay varios protocolos de comunicación y redes nuevos y crecientes, como
thread como alternativa para las aplicaciones domésticas y las tecnologías de televisión en espacios en blanco que se
pueden aplicar en las ciudades. Confiar en la aplicación y en sus factores, como los requisitos de datos, la seguridad
y el consumo de energía, determinará la elección de los protocolos de comunicación y de red más adecuados[38]. Los
dispositivos de IO pueden conectarse directamente utilizando tecnologías celulares como la 2G/3G/4G celular, o
pueden conectarse a través de una pasarela, formando una red de área local, para obtener una conexión a Internet[37,
38]. Las tecnologías de computación ubicua mencionadas, como los sensores integrados, la comunicación ligera y
los protocolos de Internet (IP), son esenciales para la IO[37]. Sin embargo, imponen varios desafíos e introducen la
necesidad de normas y protocolos de comunicación específicos[37]. Los procesos se comunican entre sí dentro del
mismo sistema o con otro diferente o incluso con otros procesos en dispositivos heterogéneos. Por lo tanto, los
sistemas operativos de la IO deben proporcionar protocolos de comunicación y de red y también debe tenerse en
cuenta la heterogeneidad[27, 37].

3.6 Soporte de simulación

Simulador se refiere al proceso de imitar un sistema operativo en otro u otro dispositivo. Las simulaciones y
emulaciones también pueden hacer que los programas se ejecuten en SOs que antes no estaban pensados para
ellos[27]. El simulador del sistema operativo proporciona diversos grados de escalabilidad y detalle para comprender
el comportamiento de los dispositivos de IO en dos aspectos principales de los recursos de un sistema informático, a
saber, la memoria y la gestión de procesos. La interfaz de usuario principal para el simulador de SO contiene una
CPU, donde todos los códigos están disponibles para el simulador para crear múltiples instancias del código como
procesos separados[27].

3.7 Seguridad
Con el tremendo progreso de la IO, más y más objetos/cosas se conectarán a Internet. Por lo tanto, es esencial
garantizar un canal de datos seguro entre los dispositivos participantes en la IO[39]. Además, es imprescindible contar
con una conexión segura y fiable entre dispositivos heterogéneos en un entorno de IO[19, 39]. Las entidades de IO
no serán en su mayor parte ni de un solo uso ni de una sola propiedad. Los dispositivos, las cosas y las políticas de
control podrían tener un uso, políticas, administración y conectividad diferentes. En consecuencia, se ordenará a los
dispositivos que tengan acceso abierto a algunos usuarios de datos. Teniendo en cuenta que la información recopilada
puede contener información personal de los usuarios, es esencial garantizar la seguridad de los dispositivos en la IO.
Generalmente, estos dispositivos de IO están limitados en recursos, memoria y potencia computacional. Además, son
más susceptibles a los ataques que otros dispositivos de punto final, como ordenadores, tabletas o teléfonos
inteligentes. Uno de los retos a los que se enfrenta la seguridad de la IO es que sus componentes pasan la mayor parte
del tiempo desatendidos, de modo que pueden ser atacados físicamente. Otro reto es que la mayoría de las
comunicaciones en la IO son inalámbricas, lo que hace que la escucha a escondidas sea extraordinariamente fácil.
Además, los dispositivos de IO no pueden aplicar esquemas de seguridad complicados debido a sus capacidades
limitadas[40].
La seguridad es una prioridad absoluta y debe considerarse también en el hardware, ya que, al ser similar a los
ordenadores de sobremesa convencionales, existen graves problemas. Los dispositivos de IO se ampliarán a la
mayoría de los aspectos de nuestras vidas, por lo que tenemos que superar estas dificultades y desafíos[41].
Para proporcionar seguridad, existen varias técnicas de seguridad tradicionales, como actualizaciones de parches,
análisis de seguridad, comprobación y eliminación de virus, detección de intrusiones y otras técnicas de seguridad.
Sin embargo, estas técnicas e instrumentos pueden utilizarse para una pequeña parte del sistema de IO que
difícilmente puede superarse con el rápido crecimiento de las amenazas y los ataques a la seguridad. El sistema de
seguridad del módulo de plataforma de confianza (TPM) de la IO es una tecnología diseñada para proporcionar
funciones basadas en hardware y relacionadas con la seguridad. Los chips de hardware TPM se pueden utilizar con
cualquier sistema operativo[42]. Un chip TPM almacena claves criptográficas que se utilizan para el cifrado que se
establece en la placa base del ordenador. Cuando está habilitado, el TPM proporciona capacidades completas de
cifrado de disco. Se convierte en la"fuente de confianza" para que el sistema proporcione integridad y autenticación
al proceso de arranque. Mantiene los discos duros bloqueados hasta que el sistema completa una comprobación de
autenticación o una verificación del sistema. El chip incluye los siguientes módulos de confianza: usuario,
percepción, terminal, red y un agente. Estos módulos están especialmente diseñados para evitar las diferentes
amenazas a la seguridad en las aplicaciones de la IO[42]. Además, los problemas de seguridad de la IO pueden
describirse desde la capa de red, como los ataques de sensores, las anomalías de los sensores, las interferencias
radioeléctricas, la seguridad del contenido de la red, la intrusión de hackers y la autorización ilegal. Sin embargo, la
IO puede tener que hacer frente a muchos problemas de seguridad en el nivel de aplicación, como el control de
acceso a las bases de datos, la tecnología de protección de la intimidad, la tecnología de seguimiento de fugas de
información, la tecnología de destrucción segura de datos informáticos y la tecnología de protección de productos
electrónicos seguros y la propiedad intelectual de los programas informáticos[42].

3.8 Consumo de energía

La eficiencia energética es una limitación crucial con los dispositivos portátiles que funcionan con baterías[43]. Los
modelos de potencia se desarrollan a partir de mediciones físicas en la plataforma de hardware. En ciertas
situaciones, se requiere que las baterías funcionen durante al menos 10 años. Aunque la utilización de la energía
depende principalmente de la selección del hardware, los sistemas operativos que mantienen las características de
gestión de la energía son capaces de gestionar eficientemente las aplicaciones para mejorar la duración de la batería
y permitir largos ciclos de inactividad en la medida de lo posible[44]. El sistema operativo representa el componente
principal del software y determina la potencia total en muchas ejecuciones de aplicaciones modernas. La selección
del sistema operativo puede tener un impacto significativo en el consumo de energía de un sistema operativo tanto
de forma activa como pasiva. Una manera activa cuando hay una gestión activa de la energía, ya que el SO puede
tomar acciones específicas para controlar, limitar u optimizar el consumo de energía del dispositivo, mientras que
en un modo pasivo, las características arquitectónicas del SO tienen un efecto indirecto sobre el consumo de
energía[44].

3.9 Soporte de multimedia

Algunas aplicaciones de IO pueden requerir que los sistemas operativos soporten tipos de datos con restricciones
de tiempo, como aplicaciones de medios de transmisión en tiempo real, juegos distribuidos y entornos virtuales en
línea. La mayoría de los sistemas operativos tradicionales son incompatibles con estas limitaciones de tiempo, y
también están mal adaptados al procesamiento multimedia, ya que los requisitos de los usuarios cambian
dinámicamente. Además, el apoyo a los programas informáticos multimedios comerciales en tiempo real tiene el
requisito adicional de que el sistema operativo debe prever el control y la comunicación de la utilización de los
recursos entre las actividades independientes en tiempo real. Además, las fuentes de audio y vídeo generan datos
que necesitan un procesamiento exhaustivo para ser comprimidos y decodificados para su transmisión. El
intercambio de datos se produce desde estas fuentes a otros destinos como altavoces y vídeo situados en el ordenador
o en otra estación remota. Los datos multimedia se procesan en el camino desde la fuente hasta el fregadero a través
de operaciones de copia, movimiento y transmisión. Los sistemas operativos gestionan los recursos donde se
produce el procesamiento de datos. El sistema operativo debe ser capaz de procesar audio y vídeo, y la cantidad de
datos que hay que transferir puede ser sustancial[45].
La Fig. 1 resume las principales características y aspectos tratados en esta sección. Utilizamos estos aspectos de
diseño y desarrollo para evaluar los sistemas operativos de código abierto de IO analizados en nuestra encuesta.

4 Classifications de los sistemas operativos de la IO

Los sistemas operativos se pueden clasificar según diferentes criterios. Por ejemplo, se pueden clasificar por su
código fuente abierto o cerrado. Además, se pueden categorizar según el propósito de su diseño en un sistema
operativo de IO especialmente diseñado o en una versión personalizada de un sistema operativo existente. Otra
clasificación para los SOs es dividirlos en basados en Linux o no basados en Linux. Por último, los sistemas
operativos pueden clasificarse en función de los dispositivos de destino, ya sean dispositivos de IO de gama alta o
dispositivos de IO de gama baja.
En las fuentes abiertas, el código está a disposición de cualquiera para que el usuario pueda utilizar el código
distribuido libremente, y modificarlo incluso con fines comerciales para adaptarlo a un requisito particular como el
sistema operativo Linux. Los SOs de código cerrado utilizan código que es implementado por partes privadas y se
mantiene inédito para tener control total sobre el SO y mantener su propiedad[9]. Un sistema operativo se suele
clasificar en dos ecosistemas de software diferentes. El primero está basado en Linux, y el segundo no está basado
en Linux. Linux OS es una plataforma cruzada de código abierto basada en Unix OS que se puede instalar en PCs,
servidores y otro hardware. Por otro lado, el sistema operativo no-Linux no está basado en Linux o Unix, sino que
depende de otros sistemas operativos como Windows y ReactOS.

La última clasificación de los sistemas operativos de la IO se basa en la capacidad y el rendimiento de los

dispositivos de la IO; pueden clasificarse en dos categorías. La primera categoría se refiere a los dispositivos de IO
de gama alta, que incluyen ordenadores monopuesto como el Raspberry Pi (RPi). Los dispositivos IoT de gama alta
pueden ejecutar sistemas operativos tradicionales como Linux. La segunda categoría corresponde a los dispositivos
de IO de gama baja, que tienen recursos limitados y no pueden funcionar con los sistemas operativos tradicionales.
Un ejemplo de dispositivos IoT de gama baja es Arduino.
En este artículo, nos centramos en los sistemas operativos de código abierto más utilizados y más avanzados
debido al límite de páginas. Para los sistemas operativos de código cerrado de IO, hemos publicado recientemente un
artículo sobre este tema[46]. La Fig. 2 muestra una taxonomía propuesta de sistemas operativos de IO de código
abierto basados en dispositivos de IO de gama baja o alta, y en sistemas operativos basados en Linux y no basados
en Linux desde una perspectiva de alto nivel.

5 OSs para dispositivos de IO de gama baja

En esta sección describiremos los sistemas operativos de gama baja más utilizados para dispositivos de IO a partir de
los aspectos y criterios presentados en la Sección 3. El objetivo principal de esta sección es proporcionar una
comprensión exhaustiva de cada sistema operativo de IO de gama baja.
5.1 TinyOS
TinyOS es un sistema operativo de código abierto no basado en Linux diseñado explícitamente para dispositivos de
IO de gama baja, dispositivos integrados e inalámbricos como redes de nodos de sensores, edificios inteligentes y
plataformas sensoriales inteligentes[47]. TinyOS está basado en un componente de software reutilizable[47]. Está
escrito utilizando el lenguaje de programación NesC, que tiene una sintaxis similar al lenguaje C[47]. Cada
componente de TinyOS tiene un marco y una estructura de variables privadas. Estos componentes tienen tres
abstracciones computacionales: comandos, eventos y tareas[47, 48]. Los comandos se utilizan para llamar a un
componente para realizar una tarea específica. Los eventos son mecanismos para introducir la comunicación de
componentes, mientras que las tareas se utilizan para representar la concurrencia de componentes[49].

5.1.1 Arquitectura y modelos de kernel: TinyOS tiene una arquitectura monolítica y utiliza una arquitectura
basada en componentes que depende de los requisitos de la aplicación. Esto reduce el tamaño del código necesario
para configurar el hardware[47]. Los diferentes componentes se agrupan con el programador para ejecutarse en la
plataforma mote. La plataforma mote tiene recursos físicos muy insuficientes dependiendo de qué componentes
están activos. Las motas típicas de TinyOS consisten en un microprocesador sin etapas de tuberías (MIPS)
entrelazadas y decenas de kilobytes de almacenamiento. Un componente es un elemento computacional
independiente que muestra una o más interfaces. Los componentes tienen tres abstracciones computacionales:
comandos, eventos y tareas. Los mecanismos para la comunicación entre componentes son comandos y eventos,
mientras que las tareas se utilizan para expresar la concurrencia entre componentes. Un comando es una petición
para realizar algún servicio mientras que las señales de evento representan la finalización del servicio[27, 47]. La
Fig. 3 muestra la arquitectura de TinyOS. El programador programa la operación de esos componentes. Cada
componente consta de cuatro partes: manejadores de comandos, manejadores de eventos, un marco encapsulado de
tamaño fijo y un grupo de tareas. Los comandos y tareas se realizan en el contexto de la trama y operan en su estado.
Cada componente declara sus comandos y eventos para permitir la modularidad y la fácil interacción con otros
componentes[32].

5.1.2 Modelo de programación y entorno de desarrollo: TinyOS soporta un modelo de concurrencia basado
en eventos que consiste en interfaces de fase dividida, computación diferida y eventos asíncronos[31]. TinyOS está
programado en NesC para limitaciones de memoria de redes de sensores que son similares pero no compatibles con
el lenguaje C. Permite escribir fragmentos de código reutilizable que indican explícitamente sus dependencias[47].
Además, TinyOS utiliza un mecanismo llamado Trickle. Trickle es un algoritmo utilizado para propagar y mantener
actualizaciones de código cuando sea necesario. Trickle aplica una política de chismes cortés, donde los nodos
ocasionalmente transmiten código a todos los nodos vecinos, y permanecen en silencio. Cuando un nodo escucha
un resumen más antiguo por sí mismo, transmite una actualización en lugar de enviar una señal de red con paquetes.
Luego, el algoritmo gestiona el proceso de envío, de modo que cada nodo sólo oye un pequeño chorrito de paquetes
que es suficiente para mantenerse al día. Trickle propaga el nuevo código en segundos y hace que el coste de
mantenimiento sea menor en términos de tiempo (propagación del nuevo código a todos los nodos de los
vecinos)[35]. El principal desafío en el desarrollo de TinyOS es la creación de componentes flexibles y
reutilizables[49].

5.1.3 Programación: El programador de tareas en TinyOS es un simple programador no preventivo de primero en

entrar, primero en salir (FIFO) usando una estructura de datos de programación de tamaño limitado. El programador
de TinyOS pone el procesador en reposo cuando se completan las tareas; para maximizar la utilización de la CPU así
como el rendimiento del sistema operativo[50].

5.1.4 Gestión y rendimiento de la memoria: TinyOS utiliza la asignación de memoria estática con protección de
memoria. No hay conceptos de asignación de memoria dinámica como pilas ocultas, memoria dinámica o punteros
de funciones porque los programas TinyOS están organizados en componentes y escritos en lenguaje NesC[47].
TinyOS ocupa poco espacio, ya que utiliza una programación de tareas FIFO no preventiva. Aplica un reloj de
sincronización en el software, que aumenta el número de entradas en la cola de tareas en el momento de la
compilación, cuando el sistema comienza con 1, 32 kHz o 1 MHz

5.1.5 Soporte de protocolos de comunicación y red: TinyOS tiene soporte incorporado para protocolos de
red comunes como el protocolo de control de transmisión (TCP), protocolo de datagrama de usuario (UDP), ICMPv6,
IPv6, IPv6 sobre WPAN de bajo consumo (6LoWPAN), protocolo de enrutamiento IPv6 para redes de bajo consumo
y con pérdidas (RPL), y protocolo de aplicación restringida (CoAP), además del protocolo de enrutamiento de
hidrógeno que se utiliza para comunicaciones fiables[51].

5.1.6 Soporte de simulación: Para validar el modelo de análisis de las aplicaciones de TinyOS, se ha desarrollado
un entorno de simulación de TinyOS Simulation (TOSSIM). La simulación TinyOS (TOSSIM) proporciona una
simulación de alta flexibilidad de las aplicaciones TinyOS que funcionan sustituyendo componentes por
implementaciones de simulación[47]. Además, TOSSIM proporciona a los desarrolladores un entorno integrado de
la red y capacidades de resolución de problemas. Las aplicaciones del lado del servidor pueden conectarse a un proxy
TOSSIM sólo si se trata de una red de sensores real. De este modo, se facilita la transición entre la simulación y los
despliegues reales[47]. TOSSIM también proporciona integración de soporte para la resolución de problemas y
depuración de aplicaciones directamente en el mote. Desafortunadamente, TOSSIM no soporta la recopilación de
medidas de potencia[47].
5.1.7 Seguridad: TinyOS utiliza la librería TinySec, que fue desarrollada utilizando el lenguaje de programación
NesC e implementada por la capa de enlace para proporcionar confidencialidad, autenticación de mensajes, integridad
y seguridad semántica[52]. El cifrado de bloque predeterminado en TinySec es el algoritmo Skipjack que se utiliza
con el método de encadenamiento de bloque de cifrado (CBC-CS). El listado tiene una longitud de clave de 80 bit
que proporciona inmunidad a los ataques de fuerza bruta[52]. El listado genera un método de código de autenticación
de mensajes (MAC) que utiliza CBC-MAC[52]. Sin embargo, CBC-MAC tiene carencias de seguridad ya que
proporciona seguridad semántica con un vector de introducción a 8 B que incluye sólo una sobrecarga de contador
en 2 B por paquete[52]. TinySec tiene una sobrecarga de energía, inactividad y velocidad de transferencia de
<10%[52].

5.1.8 Consumo de energía: TinyOS proporciona un funcionamiento eficiente de bajo consumo de energía y
almacenamiento limitado utilizando un modelo de ejecución simple[44]. El modelo de ejecución de TinyOS se basa
en operaciones de fase dividida e interrumpe a los manipuladores. Permite al programador reducir la utilización de
la memoria de acceso aleatorio (RAM) y mantener fácilmente el código de sincronización. Esto evita la necesidad de
hilos y permite que todos los programas se ejecuten en una sola pila. Sin embargo, implica que si un código de
sincronización se ejecuta a largo plazo, impide que se ejecute otro código de sincronización, lo que puede influir
negativamente en la capacidad de respuesta del sistema[44].

5.1.9 Soporte multimedia: TinyOS admite una pila completa de redes IP, con protocolos IP estándar como UDP,
TCP y el protocolo de transferencia de hipertexto (HTTP) que se utilizan para transmitir contenido multimedia. Los
frameworks disponibles para códecs de video y streaming multimedia son limitados en este sistema operativo y no
tienen soporte extendido. Además, el protocolo de transporte en tiempo real (RTP) no se encuentra en la base de
TinyOS[53].

5.1.10 Más información sobre TinyOS: TinyOS aplica operaciones de fase dividida sin bloqueo que permiten a
los desarrolladores redefinir la API del núcleo eligiendo un conjunto de operaciones existente o implementando una
pila de llamadas del sistema. En este método, todas las operaciones de E/S que duran más de unos pocos cientos de
microsegundos son asíncronas y tienen una llamada de retorno conocida como llamadas de procedimiento
diferido[47].

5.2 Contiki OS
Contiki es un sistema operativo de código abierto no basado en Linux para dispositivos de IO de gama baja
diseñados especialmente para IO. Es un sistema operativo ligero, altamente portátil y multitarea que funciona con
pequeños microcontroladores de bajo consumo de energía con una memoria mínima. Contiki OS está escrito en el
lenguaje de programación C. Utiliza 2 kB de RAM y 40 kB de memoria de sólo lectura (ROM). Hoy en día, Contiki
se puede ejecutar en varias plataformas de hardware como Alf y Vegard RISC procesador (AVR), MSP430, y
Z80[31, 52, 54].

5.2.1 Arquitectura y modelos de kernel: A diferencia de TinyOS. Contiki OS tiene una arquitectura
modular[25]. El núcleo del sistema operativo Contiki consiste principalmente en múltiples programadores de
eventos ligeros y un mecanismo de sondeo. El programa de eventos es responsable de enviar eventos para ejecutar
procesos y llama periódicamente a los manejadores de sondeo de los procesos, que identifican la acción del proceso
sondeado[31]. Por otro lado, el mecanismo de votación identifica los eventos de alta prioridad. El mecanismo de
sondeo es utilizado por los procesos que operan cerca del hardware para comprobar las actualizaciones de estado
de los dispositivos de hardware. Todos los procesos que implementan un gestor electoral se solicitan en orden de
prioridad[54]. La Fig. 4 muestra la arquitectura de Contiki OS. Contiki OS contiene manejo de datos de sensores,
protocolos de comunicación y controladores de dispositivos como servicios. Cada servicio tiene su interfaz y su
implementación.

5.2.2 Modelo de programación y entorno de desarrollo: A diferencia de TinyOS, los modelos de programación de
Contiki son compatibles tanto con multithreading como con el uso de protothreads. La principal ventaja de los
protohilos es su mínima sobrecarga de memoria sin necesidad de apilarlos. Dado que los eventos se ejecutan hasta
su finalización, Contiki no permite la interrupción de los handlers para publicar nuevos eventos, y no permite la
sincronización de procesos[27]. Los modelos de programación con Contiki se definen por eventos de manera que
todas las tareas se ejecutan en el mismo contexto[52]. El mecanismo Protothreads se ejecuta en la parte superior del
kernel controlado por eventos. Un proceso protohilo se invoca cada vez que un proceso recibe un evento, y el
mecanismo de los protohilos decide qué memoria debe asignarse[55]. Contiki es implementado por bibliotecas de
sistemas que están conectadas con programas. Los programas pueden conectarse con las bibliotecas de tres maneras.
En primer lugar, los programas pueden conectarse estáticamente con las bibliotecas que forman parte del núcleo de
Contiki. En segundo lugar, los programas pueden vincularse estáticamente con las bibliotecas que forman parte del
programa que se puede cargar. En tercer lugar, los programas pueden llamar a los servicios utilizando una biblioteca
específica. Las bibliotecas que se aplican como servicios pueden ser reemplazadas dinámicamente en el tiempo de
ejecución. Considere un programa que utilice las funciones memcpy() y atoi() para copiar memoria y convertir
cadenas en enteros, respectivamente. La función memcpy() es una función de biblioteca C de uso frecuente; mientras
que atoi() se utiliza con menos frecuencia. Por lo tanto, en este ejemplo, memcpy() ha sido incluido en el núcleo de
Contiki pero no atoi(). La función memcpy() se enlazará con su dirección estática en el núcleo cuando el programa
se enlaza para producir un binario. El código objeto de la parte de la librería C que implementa la función atoi()
debe, sin embargo, incluirse en el programa binario[31]. Además, Contiki utiliza módulos cargables para realizar
reprogramación y actualización de código dinámico. Con los módulos cargables, sólo es necesario modificar partes
específicas de los códigos cuando se cambia un solo programa[56]. Además, Contiki proporciona un shell de línea
de comandos que es útil durante el desarrollo y depuración de los sistemas Contiki[57].

5.2.3 Programación: La programación utilizada en el sistema operativo Contiki es similar a la de TinyOS, en la que
ambos utilizan la estrategia de programación FIFO. En Contiki, toda la programación orientada a eventos se realiza
en un solo nivel y eventos (multitarea preventiva); los eventos se ejecutan a medida que llegan[31].

5.2.4 Gestión y rendimiento de la memoria: A diferencia de TinyOS, Contiki soporta la asignación o

deslocalización dinámica de memoria a través de mmeb() y mmem() así como malloc(). El asignador de bloques de
memoria memb() es el más utilizado. El asignador de memoria gestionada mmem() se utiliza con poca frecuencia y
utiliza el asignador de memoria en pila estándar de la biblioteca C malloc()[58]. Además, Contiki utiliza la técnica
del sistema de archivos de café Contiki para el almacenamiento de datos dentro de la red de sensores. Permite que
existan múltiples archivos en la misma memoria flash física[58].

5.2.5 Soporte de protocolos de comunicación y red: Contiki OS soporta muchos protocolos como CoAP y el
transporte de telemetría de colas de mensajes (MQTT)[59]. Además, las dos principales pilas de comunicación son
uIP y Rime, que consisten en un conjunto de protocolos ligeros personalizados para redes inalámbricas con
restricciones de energía[59]. Contiki soporta una pila de red IP completa con protocolos IP estándar como UDP, TCP
y HTTP[60]. Además, tiene soporte para la capa de adaptación 6LoWPAN, el protocolo de enrutamiento multi-hop
RPL IPv6 y el protocolo de capa de aplicación CoAP RESTful[61].

5.2.6 Soporte de simulación: El simulador de Cooja soporta Contiki, que es una herramienta útil para el
desarrollo de aplicaciones del sistema operativo Contiki. Cooja hace que la simulación sea colosalmente menos
exigente al proporcionar un entorno de simulación que permite probar el código antes de ejecutarlo en los
dispositivos de hardware de destino[62].

5.2.7 Seguridad: Contiki OS utiliza ContikiSec transport layer security (TLS)/datagram transport layer security
(DTLS), que es una capa de red segura, y contiene tres modos: autenticación, confidencialidad e integridad en la
comunicación. ContikiSec utiliza un bajo consumo de energía y seguridad a la vez que cumple con una pequeña
huella de memoria[52].

5.2.8 Consumo de energía: Contiki está diseñado para funcionar con dispositivos de baja potencia que pueden
necesitar seguir funcionando durante bastante tiempo con baterías[63]. Para ayudar a mejorar el consumo de energía
de los dispositivos de bajo consumo, Contiki proporciona un mecanismo de perfil de energía basado en software
para estimar la utilización de energía del sistema y para saber dónde se consumió la energía, lo que permite tomar
conciencia de la energía[62].

5.2.9 Soporte multimedia: Contiki soporta todos los protocolos de pila de red IP como UDP, TCP y HTTP que
se utilizan para transmitir contenidos multimedia. Los frameworks disponibles para códecs de vídeo y streaming
multimedia son limitados en este sistema operativo y no tienen soporte extendido. Además, el protocolo RTP no se
encuentra en la base de Contiki.

5.2.10 Más información sobre el sistema operativo contiki: Una de las características esenciales de Contiki es
la carga dinámica, que es la capacidad de conectar módulos en tiempo de ejecución[64]. Los nodos transferidos
por Contiki pueden funcionar con baterías gracias al mecanismo de ciclo de servicio de radio ContikiMAC que
permite que los nodos se duerman entre cada mensaje retransmitido[65]. A diferencia de TinyOS que no tiene
operaciones de bloqueo, Contiki proporciona algún bloqueo condicional de funciones en un bloque de instrucciones
secuencial.

5.3 Sistema operativo en tiempo real para sistema operativo IoT (RIOT)
El RIOT es conocido como'el sistema operativo amigable para el IoT'. RIOT es un sistema operativo de código
abierto no basado en Linux especializado en dispositivos IoT de gama baja con un mínimo de 1.5 kB de RAM
y 5 kB de ROM[66]. RIOT proporciona una abstracción uniforme sobre los detalles de los diferentes hardwares de
IoT. Fue desarrollado por una comunidad de base utilizando el lenguaje de programación C. RIOT puede funcionar
en varias plataformas, incluyendo sistemas embebidos, y es fácil de usar. Soporta muchas funcionalidades como el
manejo de interrupciones, gestión de memoria, IPC y sincronización. Además, RIOT tiene muchas ventajas como
fiabilidad, previsibilidad, rendimiento y escalabilidad[67].

5.3.1 Arquitectura y modelos de kernel: A diferencia de otros Oss como TinyOS o Contiki RIOT tiene una
arquitectura de microkernel, que ha sido diseñada para trabajar en varias plataformas de IOT con diferentes
arquitecturas de CPU (32 bit, 16 bit, 8 bit) tales como ARMv7, ARM Cortex-M0 + , MSP430, y algunos
microcontroladores AVR recientes. La arquitectura del microkernel de RIOT OS fue desarrollada usando C + +, y soporta
el multithreading completo que proporciona una API amigable para el desarrollador y permite la programación de
aplicaciones C + + y ANSI C.El kernel RIOT nunca se bloqueará porque soporta controladores de dispositivos de error.
El diseño de la arquitectura de RIOT también contiene conformidad con POSIX[42, 68]. La Fig. 5 muestra la
estructura del RIOT, que se divide en cuatro capas. La primera capa es el kernel; que consiste en el programador, la
comunicación entre procesos, el enhebrado, la sincronización de hilos, las estructuras de datos de soporte y las
definiciones de tipos. La segunda capa es el código específico de la plataforma (placas de CPU), que contiene la
configuración para esa CPU en particular. La tercera capa son los controladores de dispositivos, que consisten en los
controladores para dispositivos externos tales como interfaces de red, sensores y actuadores. La cuarta capa
comprende bibliotecas, código de red y aplicaciones para demostrar características y pruebas. Además, esta capa
incluye una colección de scripts para varias tareas así como documentación de entorno predefinida (doc)[67].

5.3.2 Modelo de programación y entorno de desarrollo: RIOT es similar a Contiki que también soporta el
multihilo preventivo. RIOT se desarrolla utilizando lenguajes de programación estándar como ANSI C y C + +[69]. Con
RIOT, los desarrolladores pueden codificar la aplicación una vez y ejecutarla en varios dispositivos de hardware IoT.
Además, RIOT proporciona APIs de programadores comunes como los sockets de distribución de software de
Berkeley (BSD) o las funcionalidades POSIX thread (pthread)[70]. Además, RIOT puede ejecutar y depurar lo mismo
que en Linux y MacOS usando un conjunto de herramientas de depuración populares como GNU Debugger (GDB)
y Valgrind [67]. Las capacidades de programación C + + utilizadas en RIOT permiten a RIOT utilizar potentes librerías
como la Wiselib, que contiene algoritmos para enrutamiento, clustering, sincronización de tiempo, localización y
seguridad. RIOT tiene otras características de programación como el soporte de enlaces dinámicos, el intérprete
Python y el perfilador de energía[71]. Además, RIOT proporciona virtualización, donde el código y la aplicación
pueden ejecutarse como un simple proceso Unix. RIOT utiliza Wireshark para el análisis de paquetes[67].

5.3.3 Programación: Junto con Contiki. RIOT implementa una programación preventiva basada en prioridades y
sin cosquillas, donde cada tarea tiene una prioridad de ejecución que ayuda al programador a seleccionar la tarea de
mayor prioridad para ejecutarse en la CPU. Las tareas RIOT con la mayor prioridad se ejecutan primero, y si hay
más de una tarea de alta prioridad, se utilizará un mecanismo de rodeo (RR)[71].

5.3.4 Gestión y rendimiento de la memoria: En el sistema operativo RIOT, se proporcionan asignaciones de

memoria dinámica y estática para las aplicaciones[72]. RIOT OS no tiene una unidad de gestión de memoria (MMU)
o unidad de punto flotante. Sin embargo, tiene una huella de memoria baja del orden de unos pocos kBs[66, 68].

5.3.5 Soporte de protocolos de comunicación y red: RIOT OS soporta varios protocolos de red incluyendo
TCP/IP v4 y v6 y los últimos estándares para conectar sistemas restringidos al grupo de trabajo de ingeniería de
Internet (IETF) 6LoWPAN[72]. Además, RIOT tiene soporte incorporado para otros protocolos de red relacionados
con IoT como CoAP y RPL[73].

5.3.6 Soporte de simulación: En el momento de escribir este artículo, RIOT OS no tiene un simulador. Más bien,
podemos tener una simulación a escala real para aplicaciones RIOT desde el simulador Contiki-Cooja para IoT[67].

5.3.7 Seguridad: RIOT soporta potentes capacidades de detección de ataques llamadas ecosistema cibernético-
físico seguro (CPS). CPS es un sistema que interactúa, monitorea y controla objetos inteligentes a través de procesos
complicados. Cuando se detecta un ataque, entonces se produce la reacción a él[69].

5.3.8 Consumo de energía: La simplicidad de la arquitectura del micronúcleo de RIOT es la característica

principal para permitir la máxima eficiencia energética[67]. El cambio de contexto RIOT puede ocurrir en dos
situaciones. La primera situación es cuando una operación de kernel correspondiente es llamada por sí misma, como
un bloqueo de mutex. La segunda situación es cuando se produce una interrupción en un interruptor de hilo.
Afortunadamente, la primera situación ocurrirá de vez en cuando. Entonces, cuando el kernel de RIOT es llamado
de nuevo, se puede realizar un cambio de tarea en muy pocos ciclos de reloj[71]. Además, RIOT OS es una
plataforma de software excepcionalmente adecuada para optimizar el consumo de energía en dispositivos basados
en microcontroladores alimentados por batería (MCU) y consume menos energía[68].

5.3.9 Soporte multimedia: RIOT soporta todos los protocolos de pila de red TCP/IP, como UDP, TCP y HTTP,
que se utilizan para transmitir contenido multimedia. Dispone de numerosos módulos embarcados que son
esenciales para el desarrollo de aplicaciones multimedia[71].

5.4 LiteOS
LiteOS es un sistema operativo ligero basado en Linux de código abierto diseñado para funcionar en dispositivos
de bajo consumo. Esto hace que LiteOS sea adecuado para una amplia gama de áreas, incluyendo casas inteligentes,
vehículos conectados y microcontroladores. LiteOS puede instalarse en dispositivos que funcionan con el sistema
operativo Google Android y puede conectarse con otros dispositivos de terceros. Está desarrollado con el propósito
de proporcionar un sistema operativo similar a Unix para los desarrolladores de IO y para proporcionar a los
programadores paradigmas de programación familiares, como un sistema de archivos jerárquico desarrollado
utilizando el lenguaje de programación LiteC y un shell similar a Unix[27, 74].

5.4.1 Arquitectura y modelos de kernel: A diferencia de RIOT, LiteOS tiene una arquitectura modular dividida
en tres subsistemas: LiteShell, LiteFS y el núcleo[32] como se muestra en la Fig. 6. LiteShell es un shell tipo Unix
que proporciona soporte para comandos de shell tales como administración de archivos, administración de procesos
y depuración. LiteShell reside en una estación base o un PC. Este apalancamiento permite comandos más complejos,
ya que la estación base o el PC tienen abundantes recursos. La LiteShell sólo se puede utilizar con la intervención
del usuario. Parte del procesamiento local se realiza en el comando de usuario por la shell y luego se transmite de
forma inalámbrica al nodo IoT deseado. El nodo IoT realiza el procesamiento requerido del comando y envía una
respuesta que se muestra al usuario. Cuando un mote no ejecuta los comandos, se devuelve un código de error. El
segundo componente arquitectónico de LiteOS es su sistema de archivos, LiteFS, que consiste en nodos de sensores
en forma de archivo y monta una red de sensores como directorio y luego lista todos los nodos de sensores de un
salto como archivo. Un usuario en la estación base puede usar esta estructura de directorios como la estructura de
directorios de Unix tradicional y también puede usar comandos legítimos. El tercer subsistema de LiteOS es el
núcleo que reside en el nodo IoT. El kernel soporta multithreading de concurrencia, carga dinámica, y utiliza RR
y programación de prioridades, lo que permite a los desarrolladores registrar manejadores de eventos a través de
funciones de devolución de llamada[27].

5.4.2 Modelo de programación y entorno de desarrollo: LiteOS es un sistema operativo multitarea que
soporta multithreading. En LiteOS, los procesos ejecutan aplicaciones en subprocesos separados. Cada hilo tiene
su memoria asignada que ayuda a proteger la memoria. LiteOS también proporciona soporte para el manejo de
eventos[27]. Además, soporta mecanismos dinámicos de reprogramación y reemplazo a través de la aplicación de
usuario. La reprogramación puede realizarse tanto si el código fuente del sistema operativo está disponible como si
no. Si está disponible, se recompilará fácilmente con nuevos ajustes de memoria, y todos los punteros de la versión
antigua serán redirigidos, mientras que si el código fuente no está disponible, utiliza un mecanismo de parcheo
diferencial para actualizar la versión antigua. Además, LiteOS soporta la depuración en línea, incluyendo relojes
variables y un gran número de puntos de interrupción. Además, contiene extensas librerías de desarrollo[76].

5.4.3Programación : LiteOS implementa tanto la programación basada en prioridades como en RR en

el kernel. La tarea a ejecutar se selecciona de la cola de preparación mediante la programación basada en
prioridades. Cuando una tarea requiere un recurso que no está disponible actualmente, la tarea permite
interrupciones y pasa al modo de reposo[32].

5.4. 4Gestión y rendimiento de la memoria : LiteOS implementa la asignación de memoria

dinámica con una sobrecarga casi nula a través de las llamadas del sistema utilizando funciones de API
malloc() y free(). La función malloc() asigna memoria mediante un puntero. Si el tamaño de la memoria es
cero, malloc() regresa a NULL o a un valor de puntero único que se puede pasar a la función free(). La
función free() libera el espacio de memoria, que debe haber sido devuelto por una llamada previa a la función
malloc(). Esto permite adaptar el tamaño de la memoria dinámica según lo requiera una aplicación[77].

5.4.5Soporte de protocolos de comunicación y de red: LiteOS no tiene protocolos de red

incorporados que soporten aplicaciones en tiempo real[77]. LiteOS proporciona soporte para la conexión de
larga distancia basada en tecnologías como la evolución a largo plazo (LTE) y NodeB (NB)-IoT, y la
conexión de corta distancia basada en protocolos de comunicación como ZigBee y 6LoWPAN[74].

5.4. 6Soporte de simulación : El simulador AVRORA puede utilizarse para emular LiteOS en
dispositivos físicos de IO. AVRORA es un conjunto de herramientas de simulación para programas escritos
para el microcontrolador del AVR. AVRORA contiene un sistema adaptable para la simulación y prototipado
de programas, que permite la experimentación, perfilado e investigación de APIs Java[78].

5.4.7Seguridad : En términos de seguridad, LiteOS proporciona espacio de usuario independiente y

separación de aplicaciones a través de un conjunto de llamadas al sistema. El mecanismo de autenticación es
necesario entre la estación base y las motas montadas, especialmente los mecanismos de autenticación de bajo
coste. Para garantizar la seguridad de las comunicaciones entre los sensores y los sistemas, LiteOS tiene un
componente de seguridad mediante la incorporación del chip Hi3519 Huawei Lite OS que puede ser
implementado en cámaras de seguridad y cámaras portátiles de alta definición[74].

5.4. 8Consumo de energía : LiteOS soporta un consumo de energía ultra bajo; puede ser usado para
ejecutar motes MicaZ con 128 B de memoria flash, 4 kB de RAM y 8 MHz de CPU. La batería LiteOS puede
alimentar un dispositivo durante cinco años o más[74, 79].

5.4.9Soporte de multimedia: LiteOS no soporta ninguna implementación de protocolos de red que soporten
aplicaciones multimedia[27].

5.4.10Más sobre LiteOS: LiteOS ofrece muchas características novedosas, incluyendo la configuración cero,
la detección automática, la conexión en red automática, el arranque rápido, un sistema de archivos jerárquico, una
interfaz de shell inalámbrica para la interacción con el usuario y operaciones en tiempo real. También proporciona
un amplio soporte inalámbrico que incluye LTE y redes de malla[60]. LiteOS es compatible con Windows XP,
Windows Vista y Linux, además de con los nodos MicaZ e IRIS. Además, es compatible con la pila de
enrutamiento plug-and-play. Otras ventajas de LiteOS son que tiene un registro de eventos extremadamente ligero y
un sistema de archivos jerárquico incorporado. Finalmente, LiteOS instantánea un estado de la hebra y puede
restaurarla a un estado anterior[74].

5.5FreeRTOS
FreeRTOS es un sistema operativo de código abierto no Linux, multitarea, preventivo y en mini tiempo real para
dispositivos de IO de gama baja, desarrollado principalmente utilizando C y algunas funciones de ensamblaje[80].
Es muy escalable, simple, fácil de usar y altamente portátil. Su principal fortaleza es el pequeño tamaño del núcleo,
lo que hace posible ejecutar diferentes aplicaciones pequeñas. Otra ventaja es que FreeRTOS soporta una amplia
variedad de arquitecturas de hardware, lo que lo convierte en una buena elección para ser utilizado con diferentes
aplicaciones IoT[81, 82].

5.5.1Arquitectura y modelos de kernel: FreeRTOS tiene una arquitectura de sistema operativo en tiempo real
(RTOS) de microkernel, que está diseñada para ser pequeña, simple y fácil de usar[28]. El kernel de FreeRTOS está
diseñado específicamente para procesadores embebidos. FreeRTOS consiste en la capa de hardware, el controlador
de dispositivo, el kernel de FreeRTOS y las tareas a realizar. La Fig. 5 muestra la arquitectura de FreeRTOS.

5.5. 2Modelo de programación y entorno de desarrollo: FreeRTOS está desarrollado profesionalmente. Es de

código abierto gratuito y totalmente compatible, incluso cuando se utiliza en aplicaciones comerciales. Sin embargo,
FreeRTOS redujo los esfuerzos de depuración debido a la falta de capa de abstracción de hardware (HAL) mediante
el uso del firmware STM32Cube MCU[83]. Además, FreeRTOS soporta múltiples hilos, mutexes, semáforos y
temporizadores de software[77]. Todos los núcleos de FreeRTOS contienen tres o cuatro archivos C (dependiendo
del uso de coroutines) que son: (i) list.c, (ii) queue.c, y (iii) tasks.c, y un archivo fuente de microcontrolador. El
archivo tasks.c realiza la mayoría de las funcionalidades del programador de ensamblador. El list.c define las
estructuras y funciones que debe utilizar el archivo tasks.c. El queue.c realiza colas seguras de hilos que se utilizan
para la sincronización y la comunicación entre tareas. Estos archivos se incluyen en el archivo.zip relacionado
únicamente con las aplicaciones que hacen que el código sea más legible y mantenible. La API de FreeRTOS está
diseñada para ser simple y fácil de usar[84].

5.5.3Programación : El planificador utilizado en FreeRTOS es un planificador de prioridades fijas,

preferente o cooperativo, dependiendo de la configuración del planificador[77]. Una programación de prioridad fija
asegura que el procesador ejecute la tarea de mayor prioridad que esté lista para ser ejecutada en cualquier momento
utilizando la política de programación RR[77].

5.5.4 Gestión y rendimiento de la memoria : FreeRTOS soporta la asignación dinámica de memoria, y su huella
de memoria es pequeña[84].

5.5. 5Soporte de protocolos de comunicación y de red: FreeRTOS utiliza los protocolos de red
6LoWPAN y CoAP[85] además del código abierto, y la pila thread-safe TCP/IP para FreeRTOS llamada
FreeRTOS + TCP[85].

5.5. 6Soporte de simulación : FreeRTOS puede ser simulado tanto en sistemas operativos Windows como
Linux usando los siguientes simuladores. Simulador de Win32 usando visual studio 2015 para Windows OS y
desarrollado por Dushara Jayasinghe[84], mientras que el simulador POSIX/Linux se usa para Linux OS usando
GNU Compiler Collection (GCC) y Eclipse proporcionado por William Davy[84].

5.5.7 Seguridad : FreeRTOS utiliza WolfSSL, que es una librería ligera TLS/secure sockets layer (SSL). WolfSSL
se utiliza para proporcionar seguridad, autenticación, integridad y confidencialidad de las comunicaciones a través
de FreeRTOS. WolfSSL es el más adecuado para el sistema embebido, ya que ocupa 20 veces menos espacio que la
biblioteca OpenSSL[84, 86].

5.5. 8Consumo de energía : Para que el microcontrolador funcione en el estado de bajo consumo,
FreeRITOS utiliza un gancho de tarea inactivo. Usando este método, disminuye el consumo de energía a través de
las interrupciones de las garrapatas del proceso. Sin embargo, si se producen demasiadas interrupciones de
garrapatas, el consumo de energía aumentará más que el límite de ahorro de energía. El modo sin cosquillas de
FreeRTOS es un modo inactivo que detiene la interrupción periódica de tictac durante los períodos de inactividad.
De este modo se realiza un ajuste de corrección del valor de recuento de garrapatas RTOS cuando se reinicia la
interrupción de garrapatas[84] (Fig. 7).

5.5.9Soporte de multimedia: FreeRTOS está diseñado para aplicaciones de baja potencia, lo que deja el costoso
proceso de codificación/decodificación a los dispositivos externos. Sin embargo, el soporte de pila TCP y UDP en
FreeRTOS puede ser utilizado para implementar algunas aplicaciones limitadas a contenidos de imagen usando
Javascript y HTML5.

5.5.10Más sobre FreeRTOS: Este sistema operativo se recomienda para manejar tareas en las que el tiempo
es crítico y que requieren control del usuario y monitoreo de sensores, ya que puede ser manejado a través de
múltiples subprocesos, temporizadores de software y semáforos, junto con el modo sin cosquillas para un bajo
consumo de recursos mientras se ejecutan varias aplicaciones.

5.6Apache Mynewt OS
Apache Mynewt es un sistema operativo de código abierto, basado en Linux y en tiempo real desarrollado
originalmente por Runtime Inc. y alojado por Apache. El sistema operativo de Mynewt se dirige a los dispositivos
de gama baja que tienen capacidades de memoria y almacenamiento limitadas y que necesitan funcionar durante
mucho tiempo con limitaciones de energía. Además, el sistema operativo Mynewt tiene muchas características
poderosas como la reconfigurabilidad precisa de las conexiones concurrentes y los controles de potencia
granular[87].

5.6.1Arquitectura y modelos de kernel: Mynewt OS tiene una arquitectura modular. Mynewt apunta a las
arquitecturas ARM Cortex M0-M4 y RISC-V con un plan para extender el soporte de hardware a la arquitectura
MIPS[88]. Además, Mynewt OS es compatible con los procesadores Arduino Zero, Arduino Zero Pro y Arduino
M0 Pro[88, 89].

5.6. 2Modelo de programación y entorno de desarrollo: El SO Mynewt soporta tareas multihilo[89]. Los
desarrolladores pueden depurar el código estableciendo puntos de ruptura, evitando roturas de pilas y eliminando
interrupciones robadas[89].

5.6.3Programación : Mynewt OS soporta la programación preventiva basada en prioridades sin

cosquillas[89].

5.6.4 Gestión y rendimiento de la memoria : El sistema operativo Mynewt soporta la asignación de pilas de
memoria y grupos de memoria[87].

5.6.5Soporte de protocolos de comunicación y de red: Mynewt OS proporciona soporte completo para la suite
TCP/IP. También soporta protocolos para redes restringidas como CoAP y 6LoWPAN[87]. Además, Mynewt OS
ha implementado completamente la pila Bluetooth 4.2 de bajo consumo de energía, la malla Bluetooth, LoRa PHY
y LoRaWAN[87].

5.6. 6Soporte de simulación : Mynewt puede ser simulado usando el emulador rápido (QEMU).

5.6.7 Seguridad : El sistema operativo Apache Mynewt permite realizar actualizaciones remotas seguras para
mantener la seguridad continua. Además, Mynewt OS proporciona un cargador de arranque seguro para verificar la
integridad y autenticidad del firmware[89], y utiliza el protocolo de gestión de seguridad para emparejar y
transportar la distribución específica de claves para asegurar la comunicación por radio[89].

5.6. 8Consumo de energía : Mynewt tiene un bajo consumo de energía; los dispositivos funcionan en
modo de reposo para conservar la energía de la batería y maximizar el uso de energía[87].

5.6.9Soporte de multimedia: En el momento de escribir este artículo, no hay soporte para contenidos multimedia
o dispositivos en el SO Apache Mynewt.

5.6.10Más sobre Apache Mynewt: HAL se utiliza en Mynewt para proporcionar una interfaz uniforme para
periféricos a través de diferentes microcontroladores, que permiten el acceso directo a los periféricos para el control
de potencia granular[89].

5.6.11ARM Mbed OS: ARM Mbed es un sistema operativo basado en Linux de código abierto para
dispositivos de IO de gama baja con licencia Apache.
2. Los núcleos de ARM lo introducen para los microcontroladores ARM Cortex M de 32 bits .
Es compatible con todos los estándares abiertos esenciales para la conectividad y la gestión de dispositivos. ARM
Mbed OS proporciona una plataforma que incluye las siguientes características: conectividad, seguridad, servicios
de gestión de la nube y funcionalidades de gestión de dispositivos que requieren los dispositivos de IO[33, 90].

5.6.12Arquitectura y modelos de kernel: ARM Mbed OS soporta arquitectura monolítica[25]. ARM Mbed
OS funciona en una arquitectura embebida ARM de 32 bits y es compatible con algunas otras plataformas[91]. La
Fig. 8 muestra la arquitectura del sistema operativo ARM Mbed y sus diferentes capas.

5.6. 13Modelo de programación y entorno de desarrollo: ARM Mbed OS usa un solo hilo y adopta un modelo
de programación basado en eventos[91]. ARM Mbed OS se desarrolla utilizando los lenguajes de programación C y
C + +. Además, tiene muchas características de programación que permiten a los desarrolladores seleccionar entre
diferentes tipos de microcontroladores. Además, la API de Mbed puede mantener el código de la aplicación legible,
simple y portátil[91].

5.6.14Programación : Mbed OS incluye un programador básico no preventivo con primitivas de

sincronización y comunicación limitadas para soportar sus protocolos de comunicación y nube[91].

5.6. 15Gestión y rendimiento de la memoria : ARM Mbed OS soporta la asignación de memoria

dinámica[91].

5.6.16Soporte de protocolos de comunicación y de red: Mbed OS es compatible con muchos protocolos de

comunicación como WiFi, Bluetooth de bajo consumo, M2M ligero (LwM2M) y Ethernet[92]. Además, soporta
varios protocolos de red, incluyendo la pila HTTP/CoAP con TLS y DTLS para seguridad IP de extremo a extremo
(v4 y v6) con 6LoWPAN, SSL y MQTT[10, 93].

5.6. 17Soporte de simulación : El sistema operativo de Mbed puede ser simulado usando QEMU, que es un
emulador y virtualizador de máquinas genérico y de código abierto[94].

5.6.18Seguridad : Los códigos no fiables y maliciosos se bloquean en el sistema operativo de Mbed para
plataformas de IO a medida que se producen las comunicaciones entre el dispositivo y la nube, y el ciclo de vida del
propio sistema se produce a través de uVisor, que separa los dominios de seguridad de los microcontroladores Arm
Cortex-M3, M4 y M7 con una unidad de protección de memoria[91]. Existen dos mecanismos para garantizar la
seguridad en Mbed mediante la integración con el desarrollo de la aplicación. El primero es Mbed TLS para
capacidades criptográficas y SSL/TLS. El segundo es Mbed OS uVisor para dominios seguros reforzados por
hardware[94].

5.6. 19Consumo de energía : El sistema operativo de Mbed es compatible con una técnica avanzada de
gestión de la energía que aumenta la eficiencia energética y mejora el rendimiento[94]. Esta técnica permite apagar
algunos dispositivos externos y el procesador para apagar los dispositivos no utilizados dentro del chip del
procesador y entrar en los modos de suspensión de bajo consumo. También es posible modificar la velocidad de
reloj en el sistema operativo Mbed de 128 a 48 MHz[94].

5.6.20 Soporte multimedia: Los módulos de imágenes pueden integrarse fácilmente en el sistema operativo de
Mbed a través de un conjunto de sensores de imágenes disponibles como una extensión. El streaming de contenidos
multimedia se puede realizar utilizando una simple conexión TCP o cualquier otro protocolo de comunicación de
alto nivel[94].

5.6.21Más sobre el sistema operativo ARM Mbed: El conector de dispositivos Mbed puede conectar
dispositivos IoT a la nube sin necesidad de infraestructura adicional[91].

6 OSs para dispositivos de IO de alta gama

En esta sección describiremos los sistemas operativos más utilizados para los dispositivos de IO de gama alta a
partir de los aspectos y criterios presentados en la Sección 3.

6.1 Sistema operativouClinux

uClinux es un sistema operativo basado en Linux de código abierto para dispositivos de gama alta. Es una extensión
del núcleo de Linux. El núcleo uClinux incluye una colección de versiones del núcleo de Linux 2.x destinadas a
microcontroladores individuales sin una MMU. Además, tiene un conjunto de aplicaciones de usuario, bibliotecas y
cadenas de herramientas. Este sistema operativo necesita un soporte especial para la comunicación entre
procesadores[77, 78].

6.1.1Arquitectura y modelos de núcleo: el SO uClinux sigue una arquitectura monolítica[95]. El núcleo uClinux
soporta varias plataformas de CPU como ColdFire, Axis ETRAX, y otras. La principal diferencia con el sistema
operativo Linux es que tiene MMU-less. Sin embargo, el sistema operativo uClinux soporta adicionalmente
diferentes sistemas de archivos, incluyendo archivos diseñados especialmente para las soluciones integradas
similares al sistema operativo Linux. Ha habido intentos anteriores de lograr la compatibilidad entre uClinux y
Linux para que uClinux sea lo más parecido posible a Linux. Estos intentos propusieron varias aplicaciones que se
desarrollaron bajo licencia pública general. Estas aplicaciones deberían soportar la versión MMU-less de Linux con
pocos cambios[95]. La Fig. 9 muestra la arquitectura del sistema operativo uClinux.

6.1. 2Modelo de programación y entorno de desarrollo: el SO uClinux soporta el modelo de programación

multihilo[97]. uClinux incluye una plataforma de compiladores cruzados que se construye a partir de las
herramientas de compiladores GNU (GCC). Su arquitectura es x86, que a menudo se construye sin la posibilidad de
ser modificado en cualquier objetivo uClinux. La depuración se puede realizar usando el depurador de GNU
(gdb)[98].

6.1.3 Programación : uClinux implementa una programación preventiva basada en prioridades[77].

6.1. 4Manejo y rendimiento de la memoria : uClinux se deriva a partir del núcleo Linux 2.0 y está diseñado para
microcontroladores sin MMUs, por lo que cualquier proceso puede leer y escribir otra memoria de proceso.
Proporciona asignación de memoria dinámica y estática[99]. Sin embargo, el sistema operativo uClinux tiene el
inconveniente de que el hardware de gestión de memoria no se ajusta al dispositivo IoT de gama baja[25].

6.1.5Soporte de protocolos de comunicación y de red: uClinux OS utiliza protocolos de red uIP y lwIP[95].
uClinux también tiene un amplio soporte de protocolos de comunicación y de red incluyendo una pila completa de
TCP/IP, IPv6, WiFi y otros protocolos de red[95].

6.1. 6Soporte de simulación : uClinux puede ser simulado usando GDB/ ARMulator y el emulador
SWARM-Software ARM-arm7. ARMulator está desarrollado utilizando el lenguaje de programación C y
proporciona algo más que un simple simulador de conjuntos de instrucciones; proporciona una plataforma virtual
para emulaciones de sistemas. Puede emular un procesador ARM y otros co-procesadores ARM[98].

6.1.7Seguridad : el sistema operativo uClinux aplica un proceso Shepherd para gestionar los problemas de
seguridad[100]. Un proceso de pastoreo es responsable de acceder a la asociación de seguridad, y luego de dejar
caer ese acceso cuando se produce un viaje de root. uClinux consta de tres primitivas principales: registrar, iniciar y
finalizar. Cada una de estas primitivas se comunica con el núcleo para ejecutar sus funciones particulares. Además,
uClinux aplica la técnica de seguridad de almacenamiento encriptado que fuerza los overheads criptográficos.
uClinux soporta la interceptación en tiempo de ejecución de las diferentes llamadas del sistema. Por ejemplo, los
archivos abiertos y en ejecución pueden hacer que estas llamadas tarden más tiempo. Cuando se inicia un viaje de
root, el proceso Shepherd utiliza un registro para realizar cualquier acción de seguridad a través de la comunicación
con el kernel y se le debe permitir dejar caer su asociación de seguridad antes de que termine ese viaje de root.
Cuando un registro termina su función, el proceso de pastoreo puede realizar su tarea para lograr la seguridad. Por
ejemplo, el mount-efs lee la clave secreta del sistema de archivos UCLinux (UCFS) desde/etc/crypt.key y la
canaliza al cryptsetup. Luego, configura un dispositivo de loopback criptográfico y monta el sistema de archivos. A
continuación, su asociación de seguridad se vuelve accesible; un proceso de pastor utiliza la acción de inicio para
dormir el proceso de pastor y sólo lo despierta cuando ocurre un viaje de raíz. Cuando se despierte, debe abandonar
su asociación de seguridad. Finalmente, cuando el proceso de pastoreo está seguro de que su asociación de
seguridad está protegida, utiliza el acabado preventivo a través de la comunicación con el núcleo para completar el
viaje de raíz. Por lo tanto, permita que los programas no confiables se ejecuten con un usuario efectivo privilegiado.
De esta manera, cualquier número de asociaciones de seguridad puede ser totalmente protegido[100].

6.1. 8Consumo de energía : uClinux soporta técnicas de gestión de energía que pueden ser modificadas,
de modo que el proceso en reposo puede ser llamado cuando ningún otro proceso está en ejecución. Esto hace que el
núcleo entre en modo de reposo hasta que se requiera un procesamiento posterior. El kernel utiliza un ticker del
kernel para despertar al sistema 100 veces por segundo, lo que causa un problema. Sin embargo, este problema se
puede resolver construyendo un kernel sin cosquillas que sólo calcula cuando el proceso necesita despertarse. Esta
solución reduce el número de interrupciones ocurridas[98].

6.1. 9Multimedia de apoyo : uClinux proporciona apoyo para multimedia a través de un proyecto de
software para la grabación, conversión y procesamiento de flujos de audio y vídeo llamado FFmpeg. FFmpeg utiliza
el servidor HTTP para el procesamiento de las emisiones en directo y el servidor de streaming del protocolo de
streaming en tiempo real (RTSP), que es una librería en la parte superior de GStreamer. El servidor gst-RTP está
diseñado para permitir a muchas fuentes conectarse, retransmitir y transmitir secuencias de vídeo y audio a través de
una red a uno o varios usuarios[98]. GStreamer soporta bibliotecas de procesamiento multimedia, codificación y
streaming[98].

6.1.10 Más información sobre uClinux: el sistema operativo uClinux soporta un gran número de dispositivos,
sistemas de archivos, protocolos de red y aplicaciones (como el software GNU). El código fuente de uClinux está
disponible para usuarios finales y desarrolladores. Es probado y refinado por muchos programadores y usuarios.
Además, los sistemas que ejecutan el sistema operativo uClinux pueden configurarse de forma diferente a la de la
conocida distribución Linux tipo Unix.

6. 2Sistema operativo Raspbian

Raspbian es un sistema operativo basado en Linux de código abierto para dispositivos de gama alta basado en
Debian (Linux) y optimizado para hardware RPi[101]. Raspbian proporciona más de 35.000 paquetes que se pueden
instalar desde el terminal. Tiene un software precompilado en un formato simple para una fácil instalación[102].
RPi es un ordenador monobloque del tamaño de una tarjeta de crédito y de bajo coste que puede ser ejecutado por
Linux y otros sistemas operativos ligeros[103]. Se puede ejecutar en múltiples procesadores ARM de bajo
rendimiento[103].

6.2.1Arquitectura y modelos de kernel: Similar al sistema operativo uClinux, el sistema operativo Raspbian sigue
una arquitectura monolítica[104]. La Fig. 10 muestra la arquitectura del sistema operativo Raspbian.

6.2. 2Modelo de programación y entorno de desarrollo: Al igual que el SO uClinux, el SO Raspbian soporta
multithreading[105]. Está escrito en lenguaje de programación Python, y el código puede ser modificado de acuerdo
a los requerimientos de una aplicación[105]. Un número considerable de lenguajes de programación han sido
adaptados para el SO Raspbian como Python, C, C + +, Java, Scratch, y Ruby; todos instalados por defecto en el SO
Raspbian[105]. También se soportan lenguajes de programación como HTML5, Javascript y JQuery[105].

6.2.3Programación : Raspbian utiliza la programación preventiva en tiempo real[106].

6.2. 4Gestión y rendimiento de la memoria : El sistema operativo Raspbian soporta una técnica de memoria
virtual que es realizada por el hardware a través de MMU. Raspbian también ofrece intercambio de memoria virtual
que divide el disco duro en partes para intercambiar fracciones de memoria principal. De este modo, se permite que
las regiones ocupadas que no tardaron suficiente tiempo estén disponibles para su asignación[104].

6.2.5Soporte de protocolos de comunicación y de red: El sistema operativo Raspbian soporta una amplia gama
de comunicaciones a través de la interfaz periférica serie (SPI), UART, I2c, y el bus serie universal (USB). También
implementa la pila completa de TCP/IP y Bluetooth. Al igual que otras distribuciones de Linux, el SO Raspbian
tiene soporte para casi todos los protocolos de red que se importan desde la distribución Debian. Además, una
librería gratuita de código abierto para LTE y otros protocolos inalámbricos están disponibles para ser usados
fácilmente con Raspbian[105].

6.2. 6Soporte de simulación : El sistema operativo Raspbian puede ser simulado usando QEMU ARM, que
es un emulador de arquitectura de CPU y una herramienta de virtualización. QEMU es capaz de emular una
arquitectura ARM muy similar a las placas RPi. Esto permite arrancar una imagen RPi directamente a sistemas x86
o x86-64. Sin embargo, para tratar con el hardware virtualizado de QEMU que no es un componente central del
RPi, el SO Raspbian debe tener un kernel RPi para que QEMU pueda controlar la imagen del kernel de
QEMU[103].

6.2.7Seguridad : El sistema operativo Raspbian soporta muchas técnicas de encriptación, autenticación y

autorización que se adaptan a la mayoría de las aplicaciones de IO. La comunidad de código abierto proporciona
soporte para este sistema operativo y para la mayoría de los algoritmos de encriptación que están disponibles en los
repositorios Raspbian. Los requisitos de seguridad personalizados pueden integrarse fácilmente en el sistema
operativo Raspbian, incluso si requieren modificaciones en las bibliotecas centrales. Los algoritmos de encriptación
como AES 128, AES 256, el estándar de encriptación de datos (DES) y Blowfish están disponibles en todas las
bibliotecas del framework, además de los protocolos de red privados virtuales y seguros HTTP[105]. Los algoritmos
de encriptación selectiva para streaming multimedia también son compatibles con el sistema operativo
Raspbian[107].

6.2. 8Consumo de energía : Una de las ventajas de crear un cluster con procesadores basados en ARM es
el bajo consumo de energía; cada RPi utiliza alrededor de 2 W de potencia (cuando funciona a 700 MHz)[103]. El
consumo de energía del sistema operativo Raspbian se basa en las placas RPi utilizadas y en el tipo de aplicaciones
que se ejecutan en el propio dispositivo. La Tabla 1 resume el consumo de energía utilizando diferentes tarjetas
RPi[105].

6.2.9Soporte de multimedia: El sistema operativo Raspbian puede realizar streaming de audio y vídeo en directo
utilizando el protocolo de iniciación de sesión (SIP) y los protocolos RTP[105]. El sistema operativo Raspbian
emplea algoritmos de compresión de predicción lineal excitados por el código para asegurar una baja latencia y una
comunicación de alta calidad[102, 108]. Además, soporta videos y música HD[105]. Además, GStreamer está
soportado en el sistema operativo Raspbian, que soporta streaming, codificación y empaquetado de varios formatos
multimedia como flv y H264[105]. Una lista completa de los plugins soportados se puede encontrar en[101].
Además, hay disponible un módulo de cámara especial para placas RPi y Raspbian OS[105]. El módulo admite los
modos de vídeo 1080p30, 720p60 y VGA90. La cámara se conecta a través del puerto de interfaz serie de la cámara
disponible en RPi, y hay varias librerías de terceros construidas para ello, incluyendo la librería Python
Picamera[105].

6.2.10Más sobre el sistema operativo Raspbian: El sistema operativo Raspbian tiene un entorno de escritorio
llamado entorno de escritorio gráfico X11 ligero. Es muy similar a los escritorios Windows y Mac y proporciona
una interfaz de usuario atractiva[101]. Además, incluye el protocolo del servidor de visualización Wayland, que
permite un uso eficiente de la unidad de procesamiento gráfico para las funciones de dibujo de la interfaz gráfica de
usuario acelerada por hardware para los robots[102].

6.3El sistema operativo Android Things

Android Things es un sistema operativo basado en Linux de código abierto para dispositivos IoT de gama alta. Es
desarrollado por Google y derivado de Android OS. Android Things OS está codificado usando un lenguaje de
programación especializado llamado Weave, que es un lenguaje común entre plataformas. Android Things OS
puede funcionar en dispositivos IoT de gama alta que ofrecen unas decenas de megabytes de memoria, ya que
depende de los niveles más bajos de Android, que pueden seguir funcionando con requisitos de sistema
insignificantes, como las bombillas. Tiene una interfaz fácil de usar que facilita la configuración del hardware.
Además, Android Things puede ejecutar dispositivos portátiles debido a las características comunes del entorno y a
la restricción de consumo de energía[33, 90, 109, 110]. Android Things es compatible con muchas plataformas de
hardware como Intel (X86), Edison (Dual-core Atom 500M), minnowboard, Qualcomm (Arm), dragonboard
(MSM8916, QCore A53), Marvell (Arm), ABox Edge (IAP140, QCore A53), Freescale (Arm) y Rockchip
(Arm)[111]. La estructura de Android Things OS se muestra en la Fig. 11.

6.3.1Arquitectura y modelos de kernel: A diferencia del sistema operativo Raspbian, Android Things OS tiene una
arquitectura modular[112].

6.3. 2Modelo de programación y entorno de desarrollo: Similar a Raspbian OS, Android Things OS soporta
multithreading y un número de SDKs Android como APIs y AdMob, donde se requiere autenticación para la
entrada de usuarios[112]. Además, los desarrolladores de Android Things OS pueden desarrollar sus programas
utilizando los lenguajes de programación C y C + + además de Java[111].

6.3.3Programación : El programador de Android Things OS soporta tanto el priorizado preventivo como el

cooperativo dependiendo de la configuración del programador[113].

6.3. 4Gestión y rendimiento de la memoria : Android Things OS implementa la asignación de memoria

dinámica a través de llamadas de sistema[77] y tiene una pequeña huella de memoria[111].

6.3.5Soporte de protocolos de comunicación y de red: Android Things OS soporta WiFi, bluetooth de baja
energía, ZigBee, IPV6 y otros protocolos de red[112].

6.3. 6Soporte de simulación : Android Things OS todavía no es compatible con Android Studio Android
Virtual Device como otras plataformas Android. Sin embargo, puede emplearse en RPi 3, Intel Edison y NXP Pico
para su uso en la simulación inicial[111].

6.3.7Seguridad : Como Android Things OS es un software abierto basado en Android, permite crear aplicaciones
de forma rápida y sencilla. Por lo tanto, habrá más lagunas de seguridad, como ataques de virus y piratería
informática[111]. Android Things OS utiliza un arranque seguro y verificado y actualizaciones firmadas vía satélite
que lo hacen más seguro[111]. Android Things OS proporciona un cifrado completo del disco para que todos los
datos estén protegidos. Todo en la unidad estará cifrado, incluyendo los archivos que guardan copias exactas de los
datos en los que el usuario ha estado trabajando, como los archivos temporales[111].

6.3. 8Consumo de energía : Android Things OS funciona con WiFi y Bluetooth de bajo consumo de
energía utilizando los requisitos mínimos del sistema, como baja memoria y pequeños procesadores. Por lo tanto,
necesita menos energía para funcionar[111].

6.3.9Soporte de multimedia: Android Things OS puede soportar completamente el streaming y procesamiento

multimedia de alto rendimiento[111]. Soporta la misma pila de contenidos multimedia del sistema operativo
Android, como H264, MP3 y VP9[111]. Este procesamiento incluye varias tareas como el análisis de imágenes y
vídeo y el procesamiento de datos que pueden procesarse dentro del dispositivo en lugar de procesarse en la
nube[111].

6.3.10 Más sobre cosas de androides: Los componentes de la plataforma Google Cloud Platform (como Firebase)
pueden integrarse fácilmente con Android Things OS[112]. Los desarrolladores podrán utilizar diferentes servicios
cloud para el almacenamiento, la gestión de estados y la mensajería[112]. Cuando se trata de Weave, el SDK estará
integrado en los dispositivos para comunicaciones locales y remotas. Además, Weave es un protocolo independiente
que puede ser como Zigbee, Z-Wave y Bluetooth Smart. Lo que hace que Android Things OS sea único es que es
compatible con todos los paquetes fuente de Android[111].

Otros sistemas operativos de código abierto: Hay algunos sistemas operativos de código abierto que siguen
creciendo y que no son populares ni obsoletos y que no se tratan en este documento, como Pyxis, Ubuntu Snappy
Core y Ostro. Por ejemplo, a través de muchas búsquedas, revelamos muy poco sobre Pyxis OS que ha sido
obsoleto y reemplazado por Pyxis 2. No parece ser un PPC64, ni está basado en CentOS/Linux. Se ve como un
sistema operativo personalizado escrito en C# para los microcontroladores de Arduino. También parece ser un
pequeño proyecto desarrollado alrededor de 2010 sin actualizaciones posteriores. Otros sistemas operativos todavía
trabajan muy duro para brillar en el campo, pero la competencia es alta ya que esta área está creciendo
dramáticamente.

7 Comparisons de los sistemas operativos de la IO

En esta sección, ofrecemos varios resúmenes tabulares resumidos de todos los sistemas operativos listados en esta
encuesta. La Tabla 2 resume las características de programación de todos los SOs discutidos en este documento.
Esta tabla enumera las características de programabilidad para cada SO en términos de uso del núcleo y la
arquitectura para una aplicación básica, tipo de programación, modelo de programación, lenguaje de programación
soportado, la capacidad de reprogramación y el soporte de tiempo real. Observamos que los lenguajes de
programación comunes utilizados en los sistemas operativos de la IO son C, C + + y Java. Java siempre se ejecuta
sobre un sistema operativo IoT. Por lo tanto, la elección no es entre C/C + + o Java, sino entre C o C + + y Java.

En el cuadro 3 se resumen los requisitos de hardware de los sistemas operativos de la IO estudiados. Esta tabla
define los requisitos de configuración del hardware del sistema operativo en términos de uso de RAM y ROM para
una aplicación básica, un procesador y una plataforma de hardware compatible principal. El propósito de las
especificaciones de hardware es proporcionar decisiones de diseño apropiadas para los dispositivos que funcionarán
con SOs de IO.

Por último, resumimos brevemente los principales aspectos técnicos de los sistemas operativos de la IO en el cuadro
4. Destaca los aspectos de implementación en términos de la shell inalámbrica programable remota, la interfaz del
sistema de archivos remoto para nodos en red, el sistema de archivos, la depuración en línea, la memoria dinámica,
el soporte de simulación y la lista de tecnologías y protocolos de red compatibles.

8 Conclusion
La proliferación de la IO está aumentando drásticamente y ya abarca muchos ámbitos y disciplinas importantes,
como las ciudades inteligentes, las plataformas sensoriales inteligentes y los sistemas de tránsito inteligentes. El
apoyo a la SG es vital para facilitar el desarrollo y la subsistencia de la IO. En este documento, ofrecemos un
estudio exhaustivo de los sistemas operativos de código abierto más utilizados y de última generación para la IO.
Primero investigamos los aspectos de diseño y desarrollo de los sistemas operativos de la IO. A continuación,
proponemos una taxonomía para clasificar y categorizar los sistemas operativos de IO más modernos y más
utilizados. Proporcionamos una amplia visión general de los sistemas operativos de código abierto de la IO, en la
que cada uno de ellos se explica detalladamente sobre la base de los aspectos de diseño y desarrollo establecidos.
Estos aspectos son: arquitectura y modelos de kernel, modelo de programación y entorno de desarrollo,
programación, gestión de memoria y rendimiento, protocolos de comunicación y redes, simulador, seguridad,
consumo de energía y soporte multimedia. Estudiamos las características, ventajas y desventajas de cada sistema
operativo. Además, se presentan varias comparaciones que se concentran en las similitudes y diferencias entre los
sistemas operativos discutidos. Destacamos que este es el primer documento de estilo tutorial de este tipo sobre
sistemas operativos de IO.

Por último, sostenemos que cada sistema operativo de IO tiene algunas limitaciones en función del escenario de
despliegue específico. Por esta razón, es un reto tener un sistema operativo que satisfaga todos los requisitos.
Además, la elección de un sistema operativo apropiado para las aplicaciones de IO es fundamental para el éxito de
las implementaciones y despliegues de IO. El desarrollador debe estudiar cuidadosamente las fortalezas y
debilidades de los sistemas operativos candidatos para tomar la mejor decisión. Como cada sistema operativo de IO
tiene sus ventajas y desventajas, puede utilizarse para identificar el sistema operativo adecuado en función de los
requisitos funcionales, no funcionales, de consumo de energía, de conectividad de los sensores, de los métodos de
comunicación y de muchos otros. Por lo tanto, esta investigación está diseñada para salvar la brecha existente en el
conocimiento de la adopción e implementación de sistemas operativos para la IO desde diferentes aspectos. Esta
encuesta proporciona una guía fácil de seguir y bien estructurada en un estilo de tutorial para investigadores y
desarrolladores que se dirigen a SOs de IO.

9 Acknowledgment
Este trabajo fue posible gracias al apoyo financiero de la Universidad Privada de Ciencias Aplicadas de Amman,
Jordania.

Referencias
1] Ma, H.: `Internet de las cosas: objetivos y retos científicos', J. Comput.
Sci. Technol. 2011, 26, (6), pp. 919-924
2] Mattern, F., Floerkemeier, C.: "From the internet of computers to the Internet of things", en Sachs, K.,
Petrov, I., Guerrero, P. (Eds.): "From active data management to event-based systems and more" (De la gestión
activa de datos a los sistemas basados en eventos y más) (Springer, Berlín, Alemania, 2010), vol. 33, (2), pp. 242-
259.
3] Zhu, Q., Ruicong, W., Chen, Q., y otros: `Portal de IO: pasarelas de redes de sensores inalámbricos a la
Internet de los objetos'. Proc. IEEE/IFIP Octava Int. Conf. Computadora Ubicua Embebida. (EUC), Hong Kong,
China, diciembre de 2010, pp. 347-352
4] Gartner Inc: Gartner dice que 8.400 millones de personas conectadas 'Cosas' estarán en uso en 2017, un 31
por ciento más que en 2016'. Disponible en https://www.gartner.com/ newsroom/id/3598917, consultado en junio de
2017.
5] Sundmaeker, H., Guillemin, P., Friess, P. y otros:"Visión y desafíos para hacer realidad la Internet de las
cosas" (Comisión Europea, Bruselas, 2010).
6] Islam, S., Kwak, D., Kabir, M., y otros: `The Internet of things for health care: a comprehensive survey',
IEEE Access. 2015, 3, pp. 678-708.
7] Keoh, S., Kumar, S., Tschofenig, H.: 'Securing the Internet of things: a standardization perspective', IEEE
Internet Things J., 2014, 1, (3), pp. 265-275.
8] Mainwaring, A., Polastre, J., Szewczyk, R., y otros: `Redes inalámbricas de sensores para la vigilancia del
hábitat'. Proc. ACM Int. Works Wireless Sensor Networks and Applications, Atlanta, GA, USA, septiembre de
2002, pp. 88-97
9] Al-Fuqaha, A., Guizani, M., Mohammadi, M. y otros: `Internet of things: a survey on enabling
technologies, protocols, and applications', IEEE Commun.
Surv. Tutor, 2015, 17, (4), págs. 2347-2376.
10] ¿Por qué se necesitan sistemas operativos especiales para la IO y los dispositivos portátiles?
Disponible en https://dzone.com/, consultado en junio de 2017.
11] Cisco Visual Networking Index: Global Mobile Data Traffic Forecast Update, 2016-2021. Disponible en
https://www.cisco.com/
12] Razzaque, M., Milojevic-Jevric, M., Palade, A., y otros: 'Middleware for Internet of things: a survey', IEEE
Internet Things J., 2016, 3, (1), pp. 70-95.
13] Roman, R., Najera, P., Lopez, J.: 'Securing the Internet of things', IEEE Comput. Red, 2011, 44, (9), págs.
51-58.

14] Internet de los objetos (IO) Dispositivos conectados Base instalada en todo el mundo de 2015 a 2025 (en
miles de millones). Disponible en https://www.statista.com/, consultado en agosto de 2017.
15] Lee, J., Sung, Y., Park, J.: "Lightweight sensor authentication scheme for energy efficiency in ubiquitous
computing environments", Sensors, 2016, 16, (12), pp. 2044-2059.
16] Tarkoma, S., Ailisto, H.: `The Internet of things program: the Finnish perspective', IEEE Commun. Mag,
2013, 51, (3), pp. 10-11
17] Al-Turjman, F., Alturjman, S.: "Context-sensitive access in industrial Internet of things (IIoT) healthcare
applications", IEEE Trans. Ind. Inf. 2018, 14, (6), págs. 2736-2744.
18] Miorandi, D., Sicari, S., De Pellegrini, F., et al: `Internet of things: vision, applications and research
challenges', Ad Hoc Netw., 2012, 10, (7), pp. 1497- 1516.
19] Roman, R., Zhou, J., Lopez, J.:'On the features and challenges of security and privacy in distributed
Internet of things', Comput. Red, 2013, 57, (10), págs. 2266-2279.
20] Balakrishna, C.: "Enabling technologies for smart city services and applications". Proc. IEEE Int. Conf.
Next Generation Mobile Applications, Services and Technologies (NGMAST), París, Francia, septiembre de 2012,
págs. 223-227
21] Wang, L., Alexander, C.: "Big data analytics and cloud computing in Internet of things", Amer. J. Inf.
Ciencias de la computación. Ing., 2016, 2, (6), pp. 70-78
22] Sarkar, C., Nambi, A., Prasad, R., y otros: 'DIAT: a scalable distributed architecture for IoT', IEEE Internet
Things J., 2015, 2, (3), pp. 230-239.
23] Qin, Z., Denker, G., G., Giannelli, C., y otros: "Una arquitectura de red definida por software para la
Internet de las cosas". Proc. IEEE Network Operations and Management Symp. (NOMS), Cracovia, Polonia, junio
de 2014, pp. 1-9
24] Chen, S., Xu, H., Liu, D., y otros: "A vision of IoT: applications, challenges, and opportunities with China
perspective", IEEE Internet Things J., 2014, 1, (4), pp. 349-359.
25] Hahm, O., Baccelli, E., Petersen, H. y otros: `Sistemas operativos para dispositivos de gama baja en la
Internet de los objetos: una encuesta', IEEE Internet Things J., 2016, 3, (5), pp. 720-734.
26] Silberschatz, A., Galvin, P., Gagne, G.: 'Operating system concepts' (Wiley, Nueva York, EE.UU., 2013,
9th edn.)
27] Farooq, M., Kunz, T.: "Operating systems for wireless sensor networks: a survey", Sens. J., 2011, 11, (6),
pp. 5900-5930
28] Will, H., Schleiser, K., Schiller, J.: "A real-time kernel for wireless sensor networks employed in rescue
scenarios". Proc. IEEE Conf. Local Computer Networks (LCN), Zurich, Suiza, octubre de 2009, pp. 834-841
29] Dunlap, G., King, S., Cinar, S., et al: 'Revirt: enabling intrusion analysis through virtual-machine logging
and replay'. Syst. de funcionamiento Symp. Diseño e Implementación (OSDI), Seattle, EE.UU., diciembre de 2002,
pp. 211-224
30] Bandyopadhyay, D., Sen, J.: `Internet of things: applications and challenges in technology and
standardization', Wirel. Pers. Comunidad, 2011, 58, (1), pp. 49- 59
31] Dunkels, A., Groonvall, B., Voigt, T.: "Sistema operativo ligero y flexible ContikiVA para pequeños
sensores conectados en red". Proc. Anual IEEE Int. Conf. Local Computer Network (LCN), Tampa, FL, EE.UU.,
noviembre de 2004, págs. 455-462.
32] Chien, T., Chan, H., Huu, T.: "A comparative study on operating system for wireless sensor networks".
Tratamiento Int. Conf. Advanced Computer Science and Information Syst, Yakarta, Indonesia, diciembre de 2011,
págs. 73-78.
33] Azure IoT device SDK for C. Disponible en https://docs.microsoft.com/en-us/ azure/, consultado en agosto
de 2017.
34] Baccelli, E., Hahm, O., Günes, M., y otros: "OS for the IoT - goals, challenges, and solutions, OS for the
IoT - goals, challenges, and solutions". Wkshps Interdisciplinaire sur la SÃl'curitÃl' Globale (WISG), Troyes,
Francia, enero de 2013, pp. 1-6.
35] Levis, P., Culler, D., Shenker, S., y otros: "Trickle: a self-regulating algorithm for code propagation and
maintenance in wireless sensor networks". Proc. USENIX/ACM Symp. Networked System Design and
Implementation (NSDI), San Francisco, CA, marzo de 2004, pp. 15-28.
36] Abdelsamea, M., Zorkany, M., M., Abdelkader, N.: `Sistemas operativos en tiempo real para Internet de
cosas, visión, arquitectura y direcciones de investigación'. Proc. Simposio Mundial. Computer Applications and
Research, Cairo, Egypt, March 2016, pp. 72-77
37] Deniz, U., Al-Turjman, F., Celik, G.: 'An overview of Internet of things and wireless communications'.
Tratamiento Int. Conf. Ingeniería Informática (UBMK), Antalya, Turquía, octubre de 2017, pp. 506-509
38] Sulyman, A., Oteafy, S., Hassanein, H.: 'Expanding the cellular-IoT umbrella: an architectural approach',
IEEE Wirel. Comunidad, 2017, 24, (3), págs. 66-71.
39] AlTurjman, F., Alturjman, S.: "Confidential smart-sensing framework in the IoT era", J. Supercomput.
2018, 74, (10), pp. 5187-5198.
40] Atzori, L., Iera, A., Morabito, G.: `The Internet of things: a survey', Comput.
Red, 2010, 54, (15), págs. 2787-2805.
41] Perrig, A., Szewczyk, R., Wen, V.: 'SPINS: protocolos de seguridad para redes de sensores', Wirel. Red,
2002, 5, (8), págs. 521-534.
42] Xiong, L., Zhou, X., Liu, W.: "Research on the architecture of trusted security system based on the Internet
of things". Tratamiento Int. Conf. Inteligente. Computer Technology and Automation, Shenzhen, Guangdong,
China, marzo de 2011, pp. 1172-1175
43] Demir, S., Al-Turjman, F.:'Energy scavenging methods for WBAN applications: a review', IEEE Sens. J.,
2018, 18, (16), págs. 6477-6488.
44] Lajara, R., Pelegri-Sebastia, J., Solano, J.: 'Power consumption analysis of operating systems for wireless
sensor networks', Sensors, 2010, 10, (6), pp. 5809-5826.
45] Hamoudy, M., Qutqut, M., Almasalha, F.: 'Video security in Internet of things: an overview', Int. J.
Comput. Red Científica. Secur. (IJCSNS), 2017, 17, (8), pp. 199-255

46] Al-Sakran, A., Qutqut, M., Almasalha, F., et al.: "An overview of the Internet of things closed source
operating systems". Int. Conferencia sobre Comunicaciones Inalámbricas y Computación Móvil (IWCMC),
Limassol, Chipre, junio de 2018
47] Levis, P., Madden, S., Polastre, J., et al.:'TinyOS: an operating system for sensor networks', en Weber, W.,
Rabaey, J., Aarts, E. (Eds.):'Ambient intelligence', vol. 1 (Springer, Nueva York, 2005), pp. 115-148.
48] Levis, P., Lee, N., Welsh, M., et al: 'TOSSIM: simulación precisa y escalable de aplicaciones TinyOS
completas'. Tratamiento Int. Conf. Embedded Networked Sensor Systems, CA, EE.UU., noviembre de 2003, pp.
126-137
49] Gay, D., Levis, P., Culler, D.:'Patrones de diseño de software para TinyOS'. Proc. ACM Conf. Lenguajes,
compiladores y herramientas para sistemas embebidos, IL, USA,
Junio de 2005, vol. 40, págs. 40 a 49.
50] Hill, J., Culler, D., Horton, M., y otros: 'Mica: the commercialization of microsensor motes', Sens. Mag,
2004, 19, págs. 40-48.
51] Sruthi, M., Rajkumar, R.: "A study on development issues over IOT platforms, protocols and operating
system". Int. Conf. Innovations in Information Embedded and Communication Systems, Coimbatore, India,
Marzo de 2016
52] Casado, L., Tsigas, P.: "Contiki Sec: una capa de red segura para redes de sensores inalámbricas bajo el
sistema operativo Contiki". Proc. Conf. nórdica Secure IT Systems, Nueva York, NY, EE.UU., octubre de 2009, pp.
133-147
53] Ma, H.: "Experimental evaluation of a video streaming system for wireless multimedia sensor networks".
Proc. Décimo taller anual del IEEE IFIP sobre la Red Ad Hoc del Mediterráneo, Sicilia, Italia, agosto de 2011, pp.
165-170.
54] Farooq, M., Aziz, S., Dogar, A.: 'State of the art in wireless sensor networks operating systems: a survey'.
Tratamiento Int. Conf. Future Generation Information Technology, Berlín, Heidelberg, diciembre de 2010, pp. 616-
631
55] Dunkels, A., Schmidt, O., Voigt, T., y otros: `Protothreads: simplificando la programación basada en
eventos de sistemas embebidos con memoria limitada'. Tratamiento Int. Conf. Embedded Networked Sensor
Systems, Boulder, CO, EE.UU., octubre de 2006, pp. 29-42
56] Dunkels, A., Finne, N., Eriksson, J.: "Run-time dynamic linking for reprogramming wireless sensor
networks". Proc. Cuarta Conferencia ACM Embedded Networked Sensor Systems (Sensys), Boulder, CO, EE.UU.,
octubre de 2006, pp. 15-28
57] Dunkels, A., Mottola, L, Tsiftes, N. y otros: 'The announcement layer: beacon coordination for the
sensornet stack'. Proc. Redes de sensores inalámbricos Conf. (EWSN), Bonn, Alemania, febrero de 2011, págs. 211-
226
58] Tsiftes, N., Dunkels, A., He, Z., et al.: 'Enabling large-scale storage in sensor networks with the coffee file
system'. Tratamiento Int. Conf. Information Processing Sensor Networks, San Francisco, CA, USA, agosto de 2009,
pp. 349-360
59] Klauck, R., Kirsche, M.: "Bonjour Contiki: a case study of a DNS based discovery service for the Internet
of things". Tratamiento Int. Conf. Ad hoc, Mobile, and Wireless Networks (ADHOC-NOW), Berlín, Alemania,
junio de 2012, págs. 316-329
60] Kuladinithi, K., Bergmann, O., Pötsch, T., et al.: 'Implementation of CoAP and its application in transport
logistics'. Proc. Wkshps on Extending the Internet to Low power and Lossy Networks, Chicago, IL, USA, April
2011, pp. 1-7
61] Kovatsch, M., Duquennoy, S., Dunkels, A.: "BA low-power CoAP for contiki". Proc. IEEE Octava Int.
Conf. Móvil Ad Hoc y Sensor Syst. (MASS), Valencia, España, octubre de 2011, pp. 855-860
62] Contiki..: El sistema operativo de código abierto para la Internet de las cosas. Disponible en http://
www.contiki-os.org/, consultado en agosto de 2017.
63] Tsiftes, N., Eriksson, J., Dunkels, A.: 'Poster abstract: low-power wireless IPv6 routing with ContikiRPL'.
Proc. Noveno ACM/IEEE Int. Conf. Information Processing in Sensor Networks, Estocolmo, Suecia, abril de 2010,
pp. 406-407
64] Munawar, W., Alizai, M., Landsiedel, O., y otros: 'Dynamic TinyOS: modular and transparent incremental
code-updates for sensor networks'. Proc. IEEE Int. Conf. Comunitario (ICC), Ciudad del Cabo, Sudáfrica, mayo de
2010, págs. 1-6
65] Kalyoncu, S.:'Wireless solutions and authentication mechanisms for Contiki based Internet of things
networks', tesis doctoral, Universidad de Halmstad, 2013.
66] Documentación de RIOT. Disponible en https://riot-os.org/api/, consultado en septiembre de 2017.
67] Emmanuel, B., Gündoğan, C., Hahm, O., et al: 'RIOT: an open source operating system for low-end
embedded devices in the IoT', IEEE Internet Things J., 2018, doi: 10.1109/JIOT.2018.2815038
68] Roussel, K., Song, Y., Zendra, O.: 'RIOT OS allana el camino para la implementación de protocolos MAC
de alto rendimiento'. Proc. Cuarto Int. Conf.
Redes de sensores (SENSORNETS), Angers, Francia, abril de 2015, págs. 5-14
69] Baccelli, E., Hahm, O., Petersen, H., y otros: `RIOT and the evolution of IoT operating systems and
applications', ERCIM News, April 2015, 101
70] Petersen, H., Adjih, C., Hahm, O., y otros: 'IoT meets robotics-first steps, RIOT car, and perspectives'.
Proc. ACM Int. Conf. Embedded Wireless Systems and Networks (EWSN), Graz, Austria, febrero de 2016, pp.
269-270
71] Milinkovi, A., Milinković, S., Lazic, L., et al: "Choosing the right RTOS for IoT platform", NFOTEH-
JAHORINA, 2015, 14, (3), pp. 504-509.
72] Baccelli, E., Hahm, O., Gunes, M., et al: 'RIOT OS: towards an OS for the Internet of things'. Proc. 32nd
IEEE Conf. Computing Communications (INFOCOM), Turín, Italia, abril de 2013, págs. 79 y 80.
73] Shang, W., Afanasyev, A., Zhang, L.: "The design and implementation of the NDN protocol stack for
RIOT-OS". Proc. IEEE Globecom Wkshps (GC Wkshps), Washington, DC, EE.UU., diciembre de 2016, pp. 1-6.
Huawei LiteOS. Disponible en http://www.huawei.com/, consultado en septiembre de 2017.
75] Vanitha, V., Palanisamy, V., Johnson, N., et al: 'LiteOS based extended service oriented architecture for
wireless sensor networks', Int. J. Comput.
Electr. Eng., 2010, 2, (3), pp. 432–436
[76] Cao, Q., Abdelzaher, T., Stankovic, J., et al.: ‘The LiteOS operating system: towards Unix-like abstractions
for wireless sensor networks’. Proc. Int. Conf.

Information Processing in Sensor Networks (IPSN), USA, April 2008, pp. 233–244
[77] Gaur, P., Tahiliani, M.: ‘Operating systems for IoT devices: a critical survey’.
Region 10 Symp. (TENSYMP), Ahmedabad, Pakistan, May 2015, pp. 33–36
[78] Hammad, M., Cook, J.: ‘Lightweight deployable software monitoring for sensor networks’. Proc. IEEE
18th Int. Conf. Computing Communications and Networks, Washington, D.C., USA, August 2009, pp. 1–6
[79] Ranjan, A., Sahu, H., Misra, P.: ‘A survey report on operating systems for tiny networked sensors’, arXiv
preprint arXiv:1505.05269, May 2015
[80] Deharbe, D., Galv'ao, S., Moreira, A.: ‘Formalizing FreeRTOS: first steps in formal methods: foundations
and applications’. Proc. 12th Brazilian Symp.
Formal Methods (SBMF), Gramado, Brazil, August 2009, pp. 101–117
[81] Andersson, K., Andersson, R.: ‘A comparison between FreeRTOS and RTLinux in embedded real-time
systems’, Linkoping University, 2005
[82] Hos'ek, P.: ‘Supporting real-time features in a hierarchical component system’, MSc thesis, Charles
University, 2010
[83] Yang, C., Chih, H.: ‘An open source audio effect unit’. Proc. IEEE Int. Conf. Systems, Man, and
Cybernetics (SMC), Budapest, Hungary, October 2016, pp. 638–643
[84] FreeRTOS. Available at http://www.freertos.org/, accessed on September 2017
[85] Kruger, C., Hancke, G.: ‘Implementing the Internet of things vision in industrial wireless sensor networks’.
Proc. IEEE Int. Conf. Industrial Informatics, Budapest, Hungary, July 2014, pp. 627–632
[86] Johny, A., Jayasudha, J., Anurag, R.: ‘Security in automotive domain using secure socket layer’, Int. J. Eng.
Innov. Technol., 2013, 3, (4), pp. 214–219
[87] Apache Mynewt OS. Available at https://mynewt.apache.org/, accessed on October 2017
[88] Kordestani, M., Bourdoucen, H.: ‘A survey on embedded open source system software for the Internet of
things’. Proc. Free and Open Source Software Conf., Muscat, Oman, February 2017, pp. 27–32
[89] An Operating System for Arduino. Available at https://www.arduino.cc/, accessed on September 2017
[90] Malche, T., Maheshwary, P.: ‘Harnessing the Internet of things (IoT): a review’, Int. J. Adv. Res. Comput.
Sci. Softw. Eng., 2015, 5, (8), pp. 320–323
[91] Mbed IoT Platform. Available at https://www.mbed.com/en/platform/, accessed on September 2017
[92] Persson, P., Angelsmark, O.: ‘Calvinâ merging cloud and IoT’. Proc. Int. Conf. Ambient Systems Networks
and Technology (ANT), London, UK, June 2015, pp. 210–217
[93] Balsamo, D., Elboreini, A., Al-Hashimi, B., et al.: ‘Exploring ARM Mbed support for transient computing
in energy harvesting IoT systems’. Proc. Seventh IEEE Int. Wkshps Advances in Sensors and Interfaces, Vieste,
Italy,
June 2017, pp. 115–120
[94] arm MBED. Available at https://www.mbed.com/, accessed on September 2017
[95] Nikkanen, K.: ‘Uclinux as an embedded solution’, Bachelor's thesis, Turku Polytechnic Institute, 2003
[96] Lu, Z., Zhang, X., Sun, C.: ‘An embedded system with uClinux based on FPGA’. Proc. Pacific-Asia
Wkshps on Computational Intelligence and

Industrial Application (PACIIA), Wuhan, China, December 2008, pp. 691– 694
[97] Wang, M., Liu, F.: ‘Research and implementation of uCLinux-based embedded browser’. Proc. Second
IEEE Asia-Pacific Service Computing Conf., Tsukuba Science City, Japan, December 2007, pp. 504–508
[98] uClinux in the GDB/ARMulator. Available at http://www.uclinux.org/pub/ uClinux/utilities/armulator/,
accessed on September 2017
[99] Teng, J., Tseng, C., Chen, Y., et al.: ‘Integration of networked embedded systems into power equipment
remote control and monitoring’. Proc. TENCON IEEE Region Conf., Chiang Mai, Thailand, November 2004, vol.
100, (3), pp. 566–569
[100] Kyle, D., Brustoloni, J.: ‘Uclinux: a Linux security module for trusted- computing-based usage controls
enforcement’. Proc. ACM Wkshps on Scalable Trusted Computing, New York, NY, USA, November 2007, pp. 63–
70
[101] Vujovic, V., Maksimovic, M.: ‘Raspberry Pi as a wireless sensor node: performances and constraints’.
Proc. Int. Convention Information and Communication Technology Electronics and Microelectronics (MIPRO),
Opatia, Croatia, May 2014, pp. 1013–1018
[102] Prasad, S., Mahalakshmi, P., Sunder, A., et al.: ‘Smart surveillance monitoring system using Raspberry Pi
and PIR sensor’, Int. J. Comput. Sci.
Inf. Technol., 2014, 5, (6), pp. 7107–7109
[103] Kiepert, J.: ‘Creating a Rraspberry Pi-based Beowulf cluster’, Boise State University, May 2013, pp. 1–17
[104] Silva, S.: ‘A Linux microkernel based architecture for OPENCV in the Raspberry Pi device’, Int. J. Sci.
Knowl. (IJSK), 2014, 5, (2), pp. 44–52
[105] The MagPi Magazine. Available at https://www.raspberrypi.org/magpi/ tutorials/, accessed on September
2017
[106] Murikipudi, A., Prakash, V., Vigneswaran, T.: ‘Performance analysis of real time operating system with
general purpose operating system for mobile robotic system’, Indian J. Sci. Technol., 2015, 8, (19), pp. 1–6
[107] Almasalha, F., Khokhar, A., Hasimoto-Beltran, R.: ‘Scalable encryption of variable length coded video bit
streams’. Proc. IEEE 35th Conf. Local Computer Networks (LCN), Denver, CO, USA, October 2010, pp. 192–195
[108] Bagal, N., Pandita, S.: ‘A review: real-time wireless audio–video transmission’, Int. J. Emerg. Technol.
Adv. Eng., 2015, 5, (4), pp. 168–170
[109] MartinFerna'ndez, F., CaballeroGil, P., CaballeroGil, C.: ‘Authentication based on non-interactive zero
knowledge proofs for the Internet of things’,
Sensors, 2016, 16, (1), p. 75
[110] Amorim, V., Delabrida, S., Oliveira, R.: ‘A constraint-driven assessment of operating systems for wearable
devices’. Proc. Computing Systems Engineering (SBESC), Joao Pessoa, Brazil, November 2016, pp. 150–155
[111] Android Things. Available at https://developer.android.com/things/, accessed on October 2017
[112] Android Platform Architecture. Available at https://developer.android.com/ guide/platform/index.html,
accessed on September 2017
[113] Akula, P., Yamuna, V., Ananda, C., et al.: ‘Development of data logger for MAV using FREERTOS ON
PIC32’, Int. J. Eng. Sci. Res. Technol