Informática III Arquitectura de Software para aplicaciones de tiempo real estricto Ejecutivos cíclicos VS. Ejecutivos de prioridad fija Integrantes: Anibal.

Presentación del tema: "Informática III Arquitectura de Software para aplicaciones de tiempo real estricto Ejecutivos cíclicos VS. Ejecutivos de prioridad fija Integrantes: Anibal."— Transcripción de la presentación:

1 Informática III Arquitectura de Software para aplicaciones de tiempo real estricto Ejecutivos cíclicos VS. Ejecutivos de prioridad fija Integrantes: Anibal Barros Porri Lucas Iede Diego Magdalena

2 Arquitectura de Software para aplicaciones de tiempo real estricto
Introducción En la práctica existen 2 enfoques basicos de aplicación para el diseño de sistemas de tiempo real, los cuales son: La arquitectura ejecutiva cíclica La arquitectura ejecutiva de prioridad fija

3 Objetivo principal de diseño
Arquitectura de Software para aplicaciones de tiempo real estricto Objetivo principal de diseño El objetivo principal de diseño de aplicaciones de tiempo real es: la arquitectura debe ser capaz de proporcionar una predicción comprobable de la capacidad del diseño de aplicaciones para satisfacer todas las limitaciones de su tiempo. El objetivo principal de diseño de aplicaciones de tiempo real que más directamente determina la arquitectura de software que se utilizará para una aplicación determinada es que: la arquitectura debe ser capaz de proporcionar una predicción comprobable de la capacidad del diseño de aplicaciones para satisfacer todas las limitaciones de su tiempo. Este objetivo difiere del objetivo expresado con frecuencia de determinismo Los sistemas en tiempo real enfatizan en la predictibilidad, confiabilidad y en los requerimientos de tiempo. Muchos de los sistemas en TR, están diseñados para trabajar como sistemas operativos distribuido, pero no se suele aprovechar esta característica.

4 Determinismo y Predictibilidad
Arquitectura de Software para aplicaciones de tiempo real estricto Determinismo y Predictibilidad El determinismo se usa frecuentemente para describir un sistema en el cual el tiempo de ejecución real y la secuencia es completamente predeterminada y fija para la ejecución entera del sistema. Si bien es cierto que el determinismo es suficiente para la predictibilidad, el determinismo no es necesario para alcanzar la predictibilidad. Además, El objetivo especifica la probabilidad de su predictibilidad, pero no necesariamente significa llevar a cabo una prueba. En este caso, comprobabilidad significa que las técnicas de diseño utilizadas deben ser derivables de modelos de ejecución rigurosamente definidos que producen resultados demostrables dentro de las limitaciones del modelo. Mientras es ciertamente cierta que el determinismo es suficiente para la pronosticabilidad, el determinismo no hay que lograr pronosticabilidad. Predictibilidad y determinismo, requerimientos de tiempo. S.O. a tiempo real Priman la predictibilidad del sistema frente a la eficiencia El parámetro del rendimiento que los define es el tiempo de respuesta corta Se pueden clasificar en “hard y soft real time” Supone un nuevo enfoque en el diseño de gestores de recursos Medidas: - Determinismo: un SO tpo real es determinista si realiza las operaciones en instantes fijos y predeterminados o en intervalos de tiempo predeterminados. El determinismo hace referencia a cuánto tiempo consume un sistema operativo en reconocer una interrupción.

