Ir al contenido

Sistema de tiempo real

De Wikipedia, la enciclopedia libre
Sistema de tiempo real

Un sistema de tiempo real es un sistema informático que interacciona con su entorno físico y responde a los estímulos del entorno dentro de un plazo de tiempo determinado.[1]

otra definicion que tenemos es que son aquellos sistemas de procesamiento de información con componentes de software y hardware que deben cumplir con requisitos de tiempo muy estrictos y específicos. En otras palabras, estos sistemas deben ser capaces de procesar y responder a las solicitudes en un tiempo establecido como critico.

Los sistemas en tiempo real se diseñan utilizando técnicas y algoritmos específicos que garantizan que los requisitos de tiempo se cumplan. Estos algoritmos incluyen planificación de tareas en tiempo real, manejo de interrupciones, sincronización de procesos y control de tiempo.

Existen sistemas de tiempo real crítico (tiempo real duro), en los que los plazos de respuesta deben respetarse siempre estrictamente y una sola respuesta tardía a un suceso externo puede tener consecuencias fatales; y sistemas de tiempo real acrítico (tiempo real suave), en los que se pueden tolerar retrasos ocasionales en la respuesta a un suceso.[1]

Un ejemplo general para los sistemas de tiempo real es el de un robot que necesita tomar una pieza de una banda sinfín. Si el robot llega tarde, la pieza ya no estará donde debía recogerla, por tanto, el trabajo se llevó a cabo incorrectamente, aunque el robot haya llegado al lugar adecuado. Si el robot llega antes de que la pieza llegue, la pieza aún no estará ahí y el robot puede bloquear su paso.

Para un sistema de tiempo real crítico (tiempo real duro), se tiene como ejemplo el caso del sistema de refrigeración de una central nuclear, el cual debe de tener respuestas en la menor cantidad de tiempo posible (preferiblemente de inmediato) y no acepta ningún retraso ni error en su proceso, pues esto llevaría a una catástrofe nuclear.

Ejemplo

[editar]

Imaginemos una intersección de calles muy transitada en una ciudad. Para gestionar eficientemente el flujo de tráfico en este punto crítico, se implementa un sistema de control de semáforos basado en tiempo real para ello realizaremos lo siguiente.

  1. Censado de tráfico: Sensores estratégicamente ubicados en la intersección detectan la presencia de vehículos y peatones en cada dirección. Estos datos son continuamente recopilados y enviados al sistema de control central.
  2. Procesamiento en tiempo real: En el centro de control, un sistema informático dedicado procesa los datos de los sensores en tiempo real. Utilizando algoritmos avanzados, analiza la información para determinar la cantidad de vehículos y peatones en espera en cada dirección, así como la duración óptima de los ciclos del semáforo.
  3. Toma de decisiones: Basado en los datos procesados y en un algoritmo de optimización predefinido, el sistema toma decisiones precisas sobre la duración de cada fase del semáforo. Como decidir dar más tiempo de verde a la dirección con mayor congestión para aliviar el tráfico.
  4. Control de actuadores: Una vez que se toman las decisiones, el sistema activa los actuadores que controlan las luces del semáforo en tiempo real. Esto implica cambiar las luces de manera precisa y coordinada, asegurando una transición fluida entre las fases del semáforo.
  5. Optimización continua: El sistema monitorea constantemente el tráfico y realiza ajustes dinámicos en tiempo real para adaptarse a las condiciones cambiantes de la carretera. Como ajustar la duración de los ciclos del semáforo según el flujo de vehículos en tiempo real.

Breve historia de los Sistemas en Tiempo Real

[editar]

