Diferencia entre revisiones de «Sistema de tiempo real»

← Ir a diferencia anterior Ir a siguiente diferencia →

Contenido eliminado Contenido añadido

En renglón

Revisión del 02:17 27 nov 2012

Un sistema en tiempo real es aquel en el que se establecen restricciones temporales para la obtención de resultados o la realización de operaciones. El funcionamiento correcto del sistema requiere, por tanto, no solo que las operaciones se realicen correctamente, si no que se realicen en el momento y con la duración adecuada.^[1] Si se cumple esta condición se dice que el sistema es predecible. Tiempo real no es necesariamente sinónimo de rapidez; un sistema en tiempo real garantiza que el rendimiento temporal del sistema es el suficiente para resolver el problema al que está dedicado.

Los procesos en que el fallo al cumplir una restricción temporal tienen consecuencias severas se denominan de tiempo real duro o sistemas en tiempo real de misión crítica. Si no hay ninguna restricción temporal de estas características y se puede permitir que las restricciones temporales sean vulneradas en ocasiones se dice que estamos ante un sistema en tiempo real suave.^[1]

Un ejemplo que ilustra los puntos anteriores 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 lo 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.

Características de los sistemas de tiempo real

Determinismo

El determinismo es una cualidad clave en los sistemas de tiempo real. Es la capacidad de determinar con una alta probabilidad, cuanto es el tiempo que se toma una tarea en iniciarse. Esto es importante por que 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 por que 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 tardara el sistema en aceptar esta petición de servicio.

Responsividad

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

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 que 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

La confiabilidad en un sistema de tiempo real es otra característica clave. El sistema no debe solamente estar libre de fallas pero más aún, la calidad del servicio que presta no debe degradarse más allá de un límite determinado.

El sistema debe de seguir en funcionamiento a pesar de catástrofes, o fallas mecánicas. Usualmente una degradación en el servicio en un sistema de tiempo real lleva consecuencias catastróficas,

Operación a prueba de fallas duras (Fail soft operation)

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.

Los sistemas de tiempo real y el análisis de sus requerimientos

Debido que los sistemas de tiempo real tienen características especiales diferentes a los demás tipos de sistemas y que los sistemas operativos de tiempo real relegan a sus usuarios el cumplimiento de estos requerimientos (según la característica de usuarios controladores vista en el capítulo anterior) es importante mencionar que este tipo de requerimientos deben de tomarse en cuenta en el proceso de desarrollo.

Sin embargo, como estos requerimientos no forman parte de una sola funcionalidad del sistema sino que forman parte de todo el sistema a menudo se definen como requerimientos no funcionales.

También se argumenta que como no son parte de la aplicación sino que es como se comporta una aplicación al introducirse en un ambiente de tiempo real entonces estos son una Característica del sistema, más que un requerimiento.

Los dos puntos de vista son erróneos, si bien es cierto que los requerimientos referentes al tiempo real se aplican a todo el sistema, a menudo tenemos que agregar o modificar software, interfaces o hardware para que estos requerimientos se cumplan, más aún, el software debe de estar preparado para que en la eventualidad de que un trabajo no cumpla con sus requerimientos de tiempo, cancele los demás trabajos relacionados con el (si una petición de entrada/salida toma más del tiempo establecido y se cancela por el sistema, el software de entrada/salida debe de informar al usuario del proceso que este evento ocurrió). Esto es claramente parte de la funcionalidad y de comportamiento del sistema. Por lo que clasificar esta restricción como requerimiento no funcional es incorrecto.

Si argumentáramos que: al ser parte de todo el sistema son una característica del sistema más que un requerimiento estaríamos diciendo que estas restricciones se cumplen con el solo hecho de pertenecer al sistema. Una característica es algo que ya esta en el sistema y que no puede ser calificada como errónea o correcta, y una restricción deberá de ser cumplida siempre y la forma en que estas restricciones se cumplen puede ser validada como errónea o correcta. Por lo que estas restricciones tampoco son una característica del sistema.