5 Arquitectura de Software para aplicaciones de tiempo real estricto
Planificación La planificación de los recursos de la CPU para sistemas de tiempo real. Se refiere al concepto de poner en secuencia el uso de cualquier recurso compartido cuyo uso involucra satisfacer las limitaciones de tiempo de aplicación. El diseño tradicional “ejecutivo cíclico” ha captado esta idea en que cada aspecto de la aplicación es estáticamente planificado. La estructura de “prioridad fija” mediante la programación de tasa monotónica. La estructura completa del diseño de aplicación será dictada por la elección del algoritmo de planificación entre el ejecutivo cíclico o la prioridad fija. Hay dos perspectivas: 1- El diseño tradicional “ejecutivo cíclico” ha captado esta idea en que cada aspecto de la aplicación es estáticamente planificado, incluyendo todos sus recursos como E/S, redes, y programación de la CPU, usando la estructura básica definida por el ejecutivo cíclico. Del mismo modo, los defensores de la estructura de “prioridad fija” (mediante la programación de tasa monotónica) también describen su trabajo en términos de un conjunto total de los recursos a utilizar, aunque esto no siempre ha sido del todo claro. 2- Así, para una estructura ejecutiva cíclica, la aplicación está dividida en un set de procedimientos que están asumidos para ser no prioritarios, porque el derecho de prioridad no es requerido para el diseño ejecutivo cíclico de un uniprocesador. Entonces la estructura del ejecutivo cíclico, llama a estos procedimientos, de a uno cada vez, según sus posiciones en una secuencia predeterminada de tiempo. De modo semejante, utilizando el enfoque de prioridad fija, la aplicación está dividida en un set de tareas prioritarias; la decisión de planificación para cada recurso es determinada exclusivamente por la prioridad de las tareas. En el paradigma de la planificación de prioridad fija, estas tareas son generalmente con derecho de prioridad, por lo que debe prestarse mucha atención a la manipulación de los recursos compartidos por las tareas para que sus requisitos de cohexistencia, así como sus requerimientos de tiempo, se garantiza que se cumplan. En las aplicaciones de tiempo real, el funcionamiento correcto NO sólo depende de la corrección de los resultados de los cálculos, sino que también depende del instante en el que éstos son obtenidos. El sistema operativo, y concretamente la política de planificación debe garantizar que todas las tareas críticas sean capaces de cumplir sus plazos de ejecución (obtener los resultados antes del plazo máximo especificado). En los planificadores cíclicos se coloca “a mano” el orden de ejecución de los trabajos durante un hiperperiodo fuera del tiempo de ejecución. Cuando esté en funcionamiento el sistema, el software que ejecuta el planificador se encargará de activar las tareas según el plan que ya ha sido definido previamente. En los planificadores por prioridades se asigna una prioridad a cada tarea en base a su importancia. En tiempo de ejecución se ejecutará siempre la tarea de más prioridad que este activa en cada instante. En este caso es el planificador el que decide en cada instante que tarea debe ejecutarse. La asignación de prioridades puede ser: - Estática. La prioridad de cada tarea permanece constante durante toda la vida del sistema. - Dinámica. Las prioridades de las tareas varían con el tiempo según unas determinadas reglas. Para una estructura ejecutiva cíclica, la aplicación está dividida en un set de procedimientos que están asumidos para ser no prioritarios, porque el derecho de prioridad no es requerido para el diseño ejecutivo cíclico de un uniprocesador. Para el enfoque de prioridad fija, la aplicación está dividida en un set de tareas prioritarias; la decisión de planificación para cada recurso es determinada exclusivamente por la prioridad de las tareas, las cuales son generalmente con derecho de prioridad.

6 Sistemas de tiempo real estrictos
Arquitectura de Software para aplicaciones de tiempo real estricto Sistemas de tiempo real estrictos Un sistema de tiempo real es un sistema informático que interacciona con su entorno, sobre el que realiza acciones de control que se producen dentro de intervalos de tiempo bien definidos Sistemas de tiempo real estricto: es absolutamente imprescindible que se cumplan siempre los plazos ya que una sola respuesta fuera del intervalo previsto podria tener consecuencias catastroficas, tales como la perdida de vidas humanas o el fracaso total de la misi´on. Un claro ejemplo de STR estricto es el sistema ABS (Sistema Anti-Bloqueo) de un autom´ovil que evita que las ruedas queden bloqueadas durante la frenada (pues esto dejaria ingobernable la direccion del vehiculo). Para ello, el sistema debe controlar la velocidad de giro de las ruedas y aflojar la presion que ejercen los frenos en caso de que se detecte un bloqueo inminente. Obviamente, una respuesta tardia del sistema en esta situacion podria desembocar en un accidente con victimas. Sistemas de tiempo real flexible: el valor que tiene una respuesta decrece con el paso, del tiempo por lo que se permite que las respuestas lleguen fuera de plazo ocasionalmente. Por ejemplo, un sistema de control industrial que nivela el flujo a trav´es de una tuber´ıa debe detectar cualquier desviaci´on del nivel ideal y disparar una alarma lo antes posible. Cuanto m´as tarde el sistema en responder para corregir la desviaci´on, mayores ser´an las p´erdidas producidas. Sistemas de tiempo real firme: una respuesta tard´ıa carece de valor, sin embargo, las consecuencias no son tan severas como en los sistemas estrictos por lo que p´erdidas de plazos ocasionales son admisibles. Por ejemplo, en una planta de embotellado, si el grifo deja salir exactamente la cantidad de l´ıquido previsto, pero lo hace unas d´ecimas de segundo tarde, cuando la botella ya no est´a debajo, ´esta se queda vac´ıa y carece de valor, sin embargo, es admisible que este fallo suceda ocasionalmente siempre y cuando el porcentaje de errores se mantenga por debajo de un cierto umbral.

