“ SISTEMAS DISTRIBUIDOS DE TIEMPO REAL ”

1. Sistemas Distribuidos “SISTEMAS DISTRIBUIDOS DE TIEMPO REAL”

2. ¿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. SISTEMAS DE TIEMPO REAL

3. ¿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. SISTEMAS DE TIEMPO REAL

4. SISTEMAS DE TIEMPO REAL ¿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.

5. SISTEMAS DE TIEMPO REAL ¿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”

6. SISTEMAS DE TIEMPO REAL ¿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…

7. SISTEMAS DE TIEMPO REAL ¿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.

8. SISTEMAS DE TIEMPO REAL • 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 .

9. SISTEMAS DE TIEMPO REAL • 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.

10. SISTEMAS DE TIEMPO REAL • 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.

11. SISTEMAS DE TIEMPO REAL • 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 .

12. SISTEMAS DE TIEMPO REAL • 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).

13. SISTEMAS DE TIEMPO REAL • Los STR pueden estructurarse con frecuencia como sigue: Dispositivos Externos Disp. Disp. Disp. Disp. Disp. Disp. Actor Sensor Computadoras Red Un sistema de cómputo distribuido de tiempo real

14. SISTEMAS DE TIEMPO REAL • Los sistemas cuentan con equipos computarizados que tienen dos aspectos en común: • 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.

15. SISTEMAS DE TIEMPO REAL • 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.

16. SISTEMAS DE TIEMPO REAL 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.

17. SISTEMAS DE TIEMPO REAL • 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).

18. SISTEMAS DE TIEMPO REAL 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.

19. SISTEMAS DE TIEMPO REAL • 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.

20. SISTEMAS DE TIEMPO REAL Aspectos de diseño. Sistemas activados por eventos vs. Sistemas activados por el tiempo. • En un STR activado por eventos, cuando ocurre un evento significativo en el mundo exterior, es detectado por algún sensor, lo que entonces provoca que el CPU conectado tenga una interrupción. • Los sistemas activados por eventos están controlados por las interrupciones. • La mayor parte de los STR funcionan de esta manera.

21. SISTEMAS DE TIEMPO REAL Aspectos de diseño. • El principal problema con los sistemas activados por eventos es que pueden fallar bajo condiciones de carga pesada. • Es decir, cuando muchos eventos ocurren a la vez. • Por ejemplo, consideremos lo que ocurre cuando un tubo se rompe en un reactor nuclear controlado por una computadora.

22. SISTEMAS DE TIEMPO REAL Aspectos de diseño. • Las alarmas de temperatura, de presión, de radioactividad y demás alarmas se activarán al mismo tiempo, lo que provoca una interrupción masiva. • Esta lluvia de eventos puede sobrecargar el sistema de cómputo y hacer que falle. • Lo que potencialmente causaría problemas mucho más serios que la ruptura de un solo tubo.

23. SISTEMAS DE TIEMPO REAL Aspectos de diseño. • Un diseño alternativo, es el STR activado por el tiempo. • En este tipo de sistema, ocurre una interrupción de reloj cada T milisegundos. • En cada marca de reloj (ciertos) sensores se muestrean y (ciertos) actores se controlan. • No hay más interrupciones que las marcas de reloj.

24. SISTEMAS DE TIEMPO REAL Aspectos de diseño. • En el ejemplo anterior del tubo roto, el sistema sería consciente del problema en la primera marca del reloj posterior al evento. • Pero la carga de interrupciones no modificaría ni contaría para el problema, de modo que el sistema no se sobrecargaría. • Operar normalmente en tiempos de crisis aumenta la posibilidad de tratar con éxito dicha crisis.

25. SISTEMAS DE TIEMPO REAL Aspectos de diseño. • No hay que decir que T debe elegirse con mucho cuidado. • Si es muy pequeño, el sistema tendrá muchas interrupciones de reloj y desperdiciará mucho tiempo durante las revisiones. • Si es muy grande, los eventos serios no serían notados hasta que fuese muy tarde. • Decidir qué sensores deben verificarse en cada marca de reloj, y cuáles verificar en otra marca de reloj, etc., son críticas.

26. SISTEMAS DE TIEMPO REAL Aspectos de diseño. • Por último, algunos eventos podrían ser más cortos que una marca de reloj, por lo que deberán guardarse para no ser omitidos. • Se pueden preservar eléctricamente mediante ciertos circuitos o mediante microprocesadores integrados a los dispositivos externos.

27. SISTEMAS DE TIEMPO REAL Aspectos de diseño. • Como ejemplo de la diferencia entre estos dos métodos, consideremos el diseño de un controlador de elevador en un edificio de 100 pisos. • Supongamos que el elevador está en el piso 60, esperando clientes. • Entonces alguien oprime el botón de llamada en el primer piso. • Justo 100 milisegundos después, alguien más oprime el botón de llamada en el piso 100.

28. SISTEMAS DE TIEMPO REAL Aspectos de diseño. • En un sistema activado por eventos, la primera llamada genera una interrupción, lo que provoca el descenso del elevador. • La segunda llamada llega después de tomar la decisión de bajar, por lo que se anota como referencia futura, pero el elevador continúa descendiendo.

29. SISTEMAS DE TIEMPO REAL Aspectos de diseño. • Consideremos ahora un controlador de elevador, activado por el tiempo. • Que muestrea cada 500 milisegundos. • Si ambas llamadas caen dentro de un período de muestreo, el controlador deberá tomar una decisión. • Por ejemplo, utilizar la regla de atender primero al cliente más cercano, en cuyo caso irá hacia arriba.

30. SISTEMAS DE TIEMPO REAL Aspectos de diseño. • En resumen: • Los diseños activados por eventos dan respuesta rápida con carga baja, pero tienen mayor costo y probabilidad de fallar con carga alta. • Los diseños activados por el tiempo tienen las propiedades opuestas y sólo son adecuados en un ambiente relativamente estático en donde se conozca mucho y de antemano acerca del comportamiento del sistema. • Cuál de ellos será el mejor, dependerá de la aplicación.

31. SISTEMAS DE TIEMPO REAL Aspectos de diseño. Predictibilidad • Una de las propiedades más importantes de cualquier STR es que su comportamiento sea predecible. • De manera ideal, debe ser claro en el momento del diseño que el sistema cumple con todos sus tiempos límite, incluso con carga pico.

32. SISTEMAS DE TIEMPO REAL Aspectos de diseño. Tolerancia de fallas • En un sistema donde la seguridad es crítica, es de particular importancia que el sistema pueda controlar el peor de los escenarios. • No basta decir que la probabilidad de que tres componentes fallen al mismo tiempo es tan baja que puede ignorarse. • Las fallas no siempre son independientes. • En consecuencia, los STR tolerantes de fallas deben poder enfrentar el número máximo de fallas y la carga máxima al mismo tiempo.

33. SISTEMAS DE TIEMPO REAL Aspectos de diseño. Comunicación en tiempo real • La comunicación en los SD de tiempo real es diferente a la comunicación en los demás. • Lograr la predictibilidad en un SD significa que la comunicación entre los procesadores también debe ser predecible. • Los protocolos LAN que son inherentemente estocásticos, como Ethernet, son inaceptables. • Una máquina que desea enviar un paquete en Ethernet puede chocar con una o más máquinas, y en otro intento puede volver a chocar.

34. SISTEMAS DE TIEMPO REAL Aspectos de diseño. Comunicación en tiempo real • Consideremos una LAN con un anillo de fichas. • Siempre que un procesador tenga un paquete por enviar, espera que le pasen la ficha en circulación. • Captura la ficha, envía su paquete y coloca de nuevo la ficha en el anillo, de modo que la siguiente máquina en el flujo tenga la oportunidad de recuperarla. • Los anillos de fichas también pueden controlar el tráfico consistente en varias clases de prioridades.

35. SISTEMAS DE TIEMPO REAL Aspectos de diseño. Comunicación en tiempo real • El objetivo en este caso es garantizar que si un paquete de alta prioridad espera ser transmitido, será enviado antes que todos los paquetes de menor prioridad de sus vecinos. • Todos estos puntos son observaciones o recomendaciones sobre el diseño de un STR, que abarca incluso el diseño de SDTR.

36. SISTEMAS DE TIEMPO REAL STR en México • Comisión Federal de Electricidad (CFE). • Utiliza un sistema de monitoreo y control ubicado en el Centro Nacional de Control de la Energía (CENACE), donde se supervisa y controla en Tiempo Real gran parte del sistema de transmisión eléctrica nacional. • Compañía de Luz y Fuerza del Centro (CLyFC). • Cuenta con un sistema de supervisión en Tiempo Real a través del Centro de Operación y Control (COC). Monitorea las fallas remotas en las subestaciones de potencia.

37. SISTEMAS DE TIEMPO REAL STR en México • Sistema de Transporte Colectivo “Metro” (STC). • Para lograr un tránsito fluido, eficiente y sin demoras, es necesario un sistema de señalización de tráfico. • Que está instalado en el Puesto de Control Central (PCC), donde se realiza el monitoreo en Tiempo Real de los trenes en cada una de las líneas.

38. SISTEMAS DE TIEMPO REAL Interfaz creada en simulink, que permite especificar el sistema distribuido

39. SISTEMAS DE TIEMPO REAL INVESTIGACIONES • En los últimos 10 años se ha dado una evolución importante tanto en el software como en el hardware de Autómatas Programables Industriales (APIs), tarjetas basadas en PC e instrumentación inteligente (smart sensors, smart actuators). • Este avance, unido al estado del arte en algoritmos de control avanzados, ofrece grandes posibilidades para diseñar sistemas distribuidos flexibles, fiables y de altas prestaciones. • El diseño y desarrollo de sistemas distribuidos conlleva la integración de fases de análisis y simulación desde diferentes puntos de vista: • Desde el diseño de los propios algoritmos de control. • Hasta el diseño de la arquitectura software del sistema o estudios de cumplimiento funcional y de requisitos temporales.

40. SISTEMAS DE TIEMPO REAL • 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.).

41. SISTEMAS DE TIEMPO REAL • 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.

42. SISTEMAS DE TIEMPO REAL • 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.

43. SISTEMAS DE TIEMPO REAL • 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.

44. SISTEMAS DE TIEMPO REAL • 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.

45. Sistemas Distribuidos “SISTEMAS DISTRIBUIDOS DE TIEMPO REAL” “FIN”