El origen del tiempo real proviene de la historia reciente del control de procesos utilizando plataformas de computación digital. De hecho, un texto temprano y definitivo sobre el concepto fue publicado en 1965. El concepto de tiempo real también tiene sus raíces en la simulación por computadora, donde se dice que una simulación que se ejecuta al menos tan rápido como el proceso físico del mundo real que modela se ejecuta en tiempo real. Muchas simulaciones deben hacer un compromiso entre ejecutarse a la misma velocidad o más rápido que el tiempo real, con una fidelidad del modelo menor o mayor. Lo mismo ocurre con las interfaces gráficas de usuario (GUI) en tiempo real, como las proporcionadas por los motores de juegos de computadora. No mucho después del texto de Martin sobre sistemas en tiempo real en 1965, se publicó un artículo definitivo que estableció los fundamentos de una definición matemática de tiempo real estricto: "Scheduling Algorithms for Multiprogramming in a Hard-Real-Time Environment" [Liu73]. Liu y Layland también definieron el concepto de tiempo real flexible en 1973; sin embargo, todavía no hay una definición formal universalmente aceptada de tiempo real flexible. Se han realizado numerosos trabajos e investigaciones para definir sistemas de calidad de servicio (QoS) donde los sistemas tienen permitido ocasionalmente no cumplir con los plazos o utilizan estrategias donde se utiliza la latencia de inicio y el almacenamiento en búfer para permitir la elasticidad en los sistemas en tiempo real.

El concepto de sistemas en tiempo real estricto se comprendió mejor a partir de la experiencia y los problemas observados en los sistemas implementados. Uno de los ejemplos más famosos en sus primeras etapas fue la sobrecarga de guía del módulo lunar del Apolo 11. El sistema del Apolo 11 sufrió una sobrecarga de recursos de la CPU que amenazaba con hacer que los servicios de guía de descenso no cumplieran con los plazos y casi resulta en la cancelación del primer alunizaje en la Luna. Durante el descenso del módulo lunar y el uso del sistema de radar, el astronauta Buzz Aldrin nota una alarma del sistema de guía por computadora. Según se relata en el libro "Failure Is Not an Option" [Kranz00], Buzz transmite por radio: "Alarma del programa. Es un 1202". Eugene Kranz, el director de operaciones de la misión Apolo 11, continúa explicando: "La alarma nos dice que la computadora está atrasada en su trabajo. Si las alarmas continúan, las actualizaciones de guía, navegación y visualización de la tripulación se volverán poco confiables. Si las alarmas persisten, la computadora podría detenerse por completo, abortando posiblemente la misión". En última instancia, basándose en la experiencia adquirida con esta condición de sobrecarga en simulación, se decidió continuar y hacer caso omiso de la alarma, como todos sabemos, el módulo Eagle aterrizó y Neil Armstrong luego puso pie de manera segura en la Luna. En general, ¿cómo se sabe que un sistema está sobrecargado en cuanto a los recursos de la CPU, memoria o E/S?

Claramente, es beneficioso mantener un margen de recursos cuando el costo del fallo es demasiado alto para ser aceptable (como fue el caso del módulo lunar), pero ¿cuánto margen es suficiente? ¿Cuándo es seguro continuar con la operación a pesar de la escasez de recursos? En algunos casos, la escasez de recursos puede ser simplemente una sobrecarga temporal de la cual el sistema puede recuperarse y seguir brindando servicios que cumplan con los requisitos de diseño. La alarma 1202 puede no haber sido la causa raíz de la sobrecarga, de hecho, algunos informes apuntan a la alarma 1201 como la causa, pero lo importante es que la sobrecarga del procesador indicada por el 1202 fue el resultado de un mayor cómputo del que se podía manejar dentro de los plazos requeridos cuando se agregó el procesamiento de la alarma a la carga de trabajo normal. Peter Adler proporciona un relato más detallado para aquellos lectores interesados en los relatos históricos precisos según lo indicado por los ingenieros que estuvieron directamente involucrados [Adler 98].