7 Condición para los esquemas de planificación
Arquitectura de Software para aplicaciones de tiempo real estricto Condición para los esquemas de planificación La condicion que requieren se refiere a la programación (planificación) de los recursos de la CPU. Sin embargo, en un sentido más amplio, es fundamental comprender que la programación se refiere en realidad al concepto de la secuencia del uso de cualquier recurso compartido cuyo uso implica satisfacer las limitaciones de tiempo de aplicación.

8 Modelo de procesos simple
Arquitectura de Software para aplicaciones de tiempo real estricto Modelo de procesos simple La aplicación está compuesta por un conjunto fijo de tareas y se conoce en tiempo de ejecución (estático) Todas las tareas son periódicas Las tareas son completamente independientes Los plazos de respuesta de todas las tareas son iguales a sus periodos El tiempo de ejecución máximo de cada tarea es conocido y fijo Todas las sobrecargas del sistema son ignoradas Modelo de tareas en tiempo real Se supone que la aplicación está compuesta por un conjunto fijo de tareas y se conoce en tiempo de ejecución (estático) Todas las tareas son periódicas, con periodos conocidos Las tareas son completamente independientes unas de otras Los plazos de respuesta de todas las tareas son iguales a sus periodos (o sea, cada tarea debe acabar antes de ser ejecutada nuevamente) El tiempo de ejecución máximo de cada tarea es conocido y fijo Todas las sobrecargas del sistema son ignoradas Modelo de tareas en tiempo real

9 Algoritmo de planificación
Arquitectura de Software para aplicaciones de tiempo real estricto Algoritmo de planificación Un algoritmo de planificación es un código que determina el orden de acceso de las tareas a los recursos del sistema tiempos de uso del procesador, memoria, etc.

10 Ciclo principal y ciclo secundario
Arquitectura de Software para aplicaciones de tiempo real estricto Ciclo principal y ciclo secundario Si las tareas a ejecutar son periódicas se puede programar un plan de ejecución consistente en un ciclo principal compuesto por varios ciclos secundarios dentro de los cuales se le asigna una cantidad de tiempo a las tareas que se quiera ejecutar.

11 Ciclo principal y ciclo secundario
Arquitectura de Software para aplicaciones de tiempo real estricto Ciclo principal y ciclo secundario

12 Generación de la señal de ciclos secundarios
Arquitectura de Software para aplicaciones de tiempo real estricto Generación de la señal de ciclos secundarios Un diseño común y simple para un ejecutivo cíclico es cargar el período del ciclo menor en una tarea después del temporizador que genera una interrupción cuando llega a cero. Si el sistema se comporta correctamente, el software estará en un estado de espera, haciendo que el ejecutivo cíclico ejecute inmediatamente una o más tareas (secuenciales) cuyos períodos estén listos para comenzar. El período de cada ciclo menor está establecido en general el mismo valor para simplificar la implementación, la cual puede ser activada por un temporizador de interrupción periódica o por alguna otra interrupción periódica de hardware externo que mantiene el programa en la sincronización con su entorno externo. En cada activación, cada tarea de la aplicación es necesaria para completar su ejecución dentro del período de ciclo menor, que también se llama un marco. El marco término se utiliza especialmente en sistemas en los que la duración del ciclo menor de edad no es una constante. Por lo tanto, cada aplicación se convierte en tarea fundamental periódicos a una tasa fija que se determina por su posición en la lista de ejecución cíclica (o línea de tiempo). Un diseño común y simple para un ejecutivo cíclico es cargar el período del ciclo menor en una tarea después del temporizador que genera una interrupción cuando llega a cero. Si el sistema se comporta correctamente (es decir, no se sobrecarga), el software estará en un estado de espera o en una tarea de fondo en el momento en que la interrupción se genera, haciendo que el ejecutivo cíclico ejecute inmediatamente una o más tareas (secuenciales) cuyos períodos estén listos para comenzar. Una sobrecarga del procesador puede ser detectado cuando el ejecutivo señala que la interrupción se ha producido cuando el software no está en el estado de espera o una tarea en segundo plano.

