Computación en tiempo real

En Ciencias de la computación, Computación en tiempo real (RTC), o Computación reactiva, es el estudio de hardware y software sistemas que están sujetos a una "restricción en tiempo real," los plazos por ejemplo operacionales del evento a la respuesta del sistema. Programas en tiempo real deben garantizar la respuesta dentro de las limitaciones de tiempo estricto, a menudo se denomina "plazos". Respuestas en tiempo real se entienden a menudo a ser del orden de milisegundos y a veces microsegundos. Por el contrario, un sistema sin instalaciones en tiempo real, puede garantía una respuesta en cualquier período de tiempo (independientemente de real o Espera tiempos de respuesta).

Un sistema en tiempo real es la que "controla un ambiente recibiendo datos, procesándolos y devolver los resultados lo suficientemente rápido para afectar el medio ambiente en aquel momento." El uso de esta palabra no debe confundirse con las dos otras utilizaciones legítimas del "tiempo real". En el dominio de las simulaciones, el término significa que el reloj de la simulación corre tan rápido como un reloj verdadero. En el procesamiento y los dominios de sistemas empresariales, el término se utiliza para decir "sin demora perceptible".

Software en tiempo real puede utilizar uno o más de las siguientes opciones: lenguajes de programación sincrónicos, sistemas operativos en tiempo realy las redes en tiempo real, cada uno de los cuales proporcionan Marcos esenciales para construir una aplicación de software en tiempo real.

Un sistema en tiempo real puede ser uno donde su aplicación puede considerarse (en contexto) misión crítica. El frenos antibloqueo en un coche son un ejemplo simple de un sistema de computación en tiempo real – la restricción en tiempo real en este sistema es el tiempo en el cual los frenos deben ser liberados para impedir el bloqueo de la rueda. Los cálculos en tiempo real se pueden decir que ha No se pudo Si no que concluyan antes de su fecha límite, donde su plazo es relativo a un evento. Un plazo de tiempo real debe ser resuelta, independientemente de carga del sistema.

Historia

El término en tiempo real deriva de su uso en temprano simulación, en que se simula un proceso reales a una tasa que coincidió con que el proceso real (ahora llamado simulación en tiempo real para evitar la ambigüedad). Equipos analógicos, más a menudo, eran capaces de simular a un ritmo mucho más rápido que en tiempo real, una situación que podría ser tan peligrosa como una simulación lenta si no fuera también reconocido y contabilizados.

Una vez cuando el MOS Technology 6502 (utilizado en la Commodore 64 y Apple II) y más tarde cuando el Motorola 68000 (utilizado en la Macintosh, Atari ST, y Commodore Amiga) eran populares, nadie puede usar su ordenador como un sistema en tiempo real. La posibilidad de desactivar otras interrupciones permitidas para bucles codificadas con tiempos definidos y la baja latencia de interrupción permite la implementación de un sistema operativo en tiempo real, dando a la interfaz de usuario y la unidades de disco menor prioridad que el hilo en tiempo real. En comparación a éstos la Programmable Interrupt Controller de la CPU Intel (8086..80586) genera una latencia muy grande y el sistema operativo Windows es ni un sistema operativo en tiempo real ni permite un programa para apoderarse completamente de la CPU y utilizar su propio Programador, sin usar lenguaje máquina nativo y superando así interrumpir todo el código de Windows. Sin embargo, que existen varias bibliotecas de codificación ofrecen capacidades de tiempo real en un lenguaje de alto nivel en una variedad de sistemas operativos, por ejemplo Tiempo Real de Java. El Motorola 68000 y familiares posteriores (68010, 68020 etc.) también se hizo popular con los fabricantes de sistemas de control industrial gracias a esta instalación. Este área de aplicación es uno en el cual el control en tiempo real ofrece genuinas ventajas en términos de seguridad y performance de los procesos.

Criterios para la computación en tiempo real

Dice que es un sistema en tiempo real Si la corrección total de una operación depende no sólo su corrección lógica, sino también sobre el tiempo en el cual se realiza. Sistemas de tiempo real, así como sus plazos, se clasifican por la consecuencia de la falta de una fecha límite:

• Duro– falta un plazo de entrega es un fracaso total del sistema.
• Firma– plazo infrecuente misses son tolerables, pero puede degradar la calidad del sistema de servicio. La utilidad de un resultado es cero después de su fecha límite.
• Suave– la utilidad de un resultado se degrada después de su fecha límite, degradando así calidad del sistema de servicio.

