RTOS o no RTOS es la pregunta

Una larga rama de comentarios me pidió que escribiera este artículo (desafortunadamente no puedo llamar a esto una discusión) a mi reciente artículo "El mundo diverso de los sistemas embebidos y el lugar de Embox en él" . Me reprocharon en varios lugares por confundir RTOS y sistema operativo incorporado, que llamé LynxOS, QNX y VxWorks no RTOS, aunque en mi opinión, por supuesto, no lo hice. Le sugerí al autor de estos comentarios varias veces que escribiera un artículo en el que declarara su visión del concepto de "sistema operativo en tiempo real", pero por alguna razón se negó. Bueno, presentaré mi visión de este término y analicemos cómo se puede llamar a RTOS y qué no. Al final, esta pregunta a menudo se hace en relación con Embox .

El término OS RV (RTOS) se refiere al campo del marketing.

Pensé comenzar de manera científica, con la introducción de términos, pero decidí que esta tesis provocativa sería muy bienvenida. Entonces, ¿por qué sostengo que el término RTOS (sistemas operativos en tiempo real) se refiere al marketing, más precisamente, es un eslogan de marketing (publicidad)? Todo es simple Cuando se produce un producto, necesita ser vendido. Pero si intenta vender solo un sistema operativo, surgirán dificultades. Aquí es donde el posicionamiento en el mercado viene al rescate. Por ejemplo, podría decir "somos más rápidos que ellos".


¡Pero puedes ir a la corte por ello! Y allí tendrá que proporcionar evidencia. Pero, ¿cómo demostrar que eres más rápido en todos los casos? Esta no es una competencia en marcha. Pero, por supuesto, una competencia no del todo correcta está ligeramente fuera del posicionamiento normal del mercado.

El posicionamiento normal implica la formación de un retrato del consumidor, identificando las propiedades del producto que tienen más demanda y enfocándose en estas propiedades. Bueno, o usted forma estas necesidades al usuario. Por ejemplo, nuestro procesador tiene tal frecuencia, el teléfono inteligente tiene un procesador N-core, y así sucesivamente.

Dado que los clásicos del género ya han formulado que los sistemas operativos son necesarios no solo para los sistemas de usuario, sino también para controlar varios procesos tecnológicos en modo automático, e incluso introdujeron el concepto de un sistema operativo en tiempo real, entonces, ya sabes, es un pecado no usarlo. Al presentar el concepto de sistemas en tiempo real, los clásicos hablaron de cierto umbral crítico de tiempo. Es decir, difiere de los sistemas convencionales, donde si el usuario espera algo, entonces puede esperar, un sistema duro en tiempo real, por ejemplo, controlar una turbina, no puede esperar, de lo contrario puede pasar a algo malo.

Por lo tanto, puede decirle al usuario que, a diferencia de los sistemas operativos convencionales, se les proporcionará un sistema que garantiza el tiempo de respuesta del sistema. Naturalmente, cuanto más pequeño es, mayor es el número de procesos tecnológicos diferentes que el sistema puede controlar. Y aparecen muchas tablas donde se proporcionan varios parámetros clave de RTOS como parámetro clave.

¿Cómo se reciben? ¡Este proceso se describe honestamente! Aquí tomamos tal y tal problema de modelo, tal y tal plataforma de hardware, y así aplicamos el efecto. Bueno, el marketing, por supuesto, puede simplificar y simplemente dar, un tiempo de reacción de 1 μs. Pero no tomamos esto en cuenta, creemos que todo se describe honestamente.

Pero disculpe, ¿qué pasa si hay otra tarea? 10 tareas, 100 tareas? ¿Y si un programador borracho bloquea las interrupciones? ¿Y si en el sistema el programador no priorizó correctamente las tareas?

Hubo un caso cuando Embox pasó las pruebas en tiempo real. Nos sentamos y pensamos cómo demostrar que este es un sistema operativo en tiempo real. Hay un laboratorio, hay un cliente que quiere que esto sea así. Descubrimos que para el cliente en tiempo real significa que el tiempo de respuesta del sistema es de 1 μs. Pregunto si el siguiente experimento será evidencia:

• Tomamos cierta plataforma de hardware
• Aplicar una señal a una de las entradas GPIO
• Programar un evento
• A la salida del GPIO, señalizamos programáticamente
• Las mediciones se llevan a cabo utilizando un osciloscopio, el tiempo de reacción será la diferencia entre los frentes de entrada y salida.