13 Definición de marco o frame
Arquitectura de Software para aplicaciones de tiempo real estricto Definición de marco o frame Se llama marco o frame a cada tarea de la aplicación donde es necesaria para completar su ejecución dentro del período de ciclo menor (secundario). El término marco se utiliza especialmente en sistemas en los que la duración del ciclo secundario no es una constante.

14 Relación de los períodos de todas las tareas
Arquitectura de Software para aplicaciones de tiempo real estricto Relación de los períodos de todas las tareas La ejecución de cada tarea individual se llama un ciclo secundario o menor, y la frecuencia del ciclo mayor se establecerá en el mínimo común múltiplo de las frecuencias de cada tarea.

15 Cómo se ejecutarían las tareas
Arquitectura de Software para aplicaciones de tiempo real estricto Cómo se ejecutarían las tareas 1. Manejar la línea de tiempo con una frecuencia que es un múltiplo común de las frecuencias de las dos tareas. 2. Manejar una de las tareas a una frecuencia ligeramente superior a su frecuencia natural (por ejemplo, controlar el sensor de cada 75 ms.). 3. Una combinación de ambos (Ej. manejar la entrada del operador cada 50 ms. y el proceso del sensor cada otro ciclo) Las tres opciones son comúnmente realizadas en los diseños existentes, pero cada uno tiene sus inconvenientes. Si el ciclo más rápido de menor importancia (opción 1) es elegido, las entradas de reloj adicionales podrían producir mayores gastos por el ejecutivo, sin capacidad de funciones añadidas para la aplicación y el tiempo de ejecución, o sea para la tarea no puede superar los 25 ms. Además, el problema que encontramos con conflictos de marco, en este caso es bastante común y la solución tiene el efecto de aumentar la frecuencia de la tarea B (6 ejecuciones cada 400 ms, en lugar de cuatro cada 300 ms...). Si la tarea requiere B 20 ms. máximo para ejecutar, por ejemplo, aumenta su uso del procesador cerca de 27% a 30%, resultando en una pérdida de carga total del 3% de procesador disponible. Si la decisión se hizo para ejecutar una de las tareas con mayor frecuencia para ponerlas en una relación armónica (opciones 2 y 3), da por resultado significativamente una utilización mayor del procesador, sin aumento de la capacidad funcional para la aplicación. Por ejemplo, si la tarea del operador en tiempo de ejecución obligada es de 35 ms., el cambio de su período de 75 ms. a 50 ms. cambia su carga en el procesador en general del 47% al 70%, entonces se tiene una pérdida del 23% de la carga del procesador disponible total. En la práctica, estas decisiones de diseño se hacen con frecuencia, pero se hacen comúnmente tan temprano en el proceso de definición de los requisitos del sistema, por la especificación arbitraria de relaciones armónicas de tiempo, que el aumento de carga significativa del sistema pasa desapercibido.

16 Arquitectura de Software para aplicaciones de tiempo real estricto
Frame overrun Un frame overrun es una condición en la que un tiempo de ejecución de la tarea excede su marco. Un correcto manejo de un marco de retraso es extremadamente difícil. Hay básicamente dos opciones: o bien el ejecutivo cíclico permite que la tarea de superación, lo que puede caer todo el resto de la línea de tiempo, o se aborta la tarea de generación de la superación. Ambos enfoques son peligrosos.

