SISTEMAS EN TIEMPO REAL Y DISTRIBUIDOS CAPITULO 1 INF-317

1. INTRODUCCIÓN Este tipo de sistemas se caracterizan por su correcto funcionamiento, depende no sólo de las entradas y salidas del mismo, sino porque además se debe dar respuesta a los diferentes eventos en el momento adecuado, pudiendo ser fatal cualquier retraso

1.1.SISTEMAS DISTRIBUIDOS DE TIEMPO REAL La capacidad de procesamiento está distribuida entre varios computadores interconectados. Las actividades del sistema tienen requisitos de tiempo. Necesidad de sistemas distribuidos: Requisitos de procesamiento. Distribución física del sistema. Fiabilidad: Tolerancia a fallos. Los sistemas distribuidos de tiempo real (SDTR) son complicados de realizar. Se consideran sistemas débilmente acoplados. Comunicación mediante mensajes Se consideran, fundamentalmente, sistemas críticos

1.1.1.DEFINICIÓN DE SISTEMAS DISTRIBUIDOS Un sistema distribuido se define como: una colección de computadoras separadas físicamente y conectadas entre sí por una red de comunicaciones distribuida; cada máquina posee sus componentes de hardware y software que el usuario percibe como un solo sistema. El tamaño de un sistema distribuido puede ser muy variado, ya sean decenas de hosts (red de área local), centenas de hosts (red de área metropolitana), y miles o millones de hosts (Internet); esto se denomina escalabilidad

1.1.2.PROGRAMACIÓN EN SISTEMAS DISTRIBUIDOS Tenemos: librerías de bajo nivel procedimientos remotos objetos distribuidos.

1.1.3.PLANIFICACIÓN EN SISTEMAS DISTRIBUIDOS Una asignación aparentemente lógica de procesos puede afectar negativamente a la planificabilidad. ASIGNACIÓN DE PROCESOS. Los procesos relacionados deberían desplegarse juntos. PROCESOS PERIÓDICOS podría parecer útil la misma aproximación con un comportamiento estático PROCESOS ESPORÁDICOS puede eliminarse añadiendo procesos que gestionen la distribución de los datos BLOQUEO REMOTO

1.1.4 EL MEDIO DE COMUNICACION Si todos los procesos de la aplicación son periodicos, es posible producir un protocolo de comunicación por franjas de tiempo. Cada nodo dispone de un reloj sincronizando con el resto de los relojes de los nodos; La dificultad esta en construir la planificación. TDMA basada en franjas te tiempo es el empleo de un paso de testigo.. ESQUEMAS DE PASO DE TESTIGO TEMPORIZADO

PROTOCOLOS BASADOS EN PRIORIDAD Indica la prioridad del mensaje que desea transmitir CAN, restringe la velocidad de comunicación. PROTOCOLOS BASADOS EN PRIORIDAD El objetivo es dar soporte a un amplio rango de requisitos de comunicación; Permite la comunicación punto a punto mediante uno o mas conmutadores. ATM

EL PARADIGMA DE PROGRAMACIÓN BASADO EN COMPONENTES A pesar del éxito de la P.O.O surgieron nuevos problemas. En lenguajes como C++, se utiliza la herencia de implementación, En el campo de tiempo real, se han usado fundamentalmente lenguajes como Ada, C,

La plataforma .NET Recientemente Microsoft ha dirigido todos sus esfuerzos hacia la tecnología .NET Se pueden tener dos visiones de .NET -Librería para el desarrollo de aplicaciones - Entorno de ejecución en q los programas se van a ejecutar, proporcionando un nivel de abstracción sobre el S.O.

El modelo de componentes de java Los componentes de .NET Los componentes van a estar cont. en ensamblados. .NET no esta diseñado para tiempo real El modelo de componentes de java JavaBeans presenta un modelo de componentes Independiente de la plataforma, Las principales características de la interfaz de JavaBeans son: -Propiedades -Eventos -Introspección

BEANS Y TIEMPO REAL No es adecuado para el desarrollo de aplicaciones de tiempo real. Modificando el propio lenguaje, podría desarrollarse un modelo que incorporara características de tiempo real: Introspección para obtener información de los componentes. Usando una terminología adecuada, se podrían indicar distintas calidades de servicio (QoS) que el entorno podría detectar y utilizar. El modelo de eventos sería adecuado, si permitiera la incorporación de tiempo o prioridades. Las características de multicast serán útiles para la implementación de canales de tiempo real con múltiples consumidores. Los contenedores, que controlan aspectos como la concurrencia, pueden extenderse para controlar planificación o la gestión de eventos. Este modelo de contenedores/niveles permite realizar un estudio más sencillo de planificabilidad adecuado para sistemas dinámicos.

El modelo de componentes CCM (Corba Component Model) Intenta solventar las dificultades que dan al combinar las numerosas políticas POA. Utilizando un subconjunto de combinaciones para un mejor desarrollo de aplicaciones en la parte del servidor. Los conceptos que forman el modelo de programación para servidores son: Los componentes, Marco de Trabajo de Implementación de Componentes. El Modelo de Programación de Componente Contenedor. Integración con persistencia, transacciones y eventos. •Empaquetamiento de componentes y su despliegue. •Interconexión con EJB 1.1. •Modelo de Metadatos de Componentes (repositorio de interfaces).

 Los componentes de CCM Es un nuevo meta-tipo en CORBA y se declararán con la palabra component. Los diversos stubs y skeletons que soportan son los ports: Facetas (Facets): interfaces que un componente ofrece. Receptáculos (Receptacles): stubs clientes que invocan a otros componentes. Fuentes de eventos (Event sources):puntos de conexión que emiten eventos. Sumideros de eventos (Event sinks): conexiones en las que los eventos de un tipo específico deben ser puestos por un suministrador o un canal. Otras características del modelo incluyen: • Claves primarias, Atributos y configuración e Interfaces Home.

El marco de trabajo para implementación de componentes Proporciona interfaces para soportar la estructura y funcionalidad de los componentes. Define un lenguaje declarativo, CIDL (Component Implementation Definition Language) que permite describir implementaciones y estados persistentes de los componentes. El CORBA CIF (Component Implementation Framework) está diseñado para desarrollar tareas como la gestión del ciclo de vida y estados de los componentes. CIF usa las descripciones CIDL para generar código que automatiza comportamientos de los componentes.

El modelo de programación basado en contenedores Un contenedor es el entorno de ejecución que es ofrecido por CCM a los componentes. Encapsulan la implementación y usan un conjunto de APIs para acceder al entorno de ejecución, facilitando el desarrollo y/o configuración de aplicaciones CORBA. Activación/Desactivación de implementaciones para preservar recursos limitados del sistema. Proporcionar un nivel de adaptación para cuatro servicios: Transacciones, Persistencia, Seguridad y Notificación. •Nivel de adaptación para callbacks que el contenedor y el ORB utilizan para informar al componente sobre eventos. •Gestión de las políticas POA, determinan la creación de referencias a los componentes

CCM y tiempo real No tiene la posibilidad de indicar restricciones temporales ni permite acotar el tiempo de ejecución de una invocación remota. Múltiples interfaces funcionales y especiales para tiempo real, mediante las facetas. Posibilidad de implementar un mecanismo de reconfiguración dinámica. Modelo basado en eventos con fuentes y sumideros, podrían incorporar restricciones temporales y/o prioridades en la transmisión y recepción de los eventos. La activación/desactivación puede usarse para tener implementaciones degradadas de los componentes. Suministran niveles de adaptación para cuatro servicios usados. Debería incorporarse un 5° nivel de adaptación que facilite el desarrollo de aplicaciones con CCM y tiempo real.

TENDENCIAS ACTUALES SOBRE COMPONENTES Y TIEMPO REAL Existen algunos trabajos intentando relacionar los componentes con el tiempo real. Hooman y Van Roosmalen, 2000: propone un modelo para el desarrollo de aplicaciones de tiempo real independiente de la plataforma y basándose en el concepto de compontes. Hooman: propone un modelo de programación en tiempo real, con un método de verificación formal de programas con anotaciones de tiempo. Henzinger: se describe un modelo formal, de forma estructurada para el desarrollo de hardware y software interactuando a través de componentes en tiempo real. En el ámbito de lo sistemas distribuidos, aparecen los primeros resultados para los componentes de tiempo real: herramientas, entornos de ejecución, métodos para expresar restricciones.

Los trabajos estudiados se dividen en tres grupos: Plataformas de ejecución con componentes u objetos Estudios sobre planeación e indicación de restricciones Estudios sobre estándares como ser Java o CORBA Villela et al : presenta un marco de trabajo con un conjunto de herramientas para el desarrollo de componentes distribuidos en tiempo real. Herramientas: Plantillas de componentes Diagramas de despliegue para la configuración de la aplicación en los distintos nodos que forman el sistema Generadores de código Un repositorio de componentes.

Hsiung et al: fue presentado VERTAF, es un marco de trabajo para aplicaciones orientadas a objetos en sistemas empotrados de tiempo real. Dispone de 5 herramientas: Implementador Modelador Planificador Verificador Generador Yen et al: propone un mecanismo integrado basado en componentes para el desarrollo de software empotrado. Para diseñar sistemas distribuidos de tiempo real predecibles se requiere: especificación de los componentes en el dominio del tiempo. interfaces funcionales. Para el desarrollo de los sistemas distribuidos se usa estándares de componentes como ser Java y CORBA.

CORBA(Common Object Request Broker Architecture) y RT-CORBA (Real-time CORBA) CORBA es ofrecer una capa homogénea para el desarrollo de aplicaciones que se ejecutan en sistemas distribuidos heterogéneos. RT-CORBA • Recursos del procesador • Recursos de comunicación • Recursos de memoria Fundamentos de CORBA

Arquitectura OMA (Object Management Architecture) Invocación de operaciones

Tipos de invocaciones Invocación estática Invocación dinámica Una segunda clasificación de las invocaciones atendiendo a la sincronización: Peticiones síncronas Peticiones asíncronas diferidas Peticiones oneway Lenguaje de Definición de Interfaces: IDL Lenguaje Declarativo Definir las interfaces de los objetos de forma independiente a un lenguaje de programación. IDL establece el contrato entre el cliente y el servidor, describiendo los tipos e interfaces de objeto utilizados en una aplicación.

ADAPTADORES DE OBJETOS ENLAZA SIRVIENTES ORB INTERFAZ DE UN OBJETO A UNA INTERFAZ DIFERENTE ADAPTA CLIENTE FUNCIONES CREAR LAS REFERENCIAS A LOS OBJETOS ASEGURAR QUE CADA OBJETO DESTINO ESTÁ REPRESENTADO POR UN SIRVIENTE Y RECIBIR LAS INVOCACIONES CURSADAS POR EL ORB EN EL LADO DEL SERVIDOR DIRIGIRLAS A LOS SIRVIENTES QUE ENCARNAN A LOS OBJETOS DESTINO

Servicio de Notificación Servicio de Trading Servicio de Transacciones SERVICIOS EN ORB Servicio de Nombres Servicio de Eventos Servicio de Notificación Servicio de Trading Servicio de Transacciones Servicio de Ciclo De Vida Servicio de Concurrencia

DESARROLLO DE UNA APLICACIÓN CORBA

GESTION DE PRIORIDADES

FUNDAMENTOS DE SDL

COMUNICACIÓN ENTRE PROCESOS

Extensión de tiempo real para SDL Extensiones que permitirán solucionar las limitaciones con restricciones temporales:

La prioridad de cada proceso dependerá de las señales en su cola de entrada y la transición que se pueda ejecutar en el estado actual. Prioridades y transiciones delos procesos. Se podrán acceder con dos funciones predefinidas: tiempo_enviado y tiempo_atendido, mediante los cuales se podrán expresar las restricciones de tiempo. Marcas de tiempo para las señales. Las transiciones se ejecutaran en función de su prioridad esto quiere decir que pueden ser interrumpidas por otras de mas alta prioridad que estén preparadas para ejecutar. Modelo de ejecución analizable.

Todos aquellos datos y recursos que son compartidos por varios procesos son encapsulados en una clase especial de proceso. Los procesos que acceden a estos recursos compartidos invocaran a estos procedimientos esta implementación es similar a la que define ADA95. Compartición de Recursos. Aparece cuando no solo es suficiente con que la respuesta a un evento deba cumplir un plazo establecido si no que la acción de entrada o salida se debe realizar en un momento especifico del tiempo, con una pequeña variación o tolerancia. Variación en activación .