Desde el Apolo 11, se han observado problemas en tiempo real aún más interesantes en el campo, lo que ha demostrado que el diseño de sistemas en tiempo real es aún más complicado que simplemente garantizar márgenes. Por ejemplo, la nave espacial Mars Pathfinder estuvo a punto de perderse debido a un problema de procesamiento en tiempo real. El problema no fue debido a una sobrecarga, sino a una inversión de prioridades que causó que se perdiera un plazo a pesar de tener un margen razonable de la CPU. Si bien se requiere un acceso seguro para la corrección funcional, cumplir con los plazos de respuesta también es un requisito para los sistemas en tiempo real. Un sistema en tiempo real debe producir respuestas funcionalmente correctas a tiempo, antes de los plazos para la corrección general del sistema. Con cierta experiencia en el desarrollo de sistemas, la mayoría de los ingenieros están familiarizados con cómo diseñar y probar un sistema para que funcione correctamente. Además, la mayoría de los ingenieros de hardware conocen métodos para diseñar la sincronización de la lógica digital y verificar su corrección. Cuando el hardware, el firmware y el software se combinan en un sistema integrado en tiempo real, es necesario diseñar y probar el tiempo de respuesta para asegurarse de que el sistema integrado cumpla con los requisitos de los plazos. Esto requiere un diseño y prueba a nivel de sistema que vayan más allá de los métodos de hardware o software típicamente utilizados.

Como ha demostrado la historia, incluso los sistemas que fueron ampliamente probados no lograron proporcionar respuestas dentro de los plazos requeridos. ¿Cómo ocurren las sobrecargas o inversiones inesperadas? Para responder a estas preguntas, primero se debe entender la teoría fundamental del tiempo real estricto.

Beneficios

[editar]
  • Sincronización mas precisa. Los sistemas en tiempo real se crean para realizar tareas que deben realizarse dentro de escalas de tiempo de ciclo precisas (hasta microsegundos).
  • Mayor previsibilidad y confiabilidad. Como los sistemas en tiempo real procesan datos dentro de marcos de tiempo predecibles y establecidos, la ejecución de tareas o cargas de trabajo está prácticamente garantizada, lo que aumenta la confiabilidad de los sistemas de misión crítica.
  • Priorización de las cargas de trabajo en tiempo real. La capacidad de priorizar ciertas cargas de trabajo sobre otras es fundamental cuando las cargas de trabajo específicas en tiempo real deben completarse según lo programado para evitar fallas catastróficas del sistema. Algunos (pero no todos) los sistemas en tiempo real tienen esta capacidad en términos de carga de trabajo o priorización de tareas.

Estructura general de un sistema en tiempo real