17 Ventajas del ejecutivo cíclico
Arquitectura de Software para aplicaciones de tiempo real estricto Ventajas del ejecutivo cíclico Es el método más determinista o predecible. Esta condición es de las más repetidas en los sistemas de tiempo real. El planificador cíclico suele ser sencillo y por lo tanto consume poca CPU. Así, pueden planificarse sin problemas procesos que ocupen hasta un 90% del total. Al ser el sistema determinista, una vez en funcionamiento siempre puede saberse qué va a pasar. Esto no sucede con los planificadores basados en prioridades.

18 Cambio de contexto (context switch)
Arquitectura de Software para aplicaciones de tiempo real estricto Cambio de contexto (context switch) Entre los parámetros clave que afectan al tiempo de respuesta esta el cambio de contextos y la latencia de la interrupción. El cambio de contexto se refiere al tiempo y sobrecarga necesitado para conmutar entre tareas, y la latencia de interrupción es el tiempo que pasa antes de que el cambio sea realmente posible. Otros parámetros afectan al tiempo de respuesta son la velocidad de calculo y el acceso a memorias masivas.

19 Arquitectura de Software para aplicaciones de tiempo real estricto
jitter Se denomina Jitter (fluctuación) a la variabilidad temporal de un resultado calculado durante el envío de señales, una ligera desviación de la exactitud de la señal de reloj. En general se denomina jitter a un cambio indeseado y abrupto de la propiedad de una señal. Esto puede afectar tanto a la amplitud como a la frecuencia y la situación de fase. El jitter es la primera consecuencia de un retraso de la señal. Se define jitter a la variación en cortos periodos de los instantes significantes de una señal se su posición ideal en el tiempo.

20 Desventajas del ejecutivo cíclico
Arquitectura de Software para aplicaciones de tiempo real estricto Desventajas del ejecutivo cíclico Fragilidad de aplicación: es el inconveniente mas grave, producido en un diseño de software. Manejo de las funciones cuyo plazo de ejecución es largo en comparación con el periodo de la tarea de mas alta cadencia. Por fragilidad de aplicación se entiende a cualquier cambio en el sistema ya sea durante la integración del sistema o posteriormente durante el mantenimiento del sistema cuando se aplica una función adicional. Generalmente se produce un resultado en alguna parte que superara el plazo de tiempo en alguna parte de la solicitud de acuerdo a como se define en la planificación cíclica original.

21 Resumen del ejecutivo cíclico
Arquitectura de Software para aplicaciones de tiempo real estricto Resumen del ejecutivo cíclico Un esquema de planificación tiene dos facetas: define un algoritmo para la compartición de recursos, y es un medio de predicción del peor caso del comportamiento de una aplicación que está utilizando esa forma de compartición de recursos. La mayoría de los sistemas periódicos de tiempo real actuales se implementan utilizan un ejecutivo cíclico. Con este enfoque, el código de aplicación debe empaquetarse en un número fijo de ciclos secundarios, de forma que la ejecución de la secuencia de ciclos secundario llamada "ciclo principal" permita que se cumplan todos los tiempos límite del sistema. Aunque es una estrategia de implementación efectiva para sistemas pequeños, este enfoque cíclico tiene una serie de inconvenientes. Con el enfoque del ejecutivo cíclico, la ejecución consiste en una secuencia de invocaciones a procedimientos. La noción de proceso (hilo) no se preserva durante la ejecución. Un enfoque alternativo es soportar la ejecución de procesos de forma directa (como es norma en los sistemas operativos de propósito general), y determinar cuál es el proceso que deberá ejecutarse en cada instante de tiempo, mediante uno o más atributos de planificación. serie de inconvenientes. * El empaquetado de los ciclos secundarios incrementa su dificultad según crece el sistema * Las actividades esporádicas son difícilmente acomodables. * Los procesos con periodos grandes (mayores que el ciclo principal) son soportados de forma ineficiente. * Los procesos con grandes tiempos de computación deben ser divididos, de forma que puedan ser empaquetados en series de ciclos secundarios. * Es muy difícil alterar la estructura del ejecutivo cíclico para acomodar los cambios en los requisitos Con este enfoque, un proceso está limitado a estar en uno de los posibles estados siguientes (suponiendo que no exista comunicación entre procesos): * Ejecutable. * Suspendido en espera de un evento temporizado (apropiado para procesos periódicos). * Suspendido en espera de un evento no temporizado (apropiado para procesos esporádicos).

