Introducción a DDS - ISTR - Ingeniería Software y Tiempo Real

Transcripción

Introducción a DDS - ISTR - Ingeniería Software y Tiempo Real
PROGRAMACIÓN DISTRIBUIDA
Introducción a DDS
(Data Distribution Service for
Real-Time Systems)
Héctor Pérez
2
RCSD: José M. Drake y Héctor Pérez
Paradigmas de interacción
¿Qué función desempeña cada nodo
del sistema distribuido?
26/05/2015
3
RCSD: José M. Drake y Héctor Pérez
26/05/2015
DDS (Data Distribution Service for Real-Time Systems)
! Estándar para el desarrollo de sistemas distribuidos
" distribución centrada en los datos de acuerdo a una
interacción editor-subscriptor
" interoperabilidad
! multi-plataforma y multi-lenguaje
" soporta múltiples parámetros de calidad de servicio
(QoS)
" respaldado por un consorcio de empresas
4
RCSD: José M. Drake y Héctor Pérez
26/05/2015
Objetivo de DDS
! DDS proporciona un desacoplo completo entre los diferentes
elementos del sistema, en base a crear un concepto de
espacio virtual de datos:
“Applied OpenSplice”, Angelo Corsaro
5
RCSD: José M. Drake y Héctor Pérez
26/05/2015
Desacoplo de las particiones en cinco dimensiones
! Desacoplo espacial: Los proveedores y consumidores pueden estar
instalados en cualquier nodo del sistema.
! Desacoplo temporal: No se requiere sincronización entre los
proveedores y consumidores (los datos pueden ser consumidos
inmediatamente tras su publicación o más tarde).
! Desacoplo de flujo: las tasas de flujo de los datos en el editor y en
el subscriptor pueden ser diferentes aunque compatibles entre sí.
! Desacoplo de plataforma: Los proveedores y los consumidores
pueden estar ubicados en nodos con sistemas operativos diferentes
y estar codificados en lenguajes de programación diferentes.
! Desacoplo de multiplicidad: Pueden coexistir múltiples proveedores
o consumidores de un mismo tipo de datos en el sistema.
6
RCSD: José M. Drake y Héctor Pérez
26/05/2015
Visión general de un sistema distribuido con DDS
Participant: Son contenedores del resto de entidades que
permiten la comunicación dentro de un mismo dominio.
Topic: Representa la asociación de
un identificador con un tipo de dato
dentro de un dominio determinado.
7
RCSD: José M. Drake y Héctor Pérez
26/05/2015
Demostración de las características básicas de DDS
! RTI Shapes Demo
8
RCSD: José M. Drake y Héctor Pérez
26/05/2015
DDS: Demo (1/3)
! Distribución básica y anónima
" Las aplicaciones distribuidas que utilizan el paradigma
editor-subscriptor no requieren conocer el origen ni el
destino de los datos.
9
RCSD: José M. Drake y Héctor Pérez
26/05/2015
Despliegue y localización de entidades
! Se utiliza la estrategia “Anunciación/Descubrimiento”
" Los datos deben ser accesibles a todas las entidades
interesadas en ellos
! los editores no conocen a los subscriptores ni viceversa
! el editor se anuncia declarando la información que quiere
publicar a través de un topic
! de igual forma, el subscriptor se anuncia especificando el
dato que quiere recibir a través de un topic
! editores y subscriptores de un mismo topic se asocian
" el middleware facilita la asociación entre editores y
subscriptores de un mismo topic
10
RCSD: José M. Drake y Héctor Pérez
26/05/2015
DDS: Demo (2/3)
! Distribución básica y anónima
" Las aplicaciones distribuidas que utilizan el paradigma
editor-subscriptor no requieren conocer el origen ni el
destino de los datos
! Descubrimiento dinámico de entidades
" Las aplicaciones son responsables de proporcionar o
solicitar los datos, mientras el middleware establece la
comunicación de forma transparente.
11
RCSD: José M. Drake y Héctor Pérez
26/05/2015
DDS: Parámetros de QoS (Calidad de Servicio)
! DDS sigue el modelo de contrato para garantizar una calidad
de servicio en la comunicación:
" el editor establece los compromisos de publicación a través de los
parámetros QoS asociados
" El subscriptor establece los requisitos de recepción a través de los
parámetros QoS asociados
! El middleware solo establece la asociación editoressubscriptores si los QoS de ambos son compatibles
12
RCSD: José M. Drake y Héctor Pérez
DDS: Parámetros de QoS (Calidad de Servicio)
26/05/2015
13
RCSD: José M. Drake y Héctor Pérez
26/05/2015
DDS: Demo (3/3)
! Distribución básica y anónima
" Las aplicaciones distribuidas que utilizan el paradigma
editor-subscriptor no requieren conocer el origen ni el
destino de los datos
! Descubrimiento dinámico de entidades
" Las aplicaciones son responsables de proporcionar o
solicitar los datos, mientras el middleware establece la
comunicación de forma transparente.
! Tolerancia a fallos
" El middleware proporciona mecanismos para utilizar nodos
de backup en caso de fallos o degradación en la calidad de
servicio.
14
RCSD: José M. Drake y Héctor Pérez
26/05/2015
Ejemplos de uso (1/3)
TACTICOS Combat
System, Thales
15
RCSD: José M. Drake y Héctor Pérez
26/05/2015
Ejemplos de uso (2/3)
Control tráfico aéreo
(Canadá)
Vehículos no tripulados
(BASE TEN RoboScout)
Entornos de Simulación
16
RCSD: José M. Drake y Héctor Pérez
26/05/2015
Ejemplos de uso (3/3)
Sistema de control de metro
(Amsterdam)
Asistencia a la conducción
(Volswagen)
Red eléctrica inteligente
(Grand Coulee Dam)
17
RCSD: José M. Drake y Héctor Pérez
26/05/2015
Comparativa
Característica
RMI
DDS
Interacción
Cliente/Servidor
Editor/Subscriptor
Distribución
Objetos
Datos
Lenguajes
Java
Java, Ada, C, C++
Protocolo
TCP/IP
UDP/IP
QoS
-
Persistencia, Disponibilidad,
Tiempo Real, Entrega
Localización de
entidades
Servidor de nombres
Descubrimiento automático
Actualización del
sistema
Carga dinámica de clases
Extensión de Topics*
Seguridad en el
acceso al nodo
Gestor de seguridad
Delega en el SO

Documentos relacionados