Por lo tanto, el objetivo de una sistema en tiempo real duro es garantizar que se cumplen todos los plazos, pero para sistemas de tiempo real suaves la meta se convierte en cumplir un cierto subconjunto de los plazos a fin de optimizar algunos criterios específicos de la aplicación. Los criterios particulares optimizados dependen de la aplicación, pero algunos ejemplos típicos incluyen maximizar el número de plazos que se reunió, minimizar el retraso de tareas y maximizar el número de tareas de alta prioridad cumplir sus plazos.

Es imperativo que un evento se reaccionó a dentro de un plazo estricto se utilizan sistemas de tiempo real duros. Dichas garantías fuertes se requiere de sistemas que no reacciona en un cierto intervalo de tiempo causaría gran pérdida de alguna manera, especialmente perjudicial físicamente los alrededores o amenazante humanos vive (aunque la definición estricta es simplemente que el plazo que falta constituye fracaso del sistema). Por ejemplo, un coche motor sistema de control es un sistema en tiempo real duro porque una señal retardada puede causar daños o fallas del motor. Otros ejemplos de sistemas embebidos en tiempo real duros sistemas médicos como corazón marcapasos y controladores de proceso industrial. Sistemas de tiempo real duros suelen encontrarse interactúan en un nivel bajo con hardware físico, en sistemas embebidos. Primeros sistemas de videojuegos tales como la Atari 2600 y Cinematronics gráficos vectoriales tenían requisitos de tiempo real duros debido a la naturaleza de los gráficos y sincronización hardware.

En el contexto de multitarea sistemas de la agenda política es normalmente prioridad conducido ()preventivo programadores). Otros algoritmos de programación incluyen Lo más temprano posible plazo primero, que, haciendo caso omiso de la sobrecarga de cambio de contexto, es suficiente para las cargas del sistema de menos del 100%. Nueva superposición de programación de sistemas, tales como una Programador de partición adaptable asistir en la gestión de grandes sistemas con una mezcla de aplicaciones en tiempo real en tiempo real y no duras.

Se emplean sistemas de tiempo real suaves donde existe algun problema de acceso concurrente y la necesidad de mantener un número de sistemas conectados al día con las cambiantes situaciones; por ejemplo el software que mantiene y actualiza los planes de vuelo comercial aviones de pasajeros. Los planes de vuelo deben mantenerse razonablemente actuales pero pueden operar a un estado latente de segundos. También son generalmente suaves en sistemas de audio y video en tiempo real; violación de las restricciones resultados en calidad degradada, pero el sistema puede seguir operar.

Tiempo real de Procesamiento Digital de señales

En un tiempo real DSP proceso, el analizado (entrada) y muestras (salida) generada pueden ser procesadas (o generadas) continuamente en el tiempo que sea necesario para la entrada y salida del mismo conjunto de muestras independiente de la demora del proceso. Esto significa que el retardo de procesamiento debe ser delimitado incluso si el proceso continúa durante un tiempo ilimitado. Eso significa que el es decir tiempo de procesamiento por ejemplo no es mayor que el período de muestreo, que es el recíproco de la frecuencia de muestreo. Este es el criterio si las muestras se agrupan juntos en grandes segmentos y procesado como bloques o se procesan individualmente y si hay son largos, cortos o inexistentes búferes de entrada y salidos.

Considerar un audio DSP ejemplo; Si requiere de un proceso de 2,01 segundos analizar, sintetizar, o procesar 2,00 segundos del sonido, no es en tiempo real. Si cuesta 1,99 segundos, es o puede ser hecho en un proceso DSP en tiempo real.

Una vida en común analógica está parado en una línea o cola esperando el pedido en una tienda de abarrotes. Si la línea asintóticamente crece más y más sin límite, el proceso de pago no es en tiempo real. Si limita la longitud de la línea, los clientes están siendo "procesados" y salida tan rápidamente, en promedio, como están siendo introducidos y ese proceso is en tiempo real. El tendero podría cerrar el negocio o al menos debe perder negocios si no puede hacer su proceso de pago en tiempo real (así es fundamentalmente importante que este proceso será en tiempo real).