22 Arquitectura de Software para aplicaciones de tiempo real estricto

23 Planificación de prioridades fijas
Arquitectura de Software para aplicaciones de tiempo real estricto Planificación de prioridades fijas La planificación de prioridades fijas: es un método estático muy usado. La prioridad es un parámetro relacionado con la urgencia o importancia de la tarea En todo momento se ejecuta la tarea con mayor prioridad de todas las ejecutables (es decir, no esté retrasado o suspendido) Las tareas se reparten el procesador de forma dinámica (invisible para el diseñador) Cada tarea tiene una prioridad En cada momento se ejecuta la tarea activa de mayor prioridad Las tareas consideradas críticas para el sistema tienen una alta prioridad, mientras que las tareas menos importantes se ejecutan a menor prioridad. En términos de previsibilidad, es fácil determinar la capacidad de la tarea de mayor prioridad para cumplir con sus plazos, pero la determinación de la previsibilidad de tareas de menor prioridad ha sido, en general es dejada para la fase de prueba del sistema de un proyecto.

24 Arquitectura de Software para aplicaciones de tiempo real estricto

25 Arquitectura de Software para aplicaciones de tiempo real estricto

26 Arquitectura de Software para aplicaciones de tiempo real estricto

27 Algoritmo de asignación de prioridad de tasa monotónica
Arquitectura de Software para aplicaciones de tiempo real estricto Algoritmo de asignación de prioridad de tasa monotónica El algoritmo de asignación de prioridad de tasa monotónica consiste en asignar menor prioridad a las tareas de menor periodo, es óptima para el modelo de tareas simples. El valor al que tiende el límite de utilización es 0,69 cuando N tiende a infinito en la sig. ecuación:

28 Arquitectura de Software para aplicaciones de tiempo real estricto
Instante crítico El instante crítico es aquel en el que se activan todos los procesos a la vez (esto suele ocurrir en el instante 0). Para la planificación de prioridades estáticas, esta suposición resulta segura; si todos los procesos cumplen sus requisitos de temporización cuando son activados conjuntamente, siempre serán panificables. Existen, sin embargo, conjuntos de procesos que se pueden beneficiar de la elección explícita de sus tiempos de activación de forma que no compartan un instante crítico. Se podría decir que un proceso tiene un desplazamiento con respecto a otros. Una consecuencia de la independencia entre procesos es que se puede suponer que en algún instante de tiempo todos los procesos son ejecutados a la vez. Esto representará la carga máxima para el procesador, y se conoce como un instante critico.

29 Arquitectura de Software para aplicaciones de tiempo real estricto

30 Análisis del tiempo de respuesta
Arquitectura de Software para aplicaciones de tiempo real estricto Análisis del tiempo de respuesta Análisis del tiempo de respuesta Las pruebas basadas en la utilización para FPS tienen 2 inconvenientes: No son exactas y, No son realmente aplicables a un modelo de tareas más general Se verá una forma diferente basada en el cálculo del tiempo de respuesta en el peor caso de cada tarea, Ri y una simple comprobación: R≤D