[editar]
Estructura general de sistemas operativos en tiempo real
Estructura general de sistemas operativos en tiempo real
  • Sistema a controlar: Cualquier sistema que pueda ser controlado
  • Interfaz con el sistema. adaptar las señales que desde el sistema se envían al computador y desde el computador se mandan al sistema. Está formado por conversores analógicos digitales y digitales analógicos, que permiten medir el estado del sistema a controlar e imponer un control sobre la operación a realizar en dicho sistema.
  • Reloj de tiempo real. Un reloj que permita tomar muestras de las señales recibidas de los dispositivos, así como, mandarles determinadas señales en los momentos precisos. El reloj de tiempo real provoca una interrupción en cada período de muestreo
  • Consola del operador. Permite al operador humano realizar intervenciones manuales (arranque, parada, modificaciones en el comportamiento del sistema, etc.)
  • Pantallas. Se utilizan para enviar información al operador sobre el estado del sistema.
  • Base de datos. Los cambios de estado del sistema son guardados en una base de datos que el operador e ingenieros de control pueden interrogar en caso de fallo del sistema o para obtener información con propósito de gestión. Esta información va creciendo y se utiliza para tomar las decisiones que surgen con el funcionamiento del sistema.
  • Sistema de monitorización remoto. En procesos industriales, la monitorización de la planta es esencial para reducir costos y aumentar la producción. Las decisiones relativas a la producción de una planta pueden repercutir en el rendimiento de otras plantas que dependen de ella, como es el caso de una planta que produce materia prima para otra.
  • Computador. El software que controla las operaciones del sistema está escrito en módulos que reflejan la naturaleza física del entorno. De forma general, estos módulos son:
  • Algoritmos de control digital. Realizan el control del sistema.
  • Registros de datos. Permiten guardar los cambios de estado del sistema.
  • Información de dirección. Permiten facilitar información sobre el estado del sistema y las operaciones que se realizan a los encargados de la dirección del sistema global.
  • Interfaz con el operador. Para interactuar con el operador.
  • Tamaño y complejidad. A menudo problemas relacionados con sistemas en tiempo real se convierten en problemas de gran tamaño y complejidad.
  • Manipulación de números reales. Es la manera de representar los valores leídos del mundo real en un computador.
  • Seguridad y fiabilidad. Los sistemas en tiempo real suelen estar relacionados con procesos en los que los fallos tienen consecuencias graves, por lo tanto la tolerancia a fallos es un factor de vital importancia en su diseño.
  • Concurrencia. A menudo es necesario controlar el acceso a recursos compartidos, ejecutar varias tareas en paralelo, lo que provoca que los STR presenten un cierto grado de procesamiento en multitarea.
  • Eficiencia. Esta característica es exigible a todo tipo de sistemas, aún más en sistemas que pueden ser críticos, como los STR. Con esta característica se pretende asegura que el funcionamiento lógico de sistema es correcto y óptimo
  • Dependencia del tiempo. Como ya hemos visto el tiempo es el factor distintivo de los STR, a los que se les exige no solo una corrección lógica, si no que cumplan unos determinados requerimientos temporales. Su comportamiento temporal tiene que ser determinista, y a la hora del diseño, hay que prever el peor de los casos
  • Dispositivos de E/S especiales. La conexión con el exterior está adaptada a los procesos que se controlan y a menudo condicionan el funcionamiento del sistema. Las interacciones con el exterior pueden ser activas o pasivas, es decir, el sistema debe controlar el acceso al medio físico, o bien el medio físico perturba de alguna manera al sistema de control.

Clasificación de los sistemas en tiempo real

[editar]

Clasificación (Según requisitos temporales)

[editar]
  • Tiempo real estricto
    • Tienen requisitos de tiempo muy estrictos y no pueden tolerar ningún retraso en la respuesta. Si el sistema no cumple con los requisitos de tiempo, el resultado puede ser desastroso.  
  • Tiempo real no estricto (soft real time)
    • Tienen requisitos de tiempo menos estrictos y, por lo tanto, el sistema sigue funcionando, incluso si no se puede ejecutar en un tiempo asignado y sobre todo no tendrá consecuencias.
  • Incrementales

Clasificación (Atendiendo la arquitectura de hardware utilizada)

[editar]
  • Propietarios
    • Aquellos que utilizan tecnologías y protocolos cerrados y exclusivos de un proveedor específico para comunicarse y cooperar entre sí
  • Abiertos
    • Aquellos que utilizan tecnologías y protocolos estándar y abiertos para comunicarse y cooperar entre sí

Clasificación (Según el flujo de ejecución)

[editar]
  • Centralizados
    • Aquellos en los que un único componente (nodo central o servidor), controla y coordina la comunicación y el procesamiento de datos entre los diferentes nodos que conforman el sistema.
  • Distribuidos
    • Aquellos en los que el procesamiento y la comunicación de datos se distribuyen entre múltiples nodos o clientes que interactúan de manera cooperativa y autónoma.

Características de los sistemas de tiempo real

[editar]

Determinismo

[editar]

El determinismo es una cualidad clave en los sistemas de tiempo real. Es la capacidad de determinar con una alta probabilidad, cuánto es el tiempo que se toma una tarea en iniciarse. Esto es importante porque los sistemas de tiempo real necesitan que ciertas tareas se ejecuten antes de que otras puedan iniciar.

Esta característica se refiere al tiempo que tarda el sistema antes de responder a una interrupción. Este dato es importante saberlo porque casi todas las peticiones de interrupción se generan por eventos externos al sistema (i.e. por una petición de servicio), así que es importante determinar el tiempo que tardará el sistema en aceptar esta petición de servicio.

