Esta integración debería implicar en alguna medida que el equipo de trabajo colabore conjuntamente en el diseño de todos los aspectos del sistema.
Ya que muy probablemente decisiones en un determinado ámbito, por ejemplo, la decisión del número de nodos de la arquitectura, influya de manera determinante en la realización de los algoritmos de control, o en las prestaciones de tolerancia a fallos.
El diseño de sistemas distribuidos con requisitos de tiempo real en muchas ocasiones posee requerimientos críticos en términos de comportamiento temporal, prestaciones y seguridad.
Este tipo de aplicaciones puede encontrarse en campos tan diversos como línea blanca, automatización de procesos de fabricación, la industria aeroespacial o en sistemas de transporte (control de automóviles, ferrocarriles, etc.).
Incluso en el campo de control de procesos industriales existen aplicaciones en que un conjunto de subsistemas deben cooperar y un subconjunto de ellos deben cumplir ciertos requisitos temporales o de seguridad.
Para abordar el diseño de este tipo de sistemas resulta fundamental el disponer de herramientas que abarquen todas las fases del diseño (desde la especificación, análisis, diseño hasta la generación de código de la aplicación).
De hecho, existen fabricantes de software que están adoptando la opción de integración de herramientas con el objetivo de cubrir las etapas del diseño.
El mercado actual ofrece herramientas potentes y bien conocidas en el ámbito del control que intercambian información con otras que cubren aspectos de diseño.
Por ejemplo, Xmath y Statemate se pueden conectar a nivel de código y un interfaz permite la simulación conjunta en entorno Statemate.
El entorno Matlab / Simulink / StateFlow ofrece interfaces gráficos que permiten la simulación conjunta de modelos simulink y stateflow.
Algunas de estas herramientas ofrecen generación automática de código pero no soportan otros tipos de análisis o simulación, como por ejemplo, del comportamiento temporal o tolerancia a fallos.
Por otro lado, el desarrollo e integración de sistemas distribuidos se está llevando a cabo mediante herramientas propietarias que permiten la programación de elementos individuales.
Sin embargo, son específicas de fabricante, por lo que el código que generan no puede ser reutilizado en equipamiento de otro fabricante.
Esto hace que los desarrolladores se deban supeditar a ciertos fabricantes con lo que los desarrollos no constituyen sistemas realmente abiertos.
Lo deseable para el desarrollador sería disponer de herramientas de soporte para Sistemas Abiertos, herramientas basadas en estándares abiertos (de forma que puedan ‘entenderse’ entre sí) y que permitieran implementaciones también basadas en estándares abiertos (lenguajes de programación, protocolos de comunicación).
Actualmente, aún son muchas las herramientas propietarias cerradas y tienen predominio absoluto en algunos campos.
Por lo que deben ser tomadas en cuenta en una solución global para no despegarse de la realidad del mercado.
¿Qué es un STR?
Para la mayoría de los programas, el hecho de que sean correctos depende sólo de la secuencia lógica de las instrucciones ejecutadas.
No del momento en que se ejecutan.
¿Qué es un STR?
Si un programa en lenguaje C calcula de manera correcta la función raíz cuadrada en punto flotante con doble precisión en una estación de trabajo de 200 Mhz.
También calculará la función de la misma manera correcta en una computadora personal de 4.77 Mhz basada en un procesador 8088, aunque más lento.
¿Qué es un STR?
Por el contrario, los programas (y sistemas) de tiempo real interactúan con el mundo exterior de una manera que implica al tiempo.
Cuando aparece un estímulo, el sistema responde a éste de cierta manera y antes de cierto momento límite.
Si se entrega la respuesta, pero después del límite, se considera que el sistema está fallando.
¿Qué es un STR?
Definición de Alan Burns y Andy Wellings:
“Un sistema en Tiempo Real es cualquier sistema donde el tiempo en que se produce su salida es significante.
Esto es debido a que generalmente la entrada corresponde a algún instante del mundo físico y la salida tiene relación con ese mismo instante.
El retrazo transcurrido entre la entrada y la salida debe ser lo suficientemente pequeño para considerarse una respuesta puntual”
¿Qué es un STR?
El momento en que se produce la respuesta es tan importante como aquello que produce.
Muchas aplicaciones relacionadas con el mundo exterior, también son de TR de manera inherente.
Algunos ejemplos son: las computadoras incluidas con los TV’s, las grabadoras de video, los automóviles, las computadoras que controlan los alerones y demás partes de los aviones…
¿Qué es un STR?
… las computadoras militares que controlan los misiles antitanques, los sistemas computarizados que controlan el tráfico aéreo, sistemas de frenos, inyección de gas.
Los experimentos científicos, desde los aceleradores de partículas hasta sensores o rastreadores colocados en ciertos animales, las fábricas automatizadas, los conmutadores telefónicos, los robots, las unidades médicas de cuidado intensivo, los digitalizadores para tomografías, etc.
Cuando un dispositivo (por ejemplo, una computadora) interactúa con un proceso real (mundo físico) es necesario que las acciones de control se efectúen dentro de unos intervalos de tiempo bien definidos.
Con objeto de que el estado del sistema controlado, que tiene su dinámica propia, no evolucione hacia valores incorrectos o indeseables.
El tiempo en que se ejecutan las acciones del sistema es relevante .
De manera típica, un dispositivo externo (tal vez un reloj) genera un estímulo para la computadora, la que entonces debe realizar ciertas acciones antes de un momento límite.
Al terminar el trabajo solicitado, el sistema queda inactivo hasta que llega el siguiente estímulo.
Con frecuencia, los estímulos son periódicos, de modo que un estímulo ocurre de manera regular cada ?T segundos, como una computadora en un televisor o videocasetera, que recibe un cuadro nuevo cada 1/60 segundos.
Otras veces, los estímulos son aperiódicos, lo que significa que son recurrentes, pero no regulares.
Como en la llegada de un avión al espacio aéreo de un controlador de tráfico aéreo.
Por último, algunos estímulos son esporádicos (inesperados), como el sobrecalentamiento de un dispositivo.
Aún en un sistema que en gran medida es periódico, una complicación es que pueden existir muchos tipos de eventos.
Como entrada de video, entrada de audio y el control de la unidad motora, cada uno con su período y acciones necesarias .
Algunos diseñadores están experimentando con la idea de colocar un microprocesador exclusivo al frente de cada dispositivo .
Colocando este dispositivo, aceptara salida de ésta cuando tenga algo que decir, y dar una entrada con la velocidad que requiera.
Por supuesto, esto no hace que la característica de TR se esfume, sino que da lugar a un SDTR, con sus propias características y retos (por ejemplo, comunicación en TR).
Los STR pueden estructurarse con frecuencia como sigue:
Disp. Disp. Disp. Disp. Disp. Disp. Red Actor Sensor Dispositivos Externos Computadoras Un sistema de cómputo distribuido de tiempo real
Tienen contacto con el mundo físico a través de sensores, mediante los cuales se recogen datos del mundo físico y actuadores con los que se envía la información procesada para la manipulación de éste.
El mundo físico dicta restricciones de tiempo que deben ser cumplidas. Los sistemas cuentan con equipos computarizados que tienen dos aspectos en común:
Los dispositivos externos son los que producen o aceptan datos o esperan ser controlados en tiempo real.
Las computadoras pueden ser pequeños microcontroladores integrados a los dispositivos, o máquinas independientes.
En ambos casos, por lo general tienen sensores para recibir señales de los dispositivos y/o actores a los cuales enviar señales.
Los sensores y actores pueden ser digitales o analógicos.
Los STR se clasifican por lo general en dos tipos dependiendo de lo serio de sus tiempos límite y de las consecuencias de omitir uno de ellos. Estos son: STR Suave STR Duro
El Tiempo Real Suave significa que no existe problema si se rebasa un tiempo límite.
Por ejemplo, un conmutador telefónico bajo condiciones de sobrecarga podría perder o equivocar de ruta 105 llamadas y seguir cumpliendo sus especificaciones.
Por el contrario, un tiempo límite no cumplido en un Sistema de Tiempo Real Duro es inaceptable.
Pues podría conducir a la pérdida de una vida o a una catástrofe ambiental.
En la práctica, existen también sistemas intermedios en los que la omisión de un tiempo límite significa que falla toda la actividad actual, pero que la consecuencia no es fatal (por ejemplo, una línea de ensamblaje).
Los STR han estado por ahí durante décadas, por lo que existe experiencia. Aunque mucha de ésta es incorrecta. Stankovic (1988) ha señalado algunas de éstas:
Mito 1: Los STR tratan de la escritura de controladores de dispositivos en código ensamblador.
Mito 2: El cómputo de TR es rápido.
Un puente elevadizo controlado por computadora. Lo que cuenta es la exactitud.
Mito 3: Las computadoras rápidas harán que el sistema de TR sea obsoleto.
No. Sólo animan a las personas a construir STR que anteriormente estaban más allá de lo normal.
Por ejemplo, el escaneo y visualización del ritmo respiratorio y cardiaco.
Los sistemas de realidad virtual, que necesitan recrear ambientes virtuales lo más rápido posible.
| Página siguiente |