31 Ventajas del algoritmo
Arquitectura de Software para aplicaciones de tiempo real estricto Ventajas del algoritmo 1. La ventaja principal, que afecta en gran medida el costo del ciclo de vida total del sistema, es la previsibilidad de todo el conjunto de las tareas relativas al cumplimiento de los requisitos definidos externamente de la aplicación, incluso cuando estos requisitos están cambiando. Si se determina a través de esta predicción de que la solicitud no cumple con sus requisitos mínimos (es decir, uno o más de las tareas críticas ya no estan seguras de completar en el tiempo), la teoría de la tasa monotónica también proporciona herramientas para analizar el potencial de correctivas acciones, tales como el uso de procesadores adicionales, procesadores más rápidos, o la reducción de la funcionalidad. 2. Ya se ha señalado que esta técnica no requiere el uso de las relaciones de frecuencia armónica entre las tareas periódicas. Por lo tanto, se hace posible para las tareas periódicas el uso de frecuencias que son naturales a los requisitos de aplicación externa y no sufrir una degradación del rendimiento. 3. El enfoque de la tasa monotónica permite la estructura de la tarea de la aplicación para reflejar con mayor precisión los requisitos de aplicación, ya que no hay necesidad de romper arbitrariamente las tareas individuales con el fin de cumplir los límites de longitud de la trama. 4. Una planificación de tasa monotónica exhibe un alto grado de estabilidad, lo que significa que en el caso de una sobrecarga la tarea se perderán sus limitaciones de tiempo predefinidos. Esta estabilidad se deriva del hecho de que, en una sobrecarga, las tareas de mayor prioridad cuya utilización no ha superado la tasa de utilización monótona obligados, se garantiza que continúen asumiendo sus limitaciones de tiempo. Tareas en o por debajo de la prioridad en que se supere esta utilización puede pasar por alto sus limitaciones de tiempo. 1. La ventaja principal, que afecta en gran medida el costo del ciclo de vida total del sistema, es la previsibilidad de todo el conjunto de las tareas relativas al cumplimiento de los requisitos definidos externamente de la aplicación, incluso cuando estos requisitos están cambiando. Dado que esta previsión se basa sólo en el conocimiento de la utilización total del procesador de la tarea fijada, para determinar la planificabilidad de un sistema cuando una tarea adicional se añade requiere recalcular solamente la planificabilidad total y determinar si la utilización de nuevas tareas causó el salto a una funcionalidad excedida. Si los nuevos límites no se superan, no hay ninguna posibilidad de influir en la ejecución de cualquiera de las tareas funcionalmente afectadas y por lo tanto la planificación del sistema no se ve afectada. Por otro lado, si ahora nos encontramos con que se superen los límites de planificabilidad, sabemos de la teoría de la tasa monótona que ya no se puede planificar tareas en forma segura, y entonces se puede predecir el rendimiento del sistema con la capacidad añadida. Si se determina a través de esta predicción de que la solicitud no cumple con sus requisitos mínimos (es decir, uno o más de las tareas críticas ya no estan seguras de completar en el tiempo), la teoría de la tasa monotónica también proporciona herramientas para analizar el potencial de correctivas acciones, tales como el uso de procesadores adicionales, procesadores más rápidos, o la reducción de la funcionalidad. 2. Ya se ha señalado que esta técnica no requiere el uso de las relaciones de frecuencia armónica entre las tareas periódicas. Por lo tanto, se hace posible para las tareas periódicas el uso de frecuencias que son naturales a los requisitos de aplicación externa y no sufrir una degradación del rendimiento. Tal eficacia general, es imposible usar en el ejecutivo cíclico, tanto por las relaciones armónicas forzadas de tipo periódicos, y debido a la necesidad de que cada marco sea poco utilizado de manera variable en el tiempo ejecutivo causados ​​por las interrupciones, DMA, tipo de instrucciones, el almacenamiento en caché de memoria, y otros efectos que pueden ser manejados. 3. El enfoque de la tasa monotónica permite la estructura de la tarea de la aplicación para reflejar con mayor precisión los requisitos de aplicación, ya que no hay necesidad de romper arbitrariamente las tareas individuales con el fin de cumplir los límites de longitud de la trama. Más bien, podemos dejar que las tareas se ejecutan durante el tiempo que sea necesario, limitado sólo por sus características de utilización propia. Uso de sobreseimiento en cuenta el índice de monótona, no hay peligro de que una larga tarea en ejecución de baja frecuencia hará una tarea de alta frecuencia a perder sus limitaciones de tiempo, siempre y cuando la utilización total consolidado no ha sido superado. 4. Una planificación de tasa monotónica exhibe un alto grado de estabilidad, lo que significa que en el caso de una sobrecarga la tarea se perderán sus limitaciones de tiempo predefinidos. Esta estabilidad se deriva del hecho de que, en una sobrecarga, las tareas de mayor prioridad cuya utilización no ha superado la tasa de utilización monótona obligados, se garantiza que continúen asumiendo sus limitaciones de tiempo. Tareas en o por debajo de la prioridad en que se supere esta utilización puede pasar por alto sus limitaciones de tiempo. Por otra parte, las técnicas disponibles para garantizar que las tareas de importancia crítica, podrían faltar por sobrecarga en corta duración, teniendo sus prioridades ajustadas para garantizar que se satisfagan sus necesidades y para analizar las consecuencias sobre el resto de la aplicación.

32 Desventajas del algoritmo
Arquitectura de Software para aplicaciones de tiempo real estricto Desventajas del algoritmo La desventaja más importante resulta de la propiedad de los sistemas de periódicos descrito previamente para el ejecutivo cíclico: las fluctuaciones (jitter) En general, este modelo no define una restricción de tiempo ajustado en la terminación real de una tarea, asegurando que se complete antes del final de su período. La variabilidad del tiempo de la terminación de una tarea monótonica esta limitado solamente por su período. Como resultado, puede haber una fluctuación (jitter) significativa, generada por el programa sobre todo para una tarea de baja prioridad.

33 Arquitectura de Software para aplicaciones de tiempo real estricto
Conclusiones Para todas las otras aplicaciones de tiempo real se recomienda el uso del enfoque de prioridad fija utilizando algoritmos con tasa monotónica de prioridad ampliada. Las ventajas generales incluyen el ser capaz de predecir la capacidad de satisfacer las necesidades de respuesta de las aplicaciones, la eficiencia del sistema global resultante de la utilización de la periodicidad natural, no-armónico, la capacidad de generar un sistema que representa un aumento de la separación de la periodicidad y funcionalidad, y una estructura sólida cuando la modificación es necesaria durante el mantenimiento del sistema. Es más apropiado usar el ejecutivo cíclico para sistemas con tareas periódicas y de tiempo de cómputos conocidos ya que este realizo una planificación muy sencilla que no requiere el uso de interrupciones. 31.-Indique, según el autor, cuál de los dos algoritmos domina en aplicaciones de tiempo real estrictos y sus ventajas que lo hacen superior Para todas las otras aplicaciones de tiempo real se recomienda el uso del enfoque de prioridad fija utilizando algoritmos con tasa monotónica de prioridad ampliada. Las ventajas generales incluyen el ser capaz de predecir la capacidad de satisfacer las necesidades de respuesta de las aplicaciones, la eficiencia del sistema global resultante de la utilización de la periodicidad natural, no-armónico, la capacidad de generar un sistema que representa un aumento de la separación de la periodicidad y funcionalidad, y una estructura sólida cuando la modificación es necesaria durante el mantenimiento del sistema. 32.-Indique según el autor para qué tipo de aplicaciones es más apropiado usar el ejecutivo cíclico Es más apropiado usar el ejecutivo cíclico para sistemas con tareas periódicas y de tiempo de cómputos conocidos ya que este realizo una planificación muy sencilla que no requiere el uso de interrupciones.

34 Gracias Fin de la presentación
Arquitectura de Software para aplicaciones de tiempo real estricto Fin de la presentación Gracias 31.-Indique, según el autor, cuál de los dos algoritmos domina en aplicaciones de tiempo real estrictos y sus ventajas que lo hacen superior Para todas las otras aplicaciones de tiempo real se recomienda el uso del enfoque de prioridad fija utilizando algoritmos con tasa monotónica de prioridad ampliada. Las ventajas generales incluyen el ser capaz de predecir la capacidad de satisfacer las necesidades de respuesta de las aplicaciones, la eficiencia del sistema global resultante de la utilización de la periodicidad natural, no-armónico, la capacidad de generar un sistema que representa un aumento de la separación de la periodicidad y funcionalidad, y una estructura sólida cuando la modificación es necesaria durante el mantenimiento del sistema. 32.-Indique según el autor para qué tipo de aplicaciones es más apropiado usar el ejecutivo cíclico Es más apropiado usar el ejecutivo cíclico para sistemas con tareas periódicas y de tiempo de cómputos conocidos ya que este realizo una planificación muy sencilla que no requiere el uso de interrupciones.