Responsividad

[editar]

La responsividad se enfoca en el tiempo que tarda una tarea en ejecutarse una vez que la interrupción ha sido atendida. Los aspectos a los que se enfoca son:

  • La cantidad de tiempo que se lleva el iniciar la ejecución de una interrupción
  • La cantidad de tiempo que se necesita para realizar la tarea que pidió la interrupción.
  • Los efectos de interrupciones anidadas.

Una vez que el resultado del cálculo de determinismo y responsividad es obtenido, se convierte en una característica del sistema y un requerimiento para las aplicaciones que correrán en él,(por ejemplo, si diseñamos una aplicación en un sistema en el cual el 95 % de las tareas deben terminar en cierto período entonces es recomendable asegurarse que las tareas ejecutadas de nuestra aplicación no caigan en el 5 % de bajo desempeño).

Usuarios controladores

[editar]

En estos sistemas, el usuario (por ejemplo, los procesos que corren en el sistema) tienen un control mucho más amplio del sistema.

  • El proceso es capaz de especificar su prioridad.
  • El proceso es capaz de especificar el manejo de memoria que requiere (que parte estará en caché y que parte en memoria swap y que algoritmos de memoria swap usar)
  • El proceso especifica qué derechos tiene sobre el sistema.

Esto aunque parece anárquico no lo es, debido a que los sistemas de tiempo real usan tipos de procesos que ya incluyen estas características, y usualmente estos TIPOS de procesos son mencionados como requerimientos. Un ejemplo es el siguiente:

«Los procesos de mantenimiento no deberán exceder el 3 % de la capacidad del procesador, a menos que en el momento que sean ejecutados el sistema se encuentre en la ventana de tiempo de menor uso.»

Confiabilidad

[editar]

La confiabilidad en un sistema de tiempo real es otra característica clave. El sistema no debe solamente estar libre de fallas, también debe de cumplir que la calidad del servicio que presta no se degradará más allá de un límite determinado de tiempo, esto quiere decir que debe de entregar la respuesta a una solicitud del usuario en una cantidad de tiempo específica.

Un sistema de tiempo real por ningún motivo debe dejar de funcionar, ya sea por fallas directas en el sistema o alguna degradación en el servicio, pues en el caso que dejara de funcionar se podrían ocasionar consecuencias catastróficas.

Cualquier sistema de tiempo real que no cumpla con esta característica dejará de ser útil y posteriormente olvidado, pues es necesario tener la confianza de que al usar cualquier sistema de tiempo real, la respuesta a las interacciones realizadas por el usuario serán prácticamente inmediatas.

Operación a prueba de fallas duras (fail hard operation)

[editar]

El sistema debe de fallar de manera que cuando ocurra una falla, el sistema preserve la mayor parte de los datos y capacidades del sistema en la mayor medida posible.

Que el sistema sea estable, es decir, que si para el sistema es imposible cumplir con todas las tareas sin exceder sus restricciones de tiempo, entonces el sistema cumplirá con las tareas más críticas y de más alta prioridad.

Extremadamente fiable y seguro

[editar]

La fiabilidad y seguridad son críticas en sistemas de tiempo real, donde un fallo puede tener consecuencias graves, como pérdida de fondos, fallos en sistemas vitales o daños ambientales. El diseño debe considerar la fiabilidad del hardware y del software, así como la minimización de errores humanos en la interacción con el sistema.

Control concurrente de componentes

[editar]

Los sistemas embebidos suelen interactuar simultáneamente con múltiples componentes externos, lo que requiere el manejo eficiente de la concurrencia. Los lenguajes modernos de programación ofrecen soporte directo para la programación concurrente, facilitando la comunicación y sincronización entre procesos.

Interacción con interfaces hardware

[editar]

Los sistemas embebidos deben interactuar con dispositivos externos, como sensores y actuadores, a través de registros de entrada y salida. El control directo de estos dispositivos y la gestión de interrupciones son fundamentales para el rendimiento y la fiabilidad del sistema.