Una señal de que no puede mantenerse al día con el flujo de entrada de datos con algoritmo de procesamiento de salida cae más lejos y más lejos detrás de la entrada no es en tiempo real. Pero si el retraso de la salida (en relación con la entrada) está delimitado con respecto a un proceso que funciona por tiempo ilimitado, entonces ese algoritmo de procesamiento de señal en tiempo real, incluso si la demora de rendimiento puede ser muy larga.

En tiempo real y de alto rendimiento

Computación en tiempo real es a veces incomprendida para ser Computación de alto rendimiento, pero esto no es una clasificación exacta. Por ejemplo, una masiva supercomputadora ejecutar una simulación científica puede ofrecer un rendimiento impresionante, sin embargo, no está ejecutando un cómputo en tiempo real. Por el contrario, una vez que el hardware y software para un sistema de frenado antibloqueo han sido diseñados para cumplir sus plazos requeridos, ningunas otras ganancias de rendimiento son obligatorias. Además, si un servidor de red es altamente cargado con el tráfico de red, su tiempo de respuesta puede ser más lento pero (en la mayoría de los casos) todavía logrará antes de que siempre hacia fuera (llega a su límite). Por lo tanto, tal un servidor de red no se consideraría un sistema en tiempo real: fracasos temporales (retrasos, los tiempos de espera, etc.) son generalmente pequeñas y compartimentado (limitado en efecto) pero no es fallas catastróficas. En un sistema en tiempo real, tales como la FTSE 100 Index, una desaceleración más allá de los límites a menudo sería considerada catastrófica en su contexto de aplicación. Por lo tanto, el requisito más importante de un sistema en tiempo real es previsibilidad y no el rendimiento.

Algunos tipos de software, como muchos programas de ajedrez, puede caer en cualquier categoría. Por ejemplo, un programa de ajedrez diseñado para jugar en un torneo con un reloj tendrá que decidir sobre una jugada antes de un determinado plazo o perder el juego y por lo tanto es un cómputo en tiempo real, pero no es un programa de ajedrez que está permitido ejecutar indefinidamente antes de mudarse. En ambos casos, sin embargo, es deseable de alto rendimiento: más trabajo que puede hacer un programa de ajedrez de torneo en el tiempo asignado, mejores serán sus movimientos y cuanto más rápido se ejecuta un programa de ajedrez sin restricciones, más pronto será capaz de moverse. Este ejemplo también ilustra la diferencia esencial entre los cómputos en tiempo real y otros cálculos: Si el programa de ajedrez de torneo no tomar una decisión sobre su próxima jugada en su tiempo asignado pierde la game—i.e., fracasa como un cómputo en tiempo real, mientras que en el otro escenario, cumplir el plazo de entrega se supone no debe para ser necesario. Alto rendimiento es indicativo de la cantidad de procesamiento que se realiza en un determinado periodo de tiempo, mientras que en tiempo real es la posibilidad de hacerse con el proceso para producir una salida útil en el tiempo disponible.

Casi en tiempo real

El término"casi en tiempo real"o"casi en tiempo real"(NRT), en telecomunicaciones y Computación, se refiere al tiempo retardo introducido, por automatizado procesamiento de datos o red transmisión, entre la ocurrencia de un evento y el uso de los datos procesados, tales como para mostrar o retroalimentación y con fines de control. Por ejemplo, una pantalla casi en tiempo real representa un evento o situación que existía en el momento actual menos el tiempo de procesamiento, como casi el tiempo del evento en vivo.

La distinción entre los términos "casi en tiempo real" y "tiempo real" es algo nebulosa y debe definirse para la situación actual. El término implica que hay no hay retrasos significativos. En muchos casos, proceso que calificó de "tiempo real" sería más exactamente descrito como "cerca de tiempo real".

Cerca en tiempo real también se refiere a transmisión retrasada en tiempo real de voz y video. Permite reproducir imágenes de vídeo, en aproximadamente en tiempo real, sin tener que esperar a un archivo video grande completo descargar. Bases de datos incompatibles pueden exportar/importar a archivos planos comunes que la otra base de datos puede importar/exportar de manera programada para que pueden sincronizar/compartir datos comunes en "cerca de tiempo real" con el otro.

La distinción entre "cerca en tiempo real" y "tiempo real" varía, y el retraso es dependiente en el tipo y la velocidad de la transmisión. El retraso en casi en tiempo real puede ser tan alto como 5 a 20 minutos en algunas aplicaciones.

Métodos de diseño