Referencias

Véase también

Data Distribution Service

↑ ^a ^b Kopetz, Hermann (2011). «1.2 Functional requirements». Real-Time Systems: Design Principles for Distributed Embedded Applications (en inglés). Springer Science+Business Media. p. 376. ISBN 978-1-4419-8237-7.

[kopetz-1] Kopetz, Hermann (2011). «1.2 Functional requirements». Real-Time Systems: Design Principles for Distributed Embedded Applications (en inglés). Springer Science+Business Media. p. 376. ISBN 978-1-4419-8237-7.

[1]

@@ Línea 1: / Línea 1: @@
+{{wikificar|t=20090515|tecnología|informática}}
-La '''computación en tiempo real''' (o [[informática]] en tiempo real) está relacionada con los sistemas del [[hardware|soporte físico]] y la [[software|programática]] 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.
+{{fusionar en|Computación en tiempo real}}
+Un '''sistema en tiempo real''' es aquel en el que se establecen restricciones temporales para la obtención de resultados o la realización de operaciones. El funcionamiento correcto del sistema requiere, por tanto, no solo que las operaciones se realicen correctamente, si no que se realicen en el momento y con la duración adecuada.<ref name=kopetz>{{cita libro|apellidos=Kopetz|nombre=Hermann|título=Real-Time Systems: Design Principles for Distributed Embedded Applications|año=2011|editorial=Springer Science+Business Media|capítulo=1.2 Functional requirements|isbn=978-1-4419-8237-7|páginas=376|idioma=Inglés}}</ref>  Si se cumple esta condición se dice que el sistema es predecible. ''Tiempo real'' no es necesariamente sinónimo de rapidez; un sistema en tiempo real garantiza que el rendimiento temporal del sistema es el suficiente para resolver el problema al que está dedicado.
-== Ejemplos ==
+Los procesos en que el fallo al cumplir una restricción temporal tienen ''consecuencias severas'' se denominan de ''tiempo real duro'' o ''sistemas en tiempo real de misión crítica''. Si no hay ninguna restricción temporal de estas características y se puede permitir que las restricciones temporales sean vulneradas ''en ocasiones'' se dice que estamos ante un ''sistema en tiempo real suave''.<ref name=kopetz />
-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 [[Programa informático|programas]] como los empleados para jugar al [[ajedrez]] sólo disponen del tiempo necesario para poder efectuar la siguiente jugada.
+Un ejemplo que ilustra los puntos anteriores 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 lo 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.
-Se podría hacer una distinción, por ejemplo, un sistema de gestión del motor de un [[Automóvil|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.
+== Características de los sistemas de tiempo real ==
-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 [[Aerolínea|compañías aéreas]] comerciales. Estos programas pueden funcionar en cuestión de [[segundo]]s.
+=== Determinismo ===
-No sería posible ofrecer vuelos comerciales modernos si estas operaciones no se pudieran realizar de manera fiable en tiempo real. Los sistemas de [[Señal de audio|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.
+El determinismo es una cualidad clave en los sistemas de tiempo real. Es la capacidad de determinar con una alta probabilidad, cuanto es el tiempo que se toma una tarea en iniciarse. Esto es importante por que 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 por que 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 tardara el sistema en aceptar esta petición de servicio.
-Las necesidades de los programas de tiempo real se pueden solucionar con [[sistema operativo de tiempo real|sistemas operativos en tiempo real]], que ofrecen un marco sobre el que construir aplicaciones de programas en tiempo real.
-== Véase también ==
+==== Responsividad ====
+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
-*[[Sistema de tiempo real]]
+* 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)
-[[Categoría:Computación en tiempo real| ]]
+==== Usuarios controladores ====
+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 que 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 ====
+La confiabilidad en un sistema de tiempo real es otra característica clave. El sistema no debe solamente estar libre de fallas pero más aún, la calidad del servicio que presta no debe degradarse más allá de un límite determinado.
+El sistema debe de seguir en funcionamiento a pesar de catástrofes, o fallas mecánicas. Usualmente una degradación en el servicio en un sistema de tiempo real lleva consecuencias catastróficas,
+==== Operación a prueba de fallas duras (Fail soft operation) ====
+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.
+=== Los sistemas de tiempo real y el análisis de sus requerimientos ===
+Debido que los sistemas de tiempo real tienen características especiales diferentes a los demás tipos de sistemas y que los sistemas operativos de tiempo real relegan a sus usuarios el cumplimiento de estos requerimientos (según la característica de '''usuarios controladores''' vista en el capítulo anterior) es importante mencionar que este tipo de requerimientos deben de tomarse en cuenta en el proceso de desarrollo.
+Sin embargo, como estos requerimientos no forman parte de una sola funcionalidad del sistema sino que forman parte de todo el sistema a menudo se definen como '''requerimientos no funcionales'''.
+También se argumenta que como no son parte de la aplicación sino que es como se comporta una aplicación al introducirse en un ambiente de tiempo real entonces estos son una '''Característica del sistema''', más que un requerimiento.
+Los dos puntos de vista son erróneos, si bien es cierto que los requerimientos referentes al tiempo real se aplican a todo el sistema, a menudo tenemos que agregar o modificar software, interfaces o hardware para que estos requerimientos se cumplan, más aún, el software debe de estar preparado para que en la eventualidad de que un trabajo no cumpla con sus requerimientos de tiempo, cancele los demás trabajos relacionados con el (si una petición de entrada/salida toma más del tiempo establecido y se cancela por el sistema, el software de entrada/salida debe de informar al usuario del proceso que este evento ocurrió). Esto es claramente parte de la funcionalidad y de comportamiento del sistema. Por lo que clasificar esta restricción como requerimiento no funcional es incorrecto.
+Si argumentáramos que: al ser parte de todo el sistema son una característica del sistema más que un requerimiento estaríamos diciendo que estas restricciones se cumplen con el solo hecho de pertenecer al sistema. Una característica es algo que ya esta en el sistema y que no puede ser calificada como errónea o correcta, y una restricción deberá de ser cumplida siempre y la forma en que estas restricciones se cumplen puede ser validada como errónea o correcta. Por lo que estas restricciones tampoco son una característica del sistema.
+== Referencias ==
+* [http://www.faqs.org/faqs/realtime-computing/faq/ Comp.realtime: Frequently Asked Questions (FAQs) (versión 3.6)]
+* [http://www.cse.buffalo.edu/faculty/bina/cse421/spring00/lec10/index.htm Bina Ramamurthy]
+* [http://www.geocities.com/txmetsb/sistemas-de-tiempo-real.htm Sistemas de tiempo real.]
+== Véase también ==
+* [[Data Distribution Service]]
+[[Categoría:Computación en tiempo real]]
-[[af:Intyds]]
-[[ca:Computació en temps real]]
-[[de:Echtzeitsystem]]
-[[en:Real-time computing]]
-[[fa:رایانش بی‌درنگ]]
-[[fr:Système temps réel]]
-[[id:Real-time]]
-[[he:מערכת זמן אמת]]
-[[ko:실시간]]
-[[ms:Pengkomputeran masa-sebenar]]
-[[nl:Real-time]]
-[[it:Real-time]]
-[[ja:リアルタイムシステム]]
-[[no:Sanntidssystem]]
-[[pl:System czasu rzeczywistego]]
-[[pt:Tempo real]]
-[[ru:Системы реального времени]]
-[[simple:Real-time computing]]
-[[sk:Reálny čas]]
-[[sv:Realtidssystem]]
-[[th:ระบบเวลาจริง]]
-[[vi:Hệ thống thời gian thực]]
-[[zh:实时计算]]