El cliente confirma que esto es exactamente lo que se necesita. Hago una pregunta aclaratoria, y estamos diseñando un sistema modelo y no podemos iniciarlo (no cargarlo) con otras tareas. Es decir, es normal que el sistema solo haga una tarea de prueba tan simple. El cliente dijo que esto requiere tareas de prueba. ¡Probablemente usted mismo entienda que el sistema ha pasado las pruebas! Naturalmente, con la confirmación de las características, es decir, el impacto se repitió.

Esta sección no está escrita de ninguna manera para menospreciar a ningún sistema operativo o desarrollador. Pero únicamente para mostrar todo lo incompleto de la imagen. No afirmé que las características de algunos sistemas operativos no permiten atribuirlos al RTOS, pero los especialistas en marketing solo utilizan este término. Vi otras pruebas cuando ordené la elección del sistema operativo de un laboratorio independiente basado en los requisitos de la tarea. Hubo un conjunto complejo de tareas modelo, y se consideró la interacción de la red, y cómo cambian los parámetros si se carga el sistema, y ​​el comportamiento en diversas situaciones de emergencia.

Definición del término "sistema operativo en tiempo real"

Ahora presentaré el término "sistema operativo en tiempo real". No, no lo haré. El hecho es que hay muchas definiciones de este término. Tome al menos los comentarios sobre el artículo original:

En los sistemas en tiempo real, una persona es generalmente superflua y, en consecuencia, la velocidad de un sistema en tiempo real debe compararse con los procesos que controla, ya sea un automóvil autónomo o un sistema de control de procesos en una fábrica.

SRV / RTOS: esta es únicamente una clasificación de la previsibilidad de la respuesta a eventos críticos.

RTOS es un sistema operativo en el que la corrección de una tarea se caracteriza no solo por la corrección lógica, sino por el tiempo que lleva completar esta tarea.

Establezca el criterio para cambiar el contexto de cualquier tarea a 1 μs por procesador de 100 MHz con un coprocesador de punto flotante con una determinación de 0.1 μs y todo encajará.
Verá claramente dónde RTOS y dónde no.

Bueno, no puedo ignorar la opinión de la que hablé en un artículo que se expresó en una de las conferencias de OSDAY :

Un sistema puede considerarse un sistema duro en tiempo real si no tiene lugares donde, con interrupciones bloqueadas, haya ciclos con un número desconocido de iteraciones.

Pero tal vez todo sea particular, y como se sugiere en los comentarios , solo necesita usar los clásicos y no inventar bicicletas. Citaré el clásico especificado (Andrew Tanenbaum, si alguien no lo adivinó):

“Otro tipo de sistema operativo es el sistema en tiempo real. Estos sistemas se caracterizan por tener el tiempo como parámetro clave. Por ejemplo, en los sistemas de control de procesos industriales, las computadoras en tiempo real tienen que recopilar datos sobre el proceso de producción y usarlos para controlar las máquinas en la fábrica. A menudo hay plazos difíciles que deben cumplirse. Por ejemplo, si un automóvil se mueve por una línea de ensamblaje, ciertas acciones deben llevarse a cabo en ciertos instantes de tiempo. Si un robot de soldadura suelda demasiado temprano o demasiado tarde, el auto se arruinará. Si la acción debe ocurrir absolutamente en un momento determinado (o dentro de un cierto rango), tenemos un sistema difícil en tiempo real. Muchos de estos se encuentran en el control de procesos industriales, aviónica, militar y áreas de aplicación similares. Estos sistemas deben proporcionar garantías absolutas de que cierta acción ocurrirá en un momento determinado.

Otro tipo de sistema en tiempo real es un sistema blando en tiempo real, en el que perder un plazo ocasional, aunque no es deseable, es aceptable y no causa ningún daño permanente. Los sistemas de audio digital o multimedia entran en esta categoría. Los teléfonos digitales también son sistemas blandos en tiempo real.

Dado que cumplir plazos estrictos es crucial en los sistemas en tiempo real, a veces el sistema operativo es simplemente una biblioteca vinculada con los programas de aplicación, con todo estrechamente acoplado y sin protección entre las partes del sistema. Un ejemplo de este tipo de sistema en tiempo real es e-Cos.

Las categorías de dispositivos portátiles, sistemas integrados y sistemas en tiempo real se superponen significativamente. Casi todos ellos tienen al menos algunos aspectos blandos en tiempo real. Los sistemas embebidos y en tiempo real solo ejecutan software implementado por los diseñadores del sistema; los usuarios no pueden agregar su propio software, lo que facilita la protección. Las computadoras de mano y los sistemas integrados están destinados a los consumidores, mientras que los sistemas en tiempo real son más para uso industrial. Sin embargo, tienen una cierta cantidad en común ".

Pero de esta descripción se deduce solo que los sistemas pueden usarse en sistemas en los que la ausencia de una reacción dentro de un período determinado puede tener consecuencias desastrosas. Bueno, para lograr un parámetro clave (que no exceda el tiempo de reacción), el sistema operativo puede ser una biblioteca, un ejemplo de eCos.

Cómo lograr características en tiempo real

No podría dar una definición estricta (si alguien está listo para dar, escriba los comentarios). Pero en todas las definiciones anteriores, hay un par de propiedades visibles (esta vez y previsibilidad). Si traduce el tiempo en la opción de previsibilidad (el peso del arco cuando se mueve de un estado a otro), ¡solo queda la previsibilidad!

Pensemos en cómo lograr esto.

Será obvio eliminar todo lo innecesario del sistema crítico. Es poco probable que un sistema universal sea estable. Incluso el camarada Tanenbaum habló sobre esto, quiero decir, cuando habló sobre eCos.

Otro enfoque que aumenta la previsibilidad del sistema, nuevamente, propuesto por Tanenbaum , es el uso de algoritmos especiales (simples) para la planificación de recursos, principalmente el tiempo del procesador, es decir, programadores de tareas especiales. Sugirió varios enfoques para la planificación, pero me gustaría centrarme primero en la tabla estática basada en tablas.

El desarrollador debe asegurarse de que todas las tareas tengan éxito al completar su segmento de tiempo. Para hacer esto, se propone analizar estáticamente la tarea crítica y determinar sus valores umbral. Este enfoque se establece en el estándar ARINC-653. El estándar para los sistemas a bordo, y usted mismo comprende, si algo de repente no tiene tiempo para trabajar en el avión, puede ocurrir una catástrofe.

El siguiente enfoque es un horario estático, pero basado en prioridades. Es decir, el desarrollador debe analizar nuevamente todas las situaciones y, después de haber asignado todas las tareas en las prioridades del sistema, asegurarse de que las tareas críticas se completen en un momento dado.

¡No quiero continuar porque hay un original! Está escrito, por supuesto, mejor de lo que puedo hacerlo, y además, nuevamente se les puede acusar de distorsionar los hechos. Cité precisamente estos enfoques para mostrar que, en cualquier caso, el desarrollador del sistema final tiene la responsabilidad de garantizar las características del sistema. Y el sistema operativo solo debe proporcionar las capacidades adecuadas.

Continuando la discusión sobre los métodos para aumentar la previsibilidad, quiero hacer otro comentario.

"Se puede lograr en tiempo real en una frambuesa, pero no con RTOS, sino con una pequeña máquina de estado que se rompe en su caché".

Aquí quiero prestar atención a los siguientes puntos:

• mayor previsibilidad (propiedades en tiempo real) debido a la exclusión de cualquier RTOS del sistema
• representación de un programa por una máquina de estados
• Bueno, la dependencia de los sistemas en tiempo real no solo de las propiedades del software, sino también del hardware.

Con una disminución en la cantidad de imprevisibilidad en el caso de una disminución en el número de líneas de código, creo que todos están de acuerdo. Aunque, como siempre, no estoy de acuerdo, pero más sobre eso más adelante.

¿Cuál es la influencia del hardware también es muy probable que no esté en duda? En particular, cuando se dijo que no había bucles con un número arbitrario de iteraciones en el estado de interrupciones bloqueadas, sonó que en algunos córtex-m en el RTOS descrito no había desconexión de las interrupciones. Esto es un poco astuto, porque allí el controlador de interrupciones desactiva las interrupciones con igual o menor prioridad, independientemente, pero el hecho de la influencia es obvio. Y, por supuesto, la presencia de caché, traducción de direcciones (o más bien fallas en las páginas), contribuye a la incertidumbre. Especialmente, quería llamar la atención sobre el hecho de que, de hecho, nadie puede garantizar la operatividad cien por ciento correcta del equipo. Bueno, las publicaciones se cayeron de ti, ¿cómo ayudará la presencia de un RTOS a evitar un resultado catastrófico de los eventos?

Representación del programa como una máquina de estado, me gustaría proponer considerarlo desde un lado no obvio. Es decir, que se puede analizar un programa de previsibilidad. Y dado que estamos hablando de todas las condiciones, entonces debe analizarse, y estáticamente, para todas las situaciones posibles. Bueno, dado que los lenguajes de programación funcionales se adaptan mucho mejor al análisis estático, es posible desarrollar un programa en algún lenguaje especial o agregar el uso de lenguajes de programación especiales. El primer enfoque se utiliza, por ejemplo, en el núcleo seL4 verificado. Un ejemplo del segundo enfoque es el mismo estándar ARINC-653 , con su formación obligatoria de requisitos en XML.

Existen otros métodos que aumentan la previsibilidad o, si lo desea, factores que afectan la previsibilidad del sistema. Hice un informe sobre este tema en una de las conferencias de OSDay . En particular, además de los ya mencionados, he resaltado un enfoque arquitectónico. Después de todo, es bien sabido que, por ejemplo, la arquitectura de microkernel puede aumentar la previsibilidad del sistema. Pero incluso en el mismo informe, se destacó un enfoque organizativo algo obvio. Este es casi el punto en el que no estaba de acuerdo en que la falta de RTOS conduce a una mayor previsibilidad. Si lo piensa, entonces, en general, el concepto de un sistema operativo ha reducido significativamente el número de errores debido a la reutilización del código. Es decir, si no tiene un código que realmente se ajuste a un conmutador / caja, entonces es mejor usar módulos listos para usar. Después de todo, el parámetro "número de errores por 1000 líneas de código" no se ha cancelado, y no importa cuán depurado sea su nuevo código, hay errores.

¿Existe RTOS en absoluto?

Habiendo establecido la declaración en la sección anterior de que hay errores en cualquier código, quiero hacer una tesis más provocativa. ¿Existe RTOS en absoluto?

Vamos a resolverlo. Al hablar con un amigo sobre los sistemas en tiempo real, acordamos en la medida en que un sistema operativo en tiempo real (estamos hablando de sistemas en tiempo real difíciles) apenas puede existir. Propuso representar todo el sistema como una máquina de estado o gráfico con una descripción del tiempo máximo de transición de un estado a otro. Además, el sistema puede considerarse estable si se demuestra que para todos los estados internos y de entrada, hay un arco que conduce a un estado determinado con un límite de tiempo. Bueno, entiendes, esto es posible solo para un sistema muy pequeño, solo la misma máquina de estados mencionada en el comentario, pero en el mundo moderno pocas personas necesitan ese sistema.

Pero no tenemos dudas de que existen sistemas en tiempo real. Y, por supuesto, RTOS también. Si esto no fuera así, entonces el primer pájaro carpintero volador destruiría la civilización, entonces no habría aviónica, astronáutica, robótica, ACS-TP y mucho más.

Cómo salir de la situación. Es muy simple, aunque en general el problema probablemente no se pueda resolver, pero para un problema específico, es posible introducir restricciones que lo resuelvan, con algún tipo de probabilidad de error significativa.

Por ejemplo, se introducen estándares: POSIX en tiempo real , ARINC-653 , ITRON . Estos estándares, de hecho, distinguen una clase de tareas que pueden resolverse si se adhiere a este estándar. O los estudios son realizados por laboratorios independientes que estudian si las propiedades de un sistema operativo particular son adecuadas para resolver el problema objetivo.

Entonces, ¿Embox RTOS o no RTOS?

En mi opinión, para responder una pregunta similar, tanto para Embox como para cualquier otro sistema operativo, solo puede preguntar: "¿Qué quieres decir?". Más precisamente: "¿Qué quieres decir con el concepto de tiempo real?". Es decir, si el tiempo de procesamiento de interrupciones es de interés, y si es posible llamar al controlador de interrupciones directamente, esto es una cosa, si necesita aumentar la confiabilidad del trabajo, aunque lentamente, pero ciertamente es mucho menos probable que falle, esta es otra, el cumplimiento de cualquier estándar es el tercero, La verificación es la cuarta. No es casualidad que el gran clásico Andrei Tanenbaum, aunque propuso métodos para aumentar la previsibilidad, utilizara el concepto mismo de un sistema en tiempo real, pero se abstuvo de cualquier definición estricta.

PD Al momento de escribir este artículo, ni un RTOS ha sido afectado.