Existen varios métodos para ayudar en el diseño de sistemas en tiempo real, un ejemplo de que es MASCOTA, un método antiguo pero muy exitoso, que representa el concurrente estructura del sistema. Otros ejemplos son CAMPANAUML en tiempo real, AADL, la Perfil de Ravenscar, y Java en tiempo real.

Véase también

• Modos de procesamiento
• Pruebas en tiempo real
• Lenguaje de programación sincrónica
• Proyecto de Ptolomeo
• DSOS
• Peor de los tiempos de ejecución

Lectura adicional

• Alan Burns y Andy Wellings (2009), Lenguajes de programación y sistemas en tiempo real (4ª ed.), Addison-Wesley, ISBN978-0-321-41745-9
• Buttazzo, Giorgio (2011), Sistemas informáticos en tiempo real duro: Algoritmos de programación predecibles y aplicacionesNueva, Nueva York: Springer.
• Liu, Jane W.S. (2000), Sistemas de tiempo realUpper Saddle River, NJ: Prentice Hall.

Enlaces externos

Comités técnicos

• Comité Técnico de IEEE en sistemas de tiempo real
• Comisión Euromicro técnico de sistemas en tiempo real

Conferencias científicas

• RTNS - Conferencia Internacional sobre sistemas y redes en tiempo real
• ECRTS - Euromicro Conferencia sobre sistemas de tiempo real
• Simposio de sistemas en tiempo real de IEEE
• Simposio de aplicaciones y tecnología en tiempo real de IEEE
• Simposio internacional orientada a objetos en tiempo real distribuido Computing
• IEEE International Conference on Aplicaciones y sistemas informáticos integrados y en tiempo real
• Conferencia tiempo & Embedded Computing

Revistas

• Revista Internacional de sistemas informáticos críticos
• Revista Internacional de sistemas de tiempo real

Grupos de investigación

• Laboratorio de integración de sistemas cibernéticos-física, Universidad de Illinois en Urbana-Champaign.
• IDA Instituto de Informática e ingeniería de red, TU Braunschweig, Alemania
• CISTER investigación unidad, ISEP, Instituto Politécnico de Porto (IPP), Portugal
• Grupo de investigación de sistemas en tiempo real, INRIA, LORIA NANCY, Francia
• Laboratorio de computación en tiempo real y embebidos (USMAN SHARIF BCS-SP03-37)
• Mälardalen investigación en tiempo real centro
• Laboratorio de computación en tiempo real
• Laboratorio de sistemas de tiempo real
• Laboratorio RTSE
• Instituto de ingeniería de sistemas - sistemas de tiempo Real grupo
• Laboratorio de sistemas de tiempo real en la Scuola Superiore Sant ' Anna, Pisa, Italia
• Universidad técnica de Kaiserslautern - Instituto de ingeniería eléctrica y tecnologías de la información - grupo de sistemas en tiempo real
• Vienna University of Technology - Instituto de ingeniería en computación - grupo de sistemas en tiempo real
• Grupo de investigación de sistemas en tiempo real en la Universidad de York, Reino Unido
• Grupo de investigación Chalmers University of Technology - confiables sistemas de tiempo real
• ARTES: un ciudadano sueco estratégica investigación iniciativa en sistemas de tiempo real apoyado por la Fundación sueca para la investigación estratégica (SSF), SE
• Sistemas en tiempo real en la University of North Carolina at Chapel Hill
• Laboratorio de sistemas de tiempo real en el Politécnico de Virginia y State University, Blacksburg
• Mc2labs industrias en tiempo real. Las TIC en tiempo real de investigación y desarrollo. Infraestructuras programación de Internet en tiempo real, Mogliano Veneto, Italia
• Simula investigación laboratorio, medios de comunicación Performance Group
• Arquitecturas paralelas para sistemas en tiempo real, Bruselas, Bélgica, Europa.

Documentos técnicos

• El qué, dónde y por qué de la simulación en tiempo real

Otras Páginas

• Aptana (categoria Cloud computing los proveedores)
• Tom Horne (categoria General de abogados de Arizona)
• Rampart (videojuego) (seccion de construccion y reparacion)
• LG enV Touch
• Dan Marohl
• Histopatologia (diario)
• OMS lista de verificacion de seguridad quirurgica
• Seguro mala fe
• Cono de solvencia
• Elecciones de la camara de representantes de Estados Unidos en California, 1986
• Calcio
• Lineback ganado
• Linguloidea