Implementación eficiente y entorno de ejecución

[editar]

Dado que los sistemas de tiempo real son sensibles al tiempo, la eficiencia de la implementación es crucial. Los lenguajes de alto nivel pueden ofrecer abstracción, pero en sistemas embebidos, los programadores deben considerar el costo de utilizar características específicas del lenguaje en términos de rendimiento y tiempo de respuesta.[2]

Campos de utilización

[editar]

Control de procesos industriales

En la industria, los sistemas en tiempo real se utilizan para controlar y supervisar procesos como la producción de alimentos, bebidas, productos químicos y farmacéuticos, entre otros. Estos sistemas garantizan que las operaciones se realicen de manera precisa y eficiente, asegurando la calidad del producto final.

Sistemas de transporte

Los sistemas de transporte, como los aviones, trenes, automóviles y barcos, utilizan sistemas en tiempo real para controlar los procesos de navegación, comunicación y seguridad. Estos sistemas permiten a los operadores responder rápidamente a los cambios en el entorno y garantizar la seguridad de los pasajeros y la carga.

Telecomunicaciones

En la industria de las telecomunicaciones, los sistemas en tiempo real se utilizan para controlar el flujo de información en redes de alta velocidad, como la transmisión de datos, voz y video en tiempo real. Estos sistemas garantizan una comunicación fluida y confiable entre los usuarios y los dispositivos.

Sistemas de defensa

Los sistemas de defensa utilizan sistemas en tiempo real para el monitoreo y la respuesta a posibles amenazas, como ataques cibernéticos, guerra electrónica, interceptación de señales y otros tipos de actividad hostil. Estos sistemas permiten a los operadores actuar rápidamente para proteger la seguridad nacional y los intereses militares.

Sistemas médicos el q lee esto es cornudo

En la medicina, los sistemas en tiempo real se utilizan para monitorear y controlar las funciones vitales de los pacientes, como la frecuencia cardíaca, la presión arterial y la respiración. Estos sistemas permiten a los médicos responder rápidamente a cualquier cambio en el estado del paciente y proporcionar una atención médica oportuna y eficiente.

Análisis y diseño de sistemas en tiempo real

[editar]

Las características especiales de los sistemas en tiempo real diferentes a los demás tipos de sistemas introducen en la definición del sistema una serie requerimientos no funcionales, que no se refieren directamente a las funciones específicas si no a propiedades emergentes como por ejemplo, requisitos de fiabilidad, eficiencia o implementación.[3]​ El diseño por análisis estructurado que emplea la descripción gráfica se enfoca en el desarrollo de especificaciones del programa que está formado por módulos independientes desde el punto de vista funcional.

Planificación de tareas en sistemas de tiempo real[4]

[editar]

El algoritmo Earliest Deadline First (EDF) es un algoritmo de programación de prioridad dinámica optimo funciona como una estrategia de planificación fundamental en sistemas de tiempo real. Opera asignando prioridades basadas en la proximidad de las fechas límite de las tareas; es decir, la tarea con la fecha límite más cercana tiene la prioridad más alta y se ejecuta primero. Este enfoque garantiza que las tareas críticas, que a menudo tienen fechas límite inminentes, se completen a tiempo, es decir, utiliza la priorización de trabajos para la programación.

Asigna prioridades a la tarea de acuerdo con el plazo absoluto. EDF es muy eficiente en comparación con otros algoritmos de programación en sistemas de tiempo real puesto que puede hacer que la utilización de la CPU sea aproximadamente del 100% y al mismo tiempo garantizar los plazos de todas las tareas.

Además, incluye la sobrecarga de kernel, si el uso de la CPU es inferior al 100%, significa que todas las tareas han cumplido con la fecha límite, encuentra un calendario optimo y factible.

Este algoritmo es particularmente útil en entornos donde las tareas tienen diferentes plazos y es crítico que se cumplan para el correcto funcionamiento del sistema.

EDF utiliza una cola de prioridad para mantener las tareas ordenadas por el tiempo restante hasta sus respectivas fechas límite, seleccionando siempre la tarea con el menor tiempo restante para su ejecución. Este es un algoritmo preemptivo, lo que significa que una tarea en ejecución puede ser interrumpida si llega una nueva tarea con una fecha límite más urgente.

Principios básicos de EDF

[editar]

Las características principales de EDF incluyen su flexibilidad, ya que se adapta bien a sistemas dinámicos donde los tiempos de ejecución de las tareas pueden variar, y su capacidad para realizar un análisis de planificación relativamente sencillo.

  1. Priorización por plazos, las tareas se programan según el plazo de finalización más temprano. La tarea con el plazo de finalización más cercano tiene la máxima prioridad.
  2. Flexibilidad de cambios, permite adaptarse a cambios en los plazos de las tareas. Si un nuevo trabajo con un plazo de finalización más temprano llega al sistema, se programará antes que las tareas existentes.
  3. Utilización de recursos, puede garantizar una utilización del sistema del 100% si todas las tareas son factibles. Esto significa que, si las tareas tienen plazos de finalización alcanzables, el sistema siempre encontrará un plan de ejecución.

Planificación y scheduling

[editar]

El funcionamiento del algoritmo EDF se detalla en 4 sencillos pasos:

  1. Asignación de Prioridades: Cuando una tarea se vuelve ejecutable, anuncia su plazo. EDF asigna prioridades basándose en estos plazos, donde la tarea con el plazo más próximo recibe la mayor prioridad.
  2. Prevención: EDF permite la prevención, lo que significa que una tarea en ejecución puede ser interrumpida si otra tarea con un plazo más cercano está lista para ejecutarse.
  3. Utilización del CPU: EDF es eficiente en la utilización del CPU, pudiendo alcanzar hasta un 100% de utilización mientras garantiza que todas las tareas cumplan con sus plazos.
  4. Programación Factible: Si EDF no puede encontrar una programación factible para todas las tareas, significa que ningún otro algoritmo de planificación podrá hacerlo. Una programación factible es aquella en la que todas las tareas se ejecutan dentro de sus plazos

Análisis de rendimiento

[editar]

Para este análisis se requiere evaluar la eficiencia del algoritmo en diferentes escenarios y cargas de trabajo, para ello utilizaremos un sencillo ejemplo. Consideremos dos procesos P1 y P2.

Sea el período de P1 p1 = 50 con tiempo de procesamiento P1 t1 = 25 y para el periodo P2 el p2 = 75 con un tiempo de procesamiento P2 t2 = 30

Solución

[editar]
  1. La fecha límite de P1 es anterior, por lo que la prioridad de P1>P2.
  2. Inicialmente, P1 se ejecuta y completa su ejecución de 25 veces.
  3. Después de 25 veces, P2 comienza a ejecutarse hasta 50 veces, cuando P1 es capaz de ejecutar.
  4. Ahora, comparando la fecha límite de (P1, P2) = (100, 75), P2 continúa ejecutándose.
  5. P2 completa su procesamiento en el momento 55.
  6. J1 comienza a ejecutarse hasta el tiempo 75, cuando J2 es capaz de ejecutar.
  7. Ahora, comparando de nuevo el plazo de (P1, P2) = (100, 150), P1 continúa ejecutándose.
  8. Repita los pasos anteriores...
  9. Finalmente, en el momento 150, tanto P1 como P2 tienen la misma fecha límite, por lo que P2 continuará ejecutándose hasta su tiempo de procesamiento, después de lo cual P1 comienza a ejecutarse.

Ventajas

[editar]

EDF garantiza una alta utilización de recursos si todas las tareas son factibles, lo que puede ser beneficioso en sistemas donde la eficiencia es crítica.

La capacidad de EDF para adaptarse a cambios en los plazos de finalización de las tareas lo hace adecuado para entornos dinámicos donde los requisitos de tiempo pueden cambiar.

Sin embargo, a pesar de sus ventajas, EDF puede no ser óptimo en términos de utilización de CPU en escenarios con un alto volumen de tareas, pudiendo llevar a situaciones de inanición o incumplimiento de plazos bajo ciertas condiciones.

Desafíos y limitaciones

[editar]

Problemas de Inanición (Starvation): EDF puede sufrir de problemas de inanición si una tarea con un plazo de finalización muy largo llega al sistema, lo que puede hacer que las tareas con plazos más cortos no se completen a tiempo.

Complejidad de Implementación: La implementación de EDF puede ser más compleja que otros algoritmos de planificación debido a la necesidad de verificar continuamente la factibilidad y realizar cambios dinámicos.

Computación en tiempo real

[editar]

La computación en tiempo real (o informática en tiempo real) está relacionada con los sistemas de hardware y software que se ven limitados por problemas de tiempo. El software de tiempo real debe necesariamente tener la característica de un tiempo de respuesta crítico.

Por ejemplo, el software encargado de controlar un respirador artificial debe ser de tiempo real, ya que un retraso en su tiempo de respuesta no es aceptable. Algunos tipos de programas como los empleados para jugar al ajedrez solo disponen del tiempo necesario para poder efectuar la siguiente jugada.

Se podría hacer una distinción, por ejemplo, un sistema de gestión del motor de un coche es un sistema en tiempo real activo porque una señal retrasada puede causar un daño o fallo en el motor. Otros ejemplos de sistemas integrados en tiempo real activos son los sistemas médicos como los marcadores de pasos artificiales y los controladores de procesos industriales.

Los sistemas de tiempo real pasivos se utilizan normalmente cuando hay un acceso compartido y se necesitan mantener actualizados un número de sistemas conectados con una situación cambiante. Un ejemplo serían los programas que mantienen y actualizan los planes de vuelo de las compañías aéreas comerciales. Estos programas pueden funcionar en cuestión de segundos.

No sería posible ofrecer vuelos comerciales modernos si estas operaciones no se pudieran realizar de manera fiable en tiempo real. Los sistemas de audio y video en directo también son sistemas en tiempo real pasivos típicos ya que si se sobrepasan los límites de tiempo lo único que puede pasar es que se empeore la calidad pero el sistema continua trabajando.

Las necesidades de los programas de tiempo real se pueden solucionar con sistemas operativos en tiempo real, que ofrecen un marco sobre el que construir aplicaciones de programas en tiempo real.

Sistemas operativos de tiempo real

[editar]

Un sistema operativo de tiempo real (SOTR o RTOS -Real Time Operating System en inglés) es un sistema operativo que ha sido desarrollado para aplicaciones de tiempo real. Como tal, se le exige corrección en sus respuestas bajo ciertas restricciones de tiempo. Si no las respeta, se dirá que el sistema ha fallado. Para garantizar el comportamiento correcto en el tiempo requerido se necesita que el sistema sea predecible (determinista).

Véase también

[editar]

Referencias

[editar]
  1. a b Villarroel Salcedo, José Luis. Sistemas de Tiempo Real. Archivado desde el original el 22 de febrero de 2014. 
  2. Burns, Alan; Wellings, Andy. Sistemas de Tiempo Real y Lenguajes de Programación. Adisson Wesley. 
  3. Sommerville, Ian (2005). «6.1.2 Requerimientos no funcionales». Ingeniería del software, Séptima edición. Pearson Educación. p. 111 |página= y |páginas= redundantes (ayuda). ISBN 84-7829-074-5. 
  4. Hei, Xiaojun. The earliest deadline first scheduling for real-time traffic in the Internet. The Hong Kong University of Science and Technology Library. Consultado el 13 de mayo de 2024. 
  • Descripción general y ejemplos de sistemas en tiempo real: Intel. (n.d.). Intel. https://www.intel.es/content/www/es/es/robotics/real-time-systems.html
  • Pratt, J. & Siewert, S. (2016). Real-Time Embedded Components and Systems with Linux and RTOS. MERCURY LEARNING and INFORMATION.

Enlaces externos

[editar]