Bus de datos frente a base de datos:las 6 preguntas que todo desarrollador de IIoT debe hacer

as interacciones son con su propia vista del espacio de datos. También tiene sentido, por ejemplo, escribir datos en un espacio sin destinatarios. En este caso, es posible que el bus de datos no haga absolutamente nada, o puede almacenar información en caché para su entrega posterior, según la configuración de QoS.

Tenga en cuenta que tanto las tecnologías de base de datos como de bus de datos reemplazan la interacción aplicación-aplicación con la interacción aplicación-datos-aplicación. Esta abstracción es absolutamente crítica. Desacopla las aplicaciones y facilita enormemente el escalado, la interoperabilidad y la integración del sistema. La diferencia es realmente una de los datos antiguos almacenados en una base de datos (probablemente centralizada), frente a los datos futuros enviados directamente a las aplicaciones desde un espacio de datos distribuido.

Pregunta 4:"La infraestructura comprende y, por lo tanto, puede filtrar selectivamente los datos". ¿No es eso cierto para todos los pub-sub, donde puede registrarse para "eventos" de su interés?

La mayoría de los pub-sub son muy primitivos. Una aplicación "registra interés", y luego todo se envía simplemente a esa aplicación. Entonces, por ejemplo, un algoritmo de detección de colisiones en intersecciones podría suscribirse a "posiciones de vehículos". Luego, la infraestructura envía mensajes desde cualquier sensor capaz de producir posiciones, sin conocimiento de los datos dentro de ese mensaje. Incluso pub-sub de "filtrado de contenido" ofrece solo especificaciones muy simples y requiere que el sistema preseleccione lo que es importante para todos. No hay un control real del flujo.

Un bus de datos es mucho más expresivo. Esa intersección podría decir "Solo me interesan las posiciones de los vehículos dentro de los 200 m, moviéndome a 10 m / s hacia mí. Si un vehículo cumple con mis especificaciones, debo actualizarlo 200 veces por segundo. Tú (el bus de datos) debes garantizarme que todos los sensores que alimentan este algoritmo prometen entregar datos tan rápido ... ni más lento ni más rápido. Si un sensor se actualiza 1000 veces por segundo, entonces solo me envía cada 5 actualizaciones. También necesito saber que realmente estás en contacto con -sensores en vivo (que defino como produciendo en los últimos 0.01 segundos) en todos los posibles accesos a la carretera en todo momento. Cada sensor debe poder almacenar 600 muestras antiguas (3 segundos) y actualizarme con esos datos antiguos si es necesario eso." (Estas son algunas de las más de 20 configuraciones de QoS en el estándar DDS).

Tenga en cuenta que una aplicación de suscripción en el caso primitivo pub-sub depende en gran medida de las propiedades reales de sus productores. De alguna manera tiene que confiar en que están vivos (!), Que tienen suficientes búferes para guardar la información que pueda necesitar, que no la inundarán de información ni la proporcionarán con demasiada lentitud. Si hay 10,000 autos siendo detectados 1000x / seg, pero solo 3 dentro de 200 m, tendrá que recibir 10,000 * 1000 =10m muestras por segundo solo para encontrar el 3 * 200 =600 al que debe prestar atención. Tendrá que hacer ping a cada sensor 100 veces por segundo solo para asegurarse de que esté activo. Si hay sensores redundantes en diferentes rutas, tiene que hacer ping a todos de forma independiente y de alguna manera asegurarse de que todas las rutas estén cubiertas. Si hay muchas aplicaciones, todas tienen que hacer ping a todos los sensores de forma independiente. También tiene que conocer el esquema de los productores, etc.

La aplicación en el segundo caso, por el contrario, recibirá exactamente las 600 muestras que le interesan, con la tranquilidad de saber que al menos un sensor para cada ruta está activo. El caudal está garantizado. Se garantiza una fiabilidad suficiente. El flujo de datos total se reduce en un 99,994% (solo necesitamos muestras de 600/10 m, y el middleware inteligente realiza el filtrado en la fuente). Para completar, tenga en cuenta que el algoritmo de colisión es completamente independiente de los propios sensores. Se puede reutilizar en cualquier otra intersección y funcionará con un sensor por ruta o 17. Si durante el tiempo de ejecución, la red se carga demasiado para cumplir con las especificaciones de datos (o algo falla), la aplicación será notificada de inmediato.

Pregunta 5:¿En qué se diferencia un bus de datos de un motor CEP?

Respuesta corta:un bus de datos es un concepto fundamentalmente distribuido que selecciona y entrega datos de productores locales que coinciden con una especificación simple. Un motor CEP es un servicio ejecutable centralizado que es capaz de especificaciones mucho más complejas, pero debe tener todos los flujos de datos enviados a un solo lugar.

Respuesta larga:un motor de procesamiento de eventos complejos (CEP) examina un flujo de datos entrante en busca de patrones que usted programe para identificar. Cuando encuentre uno de esos patrones, puede programarlo para que actúe. Los patrones pueden ser combinaciones complejas de datos futuros pasados ​​y entrantes. Sin embargo, es un servicio único que se ejecuta en una sola CPU en algún lugar. No transmite información.

Un bus de datos también busca patrones de datos. Sin embargo, las especificaciones son más sencillas; toma decisiones sobre cada elemento de datos a medida que se produce. Las acciones también son más sencillas; la única acción que puede tomar es enviar esos datos a un solicitante. El poder de un bus de datos es que se distribuye fundamentalmente. La búsqueda ocurre localmente en potencialmente cientos, miles o incluso millones de nodos. Por lo tanto, el bus de datos es una forma muy poderosa de seleccionar los datos correctos de las fuentes correctas y enviarlos a los lugares correctos. Un bus de datos es como un conjunto distribuido de motores CEP, uno para cada posible fuente de información, que son programados automáticamente por los usuarios de esa información. Por supuesto, el bus de datos tiene muchas otras propiedades más allá de la coincidencia de patrones, como la mediación de esquemas, la gestión de redundancia, el soporte de transporte, un protocolo interoperable, etc.

Pregunta 6:¿Qué aplicación impulsó el estándar DDS y los buses de datos?

Las primeras aplicaciones se encontraban en robots inteligentes, "superioridad de la información" y grandes sistemas coordinados como la gestión de combate naval. Estos sistemas necesitaban confiabilidad incluso cuando los componentes fallan, datos lo suficientemente rápidos para controlar los procesos físicos y descubrimiento selectivo y entrega a escala. La centralidad de datos realmente simplificó el código de la aplicación y las interfaces controladas, lo que permitió a los equipos de programadores trabajar en grandes sistemas de software a lo largo del tiempo. El estándar DDS es una familia de estándares activa y en crecimiento que originalmente fue impulsada tanto por proveedores como por clientes. Tiene un uso significativo en muchas verticales, incluidas la médica, el transporte, las ciudades inteligentes y la energía.

Si desea conocer cómo el software inteligente está arrasando con el IIoT, asegúrese de descargar nuestro documento técnico sobre el futuro de la industria automotriz, "El secreto de